During an audit, a municipal SRE needs to see which API extensions are installed. Which approach inventories CustomResourceDefinitions in the cluster?
Select an answer to reveal the explanation.
Short Explanation
kubectl get crds (apiextensions.k8s.io) is the audit clipboard for “what custom APIs did we install?” Image lists and swap metrics will not tell you. Inventory the API extensions where they live—in the API.
Full Explanation
During an audit, a municipal SRE inventories CustomResourceDefinitions by listing them via the apiextensions.k8s.io API—for example kubectl get crds. That command is the audit clipboard for which custom APIs the city installed; image lists and swap metrics will not tell you. Inspecting only containerd image lists on workers for CRD YAML filenames is incomplete and indirect. Reading kubelet swap metrics does not enumerate apiextensions by design. Querying Endpoints exclusively in kube-public does not provide registered CRD names. Exam caveat: CRDs are API objects—inventory them through the API extensions group. Operational check: kubectl get crds, export the list for the audit binder, and sample kubectl explain on critical municipal CRDs to confirm intended operators are present. 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.