What? Kubernetes decides to ditch Docker?

It’s true. Kubernetes has now abandoned Docker.

Github.com/kubernetes/…

Docker support in Kubelet is now deprecated and will be removed in future releases. Kubelet previously used a module called Dockershim to implement CRI support for Docker. However, the Kubernetes community has identified maintenance issues associated with this and recommends that you consider using an available container runtime with a full implementation of CRI (compatible with V1Alpha1 or V1).

In short, Docker does not support the Kubernetes runtime API CRI (Container Runtime Interface), and Kubernetes users have been using a bridge service called “Dockershim”. Dockershim can convert the Docker API to CRI, but Kubernetes will no longer provide this bridge service in future releases.

Of course, Docker itself is a very powerful tool for creating development environments. But in order to understand the cause of the current situation, we need to fully analyze Docker’s role in the existing Kubernetes architecture.

Kubernetes is an infrastructure tool that groups a variety of different computing resources (such as virtual/physical machines) into a unified mass of computing resources that can be used by applications or shared with others. In such an architecture, Docker (or container runtime) is only used for scheduling through the Kubernetes control plane to run applications within the actual host.

From the architecture diagram above, you can see that each Kubernetes node communicates with the control plane. Kubelet on each node retrieves metadata and performs CRI to create/delete containers on that node.

1. But why was Docker abandoned?

As mentioned earlier, Kubernetes can only communicate with CRI, so to communicate with Docker, you must use a bridge service. This is the first reason to ditch Docker.

To explain the next reason, we have to talk a little bit about the Docker architecture. First refer to the following schematic diagram.

Yes, Kubernetes actually needs to stay inside the red box. Docker networks and volumes are excluded.

These unused features can themselves pose a security risk. In fact, the less functionality you have, the less attack surface you have.

Therefore, we need to consider using an alternative, the CRI runtime.

2. CRI runtime

There are two main implementations of the CRI runtime.

containerd

If you just want to migrate from Docker, containerd is the best option. Because it actually works inside Docker and does all the “runtime” work, as shown above. More importantly, the CRI it provides is actually 100% provided by Docker.

Containerd is also fully open source, so you can check out the documentation and even contribute to the project on GitHub.

Github.com/containerd/…

CRI-O

Cri-o is a CRI runtime developed primarily by Red Hat employees. The big difference is that it doesn’t rely on Docker and is currently available in Red Hat OpenShift.

Interestingly, RHEL 7 also doesn’t officially support Docker. Instead, Podman, Buildah, and Cri-O are available only for container environments.

github.com/cri-o/cri-o

Cri-o’s advantage is its minimalist style, or that it is designed to exist as a “pure CRI” runtime. Unlike Containerd, which is part of Docker, Cri-O is essentially a pure CRI runtime and therefore does not contain anything other than CRI.

Migrating from Docker to Cri-O is often more difficult, but cri-O can at least support the proper operation of Docker containers on Kubernetes.

3. One more thing…

When we talk about container runtimes, be aware of exactly what type of runtimes we are talking about. There are two runtimes: CRI runtimes and OCI runtimes.

CRI runtime

As mentioned earlier, CRI is an API provided by Kubernetes for communicating with the container runtime to create/drop containerized applications.

Each containerized application communicates in gRPC via IPC as Kubelet and runs on the same host. The CRI runtime is responsible for getting the request from Kubelet and executing the OCI container runtime to run the container. It’s a little bit more complicated, and we’re going to illustrate that with diagrams.

Therefore, the CRI runtime does the following:

  1. Get the gRPC request from Kubelet.

  2. Create the OCIjson configuration according to the specification.

OCI runtime

The OCI runtime is responsible for generating containers using Linux kernel system calls, such as cgroups and namespaces. You’ve probably heard of runc or gVisor, and here it is.

Appendix 1: How runC works

CRI executes the binary through a Linux system call, and runC generates the container. This indicates that runC relies on the kernel running on a Linux computer.

This also means that if you find a vulnerability in runC that gives you root privileges on the host, then the containerized application can also leak root privileges. It is clear that malicious hackers will seize the opportunity to invade hosts with disastrous consequences. This is why Docker (or any other container runtime) needs to be constantly updated, not just the containerized application itself.

Appendix 2: How gVisor works

GVisor is the OCI runtime originally created by Google employees. It actually runs on the same infrastructure that hosts various Google Cloud services, including Google Cloud Run, Google App Engine, and Google Cloud Functions.

Interestingly, gVisor includes a “guest kernel” layer, meaning that containerized applications have no direct access to the host kernel. Even if an application “thinks” it is exposed, it is only exposed to gVisor’s visitor kernel.

The security mode of gVisor is interesting and I recommend that you refer to the official documentation.

gvisor.dev/docs/

The significant differences between gVisor and runC are as follows:

  • Poorer performance

  • The Linux kernel layer is not 100% compatible: see the compatibility section of the official documentation

  • Not supported by default

Gvisor. Dev/docs/user \ _…

4, summarize

1.Docker is definitely deprecated and you should start thinking about using CRI runtimes such as Containerd and CRI-O.

A. Containerd is compatible with Docker and both share the same core components.

B. If you mainly use Kubernetes’ minimal feature options, Cri-O may be more suitable.

2. Clearly understand the functional and scope differences between the CRI runtime and the OCI runtime.

Depending on your actual workload and business needs, runC may not always be the best choice, so consider that!

Translation link:

Dev. To/inductor/wa…

Some interview questions for 2020 are summarized. The interview questions are divided into 19 modules, which are: Java Basics, Containers, multithreading, reflection, object copy, Java Web, exceptions, Networking, Design patterns, Spring/Spring MVC, Spring Boot/Spring Cloud, Hibernate, MyBatis, RabbitMQ, Kafka, Zookeeper, MySQL, Redis, JVM.

Access to information above information: concern public number: programmers with stories, access to learning materials. Remember to click follow + comment oh ~