This article is based on the Kubernetes 1.13 release, which became generally available on December 3, 2018. Quotes are drawn from an eWEEK interview with Aishwarya Sundar, release lead for Kubernetes 1.13 and Google Software Engineer.
Overview
Kubernetes 1.13 was released on December 3, 2018, marking the fourth and final release of the year for the project. Following 1.10 (March 26), 1.11 (June 27), and 1.12 (September 27), version 1.13 was notable for being the shortest development cycle in Kubernetes history at that point. Despite that compressed timeline, the release team focused on graduating long-standing features to general availability (GA) and improving the overall reliability of the platform.
Aishwarya Sundar, the release lead, described the guiding philosophy: “One of the main themes that we tried to align the cycle with was around stability—focusing more on giving users a reliable and stable end-of-year refresh of capabilities, mostly focusing on graduating long-term outstanding features that have had time to mature.”
Three features reached GA in this release: kubeadm, the Container Storage Interface (CSI), and CoreDNS as the default cluster DNS provider. The release also added Topology Aware Volume Scheduling as a stable feature and promoted several capabilities to beta and alpha status.
Release Process Improvements
The 1.13 cycle introduced several non-user-facing process improvements that helped the team ship on time despite the shorter window. Sundar highlighted tighter CI/CD signal monitoring, earlier triage of breaking changes, and stricter criteria for test jobs that could block a release.
“We made a few release process improvements as well, focusing on CI/CD signals and triaging breaking changes early on in the cycle and also tightening the criteria for test jobs that block the release. All of these were non-user-facing improvements that we did in terms of the release process itself to ensure that we can land a stable, reliable release on time.”
— Aishwarya Sundar, Kubernetes 1.13 Release Lead
Storage: CSI Goes GA and Topology-Aware Scheduling Stabilizes
Container Storage Interface (CSI)
The Container Storage Interface had been under active development for nearly a year before 1.13, first appearing as a beta feature in Kubernetes 1.10. With 1.13, CSI reached general availability, providing a stable and standardized abstraction layer that allows third-party storage vendors to build out-of-tree plugins without modifying the Kubernetes core codebase.
Before CSI, storage drivers were compiled directly into the Kubernetes binary (in-tree plugins), making it difficult for vendors to iterate independently. The stable CSI API allows vendors to ship and update storage plugins as standalone components, improving the ecosystem’s overall agility and reducing the maintenance burden on the Kubernetes project itself.
Topology Aware Volume Scheduling
Also reaching stable status in 1.13, Topology Aware Volume Scheduling enables the Kubernetes scheduler to make intelligent decisions when provisioning storage volumes alongside pods. In a multi-zone cluster, for example, this feature ensures that a volume is provisioned in the same availability zone as the pod that will consume it—preventing cross-zone latency or access failures.
“So we have the scheduler which provides input as to which would be the best place to provision a volume and the pod. For example, if you have a multi-zone cluster, this means the volumes will get provisioned in an appropriate zone that can run within the pod, allowing administrators to easily deploy and scale stable workloads.”
— Aishwarya Sundar
By co-locating volumes and pods within the same topology domain, this feature directly supports high-availability and fault-tolerant deployment architectures.
kubeadm Reaches General Availability
kubeadm, the command-line tool for bootstrapping Kubernetes clusters, also graduated to GA in version 1.13. kubeadm simplifies the process of creating, configuring, and upgrading Kubernetes clusters by automating the complex bootstrapping steps that would otherwise require manual intervention.
The GA designation came after multiple release cycles of gathering user feedback, fixing bugs, and hardening the tool’s behavior. With GA status, users can rely on kubeadm’s command-line interface and behavior remaining stable across future Kubernetes releases, making it a suitable foundation for production cluster lifecycle management.
Key kubeadm capabilities include:
- Cluster bootstrap: Initializes a control plane node with sensible defaults using
kubeadm init. - Node join: Simplifies adding worker nodes to an existing cluster with
kubeadm join. - Upgrade management: Guides the user through control-plane and node upgrades with
kubeadm upgrade. - Configuration tracking: Stores cluster configuration in a ConfigMap for auditability and reproducibility.
CoreDNS Becomes the Default DNS Provider
Kubernetes 1.13 replaced kube-dns with CoreDNS as the default in-cluster DNS server. CoreDNS is a flexible, plugin-based DNS server written in Go and a CNCF project. Its plugin architecture makes it easier to extend with features such as custom DNS resolution policies, caching, health checks, and metrics—without patching core DNS functionality.
Clusters upgraded from older versions would continue to use kube-dns unless explicitly migrated, but new clusters created with kubeadm 1.13 would default to CoreDNS.
Beta Features: A Look at What’s Coming
kubectl diff
kubectl diff entered beta in 1.13. The command compares a locally declared object configuration (e.g., a YAML manifest) against the live state of the corresponding object in the cluster. This gives operators a clear, diff-style view of pending changes before applying them, reducing the risk of unintended configuration drift.
API Server Dry Run
Also promoted to beta, the API server dry run feature allows users to submit API requests that are fully validated and processed by the server-side logic—including admission webhooks—without actually persisting any changes to etcd. This moves validation responsibility from the client (kubectl) to the server, making it possible to catch errors that client-side dry runs would miss.
“The API server dry run is one of the things which will help us fix a lot of existing bugs, that are elusive today with applied commands being managed within kubectl and not with an API server.”
— Aishwarya Sundar
Alpha Features: Third-Party Device Monitoring Plugins
Kubernetes 1.13 introduced alpha support for third-party device monitoring plugins. This feature allows cluster administrators and hardware vendors to expose device-level metrics (e.g., GPU utilization, network interface counters) to the Kubernetes monitoring stack without requiring changes to the core kubelet.
“The main advantage of this feature is it will enable cluster administrators to gather more container-level metrics for devices and provide device vendors with the ability to provide device-specific metrics.”
— Aishwarya Sundar
This builds on the existing Device Plugin framework introduced in earlier releases and moves the ecosystem toward a more extensible hardware management model.
Summary of Key Changes in Kubernetes 1.13
| Feature | Status in 1.13 | Category |
|---|---|---|
| Container Storage Interface (CSI) | General Availability | Storage |
| Topology Aware Volume Scheduling | Stable | Storage |
| kubeadm | General Availability | Cluster Lifecycle |
| CoreDNS as default DNS | General Availability | Networking |
| kubectl diff | Beta | CLI / UX |
| API Server Dry Run | Beta | API Machinery |
| Third-Party Device Monitoring Plugins | Alpha | Node / Hardware |
Background: Kubernetes and the CNCF
Kubernetes is a container orchestration platform originally developed by Google and donated to the Cloud Native Computing Foundation (CNCF) in July 2015. Since then it has become the de facto standard for running containerized workloads at scale. The 1.13 release demonstrated the project’s increasing focus on production readiness—graduating long-standing beta features and improving the release engineering process rather than simply adding new experimental functionality.