As Kubernetes adoption grows, so too does the maturity of the development process.
Kubernetes is an open source container orchestration platform that is run as a Cloud Native Computing Foundation (CNCF) project. On Sept. 27, Kubernetes 1.12 became generally available, with new features that help to improve performance, scalability and security.
"When I look at the the things that have come through in this release, in terms of features, I feel like this is what you would expect, and there's not necessarily something shocking or exciting here," Tim Pepper, senior staff engineer at VMware and release lead for Kubernetes 1.12, said.
As part of the multi-stakeholder release management process for Kubernetes, there is a different release lead for each new major Kubernetes milestone. The Kubernetes 1.12 update marks the first time the release lead position was led by VMware. For the Kubernetes 1.11 release, Red Hat's Josh Berkus was the release lead.
Pepper said the way the release team works is that when it comes to subject matter and technical expertise, they defer to the more than 30 different Special Interest Groups (SIGs) that work on specific areas of Kubernetes.
Server Operating System Parity
While Kubernetes was initially developed to work on Linux, it is also supported on Windows, with an increasing level of feature parity.
For features that get labeled as Generally Available and Stable, Pepper said during the Kubernetes 1.12 cycle there were some capabilities that came to Windows, as questions came up during the development process about whether the features were at parity with how they work on Linux.
"Folks said you know what, this is not quite at parity and we actually should start trying to strive for that," Pepper said. "If we call a feature stable, people are going to expect it to work the same (on supported operating systems)."
Overall, he noted that the conversations about feature parity across Kubernetes running on Linux and on Windows is all part of the larger theme to emerge during the 1.12 release regarding maturity and sophistication.
When Kubernetes got started, all of its various sub-projects and components were managed under a single, large Github repository. In recent months, Pepper said there has been conversations about splitting up the monolith into more discrete separate development efforts and processes.
"My worry from a release team perspective is that as all of these things spread out, integration is hard, Pepper said. "I think this is going to be a big area where we need to manage how we scale."
Reference Architecture vs. Distributions
Today, the mainline open source Kubernetes project can be and is currently used by developers and some organizations for deployment. That might not be the case in the future, however, as the Kubernetes project determines what role it wants to play in the production deployment ecosystem.
"Are we actually outputting a reference implementation, or is there an upstream distribution where we are like a Debian to the other downstream consumers?" Pepper said. "There's discussions that are happening around that, and it'll be interesting to see over the coming year how that plays out."
Pepper said there is already a degree of conformance testing with Kubernetes, as well as certified vendors, distributions and hosting providers.
"We haven't ended up with every vendor, distribution and hosting platform being somehow a unique snowflake where users can't port a pod from one system to another," he said. "We wouldn't want to have the future become that."
Sean Michael Kerner is a senior editor at ServerWatch and InternetNews.com. Follow him on Twitter @TechJournalist.