Knowledge Sharing: Category-based Interpretation of Kubernetes v1.14 Release Notes

This article is jointly written by Zhang Lei, Xin Gui, Lin Shi, Xi Yuan, Zhong Yuan, and Xun Ming

Kubernetes 1.14.0 was officially released on March 25, 2019. As you can see, this release has many important changes in comparison with Kubernetes v1.12 and v1.13. The length of Kubernetes 1.14 Release Notes also hit a record high.

The “lengthy” release notes contain a large amount of information. How can we efficiently filter and explore the information that we need to help our teams accurately and quickly sort out the most important technology updates?

This article reorganizes and sorts out the Kubernetes v1.14 Release Notes by topics, and conducts technical analysis and discussion on important changes by category. We hope the “category-based interpretation” can help you better understand the core content of the Kubernetes v1.14 release.

Production-Level Support for Windows Nodes

The release of Kubernetes v1.14 marked an important milestone in its production-level support for Windows nodes. Kubernetes v1.14 significantly enhances its support for Windows:

With the growth of the Windows container ecosystem, container services of more and more major cloud vendors began to provide production-level support for Windows nodes. Alibaba Cloud Kubernetes (ACK) recently added support for Windows Container. ACK now provides unified management for hybrid deployment of Linux and Windows applications.

For more information, see Support for Windows Nodes is Graduating to Stable (#116).

Local Persistent Volumes Are Now Generally Available (GA)

The Kubernetes community has long been yearning for a feature that allows Kubernetes to directly use local storage devices (such as a local SSD) of the host as a persistent volume (Local PV). The reasons are obvious: in comparison with remote storage (network storage), Local PV has outstanding advantages, such as low latency, ease of use, stability, and low cost. For applications that have special requirements for such characteristics (for example database and search engine applications), Local PV can make a big difference.

Local PV goes GA in Kubernetes v1.14. This offers an important possibility for persistent storage in the cloud.

However, it is important to understand that Local PV has some potential risks as well:

You can solve the first problem by using a local volume provisioner provided by Alibaba Cloud to allow your local SSD Nvme instance to automatically create data volumes. However, the poor fault tolerance and poor robustness are tricky problems to solve.

For more information, see Durable Local Storage Management is Now GA (#121).

Pod Priority and Preemption Is In GA

The motivation of pod priority and preemption is clear: it enables Kubernetes (K8s) to run high-priority tasks by preempting resources of low-priority tasks.

The priority of a pod determines the importance of the pod in a cluster: (1) A high-priority pod is more likely to be scheduled first (K8s uses a queue scheduling model). But this does not necessarily mean that a high-priority pod will always be scheduled first, because there are many factors that affect the scheduling order. (2) Sometimes, a cluster may run out of resources, and the high-priority pod cannot be scheduled (no qualified node is available to run the pod). In this case, K8s will start the preemption mechanism to preempt resources of a low-priority pod that is running, and then run the high-priority pod. This is how the preemption mechanism works.

From time to time, K8s Scheduler may detect that a pod (Pod-A) does not have a proper node to run on (predicates of all nodes in the cluster failed). In this case, it removes some pods with a lower priority to “create room” for Pod-A. To implement such a “simple” idea in a distributed environment, many detailed problems must be solved, some of which are as follows. How does K8s Scheduler decide which pods of which node to remove? How can K8s Scheduler ensure that the resources created for Pod-A are not occupied by other Pods? How does K8s Scheduler prevent Pod-A from starvation? How does K8s Scheduler handle pod scheduling constraints with affinity requirements? Does K8s need to support cross-node preemption to cope with certain constraints (such as anti-affinity constraints of Failure Domain)? For more information, see Pod Priority and Preemption in Kubernetes (#564) .

Must-Know about Pod Ready++

Before the release of Kubernetes v1.14, Kubernetes determines whether a pod is ready by checking whether all containers within this pod run normally. There is a problem. The readiness of containers (or main processes of containers) in a pod does not necessarily mean that the pod is ready. To ensure the pod is normal and ready to serve traffic, we hope to use some external indicators to tell us whether the pod is really ready. These external indicators include the readiness of the service, DNS, and storage of the pod.

This feature is called Pod Readiness Gates or Pod Ready ++ in Kubernetes v1.14. Pod Ready ++ provides a strong extension to indicate the readiness of a pod. Note that, you need to compile an external controller to set values to corresponding indicators of Pod Readiness Gates.

For more information, see Pod Ready++ (#580) .

Kubernetes Native Application Management

After the release of Kubernetes v1.14, Kubernetes itself is able to manage Kubernetes native applications. The most important command that implements this feature is Kustomize.

Kustomize allows you to generate YAML files that are required to deploy applications by using the overlay method based on a base YAML file (template). This avoids directly modifying the template YAML file through replacing strings as Helm does. When you create new YAML files by using the overlay method, other users can freely use any base YAML files or YAML files that are generated at any layers. This allows every user to manage large amounts of YAML files by using Git style procedures such as fork, modify, and rebase. The idea of patching is similar to docker images. It not only avoids the modification or string replacement of YAML files, but also saves you the effort in studying DSL syntaxes (such as Lua).

After the release of Kubernetes v1.14, Kustomize becomes a subcommand of kubectl. The Kubernetes community is exploring an application management method that is different from Helm and is more Kubernetes native. We’ll see how it works.

For more information, see Added Kustomize as a subcommand in kubectl (#73033, @Liujingfang1).

Improved User-Friendliness

When we get more and more familiar with Kubernetes, we rely more and more on Kubectl. Our requirements also become increasingly diversified. In Kubernetes v1.14, kubectl improves user experience and enhances its support for daily management capabilities in the following aspects:

Improved Stability

Like all previous versions, the Kubernetes v1.14 release has attracted many attentions to its stability and reliability enhancements. Now, take a look at some notable fixes and upgrades.

Enhanced and Optimized Performance in Large Scale Scenarios

When main functions of Kubernetes become stably available, the community has been increasingly focusing on various problems of the Kubernetes project in large scale scenarios. Kubernetes v1.14 introduces many optimizations from the perspective of end users. For example:


Follow me to keep abreast with the latest technology news, industry insights, and developer trends.