共计 4249 个字符，预计需要花费 11 分钟才能阅读完成。
作者：adamzhoul，OpenYurt 成员
关上 openYurt 的 README.md，在简略介绍之后就是 Getting started:
yurtctl convert --provider [minikube|kubeadm|kind] // To convert an existing Kubernetes cluster to an OpenYurt cluster
yurtctl revert // To uninstall and revert back to the original cluster settings简略一行命令就可体验 OpenYurt 了，感觉十分不便。
稍等！为什么是 convert/revert 而不是 install/uninstall ?
这个命令对集群做了什么？
看来，在执行它之前有必要搞清楚它到底做了什么。
yurtctl convert 到底做了些什么？
外围流程
追随 openYurt 源代码（详情请见文末相干链接），梳理了 convert 的外围流程：
可见 1、2 并没有什么特地，只是惯例的服务部署。
3，则是对原有 k8s 零碎组件的操作，须要特地留神。
4，节点转换看着也并不简单，却对边缘至关重要。**
disable nodelifecycle controller 做了什么
工作内容：
1. 查问管制面节点
2. 创立 job，通过 nodeName: {{.nodeName}} 确保 job 的 pod 调度到对应 node 上执行(通过 nsenter 的形式执行，批改宿主机上文件)。
3. sed -i ‘s/–controllers=/–controllers=-nodelifecycle,/g’ /etc/kubernetes/manifests/kube-controller-manager.yaml
查看 kube-controller-manager.yaml
...
containers:
- command:
- kube-controller-manager
- --allocate-node-cidrs=true
...
- --controllers=-nodelifecycle,*,bootstrapsigner,tokencleaner
...可见，下面的一系列操作最终就是批改了 kube-controller-manager 的启动命令。
查看 kube-controller-manager 启动参数阐明：
–controllers 代表须要开启的 controller 列表\
可见，sed 命令就是去掉了 nodelifecycle 这个 controller。
那，nodelifecycle controller 是做什么的？
简略来说：
*1. 一直监听，kubelet 上报上来的 node 信息 \
- 如果某个 node 状态异样，或者说长时间没有上报等 \
2.1 驱赶这个 node 节点或者其余 —> 导致下面的 pod 被从新调度 *
可见，对于处于弱网环境的边缘节点，很容易就命中异样状态，导致 node 被驱赶，pod 被从新调度。
所以这里把它去掉了。应用 yurt-controller-manager 来代替它。
即便节点心跳失落，处于自治模式的节点中的 pod 也不会从 APIServer 中驱赶。
注：这里自治模式的节点，指的就是边缘节点。咱们通常会通过加 annotation 的形式把节点标记为自治节点。
节点转换是怎么实现的，云端节点和边缘节点有什么差别？
同样，是通过跑 job 的形式，在指标宿主机上下文中执行相干操作。
不过，相比于暴力应用 nsenter，这里用了更加优雅的形式。通过将宿主机根门路 volume 挂载到容器里的形式。
kubelet 的批改
在文件 /var/lib/kubelet/kubeadm-flags.env 中为 KUBELET_KUBEADM_ARGS 增加配置：
–kubeconfig=/var/lib/openyurt/kubelet.conf –bootstrap-kubeconfig=
作用：
1. 参数：–kubeconfig，给 kubelet 指定了拜访 apiServer 的配置文件。
2. 当 –kubeconfig 文件存在，–bootstrap-kubeconfig 为空时， kubelet 启动就不须要通过 bootstrap-token 置换文件证书等过程，间接读取 kubeconfig 文件拜访 apiServer。 *\
*
3. 因为 KUBELET_KUBEADM_ARGS 是 kubelet 启动参数的最初一部分，所以能够起到笼罩后面参数的作用。
其中 /var/lib/openyurt/kubelet.conf 内容如下，间接将流量指定到 yurthub：
apiVersion: v1
clusters:
- cluster:
server: http://127.0.0.1:10261
name: default-cluster
contexts:
- context:
cluster: default-cluster
namespace: default
user: default-auth
name: default-context
current-context: default-context
kind: Config
preferences: {}yurthub 的启动细节
yurthub 容器启动参数如下：
command:
- yurthub
- --v=2
- --server-addr=__kubernetes_service_addr__
- --node-name=$(NODE_NAME)
- --join-token=__join_token__
- --working-mode=__working_mode__通过参数咱们可看出：
1. server-addr 指定了云端 apiServer 地址。留神这里的地址肯定是公网可拜访地址，否则异构网络下会有问题。
2. join-token 就是退出节点的 token，可应用 kubeadm token create 来创立。k8s 提供机制，通过 token 置换出失常拜访的 kubeconf 文件。
3. working-mode：cloud/edge。这就是边缘节点和云端节点的差别。
咱们都晓得 yurthub 能够用来做缓存，是解决边缘自治的重要环节。那么云端为什么也须要部署？为什么还要辨别 edge 或者 cloud 工作模式？简略查看 yurthub 源代码 cmd/yurthub/app/start.go:
if cfg.WorkingMode == util.WorkingModeEdge {cacheMgr, err = cachemanager.NewCacheManager(cfg.StorageWrapper, cfg.SerializerManager, cfg.RESTMapperManager, cfg.SharedFactory)
...
} else {klog.Infof("%d. disable cache manager for node %s because it is a cloud node", trace, cfg.NodeName)
}
if cfg.WorkingMode == util.WorkingModeEdge {
...
gcMgr, err := gc.NewGCManager(cfg, restConfigMgr, stopCh)
} else {klog.Infof("%d. disable gc manager for node %s because it is a cloud node", trace, cfg.NodeName)
}可见，云端 yurthub，少做了 cache、GC 的工作。
查看 issue（详情请见文末相干链接）可理解：云端也能够利用 yurthub 提供的 data-filtering 能力来管制 service 的流量。
当然，云端也不须要做 cache 等工作。
命令行参数
在执行过程中，有几个参数比拟重要：
–cloud-nodes 用于标识哪些是云端节点，多个节点用逗号分隔：node1,node2
–deploy-yurttunnel 标记是否要部署 yurttunnel
–kubeadm-conf-path 标记节点机器上 kubeadm 配置文件门路。默认：/etc/systemd/system/kubelet.service.d/10-kubeadm.conf
更多参数，可应用 yurtctl convert –help 来查看。
总结
简略来说，convert 外围做了几个事件：
1. disable K8s 的 nodelifecontroller，用本人的 yurtcontrollermanager 来替换它的职责。
2. 装置本人的各类组件，deployment、damenonset 等模式部署。（这类资源部署无需任何放心，因为搞不坏集群，也不太会呈现问题。）
3. 边缘节点：启动 yurthub 动态 pod；将 kubelet 流量转发到 yurthub。
可见，convert 的事件还是比拟可控的。执行 yurtctl convert 也不必太放心。当然，最初的放心也应该由 yurtctl revert 来彻底消除！
yurtctl revert 又干了些什么？
外围流程
整个 revert 的过程就是 convert 的反向操作，还比拟好了解。
须要留神的是。如果 convert 失败，比方 job 执行超时或者失败。job 是不会被删除的。
即便 yurtctl revert 也不会删除。目标是为了保留现场不便定位问题。
如果须要从新执行 yurtctl convert，须要手动删除 job。
kubectl get job -n kube-system -A |grep convert
kubectl delete job -n kube-system < job-name>总结
yurtctl convert/revert 命令是最快捷体验 OpenYurt 性能的办法之一。
在理解了这两个命令的实现原理，也就对 OpenYurt 的技术计划理解大半了。
执行命令也不放心了，so easy！
相干链接
1）源代码：
https://github.com/openyurtio/openyurt/blob/5063752a9f6645270e3177e39a46df8c23145af2/pkg/yurtctl/cmd/convert/convert.go#L300
2）issue:
https://github.com/openyurtio/openyurt/issues/450
点击【此处】浏览网站原文。
