Merge pull request #48047 from my-git9/pp-30629

[zh-cn] sync api-concepts admission-controllers node
pull/48114/head
Kubernetes Prow Robot 2024-09-28 01:22:02 +01:00 committed by GitHub
commit c49c5f419e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 100 additions and 22 deletions

View File

@ -1480,7 +1480,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
*must* have a reconciliation system, as it is not guaranteed that subsequent
webhooks or other validating admission controllers will permit the request to finish.
-->
如果以此方式调用的 Webhook 有其它副作用(如:减少配额),则它 **必须** 具有协调机制。
如果以此方式调用的 Webhook 有其它副作用(如:减少配额),则它**必须**具有协调机制。
这是因为无法保证后续的 Webhook 或其他验证性准入控制器都允许请求完成。
<!--
@ -1505,4 +1505,4 @@ You can enable additional admission controllers beyond the default set using the
有。推荐使用的准入控制器默认情况下都处于启用状态
(请查看[这里](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/#options))。
因此,你无需显式指定它们。
你可以使用 `--enable-admission-plugins` 标志( **顺序不重要** )来启用默认设置以外的其他准入控制器。
你可以使用 `--enable-admission-plugins` 标志(**顺序不重要**)来启用默认设置以外的其他准入控制器。

View File

@ -52,6 +52,19 @@ Read operations:
* pods
* 与绑定到 kubelet 节点的 Pod 相关的 Secret、ConfigMap、PersistentVolumeClaim 和持久卷
{{< feature-state feature_gate_name="AuthorizeNodeWithSelectors" >}}
<!--
When the `AuthorizeNodeWithSelectors` feature is enabled
(along with the pre-requisite `AuthorizeWithSelectors` feature),
kubelets are only allowed to read their own Node objects,
and are only allowed to read pods bound to their node.
-->
当启用 `AuthorizeNodeWithSelectors` 特性
(以及作为先决条件的 `AuthorizeWithSelectors` 特性)时,
kubelet 只允许读取它们自己的 Node 对象,
并且只允许读取绑定到其节点的 Pod。
<!--
Write operations:
-->
@ -65,7 +78,7 @@ Write operations:
* events
-->
* 节点和节点状态(启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点)
* Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod)
* Pod 和 Pod 状态(启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod
* 事件
<!--
@ -116,7 +129,7 @@ For specifics about how the kubelet determines the hostname, see the
-->
`<nodeName>` 的值**必须**与 kubelet 注册的节点名称精确匹配。默认情况下,节点名称是由
`hostname` 提供的主机名,或者通过 kubelet `--hostname-override`
[选项](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 覆盖。
[选项](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)覆盖。
但是,当使用 `--cloud-provider` kubelet 选项时,具体的主机名可能由云提供商确定,
忽略本地的 `hostname``--hostname-override` 选项。有关
kubelet 如何确定主机名的详细信息,请参阅

View File

@ -0,0 +1,49 @@
---
title: 监视Watch
id: watch
date: 2024-07-02
full_link: /zh-cn/docs/reference/using-api/api-concepts/#api-verbs
short_description: >
用于以流的形式跟踪 Kubernetes 中对象变化的动词。
aka:
tags:
- API verb
- fundamental
---
<!--
title: Watch
id: watch
date: 2024-07-02
full_link: /docs/reference/using-api/api-concepts/#api-verbs
short_description: >
A verb that is used to track changes to an object in Kubernetes as a stream.
aka:
tags:
- API verb
- fundamental
-->
<!--
A verb that is used to track changes to an object in Kubernetes as a stream.
It is used for the efficient detection of changes.
-->
用于以流的形式跟踪 Kubernetes 中对象更改的动词。
它用于高效检测更改。
<!--more-->
<!--
A verb that is used to track changes to an object in Kubernetes as a stream. Watches allow
efficient detection of changes; for example, a
{{< glossary_tooltip term_id="controller" text="controller">}} that needs to know whenever a
ConfigMap has changed can use a watch rather than polling.
See [Efficient Detection of Changes in API Concepts](/docs/reference/using-api/api-concepts/#efficient-detection-of-changes) for more information.
-->
用于以流的形式跟踪 Kubernetes 中对象变化的动词。
监视可以有效地检测变化;例如,需要知道 ConfigMap
何时发生变化的{{< glossary_tooltip term_id="controller" text="控制器">}}可以使用监视而不是轮询。
请参阅[有效检测 API 概念的变化](/zh-cn/docs/reference/using-api/api-concepts/#efficient-detection-of-changes)了解更多信息。

View File

@ -32,15 +32,18 @@ Kubernetes API 是通过 HTTP 提供的基于资源 (RESTful) 的编程接口。
为了方便或者提高效率,可以以不同的表示形式接受和服务这些资源。
<!--
Kubernetes supports efficient change notifications on resources via *watches*.
Kubernetes supports efficient change notifications on resources via
_watches_:
{{< glossary_definition prepend="in the Kubernetes API, watch is" term_id="watch" length="short" >}}
Kubernetes also provides consistent list operations so that API clients can
effectively cache, track, and synchronize the state of resources.
You can view the [API reference](/docs/reference/kubernetes-api/) online,
or read on to learn about the API in general.
-->
Kubernetes 支持通过 **watch** 实现高效的资源变更通知。
Kubernetes 还提供了一致的列表操作,以便 API 客户端可以有效地缓存、跟踪和同步资源的状态。
Kubernetes 支持通过 **watch** 实现高效的资源变更通知:
{{< glossary_definition prepend="在 Kubernetes API 中watch 的是" term_id="watch" length="short" >}}
Kubernetes 还提供一致的列表操作,以便 API 客户端可以有效地缓存、跟踪和同步资源的状态。
你可以在线查看 [API 参考](/zh-cn/docs/reference/kubernetes-api/)
或继续阅读以了解 API 的一般信息。
@ -83,9 +86,9 @@ as a permission check
大多数 Kubernetes API
资源类型都是[对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
它们代表集群上某个概念的具体实例,例如 Pod 或名字空间。
少数 API 资源类型是 “虚拟的”,它们通常代表的是操作而非对象本身,
少数 API 资源类型是“虚拟的”,它们通常代表的是操作而非对象本身,
例如权限检查(使用带有 JSON 编码的 `SubjectAccessReview` 主体的 POST 到 `subjectaccessreviews` 资源),
或 Pod 的子资源 `eviction`(用于触发 [API-发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/))。
或 Pod 的子资源 `eviction`(用于触发 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/))。
<!--
### Object names
@ -161,7 +164,8 @@ Examples:
注意: 核心资源使用 `/api` 而不是 `/apis`,并且不包含 GROUP 路径段。
例如:
例如:
* `/api/v1/namespaces`
* `/api/v1/pods`
* `/api/v1/namespaces/my-namespace/pods`
@ -187,9 +191,12 @@ The following paths are used to retrieve collections and resources:
你还可以访问资源集合(例如:列出所有 Node。以下路径用于检索集合和资源
* 集群作用域的资源:
* `GET /apis/GROUP/VERSION/RESOURCETYPE` - 返回指定资源类型的资源的集合
* `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME` - 返回指定资源类型下名称为 NAME 的资源
* 名字空间作用域的资源:
* `GET /apis/GROUP/VERSION/RESOURCETYPE` - 返回所有名字空间中指定资源类型的全部实例的集合
* `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE` - 返回名字空间 NAMESPACE 内给定资源类型的全部实例的集合
* `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME` - 返回名字空间 NAMESPACE 中给定资源类型的名称为 NAME 的实例
@ -535,7 +542,7 @@ response (10-20MB) and consume a large amount of server resources.
-->
在较大规模集群中,检索某些资源类型的集合可能会导致非常大的响应,从而影响服务器和客户端。
例如,一个集群可能有数万个 Pod每个 Pod 大约相当于 2 KiB 的编码 JSON。
跨所有名字空间检索所有 Pod 可能会导致非常大的响应 (10-20MB) 并消耗大量服务器资源。
跨所有名字空间检索所有 Pod 可能会导致非常大的响应10-20MB并消耗大量服务器资源。
<!--
The Kubernetes API server supports the ability to break a single large collection request
@ -1280,7 +1287,7 @@ information about warnings and the Kubernetes API, see the blog article
`Warn`
:(默认值)使 API 服务器成功处理请求,并向客户端发送告警信息。告警信息通过 `Warning:` 响应头发送,
并为每个未知字段或重复字段添加一条告警信息。有关告警和相关的 Kubernetes API 的信息,
可参阅博文[告警:增加实用告警功能](/blog/2020/09/03/warnings/)。
可参阅博文[告警:增加实用告警功能](/zh-cn/blog/2020/09/03/warnings/)。
<!--
: The API server rejects the request with a 400 Bad Request error when it
@ -1418,7 +1425,7 @@ that they do not have side effects, by setting their `sideEffects` field to `Non
-->
如果请求的非试运行版本会触发具有副作用的准入控制器,则该请求将失败,而不是冒不希望的副作用的风险。
所有内置准入控制插件都支持试运行。
此外,准入 Webhook 还可以设置[配置对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhook-v1-admissionregistration-k8s-io)
此外,准入 Webhook 还可以设置[配置对象](/zh-cn/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhook-v1-admissionregistration-k8s-io)
`sideEffects` 字段为 `None`,借此声明它们没有副作用。
<!--
@ -1844,7 +1851,7 @@ For **get** and **list**, the semantics of `resourceVersion` are:
对于 **get****list** 而言,`resourceVersion` 的语义为:
**get:**
**get**
<!--
| resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" |
@ -1855,7 +1862,7 @@ For **get** and **list**, the semantics of `resourceVersion` are:
|-----------------------|---------------------|----------------------------------------|
| 最新版本 | 任何版本 | 不老于给定版本 |
**list:**
**list**
<!--
From version v1.19, Kubernetes API servers support the `resourceVersionMatch` parameter
@ -1943,10 +1950,6 @@ Any
for the request to return data at a much older resource version that the client has previously
observed, particularly in high availability configurations, due to partitions or stale
caches. Clients that cannot tolerate this should not use this semantic.
Most recent
: Return data at the most recent resource version. The returned data must be
consistent (in detail: served from etcd via a quorum read).
-->
任意版本
: 返回任何资源版本的数据。最新可用资源版本优先,但不需要强一致性;
@ -1954,10 +1957,24 @@ Most recent
请求可能返回客户端先前观察到的更旧资源版本的数据,特别是在高可用性配置中。
不能容忍这种情况的客户不应该使用这种语义。
<!--
Most recent
: Return data at the most recent resource version. The returned data must be
consistent (in detail: served from etcd via a quorum read).
For etcd v3.4.31+ and v3.5.13+ Kubernetes {{< skew currentVersion >}} serves “most recent” reads from the _watch cache_:
an internal, in-memory store within the API server that caches and mirrors the state of data
persisted into etcd. Kubernetes requests progress notification to maintain cache consistency against
the etcd persistence layer. Kubernetes versions v1.28 through to v1.30 also supported this
feature, although as Alpha it was not recommended for production nor enabled by default until the v1.31 release.
-->
最新版本
: 返回最新资源版本的数据。
返回的数据必须一致(详细说明:通过仲裁读取从 etcd 提供)。
对于 etcd v3.4.31+ 和 v3.5.13+ Kubernetes {{< skew currentVersion >}} 使用**监视缓存**来为“最新”读取提供服务:
监视缓存是 API 服务器内部的基于内存的存储,用于缓存和镜像持久化到 etcd 中的数据状态。
Kubernetes 请求进度通知以维护与 etcd 持久层的缓存一致性。Kubernetes
版本 v1.28 至 v1.30 也支持此特性,尽管当时其处于 Alpha 状态,不推荐用于生产,
也不默认启用,直到 v1.31 版本才启用。
<!--
Not older than
@ -1992,7 +2009,7 @@ Continue Token, Exact
精确匹配
: 以提供的确切资源版本返回数据。如果提供的 `resourceVersion` 不可用,
则服务器以 HTTP 410 “Gone”响应。对于对支持 `resourceVersionMatch` 参数的服务器的 **list** 请求,
则服务器以 HTTP 410 “Gone” 响应。对于对支持 `resourceVersionMatch` 参数的服务器的 **list** 请求,
这可以保证集合的 `.metadata.resourceVersion` 与你在查询字符串中请求的 `resourceVersion` 相同。
该保证不适用于该集合中任何项目的 `.metadata.resourceVersion`
@ -2000,7 +2017,6 @@ Continue Token, Exact
: 返回初始分页 **list** 调用的资源版本的数据。
返回的 **Continue 令牌**负责跟踪最初提供的资源版本,最初提供的资源版本用于在初始分页 **list** 之后的所有分页 **list** 中。
{{< note >}}
<!--
When you **list** resources and receive a collection response, the response includes the