A water utility asks which Kubernetes extension mechanism adds custom cluster APIs, as distinct from CNI, CSI, or CRI node plugins?
Select an answer to reveal the explanation.
Short Explanation
CNI/CSI/CRI are the “plugs under the hood” for network, disk, and containers. CRDs are how you teach the API server brand-new nouns—like BackupSchedule—that kubectl can get and apply. Different layer of the stack.
Full Explanation
A water utility asking how Kubernetes adds custom cluster APIs—as distinct from CNI/CSI/CRI node plugins—should use CustomResourceDefinitions. CRDs teach the API server new nouns like BackupSchedule that kubectl can get and apply; CNI/CSI/CRI are under-the-hood plugs for network, disk, and containers. Additional kube-proxy modes do not register new REST API kinds automatically. CNI does not exclusively define new API groups for arbitrary custom resources. CSI does not exclusively register arbitrary namespaced kinds as the API extension mechanism. Exam caveat: API extension mechanism = CRD; node plugins ≠ new REST kinds by themselves. Operational check: kubectl get crd, install a sample CRD, kubectl get/apply an instance, and separate that from CNI/CSI/CRI health checks. 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. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.