Municipal hosts still assume an old Docker Engine–only dockershim setup; the team needs a runtime for current Kubernetes. What should they prepare?
Select an answer to reveal the explanation.
Short Explanation
Modern Kubernetes talks CRI, not the old dockershim story. Put containerd or CRI-O on the hosts and configure kubelet for that runtime. Swarm or raw docker run is a different orchestra.
Full Explanation
Municipal hosts that still assume an old Docker Engine–only dockershim setup must prepare a CRI-compatible runtime for current Kubernetes. Install containerd or CRI-O—or another supported CRI runtime—and point kubelet at that runtime’s endpoint. Modern Kubernetes talks CRI, not the removed dockershim story, so civic platform images should stage and validate the runtime before kubeadm init, join, or upgrades. Re-enabling dockershim in kubelet flags for modern Kubernetes lines is not a supported remediation; dockershim was removed from upstream. Replacing kubelet with Docker Swarm managers on each worker abandons Kubernetes node management and the CKA operational model. Running application containers via plain docker run while skipping kubelet leaves the city without scheduler placement, controllers, and Pod lifecycle integration. Exam caveat: when a question contrasts dockershim nostalgia with “what should they prepare,” the answer is a CRI runtime such as containerd or CRI-O plus kubelet configuration. Operational check: install and enable the runtime, verify systemctl status and crictl info, configure kubelet’s container runtime endpoint, then proceed with kubeadm and confirm Pods create sandboxes through CRI.