How CRI-O works with Kubernetes

When you want to start or stop a container with Kubernetes, Kubernetes talks to CRI-O, and CRI-O talks to an OCI-compliant container runtime such as runc for Docker to start a container. CRI-O can also pull OCI-compliant container images and manage them on a disk. Good news for Container Developers—they do not need to work with CRI-O directly, as Kubernetes handles that automatically. But it is important to understand the concept and overall architecture:

To sum this up, there are a few things to note before we go to the hands-on part and install CRI-O in our lab:

• Kubernetes is configured to talk to CRI-O to launch a new Pod in a container environment
• CRI-O pulls the OCI-compliant Container Image, if necessary, from a registry and manages it locally
• CRI-O talks to OCI-compliant Container Runtime (runc, by default) to run it on a Kubernetes Node
• Container Runtime starts the container from a container image that's talking to a Linux Kernel
• Linux Kernel starts Container Processes such as an inappropriate namespace, group, context, and so on

• Each container is monitored and logged by a separate process controlled by Linux Kernel
• The networking part for containers is controlled by a Container Network Interface (CNI) that can be used by CRI-O as well