{"id":575,"date":"2018-10-17T17:07:54","date_gmt":"2018-10-17T17:07:54","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=575"},"modified":"2018-10-17T17:27:36","modified_gmt":"2018-10-17T17:27:36","slug":"kubernetes-containerd-integration-goes-ga","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/17\/kubernetes-containerd-integration-goes-ga\/","title":{"rendered":"Kubernetes Containerd Integration Goes GA"},"content":{"rendered":"

Kubernetes Containerd Integration Goes GA<\/a><\/h3>\n

Authors: Lantao Liu, Software Engineer, Google and Mike Brown, Open Source Developer Advocate, IBM<\/p>\n

In a previous blog – Containerd Brings More Container Runtime Options for Kubernetes<\/a>, we introduced the alpha version of the Kubernetes containerd integration. With another 6 months of development, the integration with containerd is now generally available! You can now use containerd 1.1<\/a> as the container runtime for production Kubernetes clusters!<\/p>\n

Containerd 1.1 works with Kubernetes 1.10 and above, and supports all Kubernetes features. The test coverage of containerd integration on Google Cloud Platform<\/a> in Kubernetes test infrastructure is now equivalent to the Docker integration (See: test dashboard)<\/a>.<\/p>\n

We\u2019re very glad to see containerd rapidly grow to this big milestone. Alibaba Cloud started to use containerd actively since its first day, and thanks to the simplicity and robustness emphasise, make it a perfect container engine running in our Serverless Kubernetes product, which has high qualification on performance and stability. No doubt, containerd will be a core engine of container era, and continue to driving innovation forward.<\/em><\/p>\n

\u2014 Xinwei, Staff Engineer in Alibaba Cloud<\/em><\/p>\n

The Kubernetes containerd integration architecture has evolved twice. Each evolution has made the stack more stable and efficient.<\/p>\n

Containerd 1.0 – CRI-Containerd (end of life)<\/h2>\n

\"cri-containerd<\/p>\n

For containerd 1.0, a daemon called cri-containerd was required to operate between Kubelet and containerd. Cri-containerd handled the Container Runtime Interface (CRI)<\/a> service requests from Kubelet and used containerd to manage containers and container images correspondingly. Compared to the Docker CRI implementation (dockershim<\/a>), this eliminated one extra hop in the stack.<\/p>\n

However, cri-containerd and containerd 1.0 were still 2 different daemons which interacted via grpc. The extra daemon in the loop made it more complex for users to understand and deploy, and introduced unnecessary communication overhead.<\/p>\n

Containerd 1.1 – CRI Plugin (current)<\/h2>\n

\"containerd<\/p>\n

In containerd 1.1, the cri-containerd daemon is now refactored to be a containerd CRI plugin. The CRI plugin is built into containerd 1.1, and enabled by default. Unlike cri-containerd, the CRI plugin interacts with containerd through direct function calls. This new architecture makes the integration more stable and efficient, and eliminates another grpc hop in the stack. Users can now use Kubernetes with containerd 1.1 directly. The cri-containerd daemon is no longer needed.<\/p>\n

Improving performance was one of the major focus items for the containerd 1.1 release. Performance was optimized in terms of pod startup latency and daemon resource usage.<\/p>\n

The following results are a comparison between containerd 1.1 and Docker 18.03 CE. The containerd 1.1 integration uses the CRI plugin built into containerd; and the Docker 18.03 CE integration uses the dockershim.<\/p>\n

The results were generated using the Kubernetes node performance benchmark, which is part of Kubernetes node e2e test<\/a>. Most of the containerd benchmark data is publicly accessible on the node performance dashboard<\/a>.<\/p>\n

Pod Startup Latency<\/h3>\n

The \u201c105 pod batch startup benchmark\u201d results show that the containerd 1.1 integration has lower pod startup latency than Docker 18.03 CE integration with dockershim (lower is better).<\/p>\n

\"latency\"<\/p>\n

CPU and Memory<\/h3>\n

At the steady state, with 105 pods, the containerd 1.1 integration consumes less CPU and memory overall compared to Docker 18.03 CE integration with dockershim. The results vary with the number of pods running on the node, 105 is chosen because it is the current default for the maximum number of user pods per node.<\/p>\n

As shown in the figures below, compared to Docker 18.03 CE integration with dockershim, the containerd 1.1 integration has 30.89% lower kubelet cpu usage, 68.13% lower container runtime cpu usage, 11.30% lower kubelet resident set size (RSS) memory usage, 12.78% lower container runtime RSS memory usage.<\/p>\n

\"cpu\"\"memory\"<\/p>\n

Container runtime command-line interface (CLI) is a useful tool for system and application troubleshooting. When using Docker as the container runtime for Kubernetes, system administrators sometimes login to the Kubernetes node to run Docker commands for collecting system and\/or application information. For example, one may use docker ps<\/em> and docker inspect<\/em> to check application process status, docker images<\/em> to list images on the node, and docker info<\/em> to identify container runtime configuration, etc.<\/p>\n

For containerd and all other CRI-compatible container runtimes, e.g. dockershim, we recommend using crictl<\/em> as a replacement CLI over the Docker CLI for troubleshooting pods, containers, and container images on Kubernetes nodes.<\/p>\n

crictl<\/em> is a tool providing a similar experience to the Docker CLI for Kubernetes node troubleshooting and crictl<\/em> works consistently across all CRI-compatible container runtimes. It is hosted in the kubernetes-incubator\/cri-tools<\/a> repository and the current version is v1.0.0-beta.1<\/a>. crictl<\/em> is designed to resemble the Docker CLI to offer a better transition experience for users, but it is not exactly the same. There are a few important differences, explained below.<\/p>\n

The scope of crictl<\/em> is limited to troubleshooting, it is not a replacement to docker or kubectl. Docker\u2019s CLI provides a rich set of commands, making it a very useful development tool. But it is not the best fit for troubleshooting on Kubernetes nodes. Some Docker commands are not useful to Kubernetes, such as docker network<\/em> and docker build<\/em>; and some may even break the system, such as docker rename<\/em>. crictl<\/em> provides just enough commands for node troubleshooting, which is arguably safer to use on production nodes.<\/p>\n

Kubernetes Oriented<\/h2>\n

crictl<\/em> offers a more kubernetes-friendly view of containers. Docker CLI lacks core Kubernetes concepts, e.g. pod<\/em> and namespace<\/a><\/em>, so it can\u2019t provide a clear view of containers and pods. One example is that docker ps<\/em> shows somewhat obscure, long Docker container names, and shows pause containers and application containers together:<\/p>\n

\"docker<\/p>\n

However, pause containers<\/a> are a pod implementation detail, where one pause container is used for each pod, and thus should not be shown when listing containers that are members of pods.<\/p>\n

crictl<\/em>, by contrast, is designed for Kubernetes. It has different sets of commands for pods and containers. For example, crictl pods<\/em> lists pod information, and crictl ps<\/em> only lists application container information. All information is well formatted into table columns.<\/p>\n

\"crictl\"crictl<\/p>\n

As another example, crictl pods<\/em> includes a \u2013namespace<\/em> option for filtering pods by the namespaces specified in Kubernetes.<\/p>\n

\"crictl<\/p>\n

For more details about how to use crictl<\/em> with containerd:<\/p>\n