Kubernetes 1.17 separates storage migration from workload migration

Removing storage vendor code from Kubernetes is useful only if existing stateful workloads can keep working. Requiring every user to rewrite storage declarations would turn an internal architecture improvement into a large application migration. The Kubernetes 1.17 announcement on December 9 describes a compatibility mechanism that avoids that requirement. CSI migration replaces the implementation behind existing in-tree storage interfaces with the corresponding CSI driver.

The migration infrastructure reaches beta in this release. Volume snapshots also reach beta, while standard cloud provider labels become generally available. These developments concern different parts of operating stateful workloads. Migration changes which implementation handles storage operations. Snapshots expose a point-in-time storage operation through Kubernetes. Topology labels describe where resources are situated so placement can account for their location.

I value keeping declared workload state independent of changes to the machinery implementing it. Storage is a demanding case because an existing volume must remain usable throughout an infrastructure transition. The important detail in 1.17 is the compatibility arrangement, including the driver and feature configuration required to make it work.

CSI already changed the maintenance boundary

The January guide to generally available CSI integration explains the original maintenance problem. In-tree volume plugins ship with Kubernetes binaries. A vendor wanting to fix a storage bug must align that work with the Kubernetes release process, while core maintainers inherit vendor code they may be unable to test. Separately deployed CSI drivers give providers their own implementation and release path.

That arrangement provides a route for new integrations, but an installed cluster already contains users of the in-tree interfaces. The December announcement says the project wants those users to benefit from CSI without breaking generally available storage APIs. The migration therefore targets the implementation behind the established interface. An existing declaration can continue using the interface while Kubernetes directs its storage operations to the CSI implementation.

The announcement names kubernetes.io/gce-pd and kubernetes.io/aws-ebs as examples of in-tree integrations that can be replaced by corresponding drivers. After migration, storage management operations previously targeting the in-tree plugin go to the CSI driver. Its intended effect is continuity for workloads and configurations, with an architectural change beneath them.

This is distinct from copying data to a different storage service. The described migration changes who handles operations for the existing storage integration. It does not claim to transfer an application's contents between unrelated backends. That distinction matters when discussing what the compatibility mechanism can accomplish for an existing workload.

Beta infrastructure does not install the provider driver

The release-pinned 1.17 changelog records a qualification that the beta label alone can obscure. Its general CSIMigration feature gate is enabled by default. Provider-specific CSIMigrationAWS and CSIMigrationGCE gates are beta but disabled by default, because they require the corresponding CSI driver to be installed.

A cluster reporting Kubernetes 1.17 therefore has not necessarily migrated its EBS or GCE persistent disks. The infrastructure is present, but the provider transition requires both configuration and a driver. That distinction gives operators a concrete way to interpret the release. The global capability and the provider-specific handoff are separate decisions with different defaults.

The changelog also recommends using the corresponding CSI driver directly for new volumes. Existing workloads can retain the established interface through migration, while new declarations can select the CSI integration. This allows compatibility work and new configuration to proceed through different entry points without implying that all manifests must change at once.

Driver compatibility still deserves attention. The same release notes remove CSI version-zero support and plugin watching in the deprecated plugins directory. Supporting a migration architecture does not preserve every historical driver protocol indefinitely. A separately installed driver must use the supported integration mechanism in the Kubernetes release that will run it.

The January guide already described the helper containers around a CSI driver. Provisioning and attachment use controllers watching Kubernetes objects, and node registration connects the driver to kubelet. Those components help explain why installing the driver is an actual operational prerequisite. A feature flag cannot supply the provider implementation or its integration helpers.

CSI also supports representing an existing volume through a manually created PersistentVolume, as the January guide demonstrates. That declaration names the driver and a volume handle identifying the existing storage. Dynamic provisioning instead begins with a claim and a StorageClass naming the provisioner. These paths show that CSI can participate in both newly provisioned storage and storage that already exists.

The migration mechanism has a related compatibility objective but operates behind an established in-tree interface. It is important to keep that objective distinct from manually redefining every volume as a new CSI PersistentVolume. The release describes preserving workload configuration through the handoff, which is the reason for adding migration infrastructure at all.

Snapshots turn storage operations into API objects

The December release describes a snapshot as a point-in-time copy of a persistent volume. Many underlying storage systems already provide that operation. Exposing it through Kubernetes allows tooling to request it through the cluster's API instead of requiring a separate storage-specific operation outside the workload system.

The announcement gives preparing for a database operation as an example of why an administrator may need a snapshot. It also identifies snapshot capabilities as building blocks for higher-level backup systems. These are related uses but different layers of functionality. A basic snapshot operation supplies a storage capability that a more complete administration tool can incorporate.

That distinction prevents overstating the beta milestone. An API for requesting a point-in-time volume copy is not, by itself, an entire application backup service. The announcement frames it as a component from which application- or cluster-level backup solutions can be developed. Those tools still need to define what resources they include and how they use the resulting storage copies.

Volume snapshots began as alpha in Kubernetes 1.12 and had a second alpha with breaking changes in 1.13, according to the release team. Reaching beta in 1.17 is therefore a maturity change in an existing effort. The changelog records enabling the VolumeSnapshotDataSource feature gate and promoting snapshot APIs to beta. The feature's history matters to users who experimented with earlier representations.

I prefer this operation being available through the same API that describes the workload's storage requests. It gives controllers a common place to express the request and observe its result. The value lies in making the operation available to automation, while the underlying storage implementation remains responsible for performing it.

Topology labels become a stable placement vocabulary

The stable cloud provider labels describe instance type and location. The release names node.kubernetes.io/instance-type, topology.kubernetes.io/region and topology.kubernetes.io/zone. Nodes receive the instance-type label, while nodes and volumes carry topology labels. Standard names let workload configuration refer to these concepts across providers.

The release explains that the scheduler uses location information to place pods in the same zone as the volumes they claim. It also describes distributing Deployment pods across zones. Topology therefore participates in workload behavior rather than merely appearing as inventory metadata. Node affinity can also refer to the standard labels in a pod specification.

For example, this fragment selects a zone through the stable label in an otherwise complete pod specification. The zone value is illustrative and must match a zone actually represented by the cluster's nodes.

spec:
  nodeSelector:
    topology.kubernetes.io/zone: example-zone

Kubernetes components populate both beta and stable labels and react to both in this release. The announcement nevertheless recommends migrating pod specifications and custom controllers to the stable names. That gives built-in components a compatibility period while allowing user-controlled configuration to adopt the stable vocabulary. A custom controller using an old literal label key still needs its own update.

The changelog identifies the earlier zone and region names under failure-domain.beta.kubernetes.io. Knowing the exact old and new keys matters because the descriptive values can look the same while the selector key changes. The stable naming change is a configuration migration for code and manifests that directly address those labels.

Together these storage changes distribute responsibility more clearly. Kubernetes provides migration machinery that preserves established interfaces, while the operator supplies and enables the appropriate CSI implementation. Snapshot APIs expose a storage operation for higher-level automation. Stable topology keys give workloads and controllers a shared vocabulary for placement. An actual 1.17 installation's behavior still follows its enabled provider gates, installed drivers and the label keys used by its workload declarations.