@@ -32,15 +32,18 @@ Kubernetes API 是通过 HTTP 提供的基于资源 (RESTful) 的编程接口。
32
32
为了方便或者提高效率,可以以不同的表示形式接受和服务这些资源。
33
33
34
34
<!--
35
- Kubernetes supports efficient change notifications on resources via *watches*.
35
+ Kubernetes supports efficient change notifications on resources via
36
+ _watches_:
37
+ {{< glossary_definition prepend="in the Kubernetes API, watch is" term_id="watch" length="short" >}}
36
38
Kubernetes also provides consistent list operations so that API clients can
37
39
effectively cache, track, and synchronize the state of resources.
38
40
39
41
You can view the [API reference](/docs/reference/kubernetes-api/) online,
40
42
or read on to learn about the API in general.
41
43
-->
42
- Kubernetes 支持通过 ** watch** 实现高效的资源变更通知。
43
- Kubernetes 还提供了一致的列表操作,以便 API 客户端可以有效地缓存、跟踪和同步资源的状态。
44
+ Kubernetes 支持通过 ** watch** 实现高效的资源变更通知:
45
+ {{< glossary_definition prepend="在 Kubernetes API 中,watch 的是" term_id="watch" length="short" >}}
46
+ Kubernetes 还提供一致的列表操作,以便 API 客户端可以有效地缓存、跟踪和同步资源的状态。
44
47
45
48
你可以在线查看 [ API 参考] ( /zh-cn/docs/reference/kubernetes-api/ ) ,
46
49
或继续阅读以了解 API 的一般信息。
@@ -83,9 +86,9 @@ as a permission check
83
86
大多数 Kubernetes API
84
87
资源类型都是[ 对象] ( /zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects ) :
85
88
它们代表集群上某个概念的具体实例,例如 Pod 或名字空间。
86
- 少数 API 资源类型是 “虚拟的”,它们通常代表的是操作而非对象本身,
89
+ 少数 API 资源类型是“虚拟的”,它们通常代表的是操作而非对象本身,
87
90
例如权限检查(使用带有 JSON 编码的 ` SubjectAccessReview ` 主体的 POST 到 ` subjectaccessreviews ` 资源),
88
- 或 Pod 的子资源 ` eviction ` (用于触发 [ API- 发起的驱逐] ( /zh-cn/docs/concepts/scheduling-eviction/api-eviction/ ) )。
91
+ 或 Pod 的子资源 ` eviction ` (用于触发 [ API 发起的驱逐] ( /zh-cn/docs/concepts/scheduling-eviction/api-eviction/ ) )。
89
92
90
93
<!--
91
94
### Object names
@@ -161,7 +164,8 @@ Examples:
161
164
162
165
注意: 核心资源使用 ` /api ` 而不是 ` /apis ` ,并且不包含 GROUP 路径段。
163
166
164
- 例如:
167
+ 例如:
168
+
165
169
* ` /api/v1/namespaces `
166
170
* ` /api/v1/pods `
167
171
* ` /api/v1/namespaces/my-namespace/pods `
@@ -187,9 +191,12 @@ The following paths are used to retrieve collections and resources:
187
191
你还可以访问资源集合(例如:列出所有 Node)。以下路径用于检索集合和资源:
188
192
189
193
* 集群作用域的资源:
194
+
190
195
* ` GET /apis/GROUP/VERSION/RESOURCETYPE ` - 返回指定资源类型的资源的集合
191
196
* ` GET /apis/GROUP/VERSION/RESOURCETYPE/NAME ` - 返回指定资源类型下名称为 NAME 的资源
197
+
192
198
* 名字空间作用域的资源:
199
+
193
200
* ` GET /apis/GROUP/VERSION/RESOURCETYPE ` - 返回所有名字空间中指定资源类型的全部实例的集合
194
201
* ` GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE ` - 返回名字空间 NAMESPACE 内给定资源类型的全部实例的集合
195
202
* ` 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.
535
542
-->
536
543
在较大规模集群中,检索某些资源类型的集合可能会导致非常大的响应,从而影响服务器和客户端。
537
544
例如,一个集群可能有数万个 Pod,每个 Pod 大约相当于 2 KiB 的编码 JSON。
538
- 跨所有名字空间检索所有 Pod 可能会导致非常大的响应 ( 10-20MB) 并消耗大量服务器资源。
545
+ 跨所有名字空间检索所有 Pod 可能会导致非常大的响应( 10-20MB) 并消耗大量服务器资源。
539
546
540
547
<!--
541
548
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
1280
1287
` Warn `
1281
1288
:(默认值)使 API 服务器成功处理请求,并向客户端发送告警信息。告警信息通过 ` Warning: ` 响应头发送,
1282
1289
并为每个未知字段或重复字段添加一条告警信息。有关告警和相关的 Kubernetes API 的信息,
1283
- 可参阅博文[ 告警:增加实用告警功能] ( /blog/2020/09/03/warnings/ ) 。
1290
+ 可参阅博文[ 告警:增加实用告警功能] ( /zh-cn/ blog/2020/09/03/warnings/ ) 。
1284
1291
1285
1292
<!--
1286
1293
: 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
1418
1425
-->
1419
1426
如果请求的非试运行版本会触发具有副作用的准入控制器,则该请求将失败,而不是冒不希望的副作用的风险。
1420
1427
所有内置准入控制插件都支持试运行。
1421
- 此外,准入 Webhook 还可以设置[ 配置对象] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhook-v1-admissionregistration-k8s-io)
1428
+ 此外,准入 Webhook 还可以设置[ 配置对象] (/zh-cn/ docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhook-v1-admissionregistration-k8s-io)
1422
1429
的 ` sideEffects ` 字段为 ` None ` ,借此声明它们没有副作用。
1423
1430
1424
1431
<!--
@@ -1844,7 +1851,7 @@ For **get** and **list**, the semantics of `resourceVersion` are:
1844
1851
1845
1852
对于 **get** 和 **list** 而言,`resourceVersion` 的语义为:
1846
1853
1847
- **get: **
1854
+ **get: **
1848
1855
1849
1856
<!--
1850
1857
| resourceVersion unset | resourceVersion="0" | resourceVersion="{value other than 0}" |
@@ -1855,7 +1862,7 @@ For **get** and **list**, the semantics of `resourceVersion` are:
1855
1862
|-----------------------|---------------------|----------------------------------------|
1856
1863
| 最新版本 | 任何版本 | 不老于给定版本 |
1857
1864
1858
- **list: **
1865
+ **list: **
1859
1866
1860
1867
<!--
1861
1868
From version v1.19, Kubernetes API servers support the `resourceVersionMatch` parameter
@@ -1943,21 +1950,31 @@ Any
1943
1950
for the request to return data at a much older resource version that the client has previously
1944
1951
observed, particularly in high availability configurations, due to partitions or stale
1945
1952
caches. Clients that cannot tolerate this should not use this semantic.
1946
-
1947
- Most recent
1948
- : Return data at the most recent resource version. The returned data must be
1949
- consistent (in detail : served from etcd via a quorum read).
1950
1953
-->
1951
1954
任意版本
1952
1955
: 返回任何资源版本的数据。最新可用资源版本优先,但不需要强一致性;
1953
1956
可以提供任何资源版本的数据。由于分区或过时的缓存,
1954
1957
请求可能返回客户端先前观察到的更旧资源版本的数据,特别是在高可用性配置中。
1955
1958
不能容忍这种情况的客户不应该使用这种语义。
1956
1959
1960
+ <!--
1961
+ Most recent
1962
+ : Return data at the most recent resource version. The returned data must be
1963
+ consistent (in detail : served from etcd via a quorum read).
1964
+ For etcd v3.4.31+ and v3.5.13+ Kubernetes {{< skew currentVersion >}} serves “most recent” reads from the _watch cache_ :
1965
+ an internal, in-memory store within the API server that caches and mirrors the state of data
1966
+ persisted into etcd. Kubernetes requests progress notification to maintain cache consistency against
1967
+ the etcd persistence layer. Kubernetes versions v1.28 through to v1.30 also supported this
1968
+ feature, although as Alpha it was not recommended for production nor enabled by default until the v1.31 release.
1969
+ -->
1957
1970
最新版本
1958
1971
: 返回最新资源版本的数据。
1959
1972
返回的数据必须一致(详细说明:通过仲裁读取从 etcd 提供)。
1960
-
1973
+ 对于 etcd v3.4.31+ 和 v3.5.13+ Kubernetes {{< skew currentVersion >}} 使用**监视缓存**来为“最新”读取提供服务:
1974
+ 监视缓存是 API 服务器内部的基于内存的存储,用于缓存和镜像持久化到 etcd 中的数据状态。
1975
+ Kubernetes 请求进度通知以维护与 etcd 持久层的缓存一致性。Kubernetes
1976
+ 版本 v1.28 至 v1.30 也支持此特性,尽管当时其处于 Alpha 状态,不推荐用于生产,
1977
+ 也不默认启用,直到 v1.31 版本才启用。
1961
1978
1962
1979
<!--
1963
1980
Not older than
@@ -1992,15 +2009,14 @@ Continue Token, Exact
1992
2009
1993
2010
精确匹配
1994
2011
: 以提供的确切资源版本返回数据。如果提供的 `resourceVersion` 不可用,
1995
- 则服务器以 HTTP 410 “Gone”响应。对于对支持 `resourceVersionMatch` 参数的服务器的 **list** 请求,
2012
+ 则服务器以 HTTP 410 “Gone” 响应。对于对支持 `resourceVersionMatch` 参数的服务器的 **list** 请求,
1996
2013
这可以保证集合的 `.metadata.resourceVersion` 与你在查询字符串中请求的 `resourceVersion` 相同。
1997
2014
该保证不适用于该集合中任何项目的 `.metadata.resourceVersion`。
1998
2015
1999
2016
从 token 开始、精确匹配
2000
2017
: 返回初始分页 **list** 调用的资源版本的数据。
2001
2018
返回的 **Continue 令牌**负责跟踪最初提供的资源版本,最初提供的资源版本用于在初始分页 **list** 之后的所有分页 **list** 中。
2002
2019
2003
-
2004
2020
{{< note >}}
2005
2021
<!--
2006
2022
When you **list** resources and receive a collection response, the response includes the
0 commit comments