作者：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.png]()
可见 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 信息
2. 如果某个 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 又干了些什么？
核心流程
![2.png]()
整个 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
点击【此处】阅读网站原文。
