|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "Kubernetes v1.35: Kubelet Configuration Drop-in Directory Graduates to GA" |
| 4 | +date: 2025-10-23 |
| 5 | +draft: true |
| 6 | +slug: kubelet-config-drop-in-directory-ga |
| 7 | +author: > |
| 8 | + Sohan Kunkerkar (Red Hat) |
| 9 | +--- |
| 10 | + |
| 11 | +Announcing the graduation to General Availability (GA) of the Kubelet Configuration Drop-in Directory feature in Kubernetes v1.35! |
| 12 | + |
| 13 | +The Kubernetes SIG Node team is excited to announce that the Kubelet Configuration Drop-in Directory feature, first introduced as alpha in Kubernetes v1.28 and promoted to beta in v1.30, has now reached GA status and is officially part of the Kubernetes v1.35 release. This enhancement significantly simplifies the management of kubelet configurations across large, heterogeneous Kubernetes clusters. |
| 14 | + |
| 15 | +With v1.35, the `--config-dir` flag is production-ready and fully supported, allowing you to specify a directory containing kubelet configuration drop-in files that will be automatically merged with your main kubelet configuration. This allows cluster administrators to maintain a cohesive base kubelet configuration while enabling targeted customizations for different node groups or use cases, without complex tooling or manual configuration management. |
| 16 | + |
| 17 | +## The problem: Managing kubelet configuration at scale |
| 18 | + |
| 19 | +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: |
| 20 | + |
| 21 | +- **Configuration drift**: Different nodes may have slightly different configurations, leading to inconsistent behavior |
| 22 | +- **Node group customization**: GPU nodes, edge nodes, and standard compute nodes often require different kubelet settings |
| 23 | +- **Operational overhead**: Maintaining separate, complete configuration files for each node type is error-prone and difficult to audit |
| 24 | +- **Change management**: Rolling out configuration changes across heterogeneous node pools requires careful coordination |
| 25 | + |
| 26 | +Previously, cluster administrators had to choose between using a single monolithic configuration file for all nodes, maintaining multiple complete configuration files, or implementing custom tooling—each approach with its own drawbacks. The Kubelet Configuration Drop-in Directory feature provides a native, built-in solution to this challenge. |
| 27 | + |
| 28 | +## What changed? |
| 29 | + |
| 30 | +With GA graduation in v1.35, the `--config-dir` flag is production-ready with stable API guarantees. This allows you to compose kubelet configuration from multiple drop-in files that are automatically merged, enabling you to maintain a base configuration while layering node-specific or environment-specific settings. |
| 31 | + |
| 32 | +## Real-world use cases |
| 33 | + |
| 34 | +### Managing heterogeneous node pools |
| 35 | + |
| 36 | +Consider a cluster with multiple node types: standard compute nodes, GPU nodes for ML workloads, and edge nodes with specialized requirements. |
| 37 | + |
| 38 | +**Base configuration** (`00-base.conf`): |
| 39 | +```yaml |
| 40 | +apiVersion: kubelet.config.k8s.io/v1beta1 |
| 41 | +kind: KubeletConfiguration |
| 42 | +clusterDNS: |
| 43 | + - "10.96.0.10" |
| 44 | +clusterDomain: cluster.local |
| 45 | +``` |
| 46 | +
|
| 47 | +**GPU node override** (`50-gpu-nodes.conf`): |
| 48 | +```yaml |
| 49 | +apiVersion: kubelet.config.k8s.io/v1beta1 |
| 50 | +kind: KubeletConfiguration |
| 51 | +maxPods: 50 |
| 52 | +systemReserved: |
| 53 | + memory: "4Gi" |
| 54 | + cpu: "1000m" |
| 55 | +``` |
| 56 | + |
| 57 | +**Edge node override** (`50-edge-nodes.conf`): |
| 58 | +```yaml |
| 59 | +apiVersion: kubelet.config.k8s.io/v1beta1 |
| 60 | +kind: KubeletConfiguration |
| 61 | +evictionHard: |
| 62 | + memory.available: "500Mi" |
| 63 | + nodefs.available: "5%" |
| 64 | +``` |
| 65 | + |
| 66 | +With this structure, GPU nodes apply both the base configuration and the GPU-specific overrides, while edge nodes apply the base configuration with edge-specific settings. |
| 67 | + |
| 68 | +### Gradual configuration rollouts |
| 69 | + |
| 70 | +When rolling out configuration changes, you can: |
| 71 | + |
| 72 | +1. Add a new drop-in file with a high numeric prefix (e.g., `99-new-feature.conf`) |
| 73 | +2. Test the changes on a subset of nodes |
| 74 | +3. Gradually roll out to more nodes |
| 75 | +4. Once stable, merge changes into the base configuration |
| 76 | + |
| 77 | +## Viewing the merged configuration |
| 78 | + |
| 79 | +Since configuration is now spread across multiple files, you can inspect the final merged configuration using the kubelet's `/configz` endpoint: |
| 80 | + |
| 81 | +```bash |
| 82 | +# Start kubectl proxy |
| 83 | +kubectl proxy |
| 84 | +
|
| 85 | +# In another terminal, fetch the merged configuration |
| 86 | +curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq . |
| 87 | +``` |
| 88 | + |
| 89 | +This shows the actual configuration the kubelet is using after all merging has been applied. |
| 90 | + |
| 91 | +## How to use it? |
| 92 | + |
| 93 | +As this feature has graduated to GA, there's no need to enable a feature gate. Simply make sure you are running Kubernetes v1.35 or later. |
| 94 | + |
| 95 | +For detailed setup instructions, configuration examples, and merging behavior, see the official documentation: |
| 96 | +- [Set Kubelet Parameters Via A Configuration File](/docs/tasks/administer-cluster/kubelet-config-file/#kubelet-conf-d) |
| 97 | +- [Kubelet Configuration Directory Merging](/docs/reference/node/kubelet-config-directory-merging/) |
| 98 | + |
| 99 | +## Best practices |
| 100 | + |
| 101 | +When using kubelet configuration drop-in directories: |
| 102 | + |
| 103 | +1. **Test configurations incrementally**: Always test new drop-in configurations on a subset of nodes before rolling out cluster-wide to minimize risk |
| 104 | + |
| 105 | +2. **Version control your drop-ins**: Store your drop-in configuration files in version control alongside your infrastructure as code to track changes and enable easy rollbacks |
| 106 | + |
| 107 | +3. **Use numeric prefixes for predictable ordering**: Name files with numeric prefixes (e.g., `00-`, `50-`, `90-`) to explicitly control merge order and make the configuration layering obvious to other administrators |
| 108 | + |
| 109 | +## Acknowledgments |
| 110 | + |
| 111 | +This feature was developed through the collaborative efforts of [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node). Special thanks to all contributors who helped design, implement, test, and document this feature across its journey from alpha in v1.28, through beta in v1.30, to GA in v1.35. |
| 112 | + |
| 113 | +To provide feedback, join our [Kubernetes Node Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-node) or participate in discussions on our [public Slack channel](http://slack.k8s.io/) (#sig-node). |
| 114 | + |
| 115 | +## Get involved |
| 116 | + |
| 117 | +If you have feedback or questions about kubelet configuration management, or want to share your experience using this feature, join the discussion: |
| 118 | + |
| 119 | +- [SIG Node community page](https://github.com/kubernetes/community/tree/master/sig-node) |
| 120 | +- [Kubernetes Slack](http://slack.k8s.io/) in the #sig-node channel |
| 121 | +- [SIG Node mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node) |
| 122 | + |
| 123 | +We'd love to hear about your experiences using kubelet configuration drop-in directories in production! |
0 commit comments