What and why is Docker doing in Moby to integrate with Kubernetes?

Yesterday’s official Docker official Kubernetes announcement in their products is an ideal reason to continue one of our latest publications on CRI-O as an alternative approach to launching containers in Kubernetes. It has already touched on the topic of cri-containerd - a kind of “Docker response” to the attempts of the Open Source-community to get away from the sole supplier of technology for containers. What caused the new turn in the life of Docker and how its pattern is confirmed in the recent history of Moby projects?

Freedom of choice: from Kubernetes and from Docker

Kubernetes as PaaS for working with containers was originally created with the idea of giving its users the freedom to choose the implementations of certain functions of the platform. (For more on this and why Kubernetes is more than PaaS, we wrote in a separate article .) The technology used to launch containers is one example of such implementations. Since the Open Source-world of containers is not limited to Docker , for a long time now Kubernetes has the ability to use rkt as an executable environment for containers. Yes, by and large such an opportunity appeared due to the efforts (and in the interests) of one particular company - CoreOS - but from this year rkt has been included in the number of projects supported by the non-profit organization CNCF, as well as its competitor from Docker - containerd (and Kubernetes develops in the same fund) .
')
However, by default Kubernetes is still not using rkt at all, but the de facto standard in the industry - Docker. The very desire to provide users with flexibility, “united” with the interests of some companies, led the project to further expand the choice of executable media through the creation of the Container Runtime Interface (CRI) - it appeared with the release of Kubernetes 1.5.

With the help of CRI, the “connection” of new container technologies has become unified and simple, and for the first time this was demonstrated in the framework of the CRI-O project, which we wrote about in more detail last week. Formally, CRI-O allows you to use any executable environment for containers that is compatible with the OCI specification ( runtime-spec ) , and in fact today supports the well-known runC (the project separated from Docker in 2015 and which became the reference implementation of the OCI standard) and Clear Containers (from Intel) .

In announcing the support of Kubernetes, Docker emphasized that "the Docker architecture philosophy has always been about providing choice and flexibility ." So they officially explained the appearance of the Kubernetes block in their platform, illustrated by 4 layers:

The layers of the platform are explained as follows (from bottom to top):

containerd as an executable environment for containers that meets the industry standard;
Swarm orchestration that turns a group of nodes into a distributed system;
Docker Community Edition , offering developers a simple workflow for creating and delivering applications in containers;
Docker Enterprise Edition to manage the full cycle of secure software delivery and container launch in production.

And the point “Swarm orchestration” is now formulated as “Swarm or Kubernetes orchestration”, and later (who knows?) Can be extended to other solutions.

In the official announcement of the company, another reason for integrating Kubernetes support into the Docker platform, the wishes of its customers, was announced. Docker users "either have already designed services to work on Kubernetes, or want Kubernetes because of the specific features they need." If you look at the situation more objectively, it is obvious that Kubernetes, like Docker at one time, is becoming an “industry standard”. And since end users choose the orchestration tool rather than the specific underlying container technology, the only option to keep (and expand) the audience for Docker is to meet the needs of the industry itself. What are the market prospects for the direct competitor Kubernetes, which is being developed within Docker - Swarm, is a question that remains open and should be clarified in the near future by company policy.

Moby and Kubernetes

All layers of the Docker platform are collected using the special Open Source-project Moby , about which we also wrote more .

In short, with his help, Docker seeks to maintain its leadership in the ecosystem of containers, promoting it in the community as a standard for "building systems based on containers." Formally, Moby also represents all upstream projects used to build the Docker platform. (In total, they account for an average of 8800 pull requests per year.)

Talking about the participation of Moby in the announced support for Kubernetes for Docker, the authors begin by saying that these works did not begin yesterday, but have been underway for about a year . And the main events are presented as follows:

Details about the “close relationship” of Moby and Kubernetes are given on the example of some projects that form the Docker platform and not only.

containerd

In the past, containerd is a Docker component that implements the runtime environment for running containers:

As in the case of runC, he suffered the fate of separation from Docker as an independent Open Source project (earlier this year he was transferred to the CNCF foundation). Its current version is 1.0.0-beta.2 , and the final release 1.0.0 should happen very soon. Being one of the basic components of Docker, the project seeks to gain wider recognition, and cri-containerd (initiated in April of this year) has become one of the main initiatives aimed at its distribution.

Being one of the first implementations of the already mentioned Kubernetes CRI interface, cri-containerd claims to become a popular solution for launching containers into Kubernetes in an era when the “heavy” Docker will not be the default option for K8s users. The current status is the alpha version, which has the full range of capabilities and is undergoing the “final stabilization process”. On September 14, Liu Lantao from Google told the Moby Summit in Los Angeles about the state of cri-containerd, noting that the project "very well" meets the requirements of CRI and Kubernetes, and also promised to release a beta version by the end of the year.

Here's how the participation pattern for containerd in Kubernetes will change with cri-containerd:

Note to illustration: dockershim is the current implementation of runtime for Docker containers in K8s.

More detailed scheme of work cri-containerd:

You can try cri-containerd in action using various instructions:

quick start with Ansible ;
installation via kubeadm ;
Installing from LinuxKit on a local virtual machine (see below for more details) .

Linukit

LinuxKit is a utility announced simultaneously with Moby for building compact Linux systems for containers. As detailed in the project description, LinuxKit "is designed to build and run clustered applications using container orchestration tools, such as Docker or Kubernetes, but not limited to them."

The project documentation contains the article “ Kubernetes and LinuxKit ”, describing the creation of minimal OS images with Kubernetes. By default, the Docker Engine installed in these K8s images is used, and to go to cri-containerd, it is enough to add one command during the build process.

InfraKit

InfraKit is a set of utilities for infrastructure orchestration, designed to make it "self-managing and self-healing." Technically, the project consists of a set of small controllers, called plug-ins and implementing various interfaces (Service Provider Interfaces, SPI — see the documentation for details). One of these interfaces, the Flavor SPI, is responsible for application-specific configurations and for checking its state. Examples of plug-ins like Flavor are Swarm and Kubernetes, which are responsible for checking the presence of a node in the cluster, suspending the reception of tasks by the node from the scheduler, etc.

The documentation for the Kubernetes plugin in InfraKit was recently summarized in this README . Also available is a 17-minute video from the lead developer of the project (David Chung) with a demonstration of the launch of the Kubernetes cluster on AWS using InfraKit and AWS CloudFormation. The bootstrap node performs a long sequence of actions from installing the latest version of the Docker Engine to updating labels to mount and format volumes. The download script is generated by the InfraKit plug-ins and templates.

libnetwork

libnetwork is the implementation of the Container Network Model (CNM) network interface for containers used in Docker. CNM is essentially a direct competitor to the Container Networking Interface (CNI), as we wrote in this article . Kubernetes has become one of the early users of CNI, inviting everyone who intends to develop their network interfaces to do this with plug-ins to CNI, which already connect to Kubernetes.

Speaking about container standards last month, Scott McCarty from Red Hat called CNM a “de facto standard” because “many network solutions vendors create utilities that are suitable for both CNI and CNM”.

Once in Docker, they intend to stay with CNM instead of CNI, what option is left for them to integrate with Kubernetes? That's right, make CNI plugins that implement libnetwork support. The process has already been launched, but has not yet entered the master branch.

It is gratifying to see Docker’s example of “going in the opposite direction” - for the benefit of all users of the upstream version of Kubernetes: the alpha version of IPVS support for load balancing introduced in K8s 1.8 was based on the code from libnetwork, originally written for Docker Swarm .

Notary

Notary is a Docker project for signing and verifying containers, based on the developments of The Update Framework (TUF) and written in Go (instead of Python with TUF) . Earlier this month, a vote was initiated on the inclusion of Notary and TUF in the incubator of the CNCF projects. Many representatives of the committee from the fund have already supported him, but the final decision has not yet been made. Notary still has no formal binding to K8s, but Docker expects that after its adoption at the CNCF, "direct integration with other CNCF projects such as Kubernetes will be implemented."

libentitlement

The libentitlement library is intended for high-level rights management in containers. The so-called entitlements allow / prohibit various security functions in the configuration profile, and the library is designed to manage these profiles for containers. A list of proposed for implementation of the entitlements can be found here .

The project is still young - the first commit in its repository took place in May. According to Docker, the development of libentitlement is carried out with the participation of the Kubernetes community. The project documentation contains the list of default entitlements for Kubernetes, however at the moment there is only the promising “TBD”.

Summarizing

The world of containers has become an interesting place for competition and simultaneous cooperation of Open Source-projects and the companies behind them.

Even without having Kubernetes among the orchestration tools integrated into the Docker platform, the engineers of this company have for some time been working on projects specifically targeted at K8s or closely intertwined with its ecosystem.

The formal announcement of Kubernetes support is a significant and pleasant event for the community, confirming the company's words about freedom of choice. For Docker itself, this is largely a necessary measure, similar to the recent similar case with the Mesosphere .

Some details about what Kubernetes’s notorious end-user support for Docker products means can be found in the relevant company blog posts: Docker CE for Mac and Windows , Docker EE .