CKA Question #51: Real Exam Question with Answer & Explanation

Question

You manage a WordPress application. Some Pods are not starting because resource requests are too high. Your task is to prepare a Linux system for Kubernetes. Docker is already installed, but you need to configure it for kubeadm. Complete these tasks to prepare the system for Kubernetes: Set up cri-dockerd : Install the Debian package ~/cri-dockerd_0.3.9.0.ubuntu-jammy_am d64.deb Debian packages are installed using dpkg. Enable and start the cri-dockerd service Configure these system parameters: Set net.bridge.bridge-nf-call-iptables to 1

Explanation

Preparing a Linux System for Kubernetes with kubeadm

Overall Goal

Kubernetes does not talk to Docker directly - it uses the Container Runtime Interface (CRI), a standardized API. Docker predates CRI and doesn't implement it natively. cri-dockerd is an adapter (a shim) that sits between Kubernetes and Docker, translating CRI calls into Docker API calls. Without it, kubeadm cannot use Docker as the container runtime.

The failed Pods in the scenario are a red herring for context - the actual task is infrastructure prep, not Pod debugging.

Step-by-Step Breakdown

Step 1: Install the cri-dockerd Debian package

sudo dpkg -i ~/cri-dockerd_0.3.9.0.ubuntu-jammy_amd64.deb

Why: dpkg -i installs a local .deb file. This deploys the cri-dockerd binary and its systemd unit files onto the system. Without this, there is no CRI shim - kubeadm init will fail when it probes for a container runtime socket.

If skipped: kubeadm will report no container runtime found and refuse to initialize the cluster.

Step 2: Enable and start the cri-dockerd service

sudo systemctl enable cri-dockerd
sudo systemctl start cri-dockerd

Why: Installing a package doesn't automatically run it. enable makes it start on every boot (via systemd). start runs it immediately in the current session.

If skipped:

• Without start: the socket isn't available right now, so kubeadm fails immediately.
• Without enable: after a reboot, no container runtime exists and the node won't rejoin the cluster.

Step 3: Set net.bridge.bridge-nf-call-iptables = 1

# Write the config permanently
echo "net.bridge.bridge-nf-call-iptables = 1" | sudo tee /etc/sysctl.d/k8s.conf

# Apply immediately without rebooting
sudo sysctl --system

Why: By default, Linux bridges forward packets without passing them through iptables. Kubernetes uses iptables rules extensively (via kube-proxy) for Service routing and network policy. If bridged traffic bypasses iptables, Pod-to-Pod and Pod-to-Service networking breaks silently - Pods appear up but can't communicate.

The br_netfilter kernel module must also be loaded for this sysctl to take effect:

sudo modprobe br_netfilter
echo "br_netfilter" | sudo tee /etc/modules-load.d/br_netfilter.conf

If skipped: iptables rules are invisible to bridge traffic. Service discovery and network policies silently fail.

What Goes Wrong Out of Order

Memory Tip

Think of it as three layers of readiness:

1. Binary layer - dpkg -i puts the tool on disk
2. Runtime layer - systemctl enable && start makes it live
3. Kernel layer - sysctl + br_netfilter make the OS Kubernetes-aware

Each layer depends on the one before it. Install → Activate → Configure.

No community discussion yet for this question.