The Kubernetes team has reached its goal of getting the latest version of the container orchestration project, v. 1.15, completed and out the door prior to the start of KubeCon China next week. This is the second release in 2019.
The latest release delivers several improvements for developers as well as a host of alpha and beta features that are expected to be integrated into future versions of Kubernetes. In total, the latest release of Kubernetes adds 26 enhancements, with three capabilities moving to stable. Thirteen features have moved to beta, and another ten are in alpha.
In the many weeks leading up to the release, two main themes for the release have surfaced. Continuous improvement was one of the major topics, leading to more stable core features, maturing existing features, better internal test coverage, and cleaning up the backlog. Extensibility was the other major theme, and this cycle therefore features more work around CRDs and API Machinery.
Key features of this release include:
Extensibility around core Kubernetes APIs
CustomResourceDefinitions Pruning
Pruning is the automatic removal of unknown fields in objects sent to a Kubernetes API. A field is unknown if it is not specified in the OpenAPI validation schema. This is both a data consistency and security relevant feature. It enforces that only data structures specified by the CRD developer are persisted to etcd. This is the behavior of native resources, and will be available for CRDs as well, starting as beta in Kubernetes 1.15.
Pruning is activated via `spec.preserveUnknownFields: false` in the CustomResourceDefinition. A future apiextensions.k8s.io/v1 variant of CRDs will enforce pruning (with a possible, but explicitly necessary opt-out). Pruning requires that CRD developer provides complete, structural validation schemas, either top-level or for all versions of the CRD.
CustomResourceDefinition Defaulting
CustomResourceDefinitions get support for defaulting. Defaults are specified using the `default` keyword in the OpenAPI validation schema. Defaults are set for unspecified field in an object sent to the API, and when reading from etcd.
Defaulting will be available as alpha in Kubernetes 1.15 and also requires structural schemas.
CustomResourceDefinition OpenAPI Publishing
OpenAPI specs for native types have been served at /openapi/v2 for long time, and they are consumed by a number of components, notably kubectl client-side validation, kubectl explain and OpenAPI based client generators.
With Kubernetes 1.15 in beta, OpenAPI schemas are also published for CRDs, yet again with the requirement of structural schemas.
Cluster Lifecycle Stability and Usability Improvements
Work on making Kubernetes installation, upgrade and configuration even more robust has been a major focus for this cycle for SIG Cluster Lifecycle. Bug fixes across bare metal tooling and production-ready user stories, such as the high availability use cases have been given priority for 1.15.
kubeadm, the cluster lifecycle building block, continues to receive features and stability work required for bootstrapping production clusters efficiently. kubeadm has promoted high availability (HA) capability to beta, allowing users to use the familiar `kubeadm init` and `kubeadm join` commands to configure and deploy an HA control plane. An entire new test suite has been created specifically for ensuring these features will stay stable over time.
Certificate management has become more robust in 1.15, with kubeadm now seamlessly rotating all your certificates (on upgrades) before they expire. Check the kubeadm documentation for information on how to manage your certificates.
The kubeadm configuration file API is moving from v1beta1 to v1beta2 in 1.15.
Continued improvement of CSI
In Kubernetes v1.15, SIG Storage continued work to enable migration of in-tree volume plugins to Container Storage Interface (CSI). SIG Storage worked on bringing CSI to feature parity with in-tree functionality, including functionality like resizing, inline volumes, and more. SIG Storage introduces new alpha functionality in CSI that doesn’t exist in the Kubernetes Storage subsystem yet, like volume cloning.
Volume cloning enables users to specify another PVC as a “DataSource” when provisioning a new volume. If the underlying storage system supports this functionality and implements the “CLONE_VOLUME” capability in its CSI driver, then the new volume becomes a clone of the source volume.
Additional Notable Feature Updates
- Support for go modules in Kubernetes Core
- Continued preparation on cloud provider extraction and code organization. The cloud provider code has been moved to kubernetes/legacy-cloud-providers for easier removal later and external consumption.
- Kubectl get and describe now work with extensions
- Nodes now support third party monitoring plugins.
- A new Scheduling Framework for schedule plugins is now Alpha
- ExecutionHook API designed to trigger hook commands in the containers for different use cases is now Alpha.
- Continued deprecation of extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs; these extensions will be retired in 1.16!
Check the release notes for a complete list of notable features and fixes.
Availability
Kubernetes 1.15 is available for download on GitHub. To get started with Kubernetes, check out these interactive tutorials. You can also easily install 1.15 using kubeadm.
