Kubernetes 1.14 is Out — What Are the New Features?

Kubernetes 1.14 is out! As always, we at StackRox are excited to dive in and see what’s new. And this release didn’t disappoint — from major new features and security improvements to small enhancements that simplify the day-to-day life of operators, this update includes a lot to unpack (and a few deprecation warnings to watch out for!).

Windows Support is now Stable

This feature is the big one: starting with 1.14, Kubernetes officially supports nodes running Microsoft Windows, as well as applications running in Windows containers. We expect this change to further accelerate enterprise adoption of Kubernetes, as organizations running both Windows- and Linux-based software will be able to manage all their workloads with a single orchestrator.

To run Windows applications, include Windows nodes in your cluster (they must be running Windows Server 2019), and simply create pods running Windows containers. Note that the Kubernetes master will still run only on a Linux node, so Windows-only clusters are unsupported. Also keep in mind that a substantial chunk of functionality does not — and will never — work in Windows, as a result of non-trivial operating system differences. Unsupported features include privileged containers, subpath volume mounting, read-only root filesystems and using memory as the storage medium.

API Discovery Endpoints are Inaccessible to Unauthenticated Users by Default

The built-in system:discovery clusterrole, which allows access to API discovery endpoints, is no longer accessible to unauthenticated users by default. Default unauthenticated access compromised security because it exposed all available API extensions, which could contain sensitive information (if, say, the cluster has Custom Resources with illuminating names). Even worse, it greatly increased the impact of vulnerability CVE-2018-1002105, which allowed attackers to send arbitrary requests to the Kubernetes API server by escalating any API call — including discovery API calls made by anonymous users!

Note that even with this change, you still have things to watch out for when it comes to running Kubernetes RBAC in a secure way.

PID Limiting is in Beta

Process ID (PID) limiting allows cluster operators to define the maximum number of process IDs that a single pod can use. This capability is important because process IDs are a shared resource on the host; without PID limits, a misbehaving or buggy pod which forks new processes indiscriminately can exhaust all available PIDs on the host, effectively crippling it and impacting all other workloads running on it. Further, users who design their applications so that each pod runs a very small number of processes can improve security by aggressively lowering the PID limit — so even if an attacker gets access to a pod somehow, their ability to cause damage will be limited since they can’t launch processes.

Since this feature is still in beta, to use it you will need to turn on the SupportPodPidsLimit feature gate; once enabled, the kubelet for each node takes in a pod-max-pids argument, which defines the PID limit.

Pod Priority and Preemption

Kubernetes now allows users to set priorities on their pods. When a cluster is overcommitted, and a high-priority pod cannot be scheduled anywhere, it can now “preempt” lower-priority pods, effectively killing them and taking their place. Note that preemption is different from eviction, where the orchestrator kills pods if the node is running out of resources. The goal of preemption is to make sure that high-priority workloads always get scheduled, even if nodes are filled with lower-priority pods.

To use this feature, define one or more priority classes, and use the new priorityClassName field in the pod spec to set a pod’s priority.

Persistent Local Volumes

Kubernetes now has stable support for persistent local volumes; previously, all persistent storage had to be remote, and data stored in local volumes would not persist beyond the lifetime of the pod. Having persistent local volumes means that it is possible to run distributed file-systems and databases in Kubernetes, while taking advantage of the better performance and (typically) lower costs of local storage.

To run a pod with a persistent local volume, create a PersistentVolume with the local type in its spec, and set its nodeAffinity to specify which node the volume you want to use it on.

Other Miscellaneous Updates

• The RunAsGroup feature is now in beta and enabled by default. You can set the runAsGroup field in a pod’s securityContext to specify the primary group ID of all processes that will run in the pod.
• kubectl now has a built-in integration with kustomize, a project that allows different resource YAMLs to share common fields, such as a label (which are applied as “customizations”).
• Several resources accessible through the extensions/v1beta1 API version are now deprecated and must be accessed through newer versions. Make sure your YAMLs are updated to use apps/v1 for Deployments, DaemonSets and ReplicaSets; network.k8s.io/v1 for NetworkPolicies; and policy/v1beta1 for PodSecurityPolicies.

To learn more, check out the official release notes for full details.