What Is New in Kubernetes 0.14
Kubernetes 0.14 delivers critical enhancements to service discovery, workload management, and cluster operations. This release focuses on maturing core APIs and improving the day-two operational experience.
| Category | Key Changes |
|---|---|
| New Features | Ingress API, Horizontal Pod Autoscaling, Kubectl rolling-update |
| API Improvements | PersistentVolume API stabilization, Node status capacity reporting |
| Networking | Service environment variables, more consistent service IPs |
| Bug Fixes | Pod lifecycle fixes, resource handling, scheduler improvements |
How did service discovery get better?
Service discovery became more reliable and application-friendly. The system now injects environment variables like KUBERNETES_RO_SERVICE_HOST for every active service, giving containers a simple way to find dependencies.
In practice, this means your application code can connect to backing services without hardcoded IPs. The service IP allocation also became more consistent across restarts, reducing connection thrashing for stateful workloads.
What workload management features were added?
Horizontal Pod Autoscaling (kubectl autoscale) landed as a new primitive. This lets you automatically scale replication controllers based on observed CPU utilization, which is huge for handling traffic spikes.
The kubectl rolling-update command also arrived, providing a declarative way to update pods without downtime. You could finally phase out old replication controllers while bringing new ones online smoothly.
Why is the Ingress API a big deal?
The Ingress API introduced a standard way to manage external access to services, typically HTTP. Before this, exposing web services required manual load balancer configuration or custom proxies.
This API abstracted away the underlying cloud provider details. You could define routing rules in a portable YAML spec, making application ingress much easier to manage across different environments.
How did cluster operations improve?
Operators gained better visibility with node capacity reporting. The API started surfacing actual machine resources like CPU and memory, which helped with scheduling and capacity planning.
The PersistentVolume API also moved towards stabilization. This laid the groundwork for dynamic storage provisioning, a killer feature for stateful applications that would come in later releases.
FAQ
Does Horizontal Pod Autoscaling work with any metric?
No, in 0.14 it only scales based on CPU utilization. You had to set CPU requests on your pods for it to function correctly.
Can I use the Ingress API without a custom controller?
No, the API itself just defines the spec. You needed to deploy an Ingress controller implementation (like nginx) to actually fulfill the routing rules.
How stable were these new features in 0.14?
Consider them alpha. The APIs worked but their schemas changed in subsequent releases. We didn't see true stability until much later.
Did rolling-update work with services?
Yes, it was designed to maintain service continuity. The command updated labels gradually so the service kept routing traffic to available pods throughout the process.
Were PersistentVolumes dynamically provisioned?
Not in 0.14. You still had to manually create volumes upfront. The API just provided a cleaner way to claim and bind existing storage.