diff --git a/content/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 0e5b7a0ed0..548dc88839 100644 --- a/content/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -135,8 +135,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. --> @@ -499,11 +499,11 @@ spec: ### 版本删除 {#version-removal} -在为所有提供旧版本自定义资源的集群将现有数据迁移到新 API 版本,并且从 CustomResourceDefinition 的 +在为所有提供旧版本自定义资源的集群将现有存储数据迁移到新 API 版本,并且从 CustomResourceDefinition 的 `status.storedVersions` 中删除旧版本之前,无法从 CustomResourceDefinition 清单文件中删除旧 API 版本。 ```yaml @@ -1352,29 +1352,50 @@ Example of a response from a webhook indicating a conversion request failed, wit ## 编写、读取和更新版本化的 CustomResourceDefinition 对象 {#write-read-and-update-versioned-crd-objects} -写入对象时,将使用写入时指定的存储版本来存储。如果存储版本发生变化, +写入对象时,将存储为写入时指定的存储版本。如果存储版本发生变化, 现有对象永远不会被自动转换。然而,新创建或被更新的对象将以新的存储版本写入。 对象写入的版本不再被支持是有可能的。 -当读取对象时,作为路径的一部分,你需要指定版本。 -如果所指定的版本与对象的持久版本不同,Kubernetes 会按所请求的版本将对象返回, -但是在满足服务请求时,被持久化的对象既不会在磁盘上更改, -也不会以任何方式进行转换(除了 `apiVersion` 字符串被更改之外)。 -你可以以当前提供的任何版本来请求对象。 +当读取对象时,你需要在路径中指定版本。 +你可以请求当前提供的任意版本的对象。 +如果所指定的版本与对象的存储版本不同,Kubernetes 会按所请求的版本将对象返回, +但磁盘上存储的对象不会更改。 + + +在为读取请求提供服务时正返回的对象会发生什么取决于 CRD 的 `spec.conversion` 中指定的内容: + + +- 如果所指定的 `strategy` 值是默认的 `None`,则针对对象的唯一修改是更改其 `apiVersion` 字符串, + 并且可能[修剪未知字段](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning)(取决于配置)。 + 请注意,如果存储和请求版本之间的模式不同,这不太可能导致好的结果。 + 尤其是如果在相同的数据类不同版本中采用不同字段来表示时,不应使用此策略。 +- 如果指定了 [Webhook 转换](#webhook-conversion),则此机制将控制转换。 -1. 存储版本是 `v1beta1`。你创建一个对象。该对象以版本 `v1beta1` 存储。 -2. 你将为 CustomResourceDefinition 添加版本 `v1`,并将其指定为存储版本。 -3. 你使用版本 `v1beta1` 来读取你的对象,然后你再次用版本 `v1` 读取对象。 - 除了 apiVersion 字段之外,返回的两个对象是完全相同的。 -4. 你创建一个新对象。对象以版本 `v1` 保存在存储中。 - 你现在有两个对象,其中一个是 `v1beta1`,另一个是 `v1`。 -5. 你更新第一个对象。该对象现在以版本 `v1` 保存,因为 `v1` 是当前的存储版本。 +1. 存储版本是 `v1beta1`。你创建一个对象。该对象以版本 `v1beta1` 存储。 +2. 你将为 CustomResourceDefinition 添加版本 `v1`,并将其指定为存储版本。 + 此处 `v1` 和 `v1beta1` 的模式是相同的,这通常是在 Kubernetes 生态系统中将 API 提升为稳定版时的情况。 +3. 你使用版本 `v1beta1` 来读取你的对象,然后你再次用版本 `v1` 读取对象。 + 除了 apiVersion 字段之外,返回的两个对象是完全相同的。 +4. 你创建一个新对象。该对象存储为版本 `v1`。 + 你现在有两个对象,其中一个是 `v1beta1`,另一个是 `v1`。 +5. 你更新第一个对象。该对象现在以版本 `v1` 保存,因为 `v1` 是当前的存储版本。 @@ -1440,8 +1463,8 @@ procedure. **选项 1:** 使用存储版本迁移程序(Storage Version Migrator) @@ -1459,18 +1482,18 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`. 以下是从 `v1beta1` 升级到 `v1` 的示例过程。 -1. 在 CustomResourceDefinition 文件中将 `v1` 设置为存储版本,并使用 kubectl 应用它。 - `storedVersions`现在是`v1beta1, v1`。 -2. 编写升级过程以列出所有现有对象并使用相同内容将其写回存储。 - 这会强制后端使用当前存储版本(即 `v1`)写入对象。 -3. 从 CustomResourceDefinition 的 `status.storedVersions` 字段中删除 `v1beta1`。 +1. 在 CustomResourceDefinition 文件中将 `v1` 设置为存储版本,并使用 kubectl 应用它。 + `storedVersions`现在是 `v1beta1, v1`。 +2. 编写升级过程以列出所有现有对象并使用相同内容将其写回存储。 + 这会强制后端使用当前存储版本(即 `v1`)写入对象。 +3. 从 CustomResourceDefinition 的 `status.storedVersions` 字段中删除 `v1beta1`。 {{< note >}}