The first major update of the open-source Kubernetes cloud-native platform in 2019 was released on March 25, with the general availability of Kubernetes 1.14.
Kubernetes is a broadly deployed container orchestration system project that is hosted by the Cloud Native Computing Foundation (CNCF) and benefits from a diverse set of contributors and vendors that support and develop the project. With Kubernetes 1.14, the project is adding 10 new enhancements as stable features that provide new capabilities for users. Among the biggest enhancements is production-level support for Windows nodes.
“I’m proud of just that fact that in Kubernetes 1.14 there are more stable enhancements than any other previous Kubernetes release,” Aaron Crickenberger, Google test engineer and Kubernetes 1.14 release lead, told eWEEK. “The continued focus on stability speaks to this community’s commitment.”
Kubernetes 1.14 follows the 1.13 milestone, which was released on Dec. 3 and was the fourth major Kubernetes release in 2018. With the regular release cadence for Kubernetes, features move in a development lifecycle from alpha to beta and eventually to stable, once a given feature is validated to be production-ready.
Windows Node Support
Kubernetes since its inception has supported the Linux operating system, but with the 1.14 release, production support for Windows Nodes is now labeled as a stable feature. With Windows Node support, Windows operating system containers can be scheduled and managed with Kubernetes.
“Windows Server containers bring this whole new dimension to the table,” Crickenberger said. “There are many things on Windows Server that don’t work the same way, if at all, as what is available on Linux.”
Crickenberger added that Windows support will help to better articulate what Kubernetes is, in the context of different operating systems and different runtimes. In his view, it will be a good test to see if organizations really want the ability to orchestrate workloads on hybrid operating system clusters. Efforts to help enable Windows for Kubernetes and containers have been ongoing for multiple years. Among the multiple firms that have worked with Microsoft on the effort is Docker Inc., which is the lead commercial vendor behind the Docker container engine.
“Kubernetes supporting Windows is a monumental step for the industry, and it further confirms the work Docker has been doing with Microsoft to develop Windows containers over the past five years,” Jenny Fong, director of product marketing at Docker, told eWEEK. “We have been collaborating with Microsoft and the Kubernetes community on key components such as Docker Engine and containerd, storage and networking, in addition to support for Active Directory-authenticated workloads, which is part of the release of 1.14.”
Another area of improvement in Kubernetes 1.14 are a series of enhancements to the kubectl (pronounced “Kube – cuddle”) command line interface.
Among the kubectl enhancements is a plugin mechanism that enables developers to share custom commands. Additionally, kubectl now integrates the Kustomize commands, which enables developers to customize YAML (Yet Another Markup Language) configurations for Kubernetes. YAML is used as the core definition language for setting up Kubernetes configuration.
“Continuing to make kubectl this thing that empowers others to identify the workloads that work for them is great,” Crickenberger said.
Kubernetes Enhancement Proposals
One of the biggest changes overall in Kubernetes 1.14 wasn’t any one specific feature, but rather a new process for defining how and when enhancements are accepted and move through the Kubernetes development cycle. The Kubernetes Enhancement Proposal (KEP) approach was first implemented for Kubernetes 1.14 and helped Crickenberger and the broader community manage the enhancements process.
Crickenberger explained that with a KEP, developers need to provide user stories that explain what a new feature is trying to allow people to do and what problems the feature is trying to solve.
“I think that it was just really useful to have a common rallying point to get a better understanding of what’s going in a release,” he said.
In the past, trying to figure out what was going into a Kubernetes release involved looking at different design documents and files in GitHub and elsewhere, according to Crickenberger. He added that taking all of that information, putting it into one place and calling it a KEP is really beneficial.
“Humans are kind of messy, but … we took all of our mess and we shoved it into one place with KEPs,” Crickenberger said. “Now that we’ve agreed this is the place we want to have our mess and talk about it, we can start to better organize it.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.