动态Kubelet配置

作者:迈克尔·陶芬(Google)

编者注:这篇文章是 系列深入文章 Kubernetes 1.11的新功能

为什么要进行动态Kubelet配置?

Kubernetes提供了以API为中心的工具,可显着改善用于管理应用程序和基础架构的工作流程。但是,大多数Kubernetes安装都在标准Kubernetes API范围之外,将Kubelet作为本机进程在每个主机上运行。

过去,这意味着集群管理员和服务提供商无法依靠Kubernetes API在活动集群中重新配置Kubelets。实际上,这要求操作员要么转入计算机以执行手动重新配置,要么使用第三方配置管理自动化工具,要么创建已经安装了所需配置的新VM,然后将工作迁移到新计算机上。这些方法是特定于环境的,并且可能很昂贵。

动态Kubelet配置使集群管理员和服务提供商能够通过Kubernetes API在活动集群中重新配置Kubelet。

什么是动态Kubelet配置?

Kubernetes v1.10使得可以通过beta配置Kubelet 配置文件 API。 Kubernetes已经提供了ConfigMap抽象,用于在API服务器中存储任意文件数据。

动态Kubelet配置扩展了Node对象,以便Node可以引用包含相同类型配置文件的ConfigMap。当节点更新为引用新的ConfigMap时,关联的Kubelet将尝试使用新的配置。

它是如何工作的?

动态Kubelet配置提供以下核心功能:

  • Kubelet尝试使用动态分配的配置。
  • Kubelet将“检查点”配置到本地磁盘,从而无需API服务器访问即可重新启动。
  • Kubelet报告“节点”状态中已分配,活动和最后一次已知良好的配置源。
  • 动态分配了无效的配置后,Kubelet会自动退回到最后一次正确的配置,并报告节点状态中的错误。

要使用动态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的本地配置文件的组合。与配置文件重叠的命令行标志始终优先于本地配置文件和动态配置,以实现向后兼容。

有关单个节点的配置更新的高级概述,请参见下图:

kubelet-diagram

我该如何学习?

请参阅/ docs / tasks / administer-cluster / reconfigure-kubelet /上的官方教程,其中包含有关用户工作流,配置如何变为“最后一个好”,Kubelet如何“检查点”配置的更多详细信息。 ,以及可能的故障模式。