[zh] Resync pages under overview
parent
9b9ac3a458
commit
3a20474c11
|
@ -1,7 +1,14 @@
|
|||
---
|
||||
title: 概述
|
||||
weight: 20
|
||||
description: 获得 Kubernetes 及其构件的高层次概要。
|
||||
description: 了解 Kubernetes 及其构件的高层次概要。
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
<!--
|
||||
title: "Overview"
|
||||
weight: 20
|
||||
description: Get a high-level outline of Kubernetes and the components it is built from.
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
-->
|
||||
|
|
|
@ -23,7 +23,7 @@ The Kubernetes API lets you query and manipulate the state of API objects in Kub
|
|||
(for example: Pods, Namespaces, ConfigMaps, and Events).
|
||||
|
||||
Most operations can be performed through the
|
||||
[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
|
||||
[kubectl](/docs/reference/kubectl/) command-line interface or other
|
||||
command-line tools, such as
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/), which in turn use the
|
||||
API. However, you can also access the API directly using REST calls.
|
||||
|
@ -35,7 +35,7 @@ API 服务器负责提供 HTTP API,以供用户、集群中的不同部分和
|
|||
Kubernetes API 使你可以查询和操纵 Kubernetes API
|
||||
中对象(例如:Pod、Namespace、ConfigMap 和 Event)的状态。
|
||||
|
||||
大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/overview/) 命令行接口或
|
||||
大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/) 命令行接口或
|
||||
类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行,
|
||||
这些工具在背后也是调用 API。不过,你也可以使用 REST 调用来访问这些 API。
|
||||
|
||||
|
@ -53,14 +53,19 @@ if you are writing an application using the Kubernetes API.
|
|||
|
||||
Complete API details are documented using [OpenAPI](https://www.openapis.org/).
|
||||
|
||||
The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
|
||||
You can request the response format using request headers as follows:
|
||||
### OpenAPI V2
|
||||
|
||||
The Kubernetes API server serves an aggregated OpenAPI v2 spec via the
|
||||
`/openapi/v2` endpoint. You can request the response format using
|
||||
request headers as follows:
|
||||
-->
|
||||
## OpenAPI 规范 {#api-specification}
|
||||
|
||||
完整的 API 细节是用 [OpenAPI](https://www.openapis.org/) 来表述的。
|
||||
|
||||
Kubernetes API 服务器通过 `/openapi/v2` 末端提供 OpenAPI 规范。
|
||||
### OpenAPI V2
|
||||
|
||||
Kubernetes API 服务器通过 `/openapi/v2` 端点提供聚合的 OpenAPI v2 规范。
|
||||
你可以按照下表所给的请求头部,指定响应的格式:
|
||||
|
||||
<!--
|
||||
|
@ -138,6 +143,71 @@ Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式,主要用
|
|||
[Kubernetes Protobuf 序列化](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)
|
||||
设计提案。每种模式对应的接口描述语言(IDL)位于定义 API 对象的 Go 包中。
|
||||
|
||||
### OpenAPI V3
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
|
||||
|
||||
<!--
|
||||
Kubernetes v1.23 offers initial support for publishing its APIs as OpenAPI v3; this is an
|
||||
alpha feature that is disabled by default.
|
||||
You can enable the alpha feature by turning on the
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `OpenAPIV3`
|
||||
for the kube-apiserver component.
|
||||
-->
|
||||
Kubernetes v1.23 提供将其 API 以 OpenAPI v3 形式发布的初始支持;这一功能特性处于 Alpha
|
||||
状态,默认被禁用。
|
||||
你可以通过为 kube-apiserver 组件启用 `OpenAPIV3`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来启用此
|
||||
Alpha 特性。
|
||||
|
||||
<!--
|
||||
With the feature enabled, the Kubernetes API server serves an
|
||||
aggregated OpenAPI v3 spec per Kubernetes group version at the
|
||||
`/openapi/v3/apis/<group>/<version>` endpoint. Please refer to the
|
||||
table below for accepted request headers.
|
||||
-->
|
||||
特性被启用时,Kubernetes API 服务器会在端点 `/openapi/v3/apis/<group>/<version>`
|
||||
提供按 Kubernetes 组版本聚合的 OpenAPI v3 规范。
|
||||
请参阅下表了解可接受的请求头部。
|
||||
|
||||
<table>
|
||||
<caption style="display:none"><!--Valid request header values for OpenAPI v3 queries-->OpenAPI v3 查询的合法请求头部值</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><!--Header-->头部</th>
|
||||
<th style="min-width: 50%;"><!--Possible values-->可选值</th>
|
||||
<th><!--Notes-->说明</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>Accept-Encoding</code></td>
|
||||
<td><code>gzip</code></td>
|
||||
<td><em><!--not supplying this header is also acceptable-->不提供此头部也是可接受的</em></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3"><code>Accept</code></td>
|
||||
<td><code>application/com.github.proto-openapi.spec.v3@v1.0+protobuf</code></td>
|
||||
<td><em><!--mainly for intra-cluster use-->主要用于集群内部使用</em></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>application/json</code></td>
|
||||
<td><em><!--default-->默认</em></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>*</code></td>
|
||||
<td><em><!--serves-->以</em> <code>application/json</code> 形式返回</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
A discovery endpoint `/openapi/v3` is provided to see a list of all
|
||||
group/versions available. This endpoint only returns JSON.
|
||||
-->
|
||||
发现端点 `/openapi/v3` 被提供用来查看可用的所有组、版本列表。
|
||||
此列表仅返回 JSON。
|
||||
|
||||
<!--
|
||||
## API changes
|
||||
|
||||
|
@ -145,13 +215,6 @@ Any system that is successful needs to grow and change as new use cases emerge o
|
|||
Therefore, Kubernetes has designed its features to allow the Kubernetes API to continuously change and grow.
|
||||
The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
|
||||
compatibility for a length of time so that other projects have an opportunity to adapt.
|
||||
|
||||
In general, new API resources and new resource fields can be added often and frequently.
|
||||
Elimination of resources or fields requires following the
|
||||
[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
|
||||
|
||||
What constitutes a compatible change, and how to change the API, are detailed in
|
||||
[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
|
||||
-->
|
||||
## API 变更 {#api-changes}
|
||||
|
||||
|
@ -160,67 +223,44 @@ What constitutes a compatible change, and how to change the API, are detailed in
|
|||
Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题,并在一定的时期内
|
||||
维持这种兼容性,以便其他项目有机会作出适应性变更。
|
||||
|
||||
<!--
|
||||
In general, new API resources and new resource fields can be added often and frequently.
|
||||
Elimination of resources or fields requires following the
|
||||
[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
|
||||
-->
|
||||
一般而言,新的 API 资源和新的资源字段可以被频繁地添加进来。
|
||||
删除资源或者字段则要遵从
|
||||
[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
|
||||
关于什么是兼容性的变更、如何变更 API 等详细信息,可参考
|
||||
[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
|
||||
|
||||
<!--
|
||||
## API groups and versioning
|
||||
|
||||
To make it easier to eliminate fields or restructure resource representations,
|
||||
Kubernetes supports multiple API versions, each at a different API path, such
|
||||
as `/api/v1` or `/apis/rbac.authorization.k8s.io/v1alpha1`.
|
||||
Kubernetes makes a strong commitment to maintain compatibility for official Kubernetes APIs
|
||||
once they reach general availability (GA), typically at API version `v1`. Additionally,
|
||||
Kubernetes keeps compatibility even for _beta_ API versions wherever feasible:
|
||||
if you adopt a beta API you can continue to interact with your cluster using that API,
|
||||
even after the feature goes stable.
|
||||
-->
|
||||
## API 组和版本 {#api-groups-and-versioning}
|
||||
|
||||
为了简化删除字段或者重构资源表示等工作,Kubernetes 支持多个 API 版本,
|
||||
每一个版本都在不同 API 路径下,例如 `/api/v1` 或
|
||||
`/apis/rbac.authorization.k8s.io/v1alpha1`。
|
||||
Kubernetes 对维护达到正式发布(GA)阶段的官方 API 的兼容性有着很强的承诺,
|
||||
通常这一 API 版本为 `v1`。此外,Kubernetes 在可能的时候还会保持 Beta API
|
||||
版本的兼容性:如果你采用了 Beta API,你可以继续在集群上使用该 API,
|
||||
即使该功能特性已进入稳定期也是如此。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Versioning is done at the API level rather than at the resource or field level
|
||||
to ensure that the API presents a clear, consistent view of system resources
|
||||
and behavior, and to enable controlling access to end-of-life and/or
|
||||
experimental APIs.
|
||||
Although Kubernetes also aims to maintain compatibility for _alpha_ APIs versions, in some
|
||||
circumstances this is not possible. If you use any alpha API versions, check the release notes
|
||||
for Kubernetes when upgrading your cluster, in case the API did change.
|
||||
-->
|
||||
版本化是在 API 级别而不是在资源或字段级别进行的,目的是为了确保 API
|
||||
为系统资源和行为提供清晰、一致的视图,并能够控制对已废止的和/或实验性 API 的访问。
|
||||
|
||||
<!--
|
||||
To make it easier to evolve and to extend its API, Kubernetes implements
|
||||
[API groups](/docs/reference/using-api/#api-groups) that can be
|
||||
[enabled or disabled](/docs/reference/using-api/#enabling-or-disabling).
|
||||
-->
|
||||
为了便于演化和扩展其 API,Kubernetes 实现了
|
||||
可被[启用或禁用](/zh/docs/reference/using-api/#enabling-or-disabling)的
|
||||
[API 组](/zh/docs/reference/using-api/#api-groups)。
|
||||
|
||||
<!--
|
||||
API resources are distinguished by their API group, resource type, namespace
|
||||
(for namespaced resources), and name. The API server may serve the same
|
||||
underlying data through multiple API version and handle the conversion between
|
||||
API versions transparently. All these different versions are actually
|
||||
representations of the same resource. For example, suppose there are two
|
||||
versions `v1` and `v1beta1` for the same resource. An object created by the
|
||||
`v1beta1` version can then be read, updated, and deleted by either the
|
||||
`v1beta1` or the `v1` versions.
|
||||
-->
|
||||
API 资源之间靠 API 组、资源类型、名字空间(对于名字空间作用域的资源而言)和
|
||||
名字来相互区分。API 服务器可能通过多个 API 版本来向外提供相同的下层数据,
|
||||
并透明地完成不同 API 版本之间的转换。所有这些不同的版本实际上都是同一资源
|
||||
的(不同)表现形式。例如,假定同一资源有 `v1` 和 `v1beta1` 版本,
|
||||
使用 `v1beta1` 创建的对象则可以使用 `v1beta1` 或者 `v1` 版本来读取、更改
|
||||
或者删除。
|
||||
尽管 Kubernetes 也努力为 Alpha API 版本维护兼容性,在有些场合兼容性是无法做到的。
|
||||
如果你使用了任何 Alpha API 版本,需要在升级集群时查看 Kubernetes 发布说明,
|
||||
以防 API 的确发生变更。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
|
||||
for more details on the API version level definitions.
|
||||
-->
|
||||
关于 API 版本级别的详细定义,请参阅
|
||||
[API 版本参考](/zh/docs/reference/using-api/#api-versioning)。
|
||||
关于 API 版本分级的定义细节,请参阅
|
||||
[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。
|
||||
|
||||
<!--
|
||||
## API Extension
|
||||
|
@ -252,12 +292,15 @@ The Kubernetes API can be extended in one of two ways:
|
|||
how the cluster manages authentication and authorization for API access.
|
||||
- Learn about API endpoints, resource types and samples by reading
|
||||
[API Reference](/docs/reference/kubernetes-api/).
|
||||
- Learn about what constitutes a compatible change, and how to change the API, from
|
||||
[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
|
||||
-->
|
||||
- 了解如何通过添加你自己的
|
||||
[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
来扩展 Kubernetes API。
|
||||
- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)
|
||||
页面描述了集群如何针对 API 访问管理身份认证和鉴权。
|
||||
- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)
|
||||
了解 API 端点、资源类型以及示例。
|
||||
- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)页面描述了集群如何针对
|
||||
API 访问管理身份认证和鉴权。
|
||||
- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。
|
||||
- 阅读 [API 变更(英文)](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)
|
||||
以了解什么是兼容性的变更以及如何变更 API。
|
||||
|
||||
|
|
Loading…
Reference in New Issue