@@ -92,7 +92,7 @@ its _desired state_.
92
92
### 对象规约(Spec)与状态(Status) {#object-spec-and-status}
93
93
94
94
几乎每个 Kubernetes 对象包含两个嵌套的对象字段,它们负责管理对象的配置:
95
- 对象 ** ` spec ` (规约)** 和 对象 ** ` status ` (状态)** 。
95
+ 对象 ** ` spec ` (规约)** 和对象 ** ` status ` (状态)** 。
96
96
对于具有 ` spec ` 的对象,你必须在创建对象时设置其内容,描述你希望对象所具有的特征:
97
97
** 期望状态(Desired State)** 。
98
98
@@ -106,7 +106,7 @@ supplied.
106
106
` status ` 描述了对象的** 当前状态(Current State)** ,它是由 Kubernetes
107
107
系统和组件设置并更新的。在任何时刻,Kubernetes
108
108
{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}
109
- 都一直都在积极地管理着对象的实际状态 ,以使之达成期望状态。
109
+ 都一直在积极地管理着对象的实际状态 ,以使之达成期望状态。
110
110
111
111
<!--
112
112
For example: in Kubernetes, a Deployment is an object that can represent an
@@ -147,7 +147,7 @@ request.
147
147
148
148
创建 Kubernetes 对象时,必须提供对象的 ` spec ` ,用来描述该对象的期望状态,
149
149
以及关于对象的一些基本信息(例如名称)。
150
- 当使用 Kubernetes API 创建对象时(直接创建,或经由 ` kubectl ` ),
150
+ 当使用 Kubernetes API 创建对象时(直接创建或经由 ` kubectl ` 创建 ),
151
151
API 请求必须在请求主体中包含 JSON 格式的信息。
152
152
** 大多数情况下,你需要提供 ` .yaml ` 文件为 kubectl 提供这些信息** 。
153
153
` kubectl ` 在发起 API 请求时,将这些信息转换成 JSON 格式。
@@ -235,6 +235,58 @@ detail the structure of that `.status` field, and its content for each different
235
235
不同类型的对象可以有不同的 ` .status ` 信息。API 参考页面给出了 ` .status ` 字段的详细结构,
236
236
以及针对不同类型 API 对象的具体内容。
237
237
238
+ <!--
239
+ ## Server side field validation
240
+
241
+ Starting with Kubernetes v1.25, the API server offers server side
242
+ [field validation](/docs/reference/using-api/api-concepts/#field-validation)
243
+ that detects unrecognized or duplicate fields in an object. It provides all the functionality
244
+ of `kubectl --validate` on the server side.
245
+ -->
246
+ ## 服务器端字段验证 {#server-side-field-validation}
247
+
248
+ 从 Kubernetes v1.25 开始,API
249
+ 服务器提供了服务器端[ 字段验证] ( /zh-cn/docs/reference/using-api/api-concepts/#field-validation ) ,
250
+ 可以检测对象中未被识别或重复的字段。它在服务器端提供了 ` kubectl --validate ` 的所有功能。
251
+
252
+ <!--
253
+ The `kubectl` tool uses the `--validate` flag to set the level of field validation. It accepts the
254
+ values `ignore`, `warn`, and `strict` while also accepting the values `true` (equivalent to `strict`)
255
+ and `false` (equivalent to `ignore`). The default validation setting for `kubectl` is `--validate=true`.
256
+ -->
257
+ ` kubectl ` 工具使用 ` --validate ` 标志来设置字段验证级别。它接受值
258
+ ` ignore ` 、` warn ` 和 ` strict ` ,同时还接受值 ` true ` (等同于 ` strict ` )和
259
+ ` false ` (等同于 ` ignore ` )。` kubectl ` 的默认验证设置为 ` --validate=true ` 。
260
+
261
+ <!--
262
+ `Strict`
263
+ : Strict field validation, errors on validation failure
264
+
265
+ `Warn`
266
+ : Field validation is performed, but errors are exposed as warnings rather than failing the request
267
+
268
+ `Ignore`
269
+ : No server side field validation is performed
270
+ -->
271
+ ` Strict `
272
+ : 严格的字段验证,验证失败时会报错
273
+
274
+ ` Warn `
275
+ : 执行字段验证,但错误会以警告形式提供而不是拒绝请求
276
+
277
+ ` Ignore `
278
+ : 不执行服务器端字段验证
279
+
280
+ <!--
281
+ When `kubectl` cannot connect to an API server that supports field validation it will fall back
282
+ to using client-side validation. Kubernetes 1.27 and later versions always offer field validation;
283
+ older Kubernetes releases might not. If your cluster is older than v1.27, check the documentation
284
+ for your version of Kubernetes.
285
+ -->
286
+ 当 ` kubectl ` 无法连接到支持字段验证的 API 服务器时,它将回退为使用客户端验证。
287
+ Kubernetes 1.27 及更高版本始终提供字段验证;较早的 Kubernetes 版本可能没有此功能。
288
+ 如果你的集群版本低于 v1.27,可以查阅适用于你的 Kubernetes 版本的文档。
289
+
238
290
## {{% heading "whatsnext" %}}
239
291
240
292
<!--
0 commit comments