Skip to content

Commit 696df09

Browse files
authored
Merge pull request #49128 from windsonsea/apipts
[zh] Sync using-api/api-concepts.md and its feature gates
2 parents 6ec2061 + 2db3a79 commit 696df09

File tree

3 files changed

+183
-8
lines changed

3 files changed

+183
-8
lines changed
Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
---
2+
title: AllowUnsafeMalformedObjectDeletion
3+
content_type: feature_gate
4+
_build:
5+
list: never
6+
render: false
7+
8+
stages:
9+
- stage: alpha
10+
defaultValue: false
11+
fromVersion: "1.32"
12+
---
13+
14+
<!--
15+
Enables the cluster operator to identify corrupt resource(s) using the **list**
16+
operation, and introduces an option `ignoreStoreReadErrorWithClusterBreakingPotential`
17+
that the operator can set to perform unsafe and force **delete** operation of
18+
such corrupt resource(s) using the Kubernetes API.
19+
-->
20+
允许集群操作员使用 **list** 操作来辨别受损的资源,
21+
引入一个 `ignoreStoreReadErrorWithClusterBreakingPotential` 选项,
22+
集群操作员可以设置此选项并使用 Kubernetes API 对受损的资源执行不安全的强制 **delete** 操作。
Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
---
2+
title: CBORServingAndStorage
3+
content_type: feature_gate
4+
_build:
5+
list: never
6+
render: false
7+
8+
stages:
9+
- stage: alpha
10+
defaultValue: false
11+
fromVersion: "1.32"
12+
---
13+
14+
<!--
15+
Enables CBOR as a [supported encoding for requests and
16+
responses](/docs/reference/using-api/api-concepts/#cbor-encoding), and as the preferred storage
17+
encoding for custom resources.
18+
-->
19+
允许将 CBOR 用作[请求和响应所支持的编码方式](/zh-cn/docs/reference/using-api/api-concepts/#cbor-encoding)
20+
同时允许将 CBOR 用作定制资源的首选存储编码方式。

content/zh-cn/docs/reference/using-api/api-concepts.md

Lines changed: 141 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -598,6 +598,64 @@ For example:
598598
Accept: application/vnd.kubernetes.protobuf, application/json
599599
```
600600

601+
<!--
602+
### CBOR resource encoding {#cbor-encoding}
603+
-->
604+
### CBOR 资源编码 {#cbor-encoding}
605+
606+
{{< feature-state feature_gate_name="CBORServingAndStorage" >}}
607+
608+
<!--
609+
With the `CBORServingAndStorage` [feature
610+
gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled, request and response
611+
bodies for all built-in resource types and all resources defined by a {{< glossary_tooltip
612+
term_id="CustomResourceDefinition" text="CustomResourceDefinition" >}} may be encoded to the
613+
[CBOR](https://www.rfc-editor.org/rfc/rfc8949) binary data format. CBOR is also supported at the {{<
614+
glossary_tooltip text="aggregation layer" term_id="aggregation-layer" >}} if it is enabled in
615+
individual aggregated API servers.
616+
-->
617+
启用 `CBORServingAndStorage` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)后,
618+
所有内置资源类型及所有由 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinition" >}}
619+
所定义的资源的请求体和响应体都可以被编码为 [CBOR](https://www.rfc-editor.org/rfc/rfc8949) 二进制数据格式。
620+
如果在各个聚合 API 服务器中启用了 CBOR,
621+
则在{{< glossary_tooltip text="聚合层" term_id="aggregation-layer" >}}中也支持 CBOR。
622+
623+
<!--
624+
Clients should indicate the IANA media type `application/cbor` in the `Content-Type` HTTP request
625+
header when the request body contains a single CBOR [encoded data
626+
item](https://www.rfc-editor.org/rfc/rfc8949.html#section-1.2-4.2), and in the `Accept` HTTP request
627+
header when prepared to accept a CBOR encoded data item in the response. API servers will use
628+
`application/cbor` in the `Content-Type` HTTP response header when the response body contains a
629+
CBOR-encoded object.
630+
-->
631+
当请求体包含单个 CBOR [编码数据项](https://www.rfc-editor.org/rfc/rfc8949.html#section-1.2-4.2)时,
632+
客户端应在 `Content-Type` HTTP 请求头中指明 IANA 媒体类型 `application/cbor`
633+
当准备接受响应中以 CBOR 编码的数据项时,客户端应在 `Accept` HTTP 请求头中指明 IANA 媒体类型 `application/cbor`
634+
API 服务器将在响应体包含以 CBOR 编码的对象时在 `Content-Type` HTTP 响应头中使用 `application/cbor`
635+
636+
<!--
637+
If an API server encodes its response to a [watch request](#efficient-detection-of-changes) using
638+
CBOR, the response body will be a [CBOR Sequence](https://www.rfc-editor.org/rfc/rfc8742) and the
639+
`Content-Type` HTTP response header will use the IANA media type `application/cbor-seq`. Each entry
640+
of the sequence (if any) is a single CBOR-encoded watch event.
641+
-->
642+
如果 API 服务器使用 CBOR 对 [watch 请求](#efficient-detection-of-changes)的响应进行编码,
643+
则响应体将是一个 [CBOR 序列](https://www.rfc-editor.org/rfc/rfc8742)
644+
`Content-Type` HTTP 响应头将使用 IANA 媒体类型 `application/cbor-seq`
645+
此序列的每个条目(如果有的话)是一个以 CBOR 编码的 watch 事件。
646+
647+
<!--
648+
In addition to the existing `application/apply-patch+yaml` media type for YAML-encoded [server-side
649+
apply configurations](#patch-and-apply), API servers that enable CBOR will accept the
650+
`application/apply-patch+cbor` media type for CBOR-encoded server-side apply configurations. There
651+
is no supported CBOR equivalent for `application/json-patch+json` or `application/merge-patch+json`,
652+
or `application/strategic-merge-patch+json`.
653+
-->
654+
除了以 YAML 编码的[服务器端应用配置](#patch-and-apply)所用的现有 `application/apply-patch+yaml` 媒体类型之外,
655+
启用 CBOR 的 API 服务器将接受 `application/apply-patch+cbor` 媒体类型用于以 CBOR 编码的服务器端应用配置。
656+
对于 `application/json-patch+json``application/merge-patch+json`
657+
`application/strategic-merge-patch+json`,没有支持的 CBOR 等效类型。
658+
601659
<!--
602660
## Efficient detection of changes
603661
@@ -767,15 +825,13 @@ the API server will send any `BOOKMARK` event even when requested.
767825
<!--
768826
On large clusters, retrieving the collection of some resource types may result in
769827
a significant increase of resource usage (primarily RAM) on the control plane.
770-
In order to alleviate its impact and simplify the user experience of the **list** + **watch**
771-
pattern, Kubernetes v1.27 introduces as an alpha feature the support
772-
for requesting the initial state (previously requested via the **list** request) as part of
773-
the **watch** request.
828+
To alleviate the impact and simplify the user experience of the **list** + **watch**
829+
pattern, Kubernetes v1.32 promotes to beta the feature that allows requesting the initial state
830+
(previously requested via the **list** request) as part of the **watch** request.
774831
-->
775832
在大型集群检索某些资源类型的集合可能会导致控制平面的资源使用量(主要是 RAM)显著增加。
776833
为了减轻其影响并简化 **list** + **watch** 模式的用户体验,
777-
Kubernetes 1.27 版本引入了一个 alpha 功能,支持在 **watch** 请求中请求初始状态
778-
(之前在 **list** 请求中请求)。
834+
Kubernetes v1.32 将在 **watch** 请求中请求初始状态(之前在 **list** 请求中请求)的特性进阶至 Beta。
779835

780836
<!--
781837
Provided that the `WatchList` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
@@ -786,9 +842,15 @@ events (of type `ADDED`) to build the whole state of all existing objects follow
786842
(if requested via `allowWatchBookmarks=true` option). The bookmark event includes the resource version
787843
to which is synced. After sending the bookmark event, the API server continues as for any other **watch**
788844
request.
845+
On the client-side the initial state can be requested by specifying `sendInitialEvents=true` as query string parameter
846+
in a **watch** request. If set, the API server starts the watch stream with synthetic init
847+
events (of type `ADDED`) to build the whole state of all existing objects followed by a
848+
[`BOOKMARK` event](/docs/reference/using-api/api-concepts/#watch-bookmarks)
849+
(if requested via `allowWatchBookmarks=true` option). The bookmark event includes the resource version
850+
to which is synced. After sending the bookmark event, the API server continues as for any other **watch**
851+
request.
789852
-->
790-
如果启用了 `WatchList` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
791-
可以通过在 **watch** 请求中指定 `sendInitialEvents=true` 作为查询字符串参数来实现这一功能。
853+
在客户端,可以通过在 **watch** 请求中指定 `sendInitialEvents=true` 作为查询字符串参数来请求初始状态。
792854
如果指定了这个参数,API 服务器将使用合成的初始事件(类型为 `ADDED`)来启动监视流,
793855
以构建所有现有对象的完整状态;如果请求还带有 `allowWatchBookmarks=true` 选项,
794856
则继续发送 [`BOOKMARK` 事件](/zh-cn/docs/reference/using-api/api-concepts/#watch-bookmarks)
@@ -1360,6 +1422,77 @@ Once the last finalizer is removed, the resource is actually removed from etcd.
13601422

13611423
当最后一个终结器也被移除时,资源才真正从 etcd 中移除。
13621424

1425+
<!--
1426+
### Force deletion
1427+
-->
1428+
### 强制删除 {#force-deletion}
1429+
1430+
{{< feature-state feature_gate_name="AllowUnsafeMalformedObjectDeletion" >}}
1431+
1432+
{{< caution >}}
1433+
<!--
1434+
This may break the workload associated with the resource being force deleted, if it
1435+
relies on the normal deletion flow, so cluster breaking consequences may apply.
1436+
-->
1437+
如果强制删除依赖于正常的删除流程,这可能会破坏与正强制删除的资源关联的工作负载,因此可能会导致集群出现严重后果。
1438+
{{< /caution >}}
1439+
1440+
<!--
1441+
By enabling the delete option `ignoreStoreReadErrorWithClusterBreakingPotential`, the
1442+
user can perform an unsafe force **delete** operation of an undecryptable/corrupt
1443+
resource. This option is behind an ALPHA feature gate, and it is disabled by
1444+
default. In order to use this option, the cluster operator must enable the feature by
1445+
setting the command line option `--feature-gates=AllowUnsafeMalformedObjectDeletion=true`.
1446+
-->
1447+
通过启用删除选项 `ignoreStoreReadErrorWithClusterBreakingPotential`
1448+
用户可以对无法解密或损坏的资源执行不安全的强制**删除**操作。
1449+
使用此选项需要先启用一个 Alpha 特性门控,默认是禁用的。
1450+
要使用此选项,集群操作员必须通过设置命令行选项
1451+
`--feature-gates=AllowUnsafeMalformedObjectDeletion=true` 来启用此特性。
1452+
1453+
{{< note >}}
1454+
<!--
1455+
The user performing the force **delete** operation must have the privileges to do both
1456+
the **delete** and **unsafe-delete-ignore-read-errors** verbs on the given resource.
1457+
-->
1458+
执行强制**删除**操作的用户必须拥有对给定资源执行 **delete****unsafe-delete-ignore-read-errors** 动作的权限。
1459+
{{< /note >}}
1460+
1461+
<!--
1462+
A resource is considered corrupt if it can not be successfully retrieved from the
1463+
storage due to a) transformation error (for example: decryption failure), or b) the object
1464+
failed to decode. The API server first attempts a normal deletion, and if it fails with
1465+
a _corrupt resource_ error then it triggers the force delete. A force **delete** operation
1466+
is unsafe because it ignores finalizer constraints, and skips precondition checks.
1467+
-->
1468+
如果某资源由于
1469+
1470+
1. 转换错误(例如解密失败)或
1471+
1. 对象解码失败
1472+
1473+
导致无法从存储中成功检索,则该资源被视为已损坏。
1474+
API 服务器会先尝试正常删除,如果由于**资源损坏**的错误而删除失败,则触发强制删除。
1475+
强制 **delete** 操作是不安全的,因为它会忽略终结器(Finalizer)约束,并跳过前置条件检查。
1476+
1477+
<!--
1478+
The default value for this option is `false`, this maintains backward compatibility.
1479+
For a **delete** request with `ignoreStoreReadErrorWithClusterBreakingPotential`
1480+
set to `true`, the fields `dryRun`, `gracePeriodSeconds`, `orphanDependents`,
1481+
`preconditions`, and `propagationPolicy` must be left unset.
1482+
-->
1483+
此选项的默认值为 `false`,这是为了保持向后兼容性。对于将
1484+
`ignoreStoreReadErrorWithClusterBreakingPotential` 设置为 `true`**delete** 请求,
1485+
`dryRun``gracePeriodSeconds``orphanDependents``preconditions``propagationPolicy` 字段必须保持不设置。
1486+
1487+
{{< note >}}
1488+
<!--
1489+
If the user issues a **delete** request with `ignoreStoreReadErrorWithClusterBreakingPotential`
1490+
set to `true` on an otherwise readable resource, the API server aborts the request with an error.
1491+
-->
1492+
如果用户对一个可以以其他方式读取的资源发出将 `ignoreStoreReadErrorWithClusterBreakingPotential`
1493+
设置为 `true`**delete** 请求,API 服务器将中止此请求并报错。
1494+
{{< /note >}}
1495+
13631496
<!--
13641497
## Single resource API
13651498

0 commit comments

Comments
 (0)