Kubernetes v1.35: Kubelet Configuration Drop-in Directory Graduates to GA

Kubernetes v1.35: Kubelet Configuration Drop-in Directory Graduates to GA With the recent v1.35 release of Kubernetes, support for a kubelet configuration drop-in directory is generally available. The newly stable feature simplifies the management of kubelet configuration across large, heterogeneous clusters. With v1.35, the kubelet command line argument --config-dir is production-ready and fully supported, allowing you to specify a directory containing kubelet configuration drop-in files. All files in that directory will be automatically merged with your main kubelet configuration. This allows cluster administrators to maintain a cohesive base configuration for kubelets while enabling targeted customizations for different node groups or use cases, and without complex tooling or manual configuration management. The problem: managing kubelet configuration at scale As Kubernetes clusters grow larger and more complex, they often include heterogeneous node pools with different hardware capabilities, workload requirements, and operational constraints. This diversity necessitates different kubelet configurations across node groups-yet managing these varied configurations at scale becomes increasingly challenging. Several pain points emerge: Configuration drift : Different nodes may have slightly different configurations, leading to inconsistent behavior Node group customization : GPU nodes, edge nodes, and standard compute nodes often require different kubelet settings Operational overhead : Maintaining separate, complete configuration files for each node type is error-prone and difficult to audit Change management : Rolling out configuration changes across heterogeneous node pools requires careful coordination Before this support was added to Kubernetes, cluster administrators had to choose between using a single monolithic configuration file for all nodes, manually maintaining multiple complete configuration files, or relying on separate tooling. Each approach had its own drawbacks. This graduation to stable gives cluster administrators a fully supported fourth way to solve that challenge. Example use cases Managing heterogeneous node pools Consider a cluster with multiple node types: standard compute nodes, high-capacity nodes (such as those with GPUs or large amounts of memory), and edge nodes with specialized requirements. Base configuration File: 00-base.conf apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration clusterDNS: - "10.96.0.10" clusterDomain: cluster.local High-capacity node override File: 50-high-capacity-nodes.conf apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration maxPods: 50 systemReserved: memory: "4Gi" cpu: "1000m" Edge node override File: 50-edge-nodes.conf (edge compute typically has lower capacity) apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration evictionHard: memory.available: "500Mi" nodefs.available: "5%" With this structure, high-capacity nodes apply both the base configuration and the capacity-specific overrides, while edge nodes apply the base configuration with edge-specific settings. Gradual configuration rollouts When rolling out configuration changes, you can: Add a new drop-in file with a high numeric prefix (e.g., 99-new-feature.conf ) Test the changes on a subset of nodes Gradually roll out to more nodes Once stable, merge changes into the base configuration Viewing the merged configuration Since configuration is now spread across multiple files, you can inspect the final merged configuration using the kubelet's /configz endpoint: # 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 . This shows the actual configuration the kubelet is using after all merging has...

Preview: ~500 words