Last checked and updated on 05 Jun 2026
What Is New in Kubernetes 1.1
Kubernetes 1.1 delivers major enhancements across scalability, application lifecycle management, and core infrastructure. This release focuses on making the platform more robust for production workloads.
| Category | Key Additions |
|---|---|
| New Features | Horizontal Pod Autoscaling, ReplicaSet, Ingress API, HTTP L7 Load Balancing, DaemonSet |
| Improvements | Larger Cluster Support, Improved Performance, Simplified Updates (kube-push) |
| Core API | Jobs API, Kubernetes Components run as Pods, Experimental OIDC Authentication |
| Networking | kube-proxy in iptables mode, Node Ports, Multi-port Services |
| Deprecations | kubectl rolling-update, PetSet (alpha), monitor-width flag |
How did Kubernetes 1.1 improve scalability and performance?
The 1.1 release significantly pushed the boundaries of what a single cluster can handle. We're now talking about supporting up to 2000 nodes, a substantial jump that matters for large-scale enterprise deployments.
Performance got a major boost with a 5x reduction in response latency for key operations like listing pods. They also moved critical components like the kube-proxy into a more efficient iptables-based implementation, which is far more performant than the previous userspace proxy for most workloads.
What new application management features were introduced?
This is where 1.1 really shined for developers and operators. The Horizontal Pod Autoscaler (HPA) landed, allowing your deployments to automatically scale the number of pods based on observed CPU utilization. This was a game-changer for handling variable traffic.
We also got the Ingress API for managing HTTP(S) L7 load balancing, the Jobs API for running finite batch computations, and DaemonSets for ensuring a pod runs on every node. The new ReplicaSet controller was introduced as the next-generation ReplicationController, offering more powerful label selector capabilities.
How did networking evolve in this release?
Networking became more robust and flexible. The shift of kube-proxy to default to iptables mode was the headline, providing better performance and reliability for service routing.
They added support for NodePorts, which expose a service on a port across every node in the cluster. Multi-port Services also became stable, simplifying the definition of services that need to expose multiple ports, like a pod that handles both HTTP and HTTPS traffic.
What changes were made to cluster operations and security?
Operations got easier with kube-push, a new command for simpler master and node upgrades. They also began the process of running Kubernetes components themselves (like the scheduler) as pods within the cluster, which is a much cleaner architectural pattern.
On the security front, experimental support for OpenID Connect (OIDC) authentication was added, providing a standardized way to integrate with external identity providers. This laid the groundwork for the richer authentication flows we have today.
What was deprecated or removed in Kubernetes 1.1?
This release started cleaning up the API. The kubectl rolling-update command was deprecated in favor of the newer Deployment object and kubectl rollout commands, which offer a more declarative approach to updates.
The alpha version of PetSet (which later became StatefulSet) was introduced but clearly marked as experimental. Some older, less-used flags like --monitor-width were also removed.
FAQ
Should I use the new Horizontal Pod Autoscaler instead of my custom scripts?
Absolutely. The built-in HPA is integrated with the API server and efficiently scales based on metrics it collects. It's more reliable than managing your own scripting solution for autoscaling.
What's the real-world difference between the old userspace kube-proxy and the new iptables mode?
The iptables mode is faster and uses fewer system resources. You'll see lower latency and higher throughput for service-to-service communication, especially in dense clusters.
Is the Ingress API ready for production use in 1.1?
It's a solid start, but remember it's a beta API. You'll still need to deploy an Ingress controller (like nginx or GCE) for it to actually work. The API itself just defines the rules.
Why would I use a ReplicaSet instead of a ReplicationController?
ReplicaSet has more expressive label selectors. You can use set-based selectors (like environment in (production, qa)) instead of just equality-based ones, giving you more flexibility in how you group pods.
What's the practical benefit of running Kubernetes components as pods?
It simplifies management. You can use standard Kubernetes tools like kubectl to view logs, manage resources, and monitor the health of your scheduler and controller manager, just like any other application.