共计 3605 个字符，预计需要花费 10 分钟才能阅读完成。
本篇内容介绍了“Kubelet Bootstrap Checkpoint 怎么应用”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
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 怎么应用”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
