From Silos to Services: Cloud Computing for the Enterprise

Nov 19 2017   11:58AM GMT

The Evolution of the Kubernetes Kommunity and Konformance

Brian Gracely Brian Gracely Profile: Brian Gracely

Red Hat

This past week the Cloud Native Computing Foundation (CNCF) announced their “Certified Kubernetes Conformance Program“, with 32 distributions or platforms being on the initial list. This allows companies to validate that their implementations do not break the core Kubernetes API implementations, along with allowing them access to usage of Kubernetes naming and logos.

Given that the vast majority of vendors are either now offering Kubernetes, or plan to offer Kubernetes in 2018, this is a valuable step forward to help customers reduce concerns they have about levels of interoperability between Kubernetes platforms.

[NOTE: We’ve been covering all aspects of Kubernetes on the new PodCTL podcastThe show is available on RSS FeediTunesGooglePlayStitcherTuneIn and all your favorite podcast players.]

Beyond the confidence this can provide the market, the Kubernetes community should be credited for doing this in a transparent way. Each implementation needs to submit their validated test results via GitHub, and the testing uses the same automated test suite that is used for all other Kubernetes development. There’s no 3rd-party entity involved.


This may seem like a nitpick, but I think it’s important to get some terminology correct, as this has confused the market with previous open source projects. We dissected an open source release in previous posts. While open source projects have been around for quite a while, and usage has grown significantly over the years, the market still confuses how they speak about them. Let’s look at a couple examples:

#1 – “The interoperability that this program ensures is essential to Kubernetes meeting its promise of offering a single open source software stack supported by many vendors that can deploy on any public, private or hybrid cloud.” (via CNCF Announcement)

#2 – Dan Kohn said that the organization has been able to bring together many of the industry’s biggest names onboard. “We are thrilled with the list of members. We are confident that this will remain a single product going forward and not fork,” he said. (via TechCrunch)

You’ll notice that terms like product and stack are interchanged for project. This happens quite a bit, which can sometimes set the wrong expectations for customers in the market who are used to certain support or lifecycle expectations from software they use. We often saw this confusion with OpenStack, which was actually many different projects all puled together under one umbrella name, but could actually be used together or independently (e.g. “Swift” Object Storage).

It’s important to remember that Kubernetes is an open source project. Things that passed that conformance test are categorized at either “distributions” or “platforms”, which means they are vendor products (or cloud services). And this program doesn’t cover things that plug into non-Kubernetes-API aspects like Container Network Interface (CNI) or Container Storage Interface (CSI) or Container Registries.

Beyond the Conformance Tests (and Logos)

While there are very positive aspects of this program, there are other elements that still need to evolve.

Projects vs. Products (Distributions & Platforms)

It is somewhat unusual to have a certification of a open source project, especially a fast-moving one like Kubernetes, since the project isn’t actually certified, but the vendor implementations of that project (in product form). Considering that Kubernetes comes out with a new release every 3 months, it will be interesting to watch how the community (and the marketplace) reacts to constantly having to re-certify, as well as questions that will arise about backwards compatibility.

Another area which is somewhat unique is that vendors have been allowed to submit offerings before they are Generally Available in the market.

A third aspect that will be interesting to watch is how certain vendors handle support for implementations if they don’t really contribute to the Kubernetes project. For example, Pivotal/VMware, Cisco and Nutanix have all announcement partnerships with Google to add Kubernetes support to their platform. Given that those three vendors have made very few public contributions to the Kubernetes projects, these appear to be more like “OEM” partnerships. So how will a customer get support for these offerings? Will they always need a fix from Google, or will they be able to make patches themselves?

Long-Term Support (LTS)

One last area that will be part of the community discussion in 2018 will be an LTS strategy, or Long-Term Support. With new Kubernetes releases coming out every three months, many companies have expressed an interest in a model that is more focused on stability. In the past this eventually happened with the Linux community, and is beginning to happen with OpenStack distributions. It will be an interesting topic to watch, as many people within the community say that LTS models stifle innovation. On the flip-side is customers that might need/want to run the software, but are struggling to keep up with frequent upgrades and patching.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: