Kubernetes 与 OpenYurt 无缝转换（命令式）

作者：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 信息
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 又干了些什么？

中心流程

整个 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​​

点击​​【此处】​​阅览网站原文。