Last checked and updated on 10 Jun 2026
What Is New in Kubernetes 1.6
| Category | Key Highlights |
|---|---|
| Scale & Stability | Cluster scale increased to 5000 nodes. Key subsystems like the API server are now more resilient under heavy load. |
| Security | RBAC promoted to beta. Introduces kubeadm security controls and automatic TLS certificate rotation. |
| Storage | StorageClass becomes dynamic with default class assignment. Multiple persistent volumes can now be attached to a single pod. |
| Scheduling | New scheduler extensibility model allows for custom scheduling policies without forking the core code. |
| Deployment & Configuration | kubectl apply is now the recommended strategy for declarative updates. Introduces the DaemonSet update strategy. |
How did Kubernetes 1.6 improve cluster scale and stability?
Kubernetes 1.6 significantly pushed the boundaries of cluster size and robustness. The maximum supported number of nodes jumped from 2000 to 5000, a 150% increase that caters to massive deployments.
This wasn't just about a number change. Core components were hardened to handle this scale. The API server, a critical bottleneck, saw major performance enhancements to prevent it from melting down under the load of thousands of nodes. In practice, this means your large clusters will be more stable and responsive.
What security enhancements were introduced in version 1.6?
RBAC (Role-Based Access Control) moved to beta, making it a stable and reliable choice for production-grade authorization. This is a big deal because it provides a fine-grained mechanism to control exactly what users and services can do within your cluster.
For cluster bootstrapping, kubeadm gained the ability to create a secure cluster out of the box with RBAC enabled. Furthermore, the kubelet now automatically rotates its TLS certificates, closing a potential security gap in long-lived clusters and reducing manual administrative overhead.
How did storage management evolve in this release?
Storage became much more dynamic and user-friendly. You can now mark a StorageClass as 'default', allowing PersistentVolumeClaims to automatically provision storage without needing to specify a class. This simplifies the user experience for the most common cases.
A major capability addition is that Pods can now have multiple PersistentVolumes attached from different providers (e.g., GCE PD and AWS EBS). This unlocks more complex, stateful workloads that need access to various storage backends simultaneously.
What changed for schedulers and deployments?
The scheduler was made pluggable. A new extensibility model allows you to implement custom scheduling policies without having to fork and rebuild the Kubernetes scheduler from source. You can now write a scheduler extender service that gets called by the default scheduler.
For deployments, the DaemonSet object finally got a robust update strategy (RollingUpdate), enabling you to safely roll out changes to daemon pods across your nodes. The community also solidified kubectl apply as the standard method for performing declarative updates to your objects.
FAQ
Is the 5000-node limit a hard cap or just a tested threshold?
It's the officially supported scale threshold. While you might run larger clusters, the core team guarantees stability and performance for clusters up to this size. Beyond that, you're on your own.
Should I switch from ABAC to RBAC now that it's beta?
Absolutely. The beta status signifies API stability. RBAC provides a much more secure and manageable authorization model than ABAC. New clusters started with kubeadm will use RBAC by default.
How does the default StorageClass work?
An administrator can annotate a StorageClass like so: storageclass.kubernetes.io/is-default-class: "true". Any PersistentVolumeClaim that doesn't specify a storageClassName will automatically use this default class for dynamic provisioning.
What's the practical benefit of a pluggable scheduler?
It lets you add custom scheduling logic for your specific hardware or workload needs without maintaining a fork. For example, you could write an extender that schedules pods based on custom metrics or internal network topology.
Does the DaemonSet RollingUpdate work like a Deployment?
Yes, the concept is similar. You can specify maxUnavailable to control how many daemon pods are taken down at once during an update, ensuring your node-level services remain available across the cluster.