这篇文章已超过一年。较早的文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
动态 Kubelet 配置
编者按：该功能在 1.22 版本中被弃用后，已在 1.24 版本中移除。
编者按：本文是关于 Kubernetes 1.11 新特性的系列深度文章之一。
为什么要进行动态 Kubelet 配置？
Kubernetes 提供了以 API 为中心的工具，显著改进了管理应用和基础设施的工作流程。然而，大多数 Kubernetes 安装都将 Kubelet 作为原生进程运行在每个宿主机上，这超出了标准 Kubernetes API 的范围。
过去，这意味着集群管理员和服务提供商无法依赖 Kubernetes API 在运行中的集群中重新配置 Kubelet。实际上，这需要操作员通过 SSH 连接到机器进行手动重新配置，使用第三方配置管理自动化工具，或者创建已安装所需配置的新虚拟机，然后将工作迁移到新机器上。这些方法依赖于特定环境且成本高昂。
动态 Kubelet 配置使集群管理员和服务提供商能够通过 Kubernetes API 在运行中的集群中重新配置 Kubelet。
什么是动态 Kubelet 配置？
Kubernetes v1.10 版本使得通过 beta 配置文件 API 配置 Kubelet 成为可能。
Kubernetes 已经提供了 ConfigMap 抽象，用于在 API 服务器中存储任意文件数据。
动态 Kubelet 配置扩展了 Node 对象，使得一个 Node 可以引用一个包含相同类型配置文件的 ConfigMap。当 Node 更新以引用新的 ConfigMap 时，相关的 Kubelet 将尝试使用新配置。
工作原理是什么？
- 动态 Kubelet 配置提供以下核心功能：
- Kubelet 尝试使用动态分配的配置。
- Kubelet 将配置“检查点”到本地磁盘，使得无需访问 API 服务器即可重启。
- Kubelet 在 Node 状态中报告已分配、活动的以及最后已知良好的配置来源。
当动态分配的配置无效时，Kubelet 会自动回退到最后已知良好配置，并在 Node 状态中报告错误。
要使用动态 Kubelet 配置功能，集群管理员或服务提供商首先需要提交一个包含所需配置的 ConfigMap，然后将每个 Node.Spec.ConfigSource.ConfigMap 引用设置为引用新的 ConfigMap。操作员可以按其偏好的速度更新这些引用，从而能够控制性地推出新配置。
每个 Kubelet 都会监视其关联的 Node 对象的更改。当 Node.Spec.ConfigSource.ConfigMap 引用更新时，Kubelet 将通过将其包含的文件写入本地磁盘来对新的 ConfigMap 进行“检查点”。然后 Kubelet 将退出，并且操作系统级别的进程管理器将重新启动它。请注意，如果 Node.Spec.ConfigSource.ConfigMap 引用未设置，Kubelet 将使用机器本地的标志和配置文件集。
重新启动后，Kubelet 将尝试使用新检查点的配置。如果新配置通过了 Kubelet 的内部验证，Kubelet 将更新 Node.Status.Config 以反映它正在使用新配置。如果新配置无效，Kubelet 将回退到其最后已知良好配置，并在 Node.Status.Config 中报告错误。
请注意，默认的最后已知良好配置是 Kubelet 命令行标志与 Kubelet 本地配置文件的组合。为了向后兼容性，与配置文件重叠的命令行标志始终优先于本地配置文件和动态配置。
有关单个节点配置更新的概览，请参阅下图：
如何了解更多？