Presentation: CRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!?

I’m a Distinguished Engineer, working as a technical executive for the IBM Watson and Cloud Platform’s CTO office. My key goal as a recently named CTO for container and Linux OS architecture strategy is to connect my years of work in the container open source communities to IBM offerings in our public and private cloud offerings.

I help determine architectural strategy related to our container open source investments, including our work in the Docker engine project, Open Container Initiative (OCI), CNCF (containerd and Kubernetes), Istio, and other related communities.

IBM Cloud, similar to other public clouds, offers Kubernetes as a managed service, as well as on-prem offerings for private cloud. Of course, like other clouds, we are highly dependent on the Linux operating system and its features around networking and containers. Part of my role at IBM is to help standardize the Linux distro (distribution software) choices across our cloud offerings.

I am going to start with describing how Kubernetes interfaces to the container runtime layer through an API interface called the Container Runtime Interface (CRI). The CRI allows any container runtime which can implement the API to plug in and provide the container execution layer for Kubernetes pods.

After a brief “state of the world” on which container runtimes have a CRI implementation today, I will discuss the pros and cons of different container runtimes. To make this more accessible, I’ll spend time with a demo Kubernetes cluster, showing a CRI runtime that I help maintain, containerd as the runtime provider. We’ll look at how to use the various available tools to debug, get metrics, events, and to generally understand what is happening in the container runtime and how the container runtime works under Kubernetes.

The talk will help developers to better understand how Kubernetes actually manages container runtimes and containerized applications at the pod level. They will also learn how operators have tools available to troubleshoot problems in the container runtime environment running under Kubernetes.

All developers need not understand these details, but there are many developers, operators, or architects who help make infrastructure architectural decisions and/or manage the infrastructure as well as develop. The talk will give them a deeper understanding of how things work and the choices available in terms of Kubernetes clusters and container runtimes.

Docker is already a broader platform than just a container runtime. For example, Docker is now a software stack that includes two underlying runtime executors: containerd and the OCI runC project. Docker now has its own orchestration platform built into the Docker engine as well as its own plugin system, networking stack, and so on. Containerd was created by Docker engineers with the focus of being an un-opinionated “boring” and stable container runtime that could be used by Docker (as it is today) as well as Kubernetes and other software platforms that need a stable runtime. It was then contributed to the Cloud Native Computing Foundation (CNCF), the same foundation that manages the Kubernetes open source codebase as well. While containerd is not the only option for Kubernetes, it is becoming an increasingly popular one and definitely viable for production use. During the talk we’ll be looking at current use of containerd and other runtimes in production today and across the public cloud container platforms.

Enterprises have raised a lot of questions in the past about security and data protection with respect to containers and public cloud. Notorious breaches have given several well-known companies a black eye in recent years as more and more of our critical software systems, including significant amounts of our personal information, are hosted in data centers worldwide. I think that secure software stacks, and how that integrates with secure hardware platforms, will continue to be a high area of focus for years to come across the cloud-native ecosystem.