Embedded Files
Container Runtime Architecture
Container cloud architecture comprises three layers: orchestration, container, and kernel layers. The orchestration layer includes container cluster management platforms like Kubernetes [1], which automates and scales containers. The kernel layer offers basic isolation functionality for containers. The container layer, positioned as the middle layer, is composed of Container Runtime Systems (CRSs) that serve two primary functions: interpreting container orchestration commands complying with Container Runtime Interface protocol (CRI) [2], e.g., containerd and cri-o, and managing the lifecycle of containers through the Open Container Initiative (OCI) [3] (e.g., runc, gvisor). As the foundational infrastructure of container clouds, CRSs play a vital role by enabling the deployment and management of containers, which is essential for modern cloud-based applications. Hence, ensuring the quality and reliability of CRSs are of paramount importance.
Overview of Container Cloud
Architecture of CRI Runtime
Architecture of OCI Runtime
Both runc and containerd were originally developed by Docker, Inc. and have become widely adopted in the Docker ecosystem, such as Kubernetes and Docker itself. gvisor is a sandboxed runtime implementation developed by Google. It is widely used in commercial cloud platforms and has received more than 14,000 starts on Github. cri-o is specifically designed as the high-level runtime for Kubernetes. It has great compatibility with CRI protocol and supports hybrid security leveled OCI runtime All four selected runtimes have been widely adopted in the CNCF ecosystem, such as Kubernetes and Docker/Moby and are intensively updated by the large open source communities.
Workflow for Docker to start a container [4]
Page updated
Google Sites
Report abuse