12 Kubernetes distributions leading the container revolution

Kubernetes and containers are changing how applications are built, deployed, and managed. These distros are leading the charge

12 Kubernetes distributions leading the container revolution
Current Job Listings

Kubernetes has become the project to turn to if you need container orchestration at scale. The open source container orchestration system out of Google is well-regarded, well-supported, and evolving fast.

Kubernetes is also sprawling, complex, and difficult to set up and configure. Not only that, but much of the heavy lifting is left to the end user. The best approach, therefore, isn’t to grab the bits and try to go it alone, but to seek out a complete container solution that includes Kubernetes as a supported, maintained component.

Here I’ve listed the 12 most prominent Kubernetes offerings—what amount to distributions that incorporate Kubernetes plus container tools, in the same sense that various vendors offer distributions of the Linux kernel and its userland.

Note that this list does not include dedicated cloud services, such as Amazon EKS or Google Kubernetes Engine, but focuses on software distributions that can be run locally or as a cloud-hosted option.

CoreOS Tectonic

CoreOS is the provider of a container-focused Linux distribution, compatible with Docker but with an opinionated image format and runtime of its own, and an “enterprise-grade Kubernetes” distribution. Together they form the foundation of the CoreOS Tectonic stack. 

The CoreOS operating system, Container Linux, stands apart chiefly by being delivered as a set of containerized components. This way, automated updates to the OS can be slipstreamed into production without taking down running applications. CoreOS also touts “one-click” updates to Kubernetes. CoreOS Tectonic runs on Amazon Web Services, Microsoft Azure, and bare metal. 

See InfoWorld’s review of CoreOS Container Linux for more details.

Canonical Distribution of Kubernetes

Canonical, makers of Ubuntu Linux, provides its own Kubernetes distribution. One of the big selling points for the Canonical Distribution of Kubernetes is the widely respected, well-understood, and commonly deployed Ubuntu Linux distribution underneath. Canonical claims that its stack will work in any cloud or on-prem deployment, with support included for both CPU- and GPU-powered workloads. Paying customers can have their Kubernetes cluster remotely managed by Canonical engineers.

Canonical and Rancher Labs (see below) co-produce a product, Cloud Native Platform, that pairs Canonical’s Kubernetes distro with Rancher’s container management platform. The idea is to use Kubernetes to manage the containers running in each cluster, and use Rancher to manage multiple Kubernetes clusters. Cloud Native Platform will become available with Rancher 2.0, which is currently available in a beta preview. 

Docker Community Edition / Docker Enterprise

For many of us, Docker is containers. And since 2014, Docker has had its own clustering and orchestration system, Docker Swarm, which until recently stood as a competitor to Kubernetes. Then in October 2017, Docker announced it would be adding Kubernetes—in its unmodified, vanilla state—as a standard pack-in with both Docker Community Edition and Docker Enterprise 2.0.

In short, Docker Inc. has read the writing on the container orchestration wall and acknowledged that Kubernetes is more suitable than Swarm for managing large and complex container environments. However, Docker still includes its original clustering system, “swarm mode”, for more modest jobs—for instance, a local, behind-the-firewall application that isn’t likely to grow much, or to maintain existing swarm-mode clusters that don't need to be revamped.

Heptio Kubernetes Subscription

Two of Kubernetes’s creators, Craig McLuckie and Joe Beda, founded Heptio to offer services and products around Kubernetes. Their first major offering is the Heptio Kubernetes Subscription (HKS), a Kubernetes deployment with paid, 24/7 support provided by Heptio. Pricing starts at $2,000 per month.

The main pitch with Heptio is enterprise-grade Kubernetes without vendor lock-in. Deployments can run on public clouds or private hardware. All the tools offered by Heptio to manage Kubernetes configurations are open source, and fixes are delivered directly to the supported clusters.

Mesosphere DC/OS

Mesosphere DC/OS uses Apache Mesos to turn a cluster of machines into a single resource that can be dynamically partitioned for multiple applications. Kubernetes is supported as one of many application packages on DC/OS, allowing you to install, run, and update Kubernetes across a DC/OS cluster.

There is room to quibble with whether DC/OS is a Kubernetes distribution per se, considering Kubernetes is not exactly part of DC/OS, but can be deployed through DC/OS like other supported apps—in something like the way a Linux application is made available through a Linux distro’s package management system. Nevertheless, Mesosphere’s approach to Kubernetes hews closely to how Kubernetes works—e.g., it uses the mainline community distribution of Kubernetes to ensure a high degree of compatibility with the existing toolset.

Mirantis Cloud Platform

Mirantis Cloud Platform incorporates OpenStack, Kubernetes, or a combination of the two as the substrate for an “agile infrastructure platform,” as Mirantis puts it. In a nutshell, Mirantis Cloud Platform is a single, integrated solution for orchestrating VMs, containers, and bare-metal servers. Apps deployed on the platform are managed across the lifecycle in “devops style,” using Salt as the configuration management tool, with integrated CI/CD support to ensure apps deploy correctly.

Mirantis Cloud Platform can run Kubernetes directly on bare metal, in OpenStack clusters, or on public clouds. Mirantis claims that Mirantis Cloud Platform makes it easier to work with Kubernetes because the work of provisioning the infrastructure underneath Kubernetes doesn’t fall to the end user.

Platform9 Managed Kubernetes

Most Kubernetes distributions focus on making Kubernetes manageable from the inside out and the top down. Platform9 Managed Kubernetes runs in whatever environment you deploy it in—local bare metal, remote public cloud—but is remotely managed as a service by Platform9’s engineers.

Platform9 rolls out updates to Managed Kubernetes approximately every six weeks under customer supervision. Functions that would normally have to be added by hand to a Kubernetes cluster, like user quotas for multi-tenancy scenarios, are provided by Platform9. Also included is integration with Platform9’s Fission project, a serverless compute aka function-as-a-service system that works with most any programming language with a containerized runtime.

Rancher 2.0

Rancher Labs has incorporated Kubernetes into its container management platform—called, simply, Rancher—with version 2.0, currently in beta. Rancher 2.0 works on a higher level than other Kubernetes distributions, sitting atop your Linux hosts, Docker containers, and Kubernetes nodes, managing all of them at arm’s length regardless of location or infrastructure. It can even manage Kubernetes clusters on Amazon EKS, Google Kubernetes Engine, Azure Container Service, and other Kubernetes-as-a-service clouds. 

Rancher also comes with its own Kubernetes distribution. Rancher is meant to remove a lot of the drudgery from the process of setting up a Kubernetes cluster and customizing Kubernetes for a specific environment, without allowing those customizations to get in the way of smooth upgrades to Kubernetes—a key consideration for such a fast-moving and constantly updated project.

Red Hat OpenShift

Red Hat OpenShift, Red Hat’s PaaS product, originally used Heroku buildpack-like “cartridges” to package applications, which were then deployed in containers called “gears.” Then Docker came along, and OpenShift was reworked to make use of the new container image and runtime standard. Inevitably, Red Hat also adopted Kubernetes as the orchestration technology within OpenShift.

OpenShift was built to provide abstraction and automation for all the components in a PaaS. This abstraction and automation also extend to Kubernetes, which still imposes a fair amount of administrative burden, so OpenShift can be used to alleviate that as part of the larger mission of deploying a PaaS.

See InfoWorld’s review of Red Hat OpenShift 3 for more details.


HyperHQ, providers of the Hyper.sh cloud service for running containers, have developed Stackube, a “Kubernetes-centric OpenStack distro.” Normally, OpenStack uses a component called Nova to provision and manage compute nodes; Stackube uses Kubernetes instead. But other than that, it uses “vanilla” OpenStack and Kubernetes, with all the additional details handled by OpenStack plugins.

The big advantage HyperHQ claims for Stackube is that it can offer varying degrees of multitenancy depending on which container runtime is used. For “soft” multitenancy, there’s Docker; for more industrial-strength separation of resources, there’s HyperContainer, which uses hypervisor-level isolation.

SUSE Cloud as a Service Platform

Best known for a Linux distribution widely popular in Europe, SUSE also offers the SUSE CaaS Platform. Conceptually, it’s reminiscent of CoreOS Tectonic—a bundling of a bare-metal “micro” OS that runs containers, Kubernetes as the container orchestration system, a built-in image registry, and cluster configuration tools.

SUSE CaaS Platform can run on public clouds as well as local bare metal, but with the caveat that “SUSE does not currently support any integration into the underlying cloud infrastructure.” Meaning that SUSE CaaS Platform isn’t designed to complement Amazon EKS or Google Kubernetes Engine, but to circumvent them, allowing you to run containers across multiple clouds and datacenters. 


Gravitational, maker of the Teleport SSH server, also produces Telekube, a “production hardened” Kubernetes distribution that runs on local or remote clusters. Telekube is positioned as a solution for a private SaaS platform, or for running Kubernetes as a service throughout multiple regions or hosting providers.

Apps on Telekube must be prepared to run in containers on Kubernetes. They must also be packaged into “Bundles” that are then published to Kubernetes clusters for distribution. Bundling requires some additional work on top of all of the other preparation needed to deploy container-based applications, but the Bundle manifest is the only Telekube-specific addition that you need to maintain.