使用 kubeadm 配置集群中的每个 kubelet
特性状态: Kubernetes v1.11 [stable]
kubeadm CLI 工具的生命周期与 kubelet 解耦;kubelet 是一个守护程序,在 Kubernetes 集群中的每个节点上运行。 当 Kubernetes 初始化或升级时,kubeadm CLI 工具由用户执行,而 kubelet 始终在后台运行。
由于kubelet是守护程序,因此需要通过某种初始化系统或服务管理器进行维护。 当使用 DEB 或 RPM 安装 kubelet 时,配置系统去管理 kubelet。 你可以改用其他服务管理器,但需要手动地配置。
集群中涉及的所有 kubelet 的一些配置细节都必须相同, 而其他配置方面则需要基于每个 kubelet 进行设置,以适应给定机器的不同特性(例如操作系统、存储和网络)。 你可以手动地管理 kubelet 的配置,但是 kubeadm 现在提供一种 KubeletConfiguration
API 类型用于。
以下各节讲述了通过使用 kubeadm 简化 kubelet 配置模式,而不是在每个节点上手动地管理 kubelet 配置。
你可以通过 kubeadm init
和 kubeadm join
命令为 kubelet 提供默认值。 有趣的示例包括使用其他容器运行时或通过服务器设置不同的默认子网。
如果你想使用子网 10.96.0.0/12
作为服务的默认网段,你可以给 kubeadm 传递 --service-cidr
参数:
现在,可以从该子网分配服务的虚拟 IP。 你还需要通过 kubelet 使用 --cluster-dns
标志设置 DNS 地址。 在集群中的每个管理器和节点上的 kubelet 的设置需要相同。 kubelet 提供了一个版本化的结构化 API 对象,该对象可以配置 kubelet 中的大多数参数,并将此配置推送到集群中正在运行的每个 kubelet 上。 此对象被称为 KubeletConfiguration。 KubeletConfiguration
允许用户指定标志,例如用骆峰值代表集群的 DNS IP 地址,如下所示:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
- 10.96.0.10
有关 KubeletConfiguration
的更多详细信息,请参阅。
由于硬件、操作系统、网络或者其他主机特定参数的差异。某些主机需要特定的 kubelet 配置。 以下列表提供了一些示例。
除非你使用云驱动,否则默认情况下 Node API 对象的
.metadata.name
会被设置为计算机的主机名。 如果你需要指定一个与机器的主机名不同的节点名称,你可以使用--hostname-override
标志覆盖默认值。当前,kubelet 无法自动检测容器运行时使用的 cgroup 驱动程序, 但是值
--cgroup-driver
必须与容器运行时使用的 cgroup 驱动程序匹配,以确保 kubelet 的健康运行状况。要指定容器运行时,你必须用
--container-runtime-endpoint=<path>
标志来指定端点。
应用此类特定于实例的配置的推荐方法是使用 。
如果自定义的 API 对象使用像 kubeadm ... --config some-config-file.yaml
这样的配置文件进行传递,则可以配置 kubeadm 启动的 kubelet。
通过调用 kubeadm config print init-defaults --component-configs KubeletConfiguration
, 你可以看到此结构中的所有默认值。
也可以在基础 KubeletConfiguration
上应用实例特定的补丁。 阅读自定义 kubelet 来获取有关各个字段的更多信息。
当调用 kubeadm init
时,kubelet 的配置会被写入磁盘 , 并上传到集群 kube-system
命名空间的 kubelet-config
ConfigMap。 kubelet 配置信息也被写入 /etc/kubernetes/kubelet.conf
,其中包含集群内所有 kubelet 的基线配置。 此配置文件指向允许 kubelet 与 API 服务器通信的客户端证书。 这解决了将集群级配置传播到每个 kubelet 的需求。
针对的第二种模式, kubeadm 的解决方法是将环境文件写入 /var/lib/kubelet/kubeadm-flags.env
,其中包含了一个标志列表, 当 kubelet 启动时,该标志列表会传递给 kubelet 标志在文件中的显示方式如下:
除了启动 kubelet 时所使用的标志外,该文件还包含动态参数,例如 cgroup 驱动程序以及是否使用其他容器运行时套接字(--cri-socket
)。
systemctl daemon-reload && systemctl restart kubelet
如果重新加载和重新启动成功,则正常的 kubeadm init
工作流程将继续。
当运行 kubeadm join
时,kubeadm 使用 Bootstrap Token 证书执行 TLS 引导,该引导会获取一份证书, 该证书需要下载 kubelet-config
ConfigMap 并把它写入 /var/lib/kubelet/config.yaml
中。 动态环境文件的生成方式恰好与 kubeadm init
完全相同。
接下来,kubeadm
运行以下两个命令将新配置加载到 kubelet 中:
在 kubelet 加载新配置后,kubeadm 将写入 /etc/kubernetes/bootstrap-kubelet.conf
KubeConfig 文件中, 该文件包含 CA 证书和引导程序令牌。 kubelet 使用这些证书执行 TLS 引导程序并获取唯一的凭据,该凭据被存储在 /etc/kubernetes/kubelet.conf
中。
当 /etc/kubernetes/kubelet.conf
文件被写入后,kubelet 就完成了 TLS 引导过程。 Kubeadm 在完成 TLS 引导过程后将删除 /etc/kubernetes/bootstrap-kubelet.conf
文件。
kubeadm
中附带了有关系统如何运行 kubelet 的 systemd 配置文件。 请注意 kubeadm CLI 命令不会修改此文件。
通过 kubeadm
DEB 包 或者 安装的配置文件被写入 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
并由 systemd 使用。 它对原来的 RPM 版本 kubelet.service 或者 作了增强:
说明:
下面的内容只是一个例子。如果你不想使用包管理器, 请遵循没有包管理器) 章节的指南。
[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"
# 这是 "kubeadm init" 和 "kubeadm join" 运行时生成的文件,
# 这是一个文件,用户在不得已下可以将其用作替代 kubelet args。
# 用户最好使用 .NodeRegistration.KubeletExtraArgs 对象在配置文件中替代。
# KUBELET_EXTRA_ARGS 应该从此文件中获取。
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
此文件指定由 kubeadm 为 kubelet 管理的所有文件的默认位置。
- 用于 TLS 引导程序的 KubeConfig 文件为
/etc/kubernetes/bootstrap-kubelet.conf
, 但仅当/etc/kubernetes/kubelet.conf
不存在时才能使用。 - 具有唯一 kubelet 标识的 KubeConfig 文件为
/etc/kubernetes/kubelet.conf
。 - 包含 kubelet 的组件配置的文件为
/var/lib/kubelet/config.yaml
。 - 包含用户指定标志替代的文件
KUBELET_EXTRA_ARGS
是来源于/etc/default/kubelet
(对于 DEB),或者/etc/sysconfig/kubelet
(对于 RPM)。KUBELET_EXTRA_ARGS
在标志链中排在最后,并且在设置冲突时具有最高优先级。