Building-permits platform engineers consider deleting a CRD while custom resource instances still exist. What operational caution applies?
Select an answer to reveal the explanation.
Short Explanation
Deleting a CRD while instances exist is like shredding the form template while filed permits still reference it—messy and often destructive. Treat CRD removal as a breaking API change. Clean up or migrate instances with a plan first.
Full Explanation
Building-permits engineers deleting a CRD while custom resource instances still exist must treat removal as a breaking API change that can cascade-delete or strand custom resources. Shredding the form template while filed permits still reference it is messy—migrate or clean up instances with a plan first. Deleting a CRD typically does affect existing instances; they do not remain fully queryable forever as a no-op. CRD deletion is not limited to removing Helm release secrets while leaving all CRs untouched. Kubernetes does not refuse all CRD deletes unless kube-proxy is scaled to zero. Exam caveat: Plan CR migration/backup before CRD deletion in production. Operational check: List CR instances, export if needed, scale down dependent operators carefully, delete CRs or migrate, then delete the CRD and confirm no unexpected data loss. 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.