What’s New in Kubernetes v1.14

“We’re pleased to announce the delivery of Kubernetes 1.14, our first release of 2019!” Seeing a new blog post that starts with that sentence is always an exciting moment, isn’t it? Well, Kubernetes 1.14 is officially out, and boy, was it worth the wait.

It is a relatively big update, with the delivery bringing a whopping total of 31 enhancements, 10 of which are stable with an additional set of 12 enhancements that are in beta. There are some interesting changes to the ecosystem, but we are going to focus on the five most exciting ones. Let’s have a look!

Support for Windows Nodes

The most exciting development in Kubernetes 1.14 is support for Windows nodes moving to stable. It has been in beta for a while now, and we bet a lot of you have been experimenting with it. The official support for Windows containers adds a new layer of flexibility to Kubernetes.

There are several important things to understand about Windows support in Kubernetes. First of all, it only works with Windows Server 2019 and you can add nodes running the operating system to your cluster. You also have the option to run applications in Windows containers.

What you can’t do is create an entire cluster using Windows. Kubernetes still relies on Linux at its foundation, so can only create a Linux Kubernetes master; support for a Windows master is not going to be available due to the nature of Kubernetes.

It is also worth noting that some features aren’t supported by Windows. If you are keen to use the server’s memory as a fast storage solution, for instance, you can’t do that with Windows containers. Read-only root filesystems and privileged containers are also not supported.

Pod Priority

Kubernetes 1.14 also brings more control over the priorities of pods. This makes Kubernetes clusters more flexible as well as easier to manage since you can now prioritize certain pods for different purposes.

The preemption feature enables running high-priority workloads, even in an overcommitted cluster. Kubernetes will simply review lower-priority pods and kill them–starting from the ones with the lowest priority setting–to make room for high-priority pods.

The feature even handles graceful termination beautifully. Low-priority pods are given a predetermined graceful termination period to allow them to complete their processes. If those processes aren’t completed until then, they get killed to make room for high-priority pods.

Better Security for API Discovery Endpoints

In older versions of Kubernetes, unauthenticated users could access API discovery endpoints, practically exposing entire API extensions to users. Anyone could send uninformed requests and get responses, exposing the entire cluster to potential attacks. With unauthorized users having the ability to escalate API calls, the security risk is substantial.

The change in Kubernetes 1.14 brings an end to that particular risk. Only authenticated users can access API discovery endpoints, adding an extra layer of security to API extensions that contain sensitive information.

That’s not to say that you can now relax because additional security measures are still needed. Good role-based access control practices–such as only assigning Administrator roles to limited users–are still essential. Other Kubernetes security best practices are still in play, too.

Process ID Limiting Entering Its Beta Stage

The one change that we’re most excited about at Caylent is process ID limiting entering its beta stage. This means the feature is now something we can play with, albeit with a few caveats. Not everyone has unlimited server resources but being able to limit process IDs accessible to a pod is a huge step in the right direction.

It is also a feature that can be used as a security measure and a way to optimize the entire cluster. When a vulnerable pod gets assigned a limited number of PIDs, even a successful attack may not result in catastrophic damage to the entire cluster.

So while it is still a beta feature, but it is a promising feature. You can turn on PID limiting from the feature gate, and then use pod-max-pids argument to set limits for your pods.

Other Interesting Features

As mentioned previously, Kubernetes 1.14 comes with a long list of interesting features. Aside from the features we’ve discussed so far, it also comes with built-in integration with Kustomize, giving you the ability to share common fields across multiple YAML files.

We also love the fact that persistent local volume is now a stable feature. Local volumes are no longer tied to pods, and they can continue to be used even after the pods associated with them have been destroyed. The possibilities for distributed systems are truly endless.

Some performance improvements are also to be expected. Mind you, there are some deprecated functions that are now removed from Kubernetes, along with changes to Kubectl and Kubelet that you need to know before updating. Be sure to review the complete release notes at Kubernetes.io before moving forward with upgrading your clusters.

Don’t forget to check out our other comprehensive blog articles in our Kubernetes resource here.

This post was originally published here.