Kubernetes 1.9 gives long-running workloads a stable API

An application platform needs a stable agreement about how its workloads are declared and observed. Kubernetes has already used Deployments and ReplicaSets in practice, but the API's maturity designation matters to people building tools and maintaining long-lived manifests. The Kubernetes 1.9 release announcement makes apps/v1 generally available and enabled by default, with a commitment to long-term backward compatibility.

The graduation groups Deployments, ReplicaSets, DaemonSets and StatefulSets under the stable Apps Workloads API. These resources cover long-running stateless and stateful applications. Jobs and CronJobs are explicitly outside this effort and retain a separate path toward general availability. The scope is substantial without implying that every Kubernetes workload API has reached the same status.

I value this change because the API is where Kubernetes' reconciliation model becomes available to applications and tools. A controller needs a declaration of intended behavior, and an operator needs a way to observe progress. Stabilizing those representations gives platform authors a firmer basis for the systems they build around Kubernetes.

Stable resources retain specific management responsibilities

The four resource kinds do not become interchangeable because they share a stable API group. A Deployment describes a Pod template and an update strategy. ReplicaSets represent the corresponding replicated Pod management. A DaemonSet manages workloads across nodes, and a StatefulSet preserves consistent identities for its instances. The release groups their APIs without erasing those different purposes.

The 1.7 announcement introduced beta StatefulSet update strategies and enhanced DaemonSet update history. Those earlier changes matter to the graduation because lifecycle behavior extends beyond creating the initial Pods. A stable workload interface needs to represent updates and their observed state as well as a requested instance count.

Kubernetes 1.8 then grouped the core workload APIs in apps/v1beta2. The 1.8 announcement identifies that intermediate beta explicitly. Version 1.9's apps/v1 is the next maturity step for this group, based on the feedback and hardening described by the release team.

That history also clarifies what the release promises. General availability applies to the versioned APIs and their compatibility, not to an assertion that any arbitrary application will operate correctly when placed in a Pod. The workload definition still has to express the application's identity, placement and update requirements in the appropriate resource kind.

A Deployment declares both membership and a template

The 1.9 Apps API source defines a Deployment's selector separately from its Pod template. The selector must match the template's labels. An example using the stable API makes that relationship visible without depending on implicit inference from the template. It uses the productpage image and port shown in the May Istio tutorial.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: productpage
          image: istio/examples-bookinfo-productpage-v1
          ports:
            - containerPort: 9080

The selector identifies the Pods belonging to the replicated workload, while the template describes the Pods to create. The example uses the same app: web label in both places. A container image and port are only part of the declaration, because the controller also needs to know which instances its desired state describes.

The release's Deployment validation code requires a selector, rejects an empty one, and validates the template against it. These checks turn a structural relationship into an API acceptance rule. The submitted object must provide a coherent description before the controller can act on it.

This matters for generators as well as handwritten manifests. A tool emitting a stable Deployment has to produce the membership declaration and template together. It cannot treat apiVersion as an isolated string change while ignoring the fields that make the resource meaningful.

Status distinguishes readiness from update progress

The stable Deployment API includes desired behavior in spec and observations in status. Its status fields distinguish the total targeted replicas from replicas using the desired template, ready replicas and available replicas. Those numbers can differ while a rollout proceeds, so one count cannot stand in for all of them.

Availability also has a defined relationship to minReadySeconds. The source describes available replicas as ready for at least that period. An application can therefore impose a period of sustained readiness before an instance counts as available. That is different from treating the first ready observation as proof that the replica has met the availability criterion.

progressDeadlineSeconds defines when a Deployment should be considered to have failed to make progress. The API source says the controller continues processing it and reports a condition with the ProgressDeadlineExceeded reason. The deadline is thus an observable failure criterion, not a command to abandon the workload or an automatic rollback guarantee.

These distinctions are useful to a deployment system waiting for an update. It needs to decide whether it is looking for enough running replicas, all replicas using the new template, or the required availability state. The stable API gives those decisions named fields rather than requiring a client to infer them from a list of container processes.

Update strategy makes capacity policy explicit

A Deployment can use Recreate or RollingUpdate. The source describes Recreate as stopping existing Pods before creating replacements. RollingUpdate instead changes the old and new replicated workloads progressively. That choice affects the capacity available during the operation, even when the application image is the only template field being changed.

Rolling updates include maxUnavailable and maxSurge. The former limits how many desired Pods can be unavailable, and the latter allows additional Pods above the desired count. Each accepts either an absolute number or a percentage. Percentage unavailability rounds down, while percentage surge rounds up according to the API definitions.

The pair cannot both be zero. That restriction reflects the work a rollout must perform, because it needs some ability to create additional capacity or remove old capacity while replacing the workload. A strategy describes the permissible transition, not merely the final replica count.

These fields make an operational tradeoff part of a versioned declaration. Keeping more capacity available can require temporary extra Pods. Avoiding extra capacity can require accepting some unavailability. The actual values express the application's chosen balance within the controller's supported update mechanism.

Storage extensibility follows a different maturity path

Kubernetes 1.9 introduces an alpha implementation of the Container Storage Interface. The release describes a common interface for provisioning, attaching and mounting storage, developed with the CSI community. Its purpose includes allowing storage vendors to develop integrations without adding their implementations to the Kubernetes core codebase.

This addresses a maintenance problem in the existing plugin model. Kubernetes supports several storage systems, and each additional integration creates work in the core when the implementation must live there. A separate interface lets providers develop the storage integration behind a defined boundary. Installing such plugins as Pods is the direction described by the announcement.

The maturity distinction is explicit. CSI must be enabled deliberately in 1.9, and the release does not recommend it for production use. Its appearance alongside stable workload APIs should not turn that alpha implementation into an assumed production dependency. The release is stabilizing one interface while introducing another for experimentation.

Windows support reaches beta as well, expanding the workload environments Kubernetes can address. That is a separate status from both apps/v1 and CSI. A stable workload object does not imply identical platform support for every operating system on which its containers might run.

Extension authors also receive earlier validation feedback

Custom Resource Definition validation becomes beta and is enabled by default. The release describes it as a way to provide immediate feedback when a user submits an invalid custom object. That moves some error reporting to the API interaction where the invalid declaration first appears.

For a custom controller, this complements reconciliation rather than implementing it. Validation can reject an unacceptable object, while the controller remains responsible for acting on an accepted declaration. Kubernetes' extension model benefits from both a clear resource contract and the software that maintains the corresponding real state.

My interest in 1.9 is strongest at those boundaries. Stable Apps APIs give long-running workloads a compatibility commitment and specific fields for update behavior and progress. CRD validation gives extension authors another way to explain acceptable declarations. CSI begins a separate effort to move storage implementations behind a common interface, with its alpha status still attached to that implementation.