[zh-cn] Cleanup custom-resource-definition-versioning page

[Zhuzhenghao]

This pr removes redundant English documentation and fixs a link in custom-resource-definition-versioning page.

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	f99e033
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/63d5da5e21c405000a8e2fcc
😎 Deploy Preview	https://deploy-preview-39079--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[tengqm]

This page has some new changes in English page that should be sync'ed, although this doesn't necessarily mean the translated text needs a change.
/hold

[Zhuzhenghao]

@tengqm Thanks for reminding. I have resync'ed the file just now.

But I just found one different section, see here.

And I also resync'ed some spaces at the end of statements. Btw, is it necessary to remove these spaces?

[Zhuzhenghao]

我发现注释的英文不分的最后一行偶尔会出现一个空格，我想了想，会不是这样的操作引起的：

我们用了编辑器的注释快捷键，cmd+/之后，从-->的最前面换行，导致遗留下 to 后面的空格？

<!-- This page explains how to add versioning information to -->

当然，这似乎不是很重要 😅

[tengqm]

We basically avoid any trailing spaces in the markdown files.

[tengqm]

When running the following command, I can see more changes than what you have sync'ed:

./scripts/lsync.sh content/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md

[Zhuzhenghao]

Changes that I ran the command are as follows:

Part 1

@@ -78,8 +78,8 @@ Removing an old version:
    If this occurs, switch back to using `served:true` on the old version, migrate the 
    remaining clients to the new version and repeat this step.
 1. Ensure the [upgrade of existing objects to the new stored version](#upgrade-existing-objects-to-a-new-stored-version) step has been completed.
-    1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition.
-    1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`.
+   1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition.
+   1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`.
 1. Remove the old version from the CustomResourceDefinition `spec.versions` list.
 1. Drop conversion support for the old version in conversion webhooks.

Synced in here.

Part 2

@@ -1037,7 +1037,7 @@ What happens to the object that is being returned while serving the read
 request depends on what is specified in the CRD's `spec.conversion`:
 - if the default `strategy` value `None` is specified, the only modifications
   to the object are changing the `apiVersion` string and perhaps [pruning
-  unknown fields](/docs/concepts/extend-kubernetes/api-extension/custom-resources/custom-resource-definitions/#field-pruning)
+  unknown fields](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning)
   (depending on the configuration). Note that this is unlikely to lead to good
   results if the schemas differ between the storage and requested version.
   In particular, you should not use this strategy if the same data is

Synced in my PR.

Part 3

@@ -1051,19 +1051,19 @@ one version to another.
 
 To illustrate this, consider the following hypothetical series of events:
 
-1.  The storage version is `v1beta1`. You create an object. It is stored at version `v1beta1`
-2.  You add version `v1` to your CustomResourceDefinition and designate it as
-    the storage version. Here the schemas for `v1` and `v1beta1` are identical,
-    which is typically the case when promoting an API to stable in the
-    Kubernetes ecosystem.
-3.  You read your object at version `v1beta1`, then you read the object again at
-    version `v1`. Both returned objects are identical except for the apiVersion
-    field.
-4.  You create a new object. It is stored at version `v1`. You now
-    have two objects, one of which is at `v1beta1`, and the other of which is at
-    `v1`.
-5.  You update the first object. It is now stored at version `v1` since that
-    is the current storage version.
+1. The storage version is `v1beta1`. You create an object. It is stored at version `v1beta1`
+2. You add version `v1` to your CustomResourceDefinition and designate it as
+   the storage version. Here the schemas for `v1` and `v1beta1` are identical,
+   which is typically the case when promoting an API to stable in the
+   Kubernetes ecosystem.
+3. You read your object at version `v1beta1`, then you read the object again at
+   version `v1`. Both returned objects are identical except for the apiVersion
+   field.
+4. You create a new object. It is stored at version `v1`. You now
+   have two objects, one of which is at `v1beta1`, and the other of which is at
+   `v1`.
+5. You update the first object. It is now stored at version `v1` since that
+   is the current storage version.
 
 ### Previous storage versions

Synced in here.

Part 4

@@ -1079,19 +1079,19 @@ procedure.
 
 *Option 1:* Use the Storage Version Migrator
 
-1.  Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
-2.  Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
+1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
+2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
 
 *Option 2:* Manually upgrade the existing objects to a new stored version
 
 The following is an example procedure to upgrade from `v1beta1` to `v1`.
 
-1.  Set `v1` as the storage in the CustomResourceDefinition file and apply it
-    using kubectl. The `storedVersions` is now `v1beta1, v1`.
-2.  Write an upgrade procedure to list all existing objects and write them with
-    the same content. This forces the backend to write objects in the current
-    storage version, which is `v1`.
-3.  Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
+1. Set `v1` as the storage in the CustomResourceDefinition file and apply it
+   using kubectl. The `storedVersions` is now `v1beta1, v1`.
+2. Write an upgrade procedure to list all existing objects and write them with
+   the same content. This forces the backend to write objects in the current
+   storage version, which is `v1`.
+3. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
 
 {{< note >}}
 The flag `--subresource` is used with the kubectl get, patch, edit, and replace commands to

Synced in here

Am I not sure I'm missing something?

[tengqm]

Thanks for double checking.
/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: a1dba38562527466ba708a1ba4db2298ddd13492

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tengqm

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• content/zh-cn/OWNERS [tengqm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Zhuzhenghao]

/unhold