Last checked and updated on April 15, 2026What Is New in Kubernetes 1.13
Kubernetes 1.13 delivers several major enhancements focused on core cluster operations and cloud provider integration. The most significant advancements are the graduation of Container Storage Interface (CSI) and CoreDNS to general availability, alongside substantial improvements to kubeadm.
| Category | Key Changes |
|---|---|
| New Features (GA) | CSI block storage support, CoreDNS as default DNS, kubeadm production-ready |
| Improvements | Azure Virtual Machine Scale Set VMSS support, subresource support for Horizontal Pod Autoscaler |
| API Changes | New kubelet.config.k8s.io and kubeproxy.config.k8s.io API groups |
| Bug Fixes | Numerous fixes across scheduling, networking, and storage components |
How did storage evolve with CSI going GA?
The Container Storage Interface (CSI) reached General Availability in 1.13, marking a major milestone for storage plugins. This means third-party storage providers can now develop drivers without needing to touch the core Kubernetes codebase.
This release specifically introduces GA support for raw block storage volumes, allowing workloads to directly access storage devices. You can now use persistent volumes as block devices in your Pod specs with the new volumeMode: Block field.
In practice, this decoupling makes adding new storage systems much simpler and faster. Storage vendors can ship their CSI drivers independently of the Kubernetes release cycle.
Why did CoreDNS become the default cluster DNS?
CoreDNS replaced kube-dns as the default DNS provider for new kubeadm clusters in 1.13. This change was driven by CoreDNS's simpler, more flexible architecture and its use of plugins for extended functionality.
The CoreDNS deployment now runs as a single container instead of the multiple containers used by the kube-dns setup. This simplifies operations and reduces resource overhead while maintaining full compatibility with existing DNS-based service discovery.
For existing clusters, kube-dns remains available, but new deployments will automatically get CoreDNS. The transition is seamless for applications as the DNS API remains unchanged.
What makes kubeadm production-ready now?
kubeadm graduated to GA in 1.13, signaling its stability for production cluster lifecycle management. The tool received significant upgrades to its configuration API and cluster upgrade process.
The new kubeadm.k8s.io/v1beta1 API version provides a more structured configuration format. kubeadm now also supports automatic certificate renewal and smoother control plane upgrade workflows with the kubeadm upgrade command.
This matters because it establishes kubeadm as the standard, vendor-neutral way to bootstrap conformant clusters. You can now reliably use it for production deployments without worrying about breaking changes.
How did cloud provider integration improve?
Azure cloud integration saw substantial enhancements with full support for Virtual Machine Scale Sets (VMSS) and Azure Standard IP addresses. This enables better scaling characteristics and integration with Azure's load balancing services.
The cloud controller manager structure was refined, moving more cloud-specific logic out of the core Kubernetes code. This follows the broader pattern of making Kubernetes more modular and cloud-agnostic.
For Azure users, VMSS support means clusters can leverage Azure's native scaling capabilities more effectively. The improved integration reduces manual configuration needed for load balancers and node management.
What API changes should developers watch for?
Kubernetes 1.13 introduced new API groups for kubelet and kube-proxy configuration: kubelet.config.k8s.io and kubeproxy.config.k8s.io. These provide more structured configuration options for these critical components.
Horizontal Pod Autoscaling gained support for custom metrics API and more flexible scaling based on external metrics. The API now allows scaling on any resource that implements the custom metrics API, not just CPU and memory.
These changes give developers finer control over application scaling behavior. You can now create autoscaling rules based on application-specific metrics like queue length or request rate.
FAQ
Is the switch to CoreDNS breaking for existing clusters?
No, existing clusters continue using kube-dns unless explicitly upgraded. Only new clusters created with kubeadm 1.13 will default to CoreDNS. The DNS service name and format remain identical.
How do I start using CSI block storage volumes?
First, ensure your storage provider has a CSI driver that supports block volumes. Then in your PersistentVolumeClaim, set volumeMode: Block instead of the default Filesystem. The volume will appear as a block device in your container.
What's the simplest way to upgrade clusters to 1.13?
For kubeadm clusters, use kubeadm upgrade which now handles control plane upgrades more smoothly. The process includes automatic certificate renewal and better rollback capabilities compared to previous versions.
Does VMSS support change how I manage Azure nodes?
Yes, with VMSS support you can manage node groups through Azure's scale set interfaces instead of individual VMs. This enables automatic scaling of worker nodes based on load and better integration with Azure monitoring services.
Are there any deprecated features I should migrate from?
Yes, several alpha features were removed including the old GPU device plugin API and the kube-dns addon. Check the changelog for complete list, but most production users won't be affected as these were alpha features.