kubernetes

Kubernetes 1.14 Puts the Spotlight on Consistent Change, Windows Node Support, and Cluster API

Another quarter, another Kubernetes release! We’re back again to highlight some of the bigger ticket improvements in the ecosystem for Kubernetes 1.14. In keeping with one of the project values (“Community over product or company”), this cycle yielded lots of interesting cross-organization collaborations—one improves the way we introduce change into the ecosystem, one fundamentally enhances the platforms Kubernetes can be run on, and one redefines cluster lifecycle management.

This work never happens in a vacuum, though. It happens across thousands of contributors, across multiple organizations, in countless time zones. Thank you to all of the contributors, especially the 1.14 Release Team, for producing yet another high-quality, on-time Kubernetes release.  

  

Applying Change Consistently

As the Kubernetes community collaborates across multiple companies and timezones, it’s increasingly important to provide a framework to present changes to the project in a consistent and clear manner. To serve this need, the Kubernetes Enhancements Proposal (KEP) was created. KEPs are process documents that capture the various elements and motivations for a change to Kubernetes and include important references, such as documentation for enhancements, graduation criteria, and test plans.

At the start of the Kubernetes 1.14 cycle, the Release Team announced that KEPs would be a requirement for all enhancements (originally called features) merging into the primary kubernetes/kubernetes repository. The goal there is that sufficient focus on the KEP process and other SIG PM efforts will eventually yield a community roadmap. SIG PM is the special interest group responsible for product, program, and project management.  

Windows Node Support

One of the most anticipated enhancements of the v1.14 release is the graduation of Windows support to stable, effectively unlocking Kubernetes for Windows-powered applications. With v1.14, Kubernetes users can now incorporate Windows worker nodes alongside Linux worker nodes, creating a heterogeneous cluster where both Windows-based and Linux-based apps can be deployed. Organizations with investments in a variety of programming languages and frameworks can now begin to use the same tools and processes to manage their workloads, regardless of the underlying operating system, taking full advantage of the cloud native ecosystem powered by Kubernetes. These organizations immediately gain operational efficiencies from using a uniform set of tools and by having access to Kubernetes for their Windows workloads.

The graduation of Windows support to stable strengthens Kubernetes' position in the industry by significantly expanding the types of applications supported. We are not done yet though. The community will continue working to advance Windows support in Kubernetes, and we expect additional features to land in the next few releases. Windows users can get started now by containerizing existing or legacy applications, or by building net new Windows or .NET based applications for Kubernetes. A hearty congratulations to all of the contributors at Cloudbase Solutions, Docker, Google, Microsoft, Pivotal, and VMware who had a hand in project managing and bringing Windows support over the finish line for Kubernetes 1.14.  

Cluster API

You may have heard some buzz around a new project called Cluster API, which aims to deliver declarative cluster creation and management via Kubernetes APIs. We’ve previously discussed exactly why this pattern is exciting. Check out Tim St. Clair’s post (The What and the Why of the Cluster API) for a detailed dive into Cluster API. In the Kubernetes 1.14 timeframe, we see tremendous forward momentum on bringing Cluster API to v1alpha1 state through deep collaboration from several contributors across the various provider implementations (AWS, Azure, vSphere, to name a few). We are all working to build a tool that vastly improves the overall cluster lifecycle story for the community.  

  

Getting Involved in Kubernetes 1.15

As the community closes the books on Kubernetes 1.14, the plans for building the 1.15 Release Team are already under way. This time around, the team will be led by Claire Laurence (Pivotal), with several VMware contributors as role leads (Kenny Coleman, Enhancements; Dhawal Bhanushali, Test Infra; Nicholas Lane, Bug Triage; Jorge Castro, Communications), showing our dedication to delivering high-quality Kubernetes releases to the community.

In my role as Co-Chair for SIG Release, I assist with staffing for the Release Team. If you’re interested in becoming a shadow for the Kubernetes 1.15 Release Team, keep your eyes peeled on the official GitHub tracking issue, where I’ll be coordinating the shadows questionnaire. All contributors, regardless of skill level, are welcome to submit the questionnaire after it becomes available. Feel free to reach out to me on Twitter (@stephenaugustus) if you have any questions.