devops

Kubernetes v1.35：Kubelet 配置 Drop‑in 目录正式 GA

发布: (2025年12月23日 GMT+8 02:30)
8 min read
原文: Kubernetes Blog

Source: Kubernetes Blog

新增功能？

  • --config-dir 标志 现已完全支持。
  • 您可以将 kubelet 指向包含 多个配置文件 的目录。
  • 该目录中的所有文件将 自动合并 到主 kubelet 配置中。

为什么使用 Drop‑In 目录？

  • 集中式基础配置 – 为所有 kubelet 保持一套通用设置。
  • 针对性自定义 – 添加节点组特定的微调，而无需修改基础文件。
  • 简化管理 – 不需要复杂的工具或对每个节点进行手动编辑。

如何启用它

# 示例 kubelet systemd 单元（或静态 pod）片段
ExecStart=/usr/local/bin/kubelet \
  --config=/etc/kubernetes/kubelet-config.yaml \
  --config-dir=/etc/kubernetes/kubelet-config.d
  • --config 指向 主要 配置文件（基础文件）。
  • --config-dir 指向一个 目录（例如 /etc/kubernetes/kubelet-config.d），其中包含额外的 YAML 文件。

最佳实践

建议细节
描述性命名文件例如 01‑base.yaml、10‑gpu‑nodes.yaml、20‑custom‑metrics.yaml。
使用数字前缀确保合并顺序确定性。
验证配置在部署前，在测试节点上运行 kubelet --validate-config。
版本锁定在共享 drop‑in 目录的节点之间保持相同的 kubelet 版本，以避免模式不匹配。
备份将目录存放在版本控制（Git）中并定期备份。

示例目录布局

/etc/kubernetes/kubelet-config.d/
├── 01-base.yaml          # Common settings for all nodes
├── 10-gpu-nodes.yaml     # GPU‑specific flags (only applied to GPU nodes)
└── 20-custom-metrics.yaml# Extra metrics exporters

当 kubelet 启动时，它会按字典顺序合并这些文件（01‑base.yaml → 10‑gpu-nodes.yaml → 20‑custom-metrics.yaml），并应用生成的配置。

Source: …

问题：在大规模环境中管理 Kubelet 配置

随着 Kubernetes 集群规模日益扩大并变得更为复杂，它们通常包含具有不同硬件能力、工作负载需求和运营约束的异构节点池。这种多样性需要在不同节点组之间使用不同的 kubelet 配置——然而在大规模环境中管理这些多样化的配置变得越来越具有挑战性。

关键痛点

  • 配置漂移 – 节点配置之间的细微差异会导致行为不一致。
  • 节点组定制 – GPU 节点、边缘节点和标准计算节点各自需要专属的 kubelet 设置。
  • 运营开销 – 为每种节点类型维护独立的完整配置文件容易出错且难以审计。
  • 变更管理 – 在异构节点池中推送配置更新需要精细的协调。

之前的做法

在 Kubernetes 原生支持 kubelet 配置之前，管理员只能在以下几种方案中选择，其各自都有缺点：

  1. 单一整体配置 适用于所有节点 – 无法满足节点特定需求。
  2. 手动维护多个完整配置 – 高风险的漂移和审计困难。
  3. 外部工具或脚本 – 增加复杂性且通常缺乏与控制平面的集成。

新的解决方案

kubelet 配置支持升至 stable，为集群管理员提供了 第四种、完全受支持的方式，能够可靠且大规模地管理异构 kubelet 设置。

示例用例

管理异构节点池

考虑一个拥有多种节点类型的集群：

  • 标准计算节点
  • 高容量节点（例如 GPU 或大内存）
  • 边缘节点，具有特殊需求

基础配置

文件：00-base.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "10.96.0.10"
clusterDomain: cluster.local

高容量节点覆盖

文件：50-high-capacity-nodes.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 50
systemReserved:
  memory: "4Gi"
  cpu: "1000m"

边缘节点覆盖

文件：50-edge-nodes.conf – 边缘计算通常容量较低

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "5%"

结果：

  • 高容量节点加载基础配置 加上 高容量覆盖。
  • 边缘节点加载基础配置 加上 边缘特定覆盖。

渐进式配置发布

在发布配置更改时，遵循以下模式：

  1. 创建一个新的 drop‑in 文件，使用较高的数字前缀（例如 99-new-feature.conf）。
  2. 在少量节点上测试 这些更改。
  3. 逐步扩展 发布到更多节点。
  4. 当更改稳定后，将新设置合并 到基础配置中。

查看合并后的配置

由于配置现在分布在多个文件中，你可以通过 kubelet 的 /configz 接口检查最终的合并配置：

# 启动 kubectl 代理
kubectl proxy

# 在另一个终端获取合并后的配置
# 将 <node-name> 替换为你的节点名称
curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

输出显示 kubelet 在应用所有合并后实际使用的完整配置，包括通过 kubelet 命令行参数提供的任何设置。

有关详细的设置说明、配置示例以及合并行为，请参阅官方文档：

Source: …

良好实践

在使用 kubelet 配置 drop‑in 目录时：

  • 增量测试配置 – 在将新 drop‑in 配置推广到整个集群之前，始终先在一部分节点上进行测试，以降低风险。
  • 对 drop‑in 进行版本控制 – 将 drop‑in 配置文件（或生成它们的源文件）与基础设施即代码一起存入版本控制系统。这样可以跟踪更改并轻松回滚。
  • 使用数字前缀实现可预测的排序 – 为文件添加数字前缀（例如 00-、50-、90-），以显式控制合并顺序，并让其他管理员能够清晰地看到配置层叠关系。
  • 注意临时文件 – 某些文本编辑器在编辑时会在同一目录下自动创建备份文件（如 .bak、.swp，或以 ~ 为后缀的文件）。请确保这些临时或备份文件不会残留在配置目录中，因为它们可能会被 kubelet 处理。

致谢

此功能是通过 SIG Node 的协作努力开发的。特别感谢所有从 alpha 版本 v1.28、beta 版本 v1.30 到 GA 版本 v1.35 期间帮助设计、实现、测试和文档化该功能的贡献者。

反馈与讨论

参与

如果您对 kubelet 配置管理有反馈或疑问，或想分享使用此功能的经验，请加入讨论：

  • SIG Node 社区页面 – (link pending)
  • Kubernetes Slack – 加入 #sig-node 频道
  • SIG Node 邮件列表 – (link pending)

SIG Node 非常期待了解您在生产环境中使用此功能的经验！

Back to Blog

相关文章

阅读更多 »