Red Hat SummitRed Hat blog
As open source leaders at Red Hat, today we celebrate the community release of Kubernetes 1.14. This release brings updates that expand the ecosystem, enhance customizability, and increase the stability of the platform.
Expanding the ecosystem from Linux only, to Windows containers support
The Kubernetes project has always been about managing workloads at scale using Linux containers. While many sub-projects have sprung up over time to handle everything from data storage, to networking to monitoring, one thing has always remained the same: Kubernetes ran Linux containers.
In a major shift for Kubernetes as a whole, version 1.14 graduates support for managing Windows containers from beta to stable. This is the culmination of a tremendous amount of work over the past year across a number of Kubernetes Special Interest Groups (SIGs) including Windows, Node, and Architecture. The result is that Kubernetes, the de facto most popular open source container orchestration platform for Linux, now comes to Windows. Red Hat congratulates Microsoft and the extended community for reaching this significant release milestone.
The community has worked hard to enable this major expansion of the Kubernetes ecosystem. For Red Hat, this means an open commitment to supporting workloads across clouds. These changes are planned for future releases of the Red Hat OpenShift Container Platform.
Customize kubectl plugins
Further expanding the customizability of Kubernetes in the 1.14 release is the graduation from beta to stable of kubectl plugins. This plugin mechanism allows developers to write Go code to extend kubectl with new commands. In practice, this works similarly to how git can be extended.
During development, the Red Hat OpenShift team has been using a variety of kubectl plugins to help debug our upcoming release of OpenShift 4. Plugins can be built to perform a variety of tasks on the cluster to build more advanced commands for things to improve troubleshooting and collect instrumentation. We are excited to see what the community builds.
Process IDs get more granular resource control
Elsewhere in the Kubernetes 1.14 release, work has been done to mitigate the risk of a single pod monopolizing all of the process IDs (PIDs) available. Administrators can limit the number of process IDs that a pod can use so that a fork bomb-type accident cannot suck up all the available resources on a node or cluster and impact other pods on the host. This feature is currently in beta in Kubernetes 1.14.
Additional work in this same area is now in alpha with this release: the ability to isolate process IDs from end users’ workloads from the node agents themselves. This protects a node from total starvation of process IDs. We look forward to graduating this capability with the community in the next release to beta.
Pod Ready plus plus for more maturation and stability
Pod Ready ++ is a new state of readiness beyond normal container readiness. This state is communicated by pods to indicate that, not only are they booted and live, but they are actually ready to serve traffic. Previously, some users were encountering scenarios where pods were reporting themselves ready when they were not in fact entirely ready to receive network traffic due to a variety of environmental factors which could lead to service disruption. Pod Ready++ indicates the pod is actually ready to go and receive traffic mitigating this risk.
Additional security for containers
The RuntimeClass and runAsGroup projects graduated to beta status in Kubernetes 1.14.
RuntimeClass works much like other class related configurations in Kubernetes. In the case of a RuntimeClass, cluster administrators are able to define and configure concrete container runtime configurations. The user can describe at the time of their pod deployment what particular provided runtime configuration they would like when their pod is started. This is an exciting new interface for users in the Kubernetes cluster because it offers each of them (that are approved to use the RuntimeClass) to be more granular with their container configuration choices should they wish rather than conforming to a single configuration for the entire cluster. This is becoming more interesting as more and more innovation is happening in the container runtime space. Imagine wanting to tell Kubernetes to launch one pod with CRI-O/runc and another pod with CRI-O/kata. RuntimeClass helps solve those use cases.
runAsGroup is another great beta feature in Kubernetes 1.14. Normally in Kubernetes there is no way to control the primary group id of the running container which is always 0 (root). You can imagine wanting a process started from the container to write to a NFS share, but not wanting the NFS share to be read/write root. This feature will enable enterprises to run containers as non zero gid and hence improve the level of security for how those containers are allowed to interact with the rest of your infrastructure and services.
Hardening Kubernetes in future releases
As always, Kubernetes is an open source project written and managed by the hands of thousands of contributors around the globe. Without all of their help, the project would not be able to continue to evolve to meet the challenges of enterprise workloads. Now, with the addition of Windows containers to the list of manageable workloads, the remaining realm of unsupported use cases gets even smaller.
Red Hat has been working alongside the Kubernetes community and other major cloud providers since the early days of Kubernetes. Thanks to the diverse efforts bringing forward new features and increased stability in Kubernetes, businesses around the world will be able to reap the rewards of the hybrid cloud for their Linux applications, and their Windows applications. We look forward to continuing to harden and stabilize Kubernetes in future releases, and to expanding our work with Microsoft to support our new Windows users to the community.
