深刻分析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的部署和升级还会变的更加简单。