Kubernetes 1.15: Continuous Improvement, Stability, and CRD Extensibility

The Kubernetes project released version 1.15 on June 19, 2019 — the second release of 2019. Rather than introducing sweeping new capabilities, the 1.15 release team set an explicit goal of continuous improvement and extensibility, prioritising stability and API consistency over feature quantity. This article breaks down the most significant changes and what they mean for platform and DevOps engineers.

Custom Resource Definitions: The Core Focus of 1.15

The majority of 1.15 engineering effort centred on Custom Resource Definitions (CRDs) — the Kubernetes extension mechanism that lets operators add custom objects to the API server. The long-term project goal is to close the gap between custom resources and built-in Kubernetes resources, eventually promoting CRDs to general availability (GA).

Structural Schemas

Kubernetes 1.15 introduced structural schemas as a prerequisite for any new CRD feature going forward. A structural schema is an OpenAPI v3 JSON Schema specification with the following constraints:

• A non-empty type must be declared at the root of the schema.
• Every declared field of an object node must specify a type.
• Every item in an array node must specify a type.
• Logical constraints (e.g., anyOf, oneOf) are permitted as long as they comply with structural schema rules.

The goal of structural schemas is to improve data consistency, enable safer validation, and provide a foundation for features like pruning and defaulting. Starting with 1.15, all new CRD features require a structural schema.

The following is an example structural schema from the Kubernetes documentation:

type: object
description: "foo bar object"
properties:
  foo:
    type: string
    pattern: "abc"
  bar:
    type: integer
  metadata:
    type: object
    properties:
      name:
        type: string
        pattern: "^a"
anyOf:
- properties:
    bar:
      minimum: 42
  required: ["bar"]Code language: JavaScript (javascript)

Example structural schema from the Kubernetes documentation.

CRD Data Pruning

With structural schemas in place, Kubernetes 1.15 enables CRD pruning: any field submitted to the API server that is not declared in the OpenAPI schema is automatically stripped before the object is persisted. This has two important benefits:

• Data quality: Unknown or misspelled fields are rejected rather than silently stored.
• Security: Prevents clients from smuggling arbitrary data through the API in custom resource objects.

CRD Field Defaults

Field defaults allow CRD authors to specify default values for fields directly within the OpenAPI validation schema. This improves API compatibility when new optional fields are added to a CRD version, because existing objects that lack the new field will have sensible defaults applied automatically.

kubeadm: High-Availability Clusters Promoted to Beta

kubeadm — the tool for bootstrapping minimum viable Kubernetes clusters — also received significant stability work in 1.15.

• Automated HA cluster creation promoted to beta. Setting up a highly available control plane with kubeadm can now be done in a more automated, reliable way. Note that kubeadm still requires an external load balancer; the community planned to provide reference implementations for common load balancers such as HAProxy and Envoy.
• Simplified certificate management. kubeadm 1.15 automatically handles certificate rotation during cluster upgrades, removing a manual and error-prone step for operators.
• kubeadm configuration file rework. Significant testing and refactoring of the kubeadm configuration file schema was completed to support the above improvements and meet beta quality standards.

Volume Cloning: Alpha Support

Kubernetes 1.15 introduced volume cloning as an alpha feature. Volume cloning allows a user to reference an existing PersistentVolume as a DataSource when provisioning a new volume. This makes it straightforward to duplicate the contents of a volume — for example, cloning a database volume to spin up a fresh instance pre-populated with data — without needing external tooling to copy the underlying storage.

Because this feature was alpha in 1.15, it was subject to change in subsequent releases and required an explicit feature gate to enable.

Summary

Kubernetes 1.15 was a deliberate stability release. For teams running CRDs in production — or planning to — the structural schema requirements and pruning behaviour represent important breaking-change considerations when upgrading. Engineers operating clusters with kubeadm should review the updated configuration file format ahead of any upgrade.

Original source: InfoQ. Release date: June 19, 2019.