Container orchestrator project Kubernetes 1.18, codename “a bit quarky”, is now available, celebrating unconventional ideas and the good things diversity can do for innovation. The moniker was chosen as a reference to a particle accelerator which was the result of global collaboration similar to the one displayed in K8s.

For Kubernetes 1.18 the team behind the project mainly focussed on getting some of the enhancements of previous versions into a stable state. Their efforts appear to have been quite successful given the graduation of 15 features to stable and another 11 moving into beta.

Among those is the Kubernetes Topology Manager, a kubelet component “that centralises the coordination of hardware resource assignments”. It offers a so-called Hint Provider as an interface for sending and receiving topology information from components which are then used to make decisions regarding the allocation of resources. This is meant to help with latency and similar issues caused by the old approach in which allocations were made independently from each other.

Another beta, although a second one, has been added for the server-side Apply feature, which should now “track and manage changes to fields of all new Kubernetes objects”. 

Features that can be considered stable now include the kubectl diff tool, which allows users “to view the difference between a locally declared object configuration and the current state of a live object”, PVC cloning, node-local DNS cache and the option to skip attach for non-attachable CSI volumes.

However, Kubernetes has also seen the addition of a couple of completely new elements, maybe the most interesting of which is the kubectl debug command. The utility is meant for troubleshooting purposes and lets devs create a temporary container in a running pod, restart pods with altered specifications, and start and attach to a privileged container in the host namespace. Earlier kubectl versions only had commands such as exec and port-forward to resolve problems, these however were only of use on the container or network level and couldn’t really help with pods and nodes for example.

The sometimes-tricky-to-work-with Ingress meanwhile gets a new pathType field as well as an IngressClass resource. IngressClass can be used to describe a type of Ingress within a Kubernetes cluster and replaces the kubernetes.io/ingress.class annotation. The pathType field helps to define if a path should be treated as a Prefix or Exact match, while the default is ImplementationSpecific.

Moreover, version 1.18 also makes some progress in Windows-related use cases. It for example contains an alpha version of CSI Proxy for Windows to enable pre-approved containers to perform privileged storage operations on the Microsoft operating system.

Before jumping on the new release, taking a look into the upgrade notes is very much advised, since there are about ten changes in central components, such as kube-apiserver and kubectl, that might make some manual adjustments necessary. Also, a lot of deprecated metrics have been removed, meaning a conversion to newer equivalents is needed to keep monitoring intact.