动态 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 如何“检查点”配置以及可能的故障模式的更多详细信息。

• ←上一页
下一页→