Kubernetes 1.7 extends the controller model to stateful updates

A stateful application's desired state includes more than a replica count. Its instances may need persistent identities, and changing their software requires a procedure that respects those identities. The Kubernetes 1.7 announcement introduces beta automated StatefulSet updates alongside new ways to extend the API. Both changes expand the kinds of operational work that can be expressed through Kubernetes resources.

The release also hardens several distinct security boundaries. NetworkPolicy becomes stable, a new node authorizer restricts kubelet access, and encryption for resources stored in etcd arrives as alpha. These are separate mechanisms with different responsibilities and maturity levels. Calling the release more secure is less useful than explaining which component now enforces which decision.

I am most interested in the controller model becoming applicable to more of the system's lifecycle. Creating a workload is only one operation. Updating an identified set of instances and giving an extension its own API are both ways to make ongoing management explicit in the cluster.

Identity and update policy are separate decisions

The StatefulSet API definitions in 1.7 describe a set of Pods with consistent network and storage identities. A given network identity maps to the same storage identity. The workload's instances therefore have a relationship to their storage that persists beyond an individual container process.

The new update strategy specifies what the controller should do when the Pod template changes. RollingUpdate applies updates to the set while respecting its ordering constraints. OnDelete retains the legacy behavior in which manually deleting a Pod causes its replacement to use the StatefulSet specification. These alternatives distinguish changing the declared template from instructing the controller to replace existing Pods automatically.

The relevant fields can be shown as a fragment of an existing StatefulSet's spec. This is not a complete workload manifest, and it leaves the application's template, service and volume claims unchanged.

updateStrategy:
  type: RollingUpdate
podManagementPolicy: OrderedReady

The two settings address different operations. updateStrategy selects how template revisions affect running instances. podManagementPolicy controls creation and deletion during scaling and replacement. Combining them into a vague instruction to roll out the application would conceal an important distinction in the API.

The default pod management policy is OrderedReady. Pods are created in increasing order, and the controller waits for each to become ready before continuing. Scale-down proceeds in the opposite order. Parallel allows the controller to create or delete Pods without waiting for that ordered readiness or termination sequence.

Parallel management can shorten startup for an application that does not require ordering. It does not establish that the application can tolerate concurrent startup. That requirement belongs to the application's own behavior. Kubernetes supplies an explicit choice so an application that does not need serial management need not pay for it.

The source also includes revision information in StatefulSet status. Current and update revisions describe the template versions involved, with replica counts associated with them. That gives operators information about the controller's progress beyond the total number of Pods. A set can have the requested count while still containing instances from different revisions.

The API also exposes a rolling-update partition ordinal. This makes the update strategy more expressive than a single enablement switch, with a field for describing where the set is partitioned during an update.

Storage integration does not determine application correctness

Local storage support arrives as alpha. The announcement says applications can access local volumes through the PVC/PV interface and use StorageClasses in StatefulSets. This extends the storage interface to another kind of backing resource without requiring the application to abandon claims as its request mechanism.

The same release adds a StorageOS volume plugin for highly available cluster-wide persistent volumes backed by local or attached storage. Local storage support and that plugin should not be treated as the same feature. One exposes a class of volumes through the Kubernetes storage model, while the other integrates a particular storage system.

StatefulSet update automation likewise does not implement the database's internal upgrade protocol. It describes how Kubernetes updates the Pods that represent instances. The release announcement names Kafka, ZooKeeper and etcd as examples of stateful applications that can benefit, but those applications retain their own data and membership semantics. The controller needs a workload definition whose ordering and readiness requirements correspond to the application.

DaemonSets receive related lifecycle work. Their existing update mechanism gains history and rollback capabilities. That matters for node-level services because changing their Pod template is an operation across the nodes where the DaemonSet runs. Revision tracking makes that change an identifiable part of the workload's lifecycle.

Security enforcement occurs at several locations

The stable NetworkPolicy API describes which Pods may communicate. Enforcement comes from a network plugin. That implementation dependency is explicit in the announcement and remains essential to understanding the feature. A stable API declaration is useful only when the selected network implementation acts on it.

The node authorizer and its admission control plugin restrict kubelet access to Secrets, Pods and other objects according to the node. This reduces the authority associated with an individual node's operation. A kubelet needs access to objects involved in its work, but that need does not imply unrestricted access to the same object kinds across the cluster.

Encryption for Secrets and other resources in etcd is alpha. It addresses stored data, which is a different boundary from network connectivity or kubelet authorization. A Pod-to-Pod communication rule does not define how the API server stores a Secret. Similarly, encrypting stored resources does not decide which authenticated API client may request them.

Kubelet TLS bootstrapping gains client and server certificate rotation support. Audit logging becomes more configurable through filtering and webhooks, with richer audit data. These changes concern credential lifecycle and the record of API activity, respectively. They complement authorization without replacing it.

The distinction is practical for administrators deciding what to enable. Network policy requires a suitable network plugin, encryption is an alpha storage feature, and the node authorizer concerns the permissions of a particular class of API client. Each mechanism needs to be evaluated at the location where it actually makes a decision.

Extensions gain their own API responsibilities

Runtime API aggregation allows third-party or user-created API servers to be served alongside Kubernetes' own APIs. The extension can supply an API server with its own implementation while presenting a Kubernetes-style API through the cluster. This is a broader extension mechanism than changing the configuration of an existing built-in workload type.

Custom Resource Definitions replace Third Party Resources. The announcement describes a cleaner API that resolves issues encountered during the TPR beta period and encourages users to migrate. It states that the community plans to remove TPR in 1.8. That is a migration notice attached to the current release, not evidence that the planned removal has already occurred.

Aggregation and CRDs provide different ways to add APIs. Aggregation incorporates a separately implemented API server. CRDs supply a resource-definition mechanism within Kubernetes. The announcement groups both under extensibility, but an extension author still needs to choose how the API itself will be implemented and where its behavior will run.

Alpha external admission controllers add another extension point. The release offers options for modifying objects as they are created and for validating policy. Admission concerns the acceptance or adjustment of an API operation. A controller's ongoing management of an accepted object remains a different responsibility.

My preference for Kubernetes' API machinery is strongest when these responsibilities remain visible. A resource definition gives users something to declare, admission can decide whether that declaration is acceptable, and operational behavior still needs an implementation. The extension mechanisms make that division available to platform authors without pretending that defining an object is enough to operate the corresponding system.

Runtime integration develops alongside workload management

The Container Runtime Interface gains RPCs for container metrics, and the project publishes CRI validation tests. Alpha containerd integration supports basic Pod lifecycle and image management. These changes extend and check the interface through which kubelet uses a runtime, while preserving an explicit alpha status for the new integration.

Taken together, the release expands both the work Kubernetes can manage and the ways users can add management behavior. StatefulSet strategies make template changes part of an identified workload's declared lifecycle. API aggregation and CRDs let platform authors expose additional resources. The security changes place narrower controls around the network, stored data and node access involved in operating those workloads and extensions.