Merge pull request #48801 from windsonsea/sideapp

[zh] Resync using-api/server-side-apply.md
pull/48810/head
Kubernetes Prow Robot 2024-11-22 05:14:55 +00:00 committed by GitHub
commit 396f9109cb
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 75 additions and 30 deletions

View File

@ -106,7 +106,7 @@ by including a value for that field in a Server-Side Apply operation.
最后一次对字段值做出断言的用户将被记录到当前字段管理器。
这可以通过发送 `POST`**create**)、`PUT`**update**)、或非应用的 `PATCH`**patch**
显式更改字段管理器详细信息来实现。
还可以通过在服务器端应用操作中包含字段的值来声明和记录字段管理器。
还可以通过在服务器端应用操作中包含字段的值来声明和记录字段管理器。
<!--
A Server-Side Apply **patch** request requires the client to provide its identity
@ -115,9 +115,8 @@ field that is controlled by a different manager results in a rejected
request unless the client forces an override.
For details of overrides, see [Conflicts](#conflicts).
-->
服务器端应用场景中的 **patch** 请求要求客户端提供自身的标识作为
[字段管理器Field Manager](#managers)。使用服务器端应用时,
如果尝试变更由别的管理器来控制的字段,会导致请求被拒绝,除非客户端强制要求进行覆盖。
服务器端应用场景中的 **patch** 请求要求客户端提供自身的标识作为[字段管理器Field Manager](#managers)。
使用服务器端应用时,如果尝试变更由别的管理器来控制的字段,会导致请求被拒绝,除非客户端强制要求进行覆盖。
关于覆盖操作的细节,可参阅[冲突](#conflicts)节。
<!--
@ -173,6 +172,16 @@ A simple example of an object created using Server-Side Apply could look like th
服务器端应用创建对象的简单示例如下:
{{< note >}}
<!--
`kubectl get` omits managed fields by default.
Add `--show-managed-fields` to show `managedFields` when the output format is either `json` or `yaml`.
-->
`kubectl get` 默认省略 `managedFields`
当输出格式为 `json``yaml` 时,你可以添加 `--show-managed-fields` 参数以显示 `managedFields`
{{< /note >}}
<!--
```yaml
---
apiVersion: v1
@ -184,7 +193,32 @@ metadata:
test-label: test
managedFields:
- manager: kubectl
operation: Apply # 注意大写: “Apply” (或者 “Update”)
operation: Apply # note capitalization: "Apply" (or "Update")
apiVersion: v1
time: "2010-10-10T0:00:00Z"
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
f:test-label: {}
f:data:
f:key: {}
data:
key: some value
```
-->
```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: test-cm
namespace: default
labels:
test-label: test
managedFields:
- manager: kubectl
operation: Apply # 注意大写“Apply” (或者 “Update”)
apiVersion: v1
time: "2010-10-10T0:00:00Z"
fieldsType: FieldsV1
@ -322,7 +356,6 @@ sets the manager identity to `"kubectl"` by default.
当你使用 `kubectl` 工具执行服务器端应用操作时,`kubectl` 默认情况下会将管理器标识设置为 `“kubectl”`
<!--
## Serialization
@ -331,7 +364,7 @@ as [YAML](https://yaml.org/), with the media type `application/apply-patch+yaml`
-->
## 序列化 {#serialization}
在协议层面Kubernetes 用 [YAML](https://yaml.org/) 来表示 Server-Side Apply 的消息体,
在协议层面Kubernetes 用 [YAML](https://yaml.org/) 来表示服务器端应用的消息体,
媒体类型为 `application/apply-patch+yaml`
{{< note >}}
@ -612,10 +645,11 @@ kind: Foo
metadata:
name: foo-sample
managedFields:
- manager: manager-one
- manager: "manager-one"
operation: Apply
apiVersion: example.com/v1
fields:
fieldsType: FieldsV1
fieldsV1:
f:spec:
f:data: {}
spec:
@ -725,8 +759,7 @@ This is not what the user wants to happen, even temporarily - it might well degr
a running workload.
-->
现在,用户希望从他们的配置中删除 `replicas`,从而避免与 HorizontalPodAutoscalerHPA及其控制器发生冲突。
然而,这里存在一个竞态:
在 HPA 需要调整 `.spec.replicas` 之前会有一个时间窗口,
然而,这里存在一个竞态:在 HPA 需要调整 `.spec.replicas` 之前会有一个时间窗口,
如果在 HPA 写入字段并成为新的属主之前,用户删除了 `.spec.replicas`
那 API 服务器就会把 `.spec.replicas` 的值设为 1Deployment 的默认副本数)。
这不是用户希望发生的事情,即使是暂时的——它很可能会导致正在运行的工作负载降级。
@ -754,6 +787,17 @@ First, the user defines a new manifest containing only the `replicas` field:
首先,用户新定义一个只包含 `replicas` 字段的新清单:
<!--
```yaml
# Save this file as 'nginx-deployment-replicas-only.yaml'.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
```
-->
```yaml
# 将此文件另存为 'nginx-deployment-replicas-only.yaml'
apiVersion: apps/v1
@ -895,6 +939,7 @@ using server-side apply with the following flag.
```shell
kubectl apply --server-side [--dry-run=server]
```
<!--
By default, field management of the object transfers from client-side apply to
kubectl server-side apply, without encountering conflicts.