Container Runtime Interface (CRI-O) workflow

Let’s break the workflow :

✅ When a request comes to start a #container, #kubelet calls the CRI that invokes the internal CRI-O daemon in the #kernel
✅ The daemon uses a compliant storage and image library on disk
✅ The CRI-O interacts with a remote registry to pull the image if not present on disk while the daemon exposes a [#grpc] server with endpoints to create, start, stop (and many more other actions) on the #containers.
✅ Under the hood, cri-o can use any OCI-compliant [low-level] runtimes to work with containers
✅ However the default one is again #runc that interacts with #linux kernel to invoke processes in namespace & #Cgroup context!

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.