Last checked and updated on April 15, 2026What Is New in Kubernetes 1.2
Kubernetes 1.2 delivers significant scalability enhancements, powerful new automation features, and a refined user experience. This release fundamentally expands the types of workloads the platform can handle, moving beyond stateless services to stateful and batch applications.
| Category | Key Highlights |
|---|---|
| New Features | Deployments, Ingress, ConfigMap, Horizontal Pod Autoscaling, Jenkins Pipeline Integration, Dynamic Provisioning (Alpha) |
| Scalability | Supported cluster size increased to 1000 nodes; 2x performance improvements in Pod startup and DNS |
| Automation | Automated rolling updates, automated cluster turn-up on AWS and GCE |
| User Experience | Improved kubectl output, new `kubectl run-container` command, dashboard UI |
| Stateful Applications | PetSet (Alpha), Persistent Volumes with new volume plugins (Quobyte, ScaleIO) |
| Deprecations | The `kubectl sh` command is deprecated in favor of `kubectl exec` |
How did Kubernetes 1.2 improve application deployment and updates?
The introduction of the Deployment API object is the cornerstone of deployment improvements. It declaratively manages ReplicaSets and enables seamless rolling updates and rollbacks, replacing the previous rolling-update client-side tool.
In practice, you define your desired application state in a Deployment manifest. The controller then drives the current state towards that goal, automatically handling the process of replacing old Pods with new ones. This shift to server-side logic makes deployment processes more robust and scriptable.
What scalability limits were pushed in this release?
Kubernetes 1.2 officially supports clusters up to 1000 nodes, a substantial jump that opens the door for much larger workloads. This isn't just a theoretical limit; core system performance saw a 2x improvement in key areas.
Pod startup latency and DNS query performance were specifically optimized. These enhancements mean that even at massive scale, the platform remains responsive. You can now run pods in the tens of thousands across a thousand machines without the control plane becoming a bottleneck.
What new resources were added for managing configuration and traffic?
Two critical new resources arrived: ConfigMap and Ingress. ConfigMaps provide a straightforward way to inject configuration data into pods, separating your application code from its configuration. This is a cleaner alternative to stuffing configs into environment variables or Docker images.
The Ingress resource finally offers a native way to manage external HTTP(S) access to services. You define routing rules in a standard Kubernetes object, and an Ingress controller (which you need to deploy) implements them. This moves L7 routing logic out of cloud-specific annotations and into first-class API objects.
How did Kubernetes 1.2 better support stateful and batch workloads?
This release marked a major step towards being a universal compute platform. The alpha PetSet resource (the precursor to StatefulSet) was introduced to manage stateful applications, providing guarantees about ordering and unique network identities.
For batch processing, the integration with the Jenkins Pipeline plugin allows you to define complex continuous delivery workflows that directly interact with the Kubernetes API. Furthermore, Horizontal Pod Autoscaling now works based on CPU usage, letting your batch jobs scale out to process queues faster and scale down to save resources.
What storage and volume capabilities were enhanced?
Persistent Volume support matured with the addition of new volume plugins, including Quobyte and ScaleIO, giving users more flexibility in their storage backend choices. The alpha feature of dynamic provisioning began to take shape, laying the groundwork for storage classes and on-demand volume creation.
This means you could start to define a storage "class" and have volumes automatically created when a PersistentVolumeClaim requested it, rather than requiring an admin to pre-provision storage manually. It was a foundational change for storage automation.
FAQ
What exactly replaces the old `kubectl rolling-update` command?
You should use the `Deployment` resource. The key difference is that `rolling-update` was a client-side operation, while a Deployment is managed server-side by a controller, making it more reliable and declarative.
Is the new Horizontal Pod Autoscaler (HPA) ready for production use?
The HPA based on CPU utilization is stable. However, remember it requires Heapster to be running in your cluster to gather the necessary metrics. The custom metrics support is still in alpha.
What do I need to use the new Ingress resource?
You need to deploy an Ingress Controller (like the nginx-ingress controller) into your cluster. The Ingress resource itself just defines the rules; the controller is the software that implements them by configuring a load balancer or proxy.
Can I use PetSet for my database in production?
PetSet is an alpha feature in 1.2. While it provides the unique identities and stable storage needed for stateful apps, we strongly advise against using alpha features for critical production workloads due to potential API changes and bugs.
How do ConfigMaps improve on environment variables for configuration?
ConfigMaps allow you to manage configuration data as a Kubernetes resource, which can be versioned and updated independently of your pod definitions. You can mount them as volumes, providing a way to update configs without restarting the pod, or use them to populate environment variables.