At Red Hat, recently we celebrated 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...