Kubernetes 1.13 is one of the quicker releases the container orchestrator has seen yet, but mostly comes with refined versions of features already known to users – a signal of the project’s growing maturity.
One example is cluster management tool kubeadm, which is now generally available and should hence be ready for use in production. It provides best practice approaches for getting basic Kubernetes clusters up and running. The new release also sees a change in the DNS server used by default.
CoreDNS has taken over from kube-dns, and is thought to be more performant when it comes to memory and CPU consumption – in part because it only consists of a single executable and process. It is also supposed to be memory-safe, and supports the creation of custom DNS entries, making way for a larger number of use cases.
With the Container Storage Interface specification finally out in v1.0, the CSI implementation itself also reached general availability status after almost a year of work. The CSI is meant to offer storage vendors a way to build plugins for volume provisioning, mounting and consumption, and the like, that can be used with different container orchestration systems. According to the GitHub repo of the spec, other than Kubernetes, Cloud Foundry and Mesos have adopted the CSI yet. Plugins however are already offered by most well known storage providers including AWS, GCE, DigitalOcean, as well as by open source projects such as MooseFS, CephFS and Cinder.
To make sure Kubernetes is able to find and therefore work with whatever plugin is added, the project has got a so-called Kubelet Device Plugin Registration in v1.11 which with this release also graduated to general availability. It offers an interface to plugins against which they can register within a kubelet.
Speaking of plugins, there is something really new in this 1.13 release after all: support for third party device monitoring plugins. The feature still has alpha status, but in the future it should provide admins with container-level metrics for their devices – GPUs for example – and give vendors a way to implement ways of supplying those without having to contribute to Kubernetes.
Other interesting updates concern Kubectl Diff and APIServer DryRun, which both get bumped up to beta status in v1.13. Both help prevent ops folks from having to rollback changes by giving them the opportunity to test configurations and operations first. While Diff helps understanding the difference between a locally declared object configuration and either a running cluster object, a previously applied one or a merged object, DryRun demonstrates the outcome of cluster operations on objects without persisting the change’s data.
More details of the new release can be found in the project’s changelog. There’ll also be a webinar on the topic on 10 January 2019 and a series of blog posts to get into some of the features. Before considering an upgrade, a brief look into the urgent upgrade notes of the project is advised.