Docker Inevitably Embraces Kubernetes Container Orchestration
April 17, 2018 Timothy Prickett Morgan
Sometimes you can beat them, and sometimes you can join them. If you are Docker, the commercial entity behind the Docker container runtime and a stack of enterprise-class software that wraps around it, and you are facing the rising popularity of the Kubernetes container orchestrator open sourced by Google, you can do both. And so, even though it has its own Swarm orchestration layer, Docker is embracing Kubernetes as a peer to Swarm in its own stack.
This is not an either/or proposition, and in fact, the way that the company has integrated Kubernetes inside of Docker Enterprise Edition, the high-end commercial distribution of its container platform, companies can – and often will – run both Swarm and Kubernetes side-by-side, orchestrating the scale and placement of container workloads on the same physical clusters.
The integration of Kubernetes into the Docker Enterprise stack, which comes with the 2.0 release of the software announced this week, serves to remind us that Kubernetes is not, in and of itself, a platform, but an orchestration layer that can be embedded into a platform. And just as Kubernetes, which is inspired by Google’s Borg cluster and container management software, was designed to have many different job schedulers plug into to control the placement of applications on the search engine giant’s own vast infrastructure, a container platform will need to have multiple container orchestrators because applications are often designed for specific orchestration layers. (More on this in a second.)
The thing that enterprises need – and importantly, will pay for – is a single container format that runs on their clusters with a consistent set of application lifecycle, security, automation, governance, and auditing functions no matter what orchestration of clustering options are chosen. This is the hard thing about creating enterprise software, and very few platforms based on open source software have accomplished this feat. Red Hat and SUSE Linux did it starting from a Linux operating system base; Cloudera, MapR Technologies, and Hortonworks have built such platforms starting from a Hadoop data analytics foundation; and to varying degrees, CoreOS (now part of Red Hat) and Docker (the company) have done so starting with the container as their kernel and working out from there. This is where all of the venture capital and private equity money really gets blown after all the hype and hubbub dies down after a new technology emerges and is going to change everything. If you want the money, you have to do this hard work, and it is not as exciting as saying you will change the world. This is more about fitting into the business world, with red tape and governance.
Docker Enterprise has been out for nearly two years now, starting out first as Docker Datacenter before being reworked into the Enterprise Edition 1.0 stack back in March 2017. Docker Enterprise includes the Compose container maker, the Datacenter management tool, and the Swarm orchestrator as well as hooks into the Docker Hub repository for container images and the “secrets” security paradigm that was rolled out in early 2017. Now it also includes a variant of the Kubernetes orchestrator, which is pulled from the upstream project into Docker Enterprise and supported with patches as needed by Docker. It is available to all customers at no incremental charge, but they have to be on a support contract. Pricing for Docker Enterprise, which comes in Basic, Standard, and Advanced versions with varying levels of features turned on and two different levels of tech support (24×7 and 9×5), range from $750 to $3,500 per node per year. The Community Edition, which is free, does not have the Kubernetes orchestrator built into it, so you have to pay to play.
Kubernetes is, given its heritage, a more complex piece of code than Swarm, and one of the tricks to integrating Kubernetes is to mask some of that complexity while still making its functionality available.
“The challenge to business is that they are trying to run containers at great scale,” David Messina, senior vice president of marketing at Docker, tells The Next Platform. “For them, this is very much a platform decision, and it is about adding new things to the platform that allows them to better manage containers across their lifecycle, from development to deployment. What drove us here is that our customers had use cases for Kubernetes, but Kubernetes often gets portrayed as the platform when it is in fact just a part of the platform. So many of our customers have rolled out Swarm, and they see the operational simplicity of it and Docker-native experience with it, and one of the things that makes our implementation of Kubernetes is that the developers do not have to make a decision. Other container platforms were forcing the developers to learn complex structures around Kubernetes, while the primary audience for Kubernetes is the operators. With this orchestration choice, developers can create code and containers independently from the orchestration choice, and at deployment time, the operator can make Swarm or Kubernetes available.”
This integration means, says Messina, that companies familiar with its Docker stack will not have to hire a bunch of Kubernetes experts to make use of Kubernetes – it is all integrated into Docker Enterprise and is kept current by Docker. The idea is that the higher-end orchestration that is available thanks to Kubernetes will allow Docker shops to crank up the application ratios on their administrators. The idea is to also eliminate Kubernetes cluster sprawl. With other Kubernetes platforms, which do not have the ability to handle multiple divisions or teams as well as span across geographies within a single management hierarchy, every new team or division or geo requires its own Kubernetes cluster. Docker Enterprise has availability zones that are comprised of logical and physical partitions, with role-based access for application development and deployment. This partitioning can be as fine-grained as a single node on the cluster, and in typical large shops, a Docker Enterprise cluster might have 1,000 server nodes with tens of different teams or divisions with their own availability zones, with maybe a three or four partitions. In some cases, the clusters span multiple datacenters, spread out for disaster recovery.
At the moment, Docker has more than 450 commercial customers who are paying for Enterprise Edition. It is hard to say how many enterprise customers have put Docker containers, in one form or another, into production, but it has to be orders of magnitude higher, including other commercial Docker stacks (like CoreOS) as well as the Docker environments among the major cloud providers – Amazon Web Services, Google Cloud Platform, and Microsoft Azure being the most important ones right now.