The Kubernetes team reached its goal of getting v1.15 of the container orchestration project done before KubeCon China next week. In the eleven weeks leading up to the release, continuous improvement was one of the major topics, leading to more stable core features, better internal test coverage, and progress on some of the new additions.

Cluster lifecycle building block kubeadm, for example, sees the promotion of its high availability capability to beta, and also gets a new test suite, and improvements on certificate rotations for more robust certificate management. The special interest group focussing on storage moved the migration to the container storage interface on, by introducing volume cloning amongst other things. The functionality is needed to get to feature parity with the in-tree volume plugins the group tries to get away from.

Apart from that many of the changes in the current release were down to work from the API special interest group and should improve extensibility. A focal point here has been CustomResourceDefinitions or CRDs for short. They now come with early-stages support for defaulting, setting default values for unspecified fields in an object sent to the API or when reading form etcd. A bit further along are the publication of OpenAPI structural schemas for CRD and pruning to remove unknown fields in objects sent to a Kubernetes API.

Other interesting additions in v1.15 include support for Go modules in the Kubernetes Core, as well as early previews of a scheduling framework for schedule plugins, and an ExecutionHook API to trigger hook commands in containers. Kubectl users will also be glad to see that get and describe now work with extensions.

Although the comparatively high release frequency keeps providers of commercial offerings as well as maintainers of production setups on their toes, the first tranche of companies has already announced enterprise support for the just released Kubernetes 1.15. Canonical for example supports the new version using kubeadm deployments, its Charmed Kubernetes, and single-node deployment MicroK8s. Meanwhile OpenShift users for example might have to wait for a bit to get to use the new features (which shouldn’t be that bad however, since most enterprise offerings tend to be one release behind to ensure security and compatibility).

Those that haven’t bound themselves to a specific enterprise distribution however are advised to look into the urgent upgrade notes before jumping onto the new version. At the moment there are also still problems with logging and joining control-plane nodes, so if those are essential to what you’re doing, maybe wait for the next patch release. Or have a go at fixing and sharing it yourself – after all, it’s open source.