深刻分析Kubelet Bootstrap Checkpoint

Author: xidianwangtao@gmail.com , Version: Kubernetes 1.12

摘要：本文對Kubelet Bootstrap Checkpoint的使用方法、應用場景、工做機制及其代碼工做流程進行了全面分析，目前仍處於Alpha階段，不肯定性較大，但值得持續的關注它在self-hosted kubernetes, kubeadm upgrade, bootkube等方向的應用，相信Kubernetes的部署和升級還會變的更加簡單。

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的使用方法、應用場景、工做機制及其代碼工做流程進行了全面分析，目前仍處於Alpha階段，不肯定性較大，但值得持續的關注它在self-hosted kubernetes, kubeadm upgrade, bootkube等方向的應用，相信Kubernetes的部署和升級還會變的更加簡單。