中文内容

已翻译official company source英文原文2025-12-22

Kubernetes v1.35：Kubelet 配置 Drop-in 目录功能正式 GA

By Sohan Kunkerkar (Red Hat) | Monday, December 22, 2025

随着 Kubernetes v1.35 版本的发布，kubelet 配置 Drop-in 目录功能现已达到一般可用（GA）状态。该稳定特性简化了在大型异构集群中对 kubelet 配置的管理。

在 v1.35 版本中，kubelet 命令行参数 --config-dir 已具备生产就绪能力并获得全面支持，允许您指定一个包含 kubelet 配置 Drop-in 文件的目录。该目录中的所有文件将自动与主 kubelet 配置文件合并。这使得集群管理员能够在维护统一的 kubelet 基础配置的同时，针对不同的节点组或使用场景进行定制化配置，且无需依赖复杂的工具或手动进行配置管理。

问题：大规模场景下的 kubelet 配置管理

随着 Kubernetes 集群规模不断扩大且日益复杂，集群通常包含具备不同硬件能力、工作负载要求和运维约束的异构节点池。这种多样性要求为不同节点组配置不同的 kubelet 参数，然而在大规模环境下管理这些差异化配置正变得愈发困难。主要面临以下痛点：

配置漂移：不同节点的配置可能存在细微差异，从而导致运行行为不一致
节点组定制化：GPU 节点、边缘节点与标准计算节点通常需要不同的 kubelet 设置
运维开销：为每种节点类型单独维护完整的配置文件不仅容易出错，且难以审计
变更管理：在异构节点池中推行配置变更需要仔细协调

在此支持加入 Kubernetes 之前，集群管理员只能在以下方案中做出选择：为所有节点使用单一的整体配置文件、手动维护多个完整的配置文件，或依赖独立工具。每种方案均有其局限性。该功能正式晋升为稳定版，为集群管理员提供了第四种受完整支持的解决方案来应对这一难题。

示例用例

管理异构节点池

假设一个集群包含多种节点类型：标准计算节点、高容量节点（如配备 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%"

在此结构下，高容量节点会同时应用基础配置与特定容量的覆盖设置，而边缘节点则应用基础配置及边缘专属设置。

配置渐进式发布

在推行配置变更时，您可以：

添加一个带有较大数字前缀的新 drop-in 文件（例如 99-new-feature.conf）
在部分节点上测试这些变更
逐步推广至更多节点
运行稳定后，将变更合并到基础配置中

查看合并后的配置

由于配置现已分散在多个文件中，您可以使用 kubelet 的 /configz 端点来检查最终合并的配置：

# Start kubectl proxy
kubectl proxy

# In another terminal, fetch the merged configuration
# Change the '<node-name>' placeholder before running the curl command
curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

这显示了 kubelet 在完成所有合并后实际使用的配置。合并后的配置还包含通过 kubelet 命令行参数指定的任何配置设置。

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

通过配置文件设置 Kubelet 参数
Kubelet 配置目录合并

最佳实践

使用 kubelet 配置的 drop-in 目录时：

逐步测试配置：在集群范围内推广之前，务必先在部分节点上测试新的 drop-in 配置，以最大限度降低风险
对 drop-in 配置进行版本控制：将 drop-in 配置文件与基础设施即代码一同纳入版本控制系统（或生成这些文件的配置源），以便跟踪变更并便于回滚
使用数字前缀以确保可预测的顺序：使用数字前缀（例如 00- 、50- 、90- ）为文件命名，以明确控制合并顺序，并使配置分层对其他管理员一目了然
注意临时文件：某些文本编辑器在编辑时会自动在同一目录下创建备份文件（如 .bak 、.swp 或带有 ~ 后缀的文件）。请确保配置目录中未遗留这些临时文件或备份文件，因为它们可能会被 kubelet 处理

致谢

此功能由 SIG Node 协作开发。特别感谢所有贡献者，在此功能从 v1.28 的 alpha 阶段，历经 v1.30 的 beta 阶段，直至 v1.35 进入 GA 阶段的全过程中，协助完成了设计、实现、测试和文档编写工作。

如需对该功能提供反馈，请加入 Kubernetes Node Special Interest Group，在公共 Slack 频道（#sig-node）参与讨论，或在 GitHub 上提交 issue。

参与贡献

如果您对 kubelet 配置管理有反馈或疑问，或者希望分享使用该功能的经验，请加入以下讨论：

SIG Node 社区页面
Kubernetes Slack 的 #sig-node 频道
SIG Node 邮件列表

SIG Node 非常希望了解您在生产环境中使用该功能的经验！

← 上一篇
下一步 →

Last modified January 03, 2026 at 3:42 PM PST: Reorganize 2025 blog content (0979e97a89)

Kubernetes v1.35：Kubelet 配置 drop-in 目录正式进入 GA 阶段