Reapply manifests under the new API version, confirm existing objects still reconcile, and watch storedVersions until the deprecated version disappears. That is the operational checkpoint that tells you whether the old schema can be retired safely.
What changes when MCP CRDs graduate from alpha to beta?
Alpha to beta is the point where the API contract becomes less forgiving. Teams should treat the move as a storage and reconciliation checkpoint, not a cosmetic version bump: reapply manifests against the new version, verify live objects still reconcile, and confirm the deprecated version is no longer being persisted in storedVersions.
The practical implication is that the cluster may continue serving older objects for a while, but the migration is not complete until the new version is the one being written and the controller is reconciling it cleanly. That is why version drift, conversion behavior, and object persistence all need to be checked together.
For MCP-related custom resources, this is especially important because schema changes can affect controller expectations, generated defaults, and any client-side manifests that were built around the alpha shape. A beta cutover is therefore an operational compatibility test as much as it is a release event.
Why the storedVersions check matters during the cutover
storedVersions tells you which API versions still exist in persisted objects. If the deprecated alpha version remains there, the cluster is still carrying old-format records, and a later removal of the alpha API can break reads, updates, or restoration workflows.
That makes the storage layer the decisive signal. A successful rollout is not just “the manifests applied,” but “the controller can reconcile current objects and the old storage version is actually draining away.” If the new beta version is not appearing in writes, the migration has not really landed.
Teams should also watch for hidden dependencies such as generated clients, admission logic, and automation that assumes the old schema. Those pieces often fail before the controller does, which means a seemingly healthy rollout can still leave some workflows tied to the deprecated version.
What a safe alpha-to-beta migration should prove
A safe migration should prove three things at once: existing resources still behave correctly, new resources are written in the beta shape, and there is no lingering operational dependence on the alpha definition. If any one of those is false, the version change is incomplete.
In practice, that means testing both steady-state reconciliation and update paths. Existing objects may look fine until they are patched, rotated, or recreated, so the migration should be validated against the actual lifecycle operations the controller performs in production.
It also means treating rollback carefully. If you still need alpha to make objects work, you have not reached a clean retirement point for the old schema. The right decision is to keep both versions supported until the new one is proven stable under real workloads, then remove the deprecated version only after the storage and reconciliation checks are clean.
Risk and Threat Considerations
Version transitions create exposure when old schemas linger after a new API is introduced. If teams drop the deprecated MCP version too early, they can strand persisted objects, break reconciliation, or create a window where automation no longer understands previously stored resources.
Failure mechanism: The controller, client manifests, or persisted objects remain tied to the alpha schema while the platform begins expecting beta behavior, leading to reconciliation failures, conversion surprises, or partial rollout drift.
Impact: Resource management can become unreliable, updates may fail silently or intermittently, and operational recovery becomes harder because older objects are still encoded in a version the team no longer expects to support.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Beta CRD cutovers require controlled schema and manifest baseline changes. |
| CM-6 — Configuration Settings | Manifest reapplication and schema drift checks are configuration management concerns. | |
| SI-2 — Flaw Remediation | Deprecated API versions must be remediated by updating or replacing old objects. | |
| Recommendation — Update the approved configuration baseline before retiring the alpha CRD version. Validate that deployed CRD settings match the beta API contract. Remediate alpha-version dependencies before removing the deprecated schema. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | CRD version migration is a controlled configuration change with persistence implications. |
| Recommendation — Apply formal change control to the CRD version transition and validate stored object state. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Alpha-to-beta CRD migration is a software configuration change that must be validated. |
| Recommendation — Verify the beta CRD configuration and retire the old version only after validation. | ||
Practitioner Guidance
What to verify: Reapply a representative set of manifests under the beta API, then confirm both create and update paths reconcile successfully. Check that the observed objects match the beta schema, not just that they remain present.
What to measure: Track whether deprecated-version entries disappear from storedVersions and whether any controller errors appear during patch, replace, or rollout activity. Those signals tell you whether the migration is actually converging.
Decision rule: If old and new versions both still coexist in storage, keep the deprecated version supported and delay retirement. If reconciliation is clean and the deprecated version is draining out of persistence, the platform is ready for the old schema to be removed.
Practitioner takeaway: Treat alpha-to-beta as a compatibility and storage migration, not just an API rename. The version change is only safe when the new schema reconciles cleanly and the old one has stopped living in persisted state.
Related resources from NHI Mgmt Group
- What does the article say is missing from MCP deployments?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should teams govern MCP servers once they are exposed through Kubernetes CRDs?
- When should security teams move MCP settings into shared referenced resources?