浅析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-path，默认为""，意味着默认Disable。
给需要Bootstrap Checkpoint的Pods加上Annotation：node.kubernetes.io/bootstrap-checkpoint=true。

三、工作机制

kubelet启动时，在NewMainKubelet中会检查--bootstrap-checkpoint-path是否不为空，如果不为空，就会创建checkpointManager。

1.jpg

注：目前Bootstrap Checkpoint只是对本节点的特定Pods进行Checkpoint，并不包括其他Kubernetes Object的Checkpoint。

3.1 创建或更新pod

当kubelet开启了checkpoint功能，用户提交了创建pod的请求，经过kube-scheduler调度后，kubelet在开始pod的创建流程。kubelet在HandlePodAddtions()方法中遍历所有pod，使用podManager.AddPod()接口[AddPod()其实就是UpdatePod()]，此方法调用了checkpoint.WritePod()接口，首先会检查pod的annotation是否开启了checkpoint（node.kubernetes.io/bootstrap-checkpoint=true），对于满足条件的pod，写入对应的checkpoint文件中（Pod_UID.yaml），最后再调用dispatchWorker去创建pod。

同理，当pod.Spec有更新，kubelet按照如下调用链：HandlePodUpdates() ==> podManager.UpdatedPod() ==> checkpoint.WritePod()记录pod的checkponit文件。

如果checkpoint.WritePod()发生Error，可以在kubelet日志中看到，但是并不会引发流程异常，也就是说，Pod还会继续创建起来，只是checkpoint失败。

3.2 删除pod

删除过程同样类似，HandlePodRemoves() ==> podManager.DeletePod() ==> checkpoint.DeletePod()，checkpoint在删除pod时，会把pod对应的checkpoint文件也删除。删除不会像创建或者更新那样，先检查pod的annotation配置。

这样做的目的是，如果pod的annotation在某次更新操作后被删除，那么该pod的checkpoint文件将会产生残留。之后pod被删除，而kubelet发生了重启，将从checkpoint文件，把该pod恢复。当然，这个pod会在与kube-apiserver同步后得知被删除，然后kubelet会再次删除它。因此，删除pod时，即使pod不存在checkpoint文件，调用os.Remove()返回的IsNotExists错误并不会上报。

3.3 Kubelet重启

当kubelet发生冷重启时，会先检查--bootstrap-checkpoint-path是否配置，如果是，就会调用checkpoint.LoadPods()根据配置的目录下的所有Pod_UID.yaml格式的文件，并通过FNV Hash算法进行CheckSum检查。

检查通过后，将checkpoint yaml文件内容转换成Pod API Object，然后把这些Pod对象通过kubetypes.PodUpdate()类型的channel一直传递给Kubelet.syncLoopIteration()，最终由dispatchWork给Kubelet podWorkers去创建对应的Pod实例。

四、应用场景

4.1 self-hosted-kubernetes

对于k8s托管的kube-apiserver，kube-controller-manager，kube-scheduler，kubelet，etcd，adds-on组件进行升级、维护的场景。关于self-hosted-kubernetes的更多内容请参考Proposal: Self-hosted Control Plane，bootkube，kubeadm upgrade等都与此相关。这也是社区设计这一特性的主要动机。下图是bootkube的原理图。

2.png

那么，对于用户来说，部署普通应用时给Pod加上Annotation：node.kubernetes.io/bootstrap-checkpoint=true来给该Pod提供bootstrap checkpoint会带来什么好处吗？

对于用户而言，如果kube-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系统重启并长时间无法与kube-apiserver进行通信（比如apiserver升级失败），这将导致Node上无法运行DaemonSet Pod，那么这个Node上的cmdb agent就无法正常上报信息。对于这种情况，如果我们给这个DaemonSet Pod设置了对应Annotation和启用了Kubelet Bootstrap Checkpoint，那么kubelet可以在不依赖kube-apiserver的情况下，通过本地的checkpoint文件恢复之前备份的Pods。

因此，给一些per-node上的关键用户组件使用Bootstrap Checkpoint是有价值的。