Improve docs for Upgrade existing custom resource objects to a new stored version

[sftim]

This is a Feature Request

What would you like to be added Change https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/ to mention:

• (I think) that when upgrading from an API version to a later version that has the same scheme, you can use Server Side Apply with a constant, almost-empty request body. Something like:

  {
  "apiVersion": "crd.example/v2",
  "kind": "DemoExample",
  "metadata": {
    "name": "example"
  }
  }

  if you wanted to move the stored version from v1. This is nice because no client-side processing is needed at all for that case. You still need to have the processing happen somewhere if conversion is needed. (I'm not sure if sending an empty request would have the same effect; something to check perhaps?) See https://github.com/kubernetes/website/pull/37267/files#r1053390383 for some context.

• Explain that if you manually update the status.storedVersions field to assert that a version is not stored, when in fact it still is stored and in use, Kubernetes [will|will not]† reject that edit †(delete as applicable)

Why is this needed https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#upgrade-existing-objects-to-a-new-stored-version is not clear on those two points.

Comments /language en /sig api-machinery

[mehabhalodiya]

/triage accepted

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[vaibhav2107]

/remove-lifecycle stale