A court platform wants to swap container runtimes on worker nodes while keeping kubelet’s integration model stable. Which design makes that runtime choice possible?
Select an answer to reveal the explanation.
Short Explanation
CRI is the universal adapter plug: kubelet speaks one language, and containerd, CRI-O, or another runtime answers. Courts can change the runtime under that plug without rewriting kubelet. CSI and CNI are not container starters.
Full Explanation
A court platform can swap container runtimes on workers while keeping kubelet’s integration stable because of the CRI abstraction: kubelet talks a standard runtime API regardless of the underlying engine. CRI is the universal adapter plug—change containerd/CRI-O underneath without rewriting kubelet. Hard-coding dockershim forever inside every kubelet binary is obsolete and not the flexibility mechanism. Replacing kubelet with a CSI sidecar that executes containers via NFS confuses storage with runtime. Binding each Pod to a unique CNI binary that also starts containers mixes networking plugins with runtime duties. Exam caveat: Runtime choice is CRI-shaped; CSI/CNI are adjacent but different plugs. Operational check: Migrate a worker to the new CRI runtime, point kubelet at it, drain/uncordon carefully, and confirm Pods start via crictl on court nodes. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team.