动态 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 本地配置文件的组合。为了向后兼容，与配置文件重叠的命令行标志始终优先于本地配置文件和动态配置。

请参阅以下图表，了解单个节点的配置更新高级概述。

我如何了解更多信息？

请参阅官方教程 /docs/tasks/administer-cluster/reconfigure-kubelet/，其中包含更多关于用户工作流程、配置如何成为“最后一次已知良好配置”、Kubelet 如何“检查点”配置以及可能的故障模式的深入细节。

• ←上一篇
• 下一篇→