Kubelet Bootstrap Checkpoint怎么應用

本篇內容介紹了“Kubelet Bootstrap Checkpoint怎么應用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Kubelet Bootstrap Checkpoint是什么

Kubelet Bootstrap Checkpoint是kubelet對特定的Pods的進行備份、恢復的kubelet內置模塊。

• Kubelet Bootstrap Checkpoint是對當前Node上帶有Annotation:node.kubernetes.io/bootstrap-checkpoint=true的Pods的Checkpoint到文件系統機制。

• 當kubelet重啟時，會檢查checkpoint目錄下各個Pods對應的checkpoint文件,加載所有的checkpoint文件，轉換成Pod Object，然后啟動這些Pods。

Kubelet Bootstrap Checkpoint應用場景

看起來似乎有點像static pod的使用方式：根據某個目錄下Pod的描述文件，kubelet監控這些文件，根據文件的變更與否，決定是否刪除、創建、更新對應的Pods。又或者有點像DaemonSet的使用場景。

最大的不同是，Kubelet Bootstrap Checkpoint是會對特定Pods的checkpoint，如果Pods通過API發生變更或者創建，那么最新的Pod數據會寫入到Pod對應的checkpoint文件中，Pod對應的checkpoint文件名格式是Pod_UID.yaml，存放的內容是完整的Pod API Object的Yaml格式內容，包括Status。

Kubelet Bootstrap Checkpoint主要的應用場景：

• self-hosted-kubernetes用來對k8s托管的apiserver,controller-manager,scheduler,kubelet,etcd,Adds-on組件進行升級、維護的場景。關于self-hosted-kubernetes的更多內容請參考self-hosted-kubernetes design-proposals，bootkube, kubeadm upgrade等都與此相關。這也是社區設計這一特性的主要動機。下圖是bootkube的原理圖。

那么，對于用戶來說，部署普通應用時給Pod加上Annotation:node.kubernetes.io/bootstrap-checkpoint=true來給該Pod提供bootstrap checkpoint會帶來什么好處嗎？

對于用戶而言，如果apiserver能正常訪問，那么bootstrap checkpoint確實沒有什么用處，因為etcd中已經有Pods API Object信息了，checkpoint就顯得多此一舉了。如果checkpoint文件和etcd中數據存在不一致的情況，反而會導致Pod先通過checkpoint恢復后，很快又根據etcd中Object Info進行重建的問題。

但是，對于Node上一些特殊的常駐Agent，比如cmdb agent，需要定期上報Node的狀態等信息，以DaemonSet Pod方式運行在Node上，如果在對Kubernetes進行升級時方式不對或者不順暢，Node系統重啟并長時間無法與apiserver進行通信（比如apiserver升級失敗），這將導致Node上無法運行DaemonSet Pod，那么這個Node上的cmdb agent就無法正常上報信息。對于這種情況，如果我們給這個DaemonSet Pod設置了對應Annotation和啟用了Kubelet Bootstrap Checkpoint，那么kubelet可以在不依賴apiserver的情況下，通過本地的checkpoint文件恢復之前備份的Pods。

因此，給一些per-node上的關鍵用戶組件使用Bootstrap Checkpoint是有價值的。

怎么啟用Kubelet Bootstrap Checkpoint

• Kubelet啟動參數中配置--bootstrap-checkpoint-path，默認為“”，意味著默認Disable。

• 給需要Bootstrap Checkpoint的Pods加上Annotation:node.kubernetes.io/bootstrap-checkpoint=true。

Bootstrap Checkpoint工作機制

• kubelet啟動時，在NerMainKubelet中會檢查--bootstrap-checkpoint-path是否不為空，如果不為空，就會創建checkpointManager。

創建或者變更Pod

• 當用戶提交創建Pod請求后，經過scheduler調度，最后由kubelet發現調度到本節點，由kubelet開始Pod的創建流程。

• checkpointManager不為空的情況下，kubelet會檢查Pod是都有Annotation:node.kubernetes.io/bootstrap-checkpoint=true，kubelet在HandlePodAddtions時會遍歷所有Pods，在dispatchWorker去創建Pod前，PodManager會調用checkpoint.WritePod接口先將滿足Annotation的Pods寫入到它們對應的checkpoint文件(Pod_UID.yaml)中。

• 同樣的，當Pod Spec發生變更，kubelet通過HandlePodUpdates遍歷所有Pods，由PodManager調用checkpoint.WritePod接口將滿足Annotation的Pods最新內容寫入到它們對應的的checkpoint文件中。

• 如果checkpoint.WritePod發生Error，可以在kubelet日志中看到，但是并不會引發流程異常，也就是說，Pod還會繼續創建起來，但是checkpoint失敗。

刪除Pod

• 當用戶提交刪除Pod請求后，kubelet通過HandlePodRemove遍歷所有Pods，由PodManager調用checkpoint.DeletePod接口將Pod對應的checkpoint文件刪除。

• 如果Pod對應的checkpoint文件不存在，不會有異常返回，也不應該有異常返回。

• 如果Pod對應的checkpoint文件存在，但是刪除失敗，那么會有kubelet Error日志，但是流程不會失敗。

注意，這里并不會去檢查Pod的Annotation是否滿足條件，而是對所有Pods都試圖去刪除對個格式的文件名。為什么不先檢查Annotation呢？這樣性能不是會更高么？試想一下這種場景，Pod的Checkpoint Annotation在變更時被刪除了，那么他的checkpoint文件就會被殘留。之后該Pod被刪除了，然后kubelet發生重啟時，還會從checkpoint中恢復這個已經被刪除的Pod，這很糟糕。當然，很快這個Pod會從apiserver中同步中知道已經被刪除了，然后kubelet再次刪除這個Pod.

Kubelet重啟

• 當kubelet發生冷重啟時，會先檢查--bootstrap-checkpoint-path是否配置了，如果是，就會調用checkpoint.LoadPods根據配置的目錄下的所有Pod_UID.yaml格式的文件，并通過FNV Hash算法進行CheckSum檢查。

• 檢查通過后，將checkpoint yaml文件內容轉換成Pod API Object，然后把這些Pods對象通過kubetypes.PodUpdate類型的channel一直傳遞給Kubelet.syncLoopIteration，最終由dispatch給Kubelet podWorkers去創建對應的Pods實例。

Bootstrap Checkpoint工作流

Bootstrap Checkpoint的代碼很簡單，也不多，這里直接貼出對應的代碼流程概要圖。

其他注意事項

• 目前Bootstrap Checkpoint只是對本節點的特定Pods進行Checkpoint，并不包括其他Kubernetes Object的Checkpoint。

• 更不是對kubelet內存數據的Checkpoint。這些都不是它想做的事，更不是應該做的事，集群狀態存儲的地方越多，問題就會越多。

“Kubelet Bootstrap Checkpoint怎么應用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！