作者：adamzhoul，OpenYurt 成員

打開 openYurt 的 README.md，在簡單介紹之后就是 Getting started:

yurtctl convert --provider [minikube|kubeadm|kind] // To convert an existing Kubernetes cluster to an OpenYurt clusteryurtctl revert // To uninstall and revert back to the original cluster settings

簡單一行命令就可體驗(yàn) OpenYurt 了，感覺非常方便。

稍等！為什么是 convert/revert 而不是 install/uninstall ?

這個(gè)命令對集群做了什么？

看來，在執(zhí)行它之前有必要搞清楚它到底做了什么。

yurtctl convert 到底做了些什么？

核心流程

跟隨 openYurt 源代碼（詳情請見文末相關(guān)鏈接），梳理了 convert 的核心流程：

可見 1、2 并沒有什么特別，只是常規(guī)的服務(wù)部署。

3，則是對原有 k8s 系統(tǒng)組件的操作，需要特別注意。

4，節(jié)點(diǎn)轉(zhuǎn)換看著也并不復(fù)雜，卻對邊緣至關(guān)重要。****

disable nodelifecycle controller 做了什么

工作內(nèi)容：

1. 查詢控制面節(jié)點(diǎn)

2. 創(chuàng)建 job，通過nodeName: {{.nodeName}} 確保 job 的 pod 調(diào)度到對應(yīng) node 上執(zhí)行(通過 nsenter 的方式執(zhí)行，修改宿主機(jī)上文件)。

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 的啟動(dòng)命令。

查看 kube-controller-manager 啟動(dòng)參數(shù)說明：

–controllers 代表需要開啟的controller列表\

可見，sed 命令就是去掉了 nodelifecycle 這個(gè) controller。

那，nodelifecycle controller 是做什么的？

簡單來說：

1. 不斷監(jiān)聽，kubelet 上報(bào)上來的 node 信息
2. 如果某個(gè) node 狀態(tài)異常，或者說長時(shí)間沒有上報(bào)等
?2.1 驅(qū)逐這個(gè) node 節(jié)點(diǎn)或者其他 —> 導(dǎo)致上面的 pod 被重新調(diào)度

可見，對于處于弱網(wǎng)環(huán)境的邊緣節(jié)點(diǎn)，很容易就命中異常狀態(tài)，導(dǎo)致 node 被驅(qū)逐，pod 被重新調(diào)度。

所以這里把它去掉了。使用 yurt-controller-manager 來代替它。

即使節(jié)點(diǎn)心跳丟失，處于自治模式的節(jié)點(diǎn)中的 pod 也不會(huì)從 APIServer 中驅(qū)逐。

注：這里自治模式的節(jié)點(diǎn)，指的就是邊緣節(jié)點(diǎn)。我們通常會(huì)通過加 annotation 的方式把節(jié)點(diǎn)標(biāo)記為自治節(jié)點(diǎn)。

節(jié)點(diǎn)轉(zhuǎn)換是怎么實(shí)現(xiàn)的，云端節(jié)點(diǎn)和邊緣節(jié)點(diǎn)有什么差異？

同樣，是通過跑 job 的方式，在目標(biāo)宿主機(jī)上下文中執(zhí)行相關(guān)操作。

不過，相比于暴力使用 nsenter，這里用了更加優(yōu)雅的方式。通過將宿主機(jī)根路徑 volume 掛載到容器里的方式。

kubelet 的修改

在文件/var/lib/kubelet/kubeadm-flags.env 中為 KUBELET_KUBEADM_ARGS 添加配置：

–kubeconfig=/var/lib/openyurt/kubelet.conf --bootstrap-kubeconfig=

作用：

?1. 參數(shù)：–kubeconfig ， 給kubelet指定了訪問apiServer的配置文件。 ?

?2. 當(dāng)–kubeconfig 文件存在，–bootstrap-kubeconfig為空時(shí)， ?? kubelet 啟動(dòng)就不需要通過 bootstrap-token 置換文件證書等過程，直接讀取 kubeconfig 文件訪問 apiServer。 ?*
*

?3. 由于 KUBELET_KUBEADM_ARGS 是 kubelet 啟動(dòng)參數(shù)的最后一部分，所以可以起到覆蓋前面參數(shù)的作用。 ?

其中??/var/lib/openyurt/kubelet.conf??內(nèi)容如下，直接將流量指定到 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 的啟動(dòng)細(xì)節(jié)

yurthub 容器啟動(dòng)參數(shù)如下：

command: - yurthub - --v=2 - --server-addr=__kubernetes_service_addr__ - --node-name=$(NODE_NAME) - --join-token=__join_token__ - --working-mode=__working_mode__

通過參數(shù)我們可看出：

?1. server-addr 指定了云端 apiServer 地址。注意這里的地址一定是公網(wǎng)可訪問地址，否則異構(gòu)網(wǎng)絡(luò)下會(huì)有問題。 ?

?2. join-token 就是加入節(jié)點(diǎn)的 token，可使用kubeadm token create來創(chuàng)建。k8s 提供機(jī)制，通過 token 置換出正常訪問的 kubeconf 文件。 ?

?3. working-mode：cloud/edge。這就是邊緣節(jié)點(diǎn)和云端節(jié)點(diǎn)的差異。 ?

我們都知道 yurthub 可以用來做緩存，是解決邊緣自治的重要環(huán)節(jié)。那么云端為什么也需要部署？為什么還要區(qū)分 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（詳情請見文末相關(guān)鏈接）可了解：云端也可以利用 yurthub 提供的 data-filtering 能力來控制 service 的流量。

當(dāng)然，云端也不需要做 cache 等工作。

命令行參數(shù)

在執(zhí)行過程中，有幾個(gè)參數(shù)比較重要：

–cloud-nodes 用于標(biāo)識(shí)哪些是云端節(jié)點(diǎn)，多個(gè)節(jié)點(diǎn)用逗號分隔：node1,node2

–deploy-yurttunnel 標(biāo)記是否要部署 yurttunnel

–kubeadm-conf-path 標(biāo)記節(jié)點(diǎn)機(jī)器上 kubeadm 配置文件路徑。默認(rèn)：/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

更多參數(shù)，可使用 yurtctl convert --help 來查看。

總結(jié)

簡單來說，convert 核心做了幾個(gè)事情：

?1. disable K8s 的 nodelifecontroller，用自己的 yurtcontrollermanager 來替換它的職責(zé)。 ?

?2. 安裝自己的各類組件，deployment、damenonset 等模式部署。（這類資源部署無需任何擔(dān)心，因?yàn)楦悴粔募?#xff0c;也不太會(huì)出現(xiàn)問題。） ?

?3. 邊緣節(jié)點(diǎn)：啟動(dòng) yurthub 靜態(tài) pod；將 kubelet 流量轉(zhuǎn)發(fā)到 yurthub。 ?

可見，convert 的事情還是比較可控的。執(zhí)行 yurtctl convert 也不用太擔(dān)心。當(dāng)然，最后的擔(dān)心也應(yīng)該由 yurtctl revert 來徹底消除！

yurtctl revert 又干了些什么？

核心流程

整個(gè) revert 的過程就是 convert 的反向操作，還比較好理解。

需要注意的是。如果 convert 失敗，比如 job 執(zhí)行超時(shí)或者失敗。job 是不會(huì)被刪除的。

即使 yurtctl revert 也不會(huì)刪除。目的是為了保留現(xiàn)場方便定位問題。

如果需要重新執(zhí)行 yurtctl convert， 需要手動(dòng)刪除 job。

kubectl get job -n kube-system -A |grep convert kubectl delete job -n kube-system < job-name>

總結(jié)

yurtctl convert/revert 命令是最快捷體驗(yàn) OpenYurt 功能的方法之一。

在了解了這兩個(gè)命令的實(shí)現(xiàn)原理，也就對 OpenYurt 的技術(shù)方案了解大半了。

執(zhí)行命令也不擔(dān)心了，so easy！

相關(guān)鏈接

1）源代碼：

??https://github.com/openyurtio/openyurt/blob/5063752a9f6645270e3177e39a46df8c23145af2/pkg/yurtctl/cmd/convert/convert.go#L300??

2）issue:

??https://github.com/openyurtio/openyurt/issues/450??

點(diǎn)擊??【此處】??閱讀網(wǎng)站原文。

總結(jié)

以上是生活随笔為你收集整理的Kubernetes 与 OpenYurt 无缝转换（命令式）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。