CKA · Question #53
You must connect to the correct host. Failure to do so may result in a zero score. Context: You manage a WordPress application. Some Pods are not starting because resource requests are too high…
Preparing a Linux System for Kubernetes with cri-dockerd Overall Goal Kubernetes doesn't talk to Docker directly - it uses the Container Runtime Interface (CRI), a standardized API. Docker predates CRI, so it needs a shim called cri-dockerd to act as a bridge between Kubernetes…
Question
Explanation
Preparing a Linux System for Kubernetes with cri-dockerd
Overall Goal
Kubernetes doesn't talk to Docker directly - it uses the Container Runtime Interface (CRI), a standardized API. Docker predates CRI, so it needs a shim called cri-dockerd to act as a bridge between Kubernetes (kubeadm) and the Docker daemon. This task sets up that bridge and configures the kernel networking required for Kubernetes to function correctly.
Step 1: Install cri-dockerd (dpkg -i)
sudo dpkg -i ~/cri-dockerd_0.3.9.3-0.ubuntu-jammy_amd64.deb
Why: The .deb file is a pre-built Debian package. dpkg -i (install) extracts and registers it with the system package manager. Without this, there's no CRI shim - kubeadm cannot communicate with Docker at all, and kubeadm init will fail with a "container runtime not found" error.
Why dpkg and not apt? You have a local file, not a remote repository package. apt pulls from repos; dpkg installs a file you already have.
Step 2: Enable and Start the cri-docker Service
sudo systemctl enable cri-docker
sudo systemctl start cri-docker
Why both commands?
start- activates the service right now for the current session.enable- registers it to auto-start on every reboot.
If you only start it, a reboot before the exam grader checks will leave the service dead. If you only enable it without starting it, the socket doesn't exist yet and kubeadm will fail immediately. You need both.
What it does: cri-dockerd creates a Unix socket (/run/cri-dockerd.sock) that kubeadm connects to when managing containers.
Step 3: Set net.bridge.bridge-nf-call-iptables = 1
# Apply immediately
sudo sysctl net.bridge.bridge-nf-call-iptables=1
# Persist across reboots
echo "net.bridge.bridge-nf-call-iptables = 1" | sudo tee /etc/sysctl.d/k8s.conf
sudo sysctl --system
Why: Kubernetes uses iptables rules to route Pod-to-Pod traffic. By default, Linux bridges bypass iptables - bridged traffic goes around the firewall rules entirely. Setting this parameter forces bridged traffic through iptables so kube-proxy's rules take effect.
What breaks without it: Pods can't reach each other or Services. The CNI network plugin (Flannel, Calico, etc.) will appear to work but traffic silently drops. This is a subtle networking failure that's hard to diagnose later.
Persistence note: sysctl changes are in-memory only unless written to /etc/sysctl.d/. Always persist them.
Also commonly required (check your exam):
net.ipv4.ip_forward = 1- allows the node to route packets between interfaces. Often needed alongside the bridge setting.
Order Dependency
Install package → Enable/start service → Configure kernel params
The kernel parameter is independent and can technically be done in any order, but installing before enabling is mandatory - you can't enable a service unit that doesn't exist yet.
Memory Tip
Think of it as "Install, Activate, Network":
- Install the bridge (cri-dockerd package)
- Activate the bridge (enable + start)
- Network through the bridge (iptables sysctl)
Each step makes the next one meaningful - install gives you something to activate, activation creates the socket, and the sysctl ensures traffic actually flows through the networking rules Kubernetes sets up.
Topics
Community Discussion
No community discussion yet for this question.