Kubernetes v1.14: What you need to know

Kubernetes v1.14 was released today. The primary themes of the release are extensibility and supporting more workloads. It includes 31 enhancements, with a record 10 features graduating from beta to stable. Here are the highlights:

Persistent local storage

This feature, which was previously available as a beta, is now classified as stable. The primary use cases for persistent local storage are databases and distributed file systems. Obviously, local storage performs better than remote disks, whether that storage is a local SSD delivered by a cloud provider or a disk attached to a bare metal system. This has been in the works since Kubernetes v1.5, so its promotion to stable status is a significant milestone.

Everything you need to grow your career. With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development. SIGN UP

Production-level support for Windows nodes

If you’re a Red Hat Enterprise Linux only shop, this feature doesn’t buy you anything, but the overwhelming majority of enterprises have heterogeneous environments that include Windows workloads. With this feature moving to stable status, you don’t have to look for a different orchestrator to manage those Windows containers. Kubernetes v1.14 provides improved support for pods, service types, workload controllers, and metrics/quotas, approaching parity with those capabilities for Linux.

PID limiting now in beta

One concern of Kubernetes administrators is the allocation of Process IDs (PIDs) on Linux hosts. In the past, there was nothing to stop a process inside a container from creating PIDs. If the system supply of PIDs is depleted, that can cause instability on the host machine even though other resources are not constrained. Administrators can now set defaults for the number of PIDs per pod (beta) and reserve a number of allocatable PIDs per node within a pod (alpha).

Pod priority and preemption support

You can now assign priorities to pods so that the Kubernetes controller can make better decisions when the cluster is out of resources. Less important pods can be removed to create room for more important ones.

Discovery APIs removed from the RBAC infrastructure

There is a set of APIs that allow unauthenticated access by default. In v1.14, the discovery APIs has been removed from that set to improve privacy and security.

kustomize integration with kubectl

kustomize lets you configure resources declaratively. In v1.14, those capabilities are available through kubectl via the -k flag or the kustomize subcommand. See the App Customization section of the kubectl docs for all the details.

kubectl plugin mechanism is now stable

kubectl plugins are standalone binaries that add subcommands to kubectl . Those subcommands can provide new and custom features not available in the base kubectl distribution. The Extend kubectl with plugins section of the Kubernetes documentation explains how it all works.

Updated kubectl docs. And a logo. And a mascot.

The documentation for kubectl has been rewritten from the ground up. You can find it at kubectl.docs.kubernetes.io. It is published as a series of chapters that take you through everything you can do with kubectl , including how to manage, customize, and deploy apps; get information about resources; debug containers, and more.

The docs include the new kubectl logo. It sports an undersea theme, with the new cuttlefish mascot swimming past the Kubernetes logo. The mascot is officially pronounced kubee-cuddle, likely the death knell for any argument that the end of the command should be pronounced “control.”

How the sausages were made

For more background on some of the features above, see the issues and their related discussions on GitHub: