What You Need to Know About Kubernetes v1.18
In this article
With the first Kubernetes release of 2020 comes a slew of changes. In this release comes 15 enhancements graduating to stable, 11 in beta and 12 in alpha, for a total of 38 enhancements. All of these enhancements makes 1.18 sizably larger than the 1.17. While it's exciting to see so much in a new release, it can also be difficult to decipher what you and your organization need to know.
We have you covered. Below is a list of what we think is the "need-to-know" in Kubernetes v1.18.
kubectl debug
Kubectl received several changes with this new release, but the one that we're most excited about is the addition of the debug command to kubectl. With this addition, users will be able to more easily debug their pods by deploying a temporary container side-by-side the pod they're attempting to debug and attaching to the console. While this is only the alpha release, we think it shows promise in simplifying debug efforts, thus worth mentioning.
ContainerD supported on Windows
Kubernetes has shown its dedication to support Windows in the container world, and 1.18 is no different with its added support of ContainerD on Windows. ContainerD is a container-runtime that started supported container services on Windows Server 2019. With this added support, Windows admins will now have better control over their container management and a better compatibility experience with the Kubernetes API.
Server-side apply
Server-side apply is an enhancement effort to move "kubectl apply" to the apiserver. This would allow for conflict-detection by keeping track of to components attempting to edit the same field. Server-side apply was introduced in v1.16, but due to it not tracking the owner of fields of changes not yet applied, conflicts occurred due to missing metadata. In v1.18 it is a requirement for all new objects to have what are called managedFields which allows for this metadata to be stored, thus resolving this bug.
Enhancing Ingress flexibility
In v1.18 there are two major changes that have been added to Ingress, and we felt both were worth mentioning. The first is the addition of a new resources "IngressClass." This is used to describe a type of Ingress with a cluster and lets Ingresses specify their class to which they are associated with the new field "ingressClassName." It's worth noting that this change replaces the "kubernetes.io/ingress.class" annotation.
The next addition is a new field "pathType." This will allows for a more granular specification on how paths should be matched with the addition of "Exact" and "Prefix" path types. With this added granularity you will be able to manage your Ingresses with much more control.
The Topology Manager moves to beta
The Topology Manager is a kubelet component that acts as a source of truth for other kubelet components so they are able to make resource allocation decisions accurately based on the topology. The manager provides Hint Providers which act as an interface for the various components to send and receive information about the topology. This addition is especially exciting because it allows for users to run their workloads in a low-latency optimized environment.
What's next?
All of this information and more can be found in the release notes for Kubernetes v1.18.
But if you find yourself needing an extra set of expert eyes or if you're looking to make the transition into the cloud native land, we can help with that. We have container platform experts that specialize in all flavors of Kubernetes, whether it is PKS & PCF, OpenShift, Rancher or vanilla Kubernetes. we can help enhance your platform. Learn more about our service offerings.
We look forward to hearing from you!