![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2023\/01\/think.webp?w=200\")
<\/figure><\/div>\n\n\nYes\u2026 Kubernetes doesn\u2019t run your containers<\/h2>\n\n\n\n
It\u2019s just an orchestration platform sitting above container runtimes. No code to run a container and to manage the container\u2019s lifecycle on its own, instead, dockershim was implemented (in kubelet<\/a> ) for talking to Docker<\/strong> as container runtime. <\/strong>I will talk about dockershim in the later section of the blog.<\/p>\n\n\n\n Also, docker has grown and matured over the last few years and has gained a stack of components like runc<\/strong> (open container initiative), containerd<\/strong> (CNCF project). OCI<\/strong> (est. in June,2015) splits docker into two parts: <\/p>\n\n\n\n Container runtime is responsible to execute containers and managing container images on nodes.<\/p>\n\n\n\n To understand the need for Container Runtime in Kubernetes, let\u2019s start with a few basic concepts:<\/p>\n\n\n\n gRPC (open-source<\/em> RPC system developed by Google in 2015) is faster than REST because it uses protocol buffers. Protobuf serializes and de-serializes data into binary thus reducing the size of the messages.<\/em><\/p>\n\n\n\n The node controller is a kubernetes control plane component that manages various aspects of nodes.<\/p>\n\n\n\n \u200aA pod is the smallest unit of reference within kubernetes. Each pod runs one or more containers, which together form a single functional unit.<\/p>\n\n\n\n The kubelet reads pod specs from the API server, usually defined in YAML configuration files. The pod specs say which container images the pod should run. It provides no details as to how containers should run\u200a\u2014\u200afor this, kubernetes needs a container runtime.<\/p>\n\n\n\n Other than PodSepcs from the API server, Kubelet can accept podSpec from a file, HTTP endpoint, and HTTP server. A good example of \u201cpodSpec from a file\u201d is \ud835\uddde\ud835\ude02\ud835\uddef\ud835\uddf2\ud835\uddff\ud835\uddfb\ud835\uddf2\ud835\ude01\ud835\uddf2\ud835\ude00 \ud835\ude00\ud835\ude01\ud835\uddee\ud835\ude01\ud835\uddf6\ud835\uddf0 \ud835\uddfd\ud835\uddfc\ud835\uddf1\ud835\ude00. Static pods are pods controlled by Kubelet on its nodes, not the API servers.<\/p>\n<\/blockquote>\n\n\n\n \u200aA Kubernetes node must have a container runtime installed. When the kubelet wants to process pod specs, it needs a container runtime to create the actual containers. The runtime is then responsible for managing the container lifecycle and communicating with the operating system kernel.<\/p>\n\n\n\n The network namespace creation is done by the container runtime only . Just before the pod is deployed and container created, it\u2019s the runtime responsibility to create the network namespace. Instead of running ip netns<\/strong> command and creating the network namespace manually, the container runtime does this automatically with the help of Pod infrastructure container i.e. pause container<\/mark><\/strong>. The command line argument to use is The most widely known container runtime is Docker, but it is not the only one in this space. In fact, the container runtime space has been rapidly evolving. Early versions of kubernetes only worked with a specific container runtime i.e. Docker Engine.<\/p>\n\n\n\n Later, kubernetes added support for working with other container runtimes using C<\/strong>ontainer R<\/strong>untime I<\/strong>nterface (est. Dec 2016). It enables interoperability between orchestrators (like Kubernetes) and many different container runtimes like containerd, CRI-O, cri-containerd, Mirantis container runtime etc.<\/p>\n\n\n\n Docker Engine doesn\u2019t implement that interface (CRI), so the Kubernetes project created special code to help with the transition, and made that dockershim<\/em> <\/strong>code a part of Kubernetes itself.<\/p>\n\n\n\n Dockershim is not a real CRI implementation but it is a built-in implementation in kubelet <\/a>code base dedicated for docker as container runtime only. The kubernetes v1.24 release<\/a> actually removed the dockershim from kubernetes.<\/p>\n\n\n\n Amazon EKS will be ending support for dockershim starting with the Kubernetes version 1.24 launch. Amazon EKS AMIs that are officially published will have containerd as the only runtime starting with version 1.24.<\/p>\n\n\n\n Since Kubernetes 1.5 a new API was introduced, the Container Runtime Interface (CRI), allows any container runtime to plug<\/a> into the kubelet configuration which enables kubelet to use a wide variety of container runtimes, without the need to recompile and provide container runtime services for Kubernetes.<\/p>\n\n\n\n Kubernetes could use any container runtime that implements CRI to manage pods, containers and container images. Docker is the most common container runtime used in production Kubernetes environments, but containerd ( initiated by Docker Inc. & donated to CNCF in March of 2017) may prove to be a better option. For more details, you could refer official blog<\/a><\/p>\n\n\n\n Standards allow ecosystems to grow and thrive as we have seen in the case of OCI and CRI. As this ecosystem grows standards will need to evolve to meet the ecosystem\u2019s needs. As everyone is upgrading to the latest version of Kubernetes so I thought CRI is a very important aspect to know before talking about what is being removed and added in newer versions of kubernetes. Hence, this blog talks about the what, why, how, and evolution of CRI in kubernetes since its existence. Thanks for reading. I\u2019d really appreciate your suggestions and feedback.<\/p>\n\n\n\n Blog Pundits: Shweta Tyagi<\/a><\/strong> and Sandeep Rawat<\/a><\/strong><\/p>\n\n\n\n OpsTree<\/a> is an End-to-End DevOps Solution Provider.<\/strong><\/p>\n\n\n\n
1) to handle docker cli & processing requests and
2) to handle container running functions i.e runC.<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2023\/01\/image-2.png?w=957\")
![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2023\/01\/image-3.png?w=1000\")
But Wait\u2026 what is Container Runtime?<\/h2>\n\n\n\n
Kubelet<\/h4>\n\n\n\n
\n
Node Controller<\/h4>\n\n\n\n
Pods<\/strong>\u200a<\/h4>\n\n\n\n
Pod specs<\/strong>\u200a<\/h4>\n\n\n\n
\n
Container Runtime<\/strong>\u200a<\/h4>\n\n\n\n
\n
--pod-infra-container-image.<\/code> With pause container<\/mark><\/strong>, app container can die & come back again (restart), and all of the network setup will still be there. Normally if the last process in a network namespace dies the namespace would be destroyed and creating a new app container would require creating all new network setup but this is not the case, pause container remains always there in sleep state inside network namespace keeping that network alive.<\/p>\n<\/blockquote>\n\n\n\nIs Docker the only container runtime?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2023\/01\/image-4.png?w=1024\")
That\u2019s How CRI Is born<\/h2>\n\n\n\n
Containerd: A core runtime<\/h2>\n\n\n\n
![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2023\/01\/image-5.png?w=1024\")
Conclusion<\/strong><\/h2>\n\n\n\n