Hands-on Lab·Kubernetes and Cloud Native Associate
The cgroup Driver: kubelet and containerd
The kubelet and the runtime each decide how to talk to cgroups. If they disagree the cluster half-works in ways that look like memory bugs. Two greps confirm they match.
Containers and Runtimes Guide 13 of 46 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 14 min
containerd 2.x moved its configuration layout. Paths below are 2.x; on 1.x the same settings live under different table names.
- runc1.3.6
- crictlv1.36.0
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when kubelet and containerd disagree and Pods misbehave in ways nothing explains, or when you are building a node from scratch. This matters because both sides independently choose how to write cgroups, and if they choose differently the node degrades under load rather than failing cleanly.
- reading
cgroupDriverout of the kubelet config and the matching option out of containerd'sconfig.toml - seeing why both sides have to agree on systemd rather than cgroupfs
- walking the
kubepods.slicetree that every Pod cgroup is created under - confirming
crictl imagesandctr -n k8s.io images lslist the same images from two different clients
Before you start
- SSH to a node with sudo.
- The runtime guide, for why containerd and the kubelet are separate programs at all.
-
Both sides, one setting
-
The tree they are both writing to
-
What images have to do with it