使用 kubeadm 配置集群中的每个 kubelet

kubeadm CLI 工具的生命周期与 kubelet 分离，kubelet 是在 Kubernetes 集群中的每个节点上运行的守护进程。kubeadm CLI 工具由用户在初始化或升级 Kubernetes 时执行，而 kubelet 则始终在后台运行。

由于 kubelet 是一个守护进程，因此需要通过某种初始化系统或服务管理器对其进行维护。当使用 DEB 或 RPM 安装 kubelet 时，systemd 会被配置为管理 kubelet。您可以使用不同的服务管理器，但需要手动配置它。

一些 kubelet 配置细节需要在参与集群的所有 kubelet 中保持一致，而其他配置方面需要在每个 kubelet 的基础上进行设置，以适应给定机器的不同特性（例如操作系统、存储和网络）。您可以手动管理 kubelet 的配置，但 kubeadm 现在提供了一个 KubeletConfiguration API 类型，用于 集中管理 kubelet 配置。

Kubelet 配置模式

以下部分描述了通过使用 kubeadm 而不是手动管理每个节点的 kubelet 配置来简化 kubelet 配置的模式。

将集群级别配置传播到每个 kubelet

您可以为 kubelet 提供默认值，这些值将由 kubeadm init 和 kubeadm join 命令使用。有趣示例包括使用不同的容器运行时或设置服务使用的默认子网。

如果您希望您的服务使用 10.96.0.0/12 作为服务的默认子网，您可以将 --service-cidr 参数传递给 kubeadm

kubeadm init --service-cidr 10.96.0.0/12

服务的虚拟 IP 现在从此子网分配。您还需要设置 kubelet 使用的 DNS 地址，使用 --cluster-dns 标志。此设置需要对于集群中每个管理器和每个节点上的每个 kubelet 保持一致。kubelet 提供了一个版本化的、结构化的 API 对象，可以配置 kubelet 中的大多数参数，并将此配置推送到集群中的每个正在运行的 kubelet。此对象称为 KubeletConfiguration。KubeletConfiguration 允许用户指定诸如以驼峰式大小写键表示的集群 DNS IP 地址列表等标志，如下例所示

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10

有关 KubeletConfiguration 的更多详细信息，请参阅 此部分。

提供特定于实例的配置细节

由于硬件、操作系统、网络或其他主机特定参数的差异，某些主机需要特定的 kubelet 配置。以下列表提供了一些示例。

• 由 kubelet 配置标志 --resolv-conf 指定的 DNS 解析文件的路径可能因操作系统而异，或者取决于您是否使用 systemd-resolved。如果此路径不正确，则配置错误的节点的 DNS 解析将失败。

• 节点 API 对象 .metadata.name 默认设置为机器的主机名，除非您正在使用云提供商。您可以使用 --hostname-override 标志来覆盖默认行为，如果您需要指定与机器主机名不同的节点名称。

• 目前，kubelet 无法自动检测容器运行时使用的 cgroup 驱动程序，但 --cgroup-driver 的值必须与容器运行时使用的 cgroup 驱动程序匹配，以确保 kubelet 的正常运行。

• 要指定容器运行时，您必须使用 --container-runtime-endpoint=<path> 标志设置其端点。

应用此类特定于实例的配置的推荐方法是使用 KubeletConfiguration 补丁。

使用 kubeadm 配置 kubelet

如果传递了带有配置文件（例如 kubeadm ... --config some-config-file.yaml）的自定义 KubeletConfiguration API 对象，则可以配置 kubeadm 将启动的 kubelet。

通过调用 kubeadm config print init-defaults --component-configs KubeletConfiguration，您可以查看此结构的默认值。

也可以在基础 KubeletConfiguration 上应用特定于实例的补丁。有关更多详细信息，请参阅 自定义 kubelet。

使用 kubeadm init 时的工作流程

当您调用 kubeadm init 时，kubelet 配置将被编组到磁盘上的 /var/lib/kubelet/config.yaml，并上传到集群的 kube-system 命名空间中的 kubelet-config ConfigMap。此外，kubeadm 工具检测节点上的 CRI socket 并将其详细信息（包括 socket 路径）写入本地配置 /var/lib/kubelet/instance-config.yaml。kubelet 配置文件的文件也写入 /etc/kubernetes/kubelet.conf，其中包含集群中所有 kubelet 的基线集群范围配置。此配置文件指向允许 kubelet 与 API 服务器通信的客户端证书。这解决了 将集群级别配置传播到每个 kubelet 的需求。

为了解决 提供特定于实例的配置细节 的第二个模式，kubeadm 将一个环境变量文件写入 /var/lib/kubelet/kubeadm-flags.env，其中包含一个要传递给 kubelet 在其启动时使用的标志列表。文件中的标志呈现方式如下

KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."

除了用于启动 kubelet 的标志外，该文件还包含诸如 cgroup 驱动程序之类的动态参数。

将这两个文件编组到磁盘后，kubeadm 尝试运行以下两个命令（如果您正在使用 systemd）

systemctl daemon-reload && systemctl restart kubelet

如果重新加载和重新启动成功，则正常的 kubeadm init 工作流程将继续。

使用 kubeadm join 时的工作流程

当您运行 kubeadm join 时，kubeadm 使用 Bootstrap Token 凭证执行 TLS bootstrap，该 bootstrap 获取下载 kubelet-config ConfigMap 所需的凭证，并将其写入 /var/lib/kubelet/config.yaml。此外，kubeadm 工具检测节点上的 CRI socket 并将其详细信息（包括 socket 路径）写入本地配置 /var/lib/kubelet/instance-config.yaml。动态环境变量文件以与 kubeadm init 相同的方式生成。

接下来，kubeadm 运行以下两个命令以将新配置加载到 kubelet 中

systemctl daemon-reload && systemctl restart kubelet

在 kubelet 加载新配置后，kubeadm 写入 /etc/kubernetes/bootstrap-kubelet.conf KubeConfig 文件，其中包含 CA 证书和 Bootstrap Token。这些由 kubelet 用于执行 TLS Bootstrap 并获取唯一的凭证，该凭证存储在 /etc/kubernetes/kubelet.conf 中。

写入 /etc/kubernetes/kubelet.conf 文件后，kubelet 完成执行 TLS Bootstrap。kubeadm 在完成 TLS Bootstrap 后删除 /etc/kubernetes/bootstrap-kubelet.conf 文件。

systemd 的 kubelet drop-in 文件

kubeadm 附带有关 systemd 应该如何运行 kubelet 的配置。请注意，kubeadm CLI 命令永远不会触及此 drop-in 文件。

由 kubeadm 包 安装到 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf 的此配置文件由 systemd 使用。它增强了基本的 kubelet.service。

如果您想进一步覆盖它，可以在 /etc/systemd/system/kubelet.service.d/（而不是 /usr/lib/systemd/system/kubelet.service.d/）中创建一个目录，并将您自己的自定义项放入该目录中的一个文件中。例如，您可以添加一个新的本地文件 /etc/systemd/system/kubelet.service.d/local-overrides.conf 以覆盖 kubeadm 配置的单元设置。

以下是您可能在 /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf 中找到的内容

[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
# the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

此文件指定 kubeadm 为 kubelet 管理的所有文件的默认位置。

• 用于 TLS Bootstrap 的 KubeConfig 文件是 /etc/kubernetes/bootstrap-kubelet.conf，但仅当 /etc/kubernetes/kubelet.conf 不存在时才使用。
• 具有唯一 kubelet 身份的 KubeConfig 文件是 /etc/kubernetes/kubelet.conf。
• 包含 kubelet 的 ComponentConfig 的文件是 /var/lib/kubelet/config.yaml。
• 包含 KUBELET_KUBEADM_ARGS 的动态环境文件来源于 /var/lib/kubelet/kubeadm-flags.env。
• 可以包含用户指定的标志覆盖的 KUBELET_EXTRA_ARGS 文件来源于 /etc/default/kubelet（对于 DEB），或 /etc/sysconfig/kubelet（对于 RPM）。 KUBELET_EXTRA_ARGS 在标志链中处于最后位置，并且在设置冲突时具有最高优先级。

Kubernetes 二进制文件和软件包内容

Kubernetes 版本发布的 DEB 和 RPM 软件包是