whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #24999 from tengqm/zh-sync-2

Browse Source 
[zh] Sync changes from English site (2)
This commit is contained in:
Kubernetes Prow Robot
2020-11-16 17:46:04 -08:00
committed by GitHub
parent 45da282d76 8ae2209de3
commit a0803dbc59
6 changed files with 230 additions and 257 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/overview/_index.md
+2
View File
@@ -2,4 +2,6 @@
title: 概述
weight: 20
description: 获得 Kubernetes 及其构件的高层次概要。
sitemap:
priority: 0.9
---
content/zh/docs/concepts/overview/kubernetes-api.md
+119 -201
View File
@@ -3,7 +3,9 @@ title: Kubernetes API
content_type: concept
weight: 30
description: >
Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。
Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。
Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。
用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。
card:
name: concepts
weight: 30
@@ -14,13 +16,17 @@ card:
<!--
The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server
exposes an HTTP API that lets end users, different parts of your cluster, and external components
communicate with one another.
exposes an HTTP API that lets end users, different parts of your cluster, and
external components communicate with one another.
The Kubernetes API lets you query and manipulate the state of objects in the Kubernetes API
(for example: Pods, Namespaces, ConfigMaps, and Events).
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
Most operations can be performed through the
[kubectl](/docs/reference/kubectl/overview/) 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.
-->
Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}
的核心是 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}。
@@ -29,38 +35,18 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和
Kubernetes API 使你可以查询和操纵 Kubernetes API
中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。
API 末端、资源类型以及示例都在[API 参考](/zh/docs/reference/kubernetes-api/)中描述。
<!-- body -->
大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/overview/) 命令行接口或
类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行，
这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。
<!--
## API changes
Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
Therefore, Kubernetes has design 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).
Consider using one of the [client libraries](/docs/reference/using-api/client-libraries/)
if you are writing an application using the Kubernetes API.
-->
## API 变更 {#api-changes}
如果你正在编写程序来访问 Kubernetes API，可以考虑使用
[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。
任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。
为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。
Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内
维持这种兼容性，以便其他项目有机会作出适应性变更。
一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
删除资源或者字段则要遵从
[API 废弃策略](/docs/reference/using-api/deprecation-policy/)。
关于什么是兼容性的变更，如何变更 API 等详细信息，可参考
[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
<!-- body -->
<!--
## OpenAPI specification {#api-specification}
@@ -70,7 +56,6 @@ 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 规范 {#api-specification}
完整的 API 细节是用 [OpenAPI](https://www.openapis.org/) 来表述的。
@@ -142,204 +127,137 @@ Kubernetes API 服务器通过 `/openapi/v2` 末端提供 OpenAPI 规范。
</table>
<!--
Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.
Kubernetes implements an alternative Protobuf based serialization format that
is primarily intended for intra-cluster communication. For more information
about this format, see the [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) design proposal and the
Interface Definition Language (IDL) files for each schema located in the Go
packages that define the API objects.
-->
Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部的通信。
相关文档位于[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)。
每种 Schema 对应的 IDL 位于定义 API 对象的 Go 包中。
Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部通信。
关于此格式的详细信息，可参考
[Kubernetes Protobuf 序列化](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)
设计提案。每种模式对应的接口描述语言（IDL）位于定义 API 对象的 Go 包中。
<!--
## API versioning
## API changes
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`.
Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
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-versioning}
## API 变更 {#api-changes}
任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。
为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。
Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内
维持这种兼容性，以便其他项目有机会作出适应性变更。
一般而言，新的 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`.
-->
## API 组和版本 {#api-groups-and-versioning}
为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本，
每一个版本都在不同 API 路径下，例如 `/api/v1` 或
`/apis/rbac.authorization.k8s.io/v1alpha1`。
<!--
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.
The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
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.
-->
版本化是在 API 级别而不是在资源或字段级别进行的，目的是为了确保 API
为系统资源和行为提供清晰、一致的视图，并能够控制对已废止的和/或实验性 API 的访问。
JSON 和 Protobuf 序列化模式遵循 schema 更改的相同准则 - 下面的所有描述都同时适用于这两种格式。
<!--
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 组](/docs/reference/using-api/#api-groups)。
<!--
Note that API versioning and Software versioning are only indirectly related. The
[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
proposal describes the relationship between API versioning and software versioning.
Different API versions imply different levels of stability and support. The criteria for each level are described
in more detail in the
[API Changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
documentation. They are summarized here:
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 版本控制和软件版本控制只有间接相关性。
[Kubernetes 发行版本提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
中描述了 API 版本与软件版本之间的关系。
不同的 API 版本名称意味着不同级别的软件稳定性和支持程度。
每个级别的判定标准在
[API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
中有更详细的描述。
这些标准主要概括如下：
API 资源之间靠 API 组、资源类型、名字空间（对于名字空间作用域的资源而言）和
名字来相互区分。API 服务器可能通过多个 API 版本来向外提供相同的下层数据，
并透明地完成不同 API 版本之间的转换。所有这些不同的版本实际上都是同一资源
的（不同）表现形式。例如，假定同一资源有 `v1` 和 `v1beta1` 版本，
使用 `v1beta1` 创建的对象则可以使用 `v1beta1` 或者 `v1` 版本来读取、更改
或者删除。
<!--
- Alpha level:
- The version names contain `alpha` (e.g. `v1alpha1`).
- May be buggy. Enabling the feature may expose bugs. Disabled by default.
- Support for feature may be dropped at any time without notice.
- The API may change in incompatible ways in a later software release without notice.
- Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
for more details on the API version level definitions.
-->
- Alpha 级别：
- 版本名称包含 `alpha`（例如：`v1alpha1`）
- API 可能是有缺陷的。启用该功能可能会带来问题，默认情况是禁用的
- 对相关功能的支持可能在没有通知的情况下随时终止
- API 可能在将来的软件发布中出现不兼容性的变更，此类变更不会另行通知
- 由于缺陷风险较高且缺乏长期支持，推荐仅在短暂的集群测试中使用
关于 API 版本级别的详细定义，请参阅
[API 版本参考](/zh/docs/reference/using-api/#api-versioning)。
<!--
- Beta level:
- The version names contain `beta` (e.g. `v2beta3`).
- Code is well tested. Enabling the feature is considered safe. Enabled by default.
- Support for the overall feature will not be dropped, though details may change.
- The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens,
we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating
API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have
multiple clusters which can be upgraded independently, you may be able to relax this restriction.
- **Please do try our beta features and give feedback on them! Once they exit beta, it may not be practical for us to make more changes.**
## API Extension
The Kubernetes API can be extended in one of two ways:
-->
- Beta 级别：
- 版本名称包含 `beta`（例如：`v2beta3`）
- 代码已经充分测试过。启用该功能被认为是安全的，功能默认已启用。
- 所支持的功能作为一个整体不会被删除，尽管细节可能会发生变更。
- 对象的模式和/或语义可能会在后续的 beta 发行版或稳定版中以不兼容的方式进行更改。
发生这种情况时，我们将提供如何迁移到新版本的说明。
迁移操作可能需要删除、编辑和重新创建 API 对象。
执行编辑操作时可能需要动些脑筋。
迁移过程中可能需要停用依赖该功能的应用程序。
- 建议仅用于非业务关键性用途，因为后续版本中可能存在不兼容的更改。
如果你有多个可以独立升级的集群，则可以放宽此限制。
- **请尝试我们的 beta 版本功能并且给出反馈！一旦它们结束 beta 阶段，进一步变更可能就不太现实了。**
<!--
- Stable level:
- The version name is `vX` where `X` is an integer.
- Stable versions of features will appear in released software for many subsequent versions.
-->
- 稳定级别：
- 版本名称是 `vX`，其中 `X` 是整数。
- 功能的稳定版本将出现在许多后续版本的发行软件中。
## API 扩展 {#api-extension}
有两种途径来扩展 Kubernetes API：
<!--
## API groups
To make it easier to extend the Kubernetes API, Kubernetes implemented [*API groups*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
1. [Custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
let you declaratively define how the API server should provide your chosen resource API.
1. You can also extend the Kubernetes API by implementing an
[aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
-->
## API 组 {#api-groups}
为了更容易地扩展 Kubernetes API，Kubernetes 实现了
[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。
API 组在 REST 路径和序列化对象的 `apiVersion` 字段中指定。
<!--
There are several API groups in a cluster:
1. The *core* group, also referred to as the *legacy* group, is at the REST path `/api/v1` and uses `apiVersion: v1`.
1. *Named* groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
(e.g. `apiVersion: batch/v1`). The Kubernetes [API reference](/docs/reference/kubernetes-api/) has a
full list of available API groups.
-->
集群中存在若干 API 组：
1. *核心（Core）*组，通常被称为 *遗留（Legacy）* 组，位于 REST 路径 `/api/v1`，
使用 `apiVersion: v1`。
1. *命名（Named）* 组 REST 路径 `/apis/$GROUP_NAME/$VERSION`，使用
`apiVersion: $GROUP_NAME/$VERSION`（例如 `apiVersion: batch/v1`）。
[Kubernetes API 参考](/zh/docs/reference/kubernetes-api/)中枚举了可用的 API 组的完整列表。
<!--
There are two paths to extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/):
1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
lets you declaratively define how the API server should provide your chosen resource API.
1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/)
and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
to make it seamless for clients.
-->
有两种途径来扩展 Kubernetes API 以支持
[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
1. 使用 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
你可以用声明式方式来定义 API 如何提供你所选择的资源 API。
1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
并使用[聚合器](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
为客户提供无缝的服务。
<!--
## Enabling or disabling API groups
Certain resources and API groups are enabled by default. They can be enabled or disabled by setting `-runtime-config`
on apiserver. `-runtime-config` accepts comma separated values. For example: to disable batch/v1, set
`-runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `-runtime-config=batch/v2alpha1`.
The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
Enabling or disabling groups or resources requires restarting apiserver and controller-manager
to pick up the `-runtime-config` changes.
-->
## 启用或禁用 API 组 {#enabling-or-disabling-api-groups}
某些资源和 API 组默认情况下处于启用状态。可以通过为 `kube-apiserver`
设置 `--runtime-config` 命令行选项来启用或禁用它们。
`--runtime-config` 接受逗号分隔的值。
例如：要禁用 `batch/v1`，设置 `--runtime-config=batch/v1=false`；
要启用 `batch/v2alpha1`，设置`--runtime-config=batch/v2alpha1`。
该标志接受逗号分隔的一组"key=value"键值对，用以描述 API 服务器的运行时配置。
{{< note >}}
启用或禁用组或资源需要重新启动 `kube-apiserver` 和 `kube-controller-manager`
来使得 `--runtime-config` 更改生效。
{{< /note >}}
<!--
## Persistence
Kubernetes stores its serialized state in terms of the API resources by writing them into
{{< glossary_tooltip term_id="etcd" >}}.
-->
## 持久性 {#persistence}
Kubernetes 也将其 API 资源的序列化状态保存起来，写入到 {{< glossary_tooltip term_id="etcd" >}}。
1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
来以声明式方式定义 API 服务器如何提供你所选择的资源 API。
1. 你也可以选择实现自己的
[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
来扩展 Kubernetes API。
## {{% heading "whatsnext" %}}
<!--
[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes
how the cluster manages authentication and authorization for API access.
Overall API conventions are described in the
[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)
document.
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
- Learn how to extend the Kubernetes API by adding your own
[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
- [Controlling Access To The Kubernetes API](/docs/concepts/security/controlling-access/) describes
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/).
-->
* [控制 API 访问](/zh/docs/reference/access-authn-authz/controlling-access/)
描述了集群如何为 API 访问管理身份认证和权限判定；
* 总体的 API 约定描述位于 [API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)中；
* API 末端、资源类型和示例等均在 [API 参考文档](/zh/docs/reference/kubernetes-api/)中描述
- 了解如何通过添加你自己的
[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 端点、资源类型以及示例。
content/zh/docs/concepts/overview/what-is-kubernetes.md
+94 -43
View File
@@ -9,7 +9,6 @@ card:
weight: 10
---
<!--
---
reviewers:
- bgrant0607
- mikedanese
@@ -19,7 +18,6 @@ weight: 10
card:
name: concepts
weight: 10
---
-->
<!-- overview -->
@@ -33,18 +31,22 @@ This page is an overview of Kubernetes.
<!--
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
-->
Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
<!--
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a [decade and a half of experience that Google has with running production workloads at scale](https://research.google/pubs/pub43438), combined with best-of-breed ideas and practices from the community.
-->
名称 **Kubernetes** 源于希腊语，意为 "舵手" 或 "飞行员"。Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438)的基础上，结合了社区中最好的想法和实践。
名称 **Kubernetes** 源于希腊语，意为“舵手”或“飞行员”。Google 在 2014 年开源了 Kubernetes 项目。
Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438)
的基础上，结合了社区中最好的想法和实践。
<!--
## Going back in time
Let's take a look at why Kubernetes is so useful by going back in time.
-->
## 言归正传
## 时光回溯
让我们回顾一下为什么 Kubernetes 如此有用。
<!--
@@ -54,24 +56,34 @@ Let's take a look at why Kubernetes is so useful by going back in time.
<!--
**Traditional deployment era:**
Early on, organizations ran applications on physical servers. There was no way to define resource boundaries for applications in a physical server, and this caused resource allocation issues. For example, if multiple applications run on a physical server, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers.
-->
**传统部署时代：**
早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。
早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。
例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，
结果可能导致其他应用程序的性能下降。
一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，
并且组织维护许多物理服务器的成本很高。
<!--
**Virtualized deployment era:**
As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization allows applications to be isolated between VMs and provides a level of security as the information of one application cannot be freely accessed by another application.
-->
**虚拟化部署时代：**
作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。
作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。
虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全，因为一个应用程序的信息
不能被另一应用程序随意访问。
<!--
Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more.
Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware.
-->
因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。
虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序
而可以实现更好的可伸缩性，降低硬件成本等等。
每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。
@@ -80,12 +92,15 @@ Each VM is a full machine running all the components, including its own operatin
Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
-->
**容器部署时代：**
容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。
容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。
因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。
由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
<!--
Containers are becoming popular because they have many benefits. Some of the container benefits are listed below:
-->
容器因具有许多优势而变得流行起来。下面列出了容器的一些好处：
容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处：
<!--
* Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.
@@ -100,13 +115,18 @@ Containers are becoming popular because they have many benefits. Some of the con
* Resource utilization: high efficiency and density.
-->
* 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
* 持续开发、集成和部署：通过快速简单的回滚(由于镜像不可变性)，提供可靠且频繁的容器镜像构建和部署。
* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的
容器镜像构建和部署。
* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，
从而将应用程序与基础架构分离。
* 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
* 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
* 云和操作系统分发的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。
* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
* 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
* 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、
Google Kubernetes Engine 和其他任何地方运行。
* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在
OS 上运行应用程序。
* 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，
并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
* 资源隔离：可预测的应用程序性能。
* 资源利用：高效率和高密度。
@@ -118,59 +138,75 @@ Containers are becoming popular because they have many benefits. Some of the con
<!--
Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system?
-->
容器是打包和运行应用程序的好方式。在生产环境中，您需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。
例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
<!--
That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of your scaling requirements, failover, deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system.
-->
这就是 Kubernetes 的救援方法！Kubernetes 为您提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。例如，Kubernetes 可以轻松管理系统的 Canary 部署。
这就是 Kubernetes 来解决这些问题的方法！
Kubernetes 为你提供了一个可弹性运行分布式系统的框架。
Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
例如，Kubernetes 可以轻松管理系统的 Canary 部署。
<!--
Kubernetes provides you with:
-->
Kubernetes 为您提供：
Kubernetes 为你提供：
<!--
* **Service discovery and load balancing**
Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
-->
* **服务发现和负载均衡**
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
* **服务发现和负载均衡**
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大，
Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
<!--
* **Storage orchestration**
Kubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.
-->
* **存储编排**
Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。
* **存储编排**
Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
<!--
* **Automated rollouts and rollbacks**
You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.
-->
* **自动部署和回滚**
您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
* **自动部署和回滚**
你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态
更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器，
删除现有容器并将它们的所有资源用于新容器。
<!--
* **Automatic bin packing**
Kubernetes allows you to specify how much CPU and memory (RAM) each container needs. When containers have resource requests specified, Kubernetes can make better decisions to manage the resources for containers.
-->
* **自动二进制打包**
Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
* **自动完成装箱计算**
Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。
当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
<!--
* **Self-healing**
Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
-->
* **自我修复**
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
* **自我修复**
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的
运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
<!--
* **Secret and configuration management**
Kubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration.
-->
* **密钥与配置管理**
Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
* **密钥与配置管理**
Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。
你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
<!--
## What Kubernetes is not
@@ -180,7 +216,11 @@ Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和
<!--
Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
-->
Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。由于 Kubernetes 在容器级别而不是在硬件级别运行，因此它提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡、日志记录和监视。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。
由于 Kubernetes 在容器级别而不是在硬件级别运行，它提供了 PaaS 产品共有的一些普遍适用的功能，
例如部署、扩展、负载均衡、日志记录和监视。
但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。
Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
<!--
Kubernetes:
@@ -192,22 +232,33 @@ Kubernetes：
* Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements.
* Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, mysql), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes through portable mechanisms, such as the Open Service Broker.
-->
* Kubernetes 不限制支持的应用程序类型。Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
* Kubernetes 不部署源代码，也不构建您的应用程序。持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
* Kubernetes 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统（例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如，[开放服务代理](https://openservicebrokerapi.org/)）来访问。
* 不限制支持的应用程序类型。
Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。
如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
* 不部署源代码，也不构建你的应用程序。
持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
* 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、
数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统
（例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在
Kubernetes 上的应用程序通过可移植机制（例如，
[开放服务代理](https://openservicebrokerapi.org/)）来访问。
<!--
* Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics.
* Does not provide nor mandate a configuration language/system (for example, jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications.
* Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
-->
* Kubernetes 不指定日志记录、监视或警报解决方案。它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
* Kubernetes 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，该声明性 API 可以由任意形式的声明性规范所构成。
* Kubernetes 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
* 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。相比之下，Kubernetes 包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用且功能更强大、健壮、弹性和可扩展性。
* 不要求日志记录、监视或警报解决方案。
它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
* 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，
该声明性 API 可以由任意形式的声明性规范所构成。
* 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
* 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。
编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。
相比之下，Kubernetes 包含一组独立的、可组合的控制过程，
这些过程连续地将当前状态驱动到所提供的所需状态。
如何从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用
且功能更强大、系统更健壮、更为弹性和可扩展。
## {{% heading "whatsnext" %}}
@@ -215,5 +266,5 @@ Kubernetes：
* Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
* Ready to [Get Started](/docs/setup/)?
-->
* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
* 开始 [Kubernetes 入门](/zh/docs/setup/)?
* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
* 开始 [Kubernetes 入门](/zh/docs/setup/)?
content/zh/docs/concepts/overview/working-with-objects/annotations.md
+4 -4
View File
@@ -121,18 +121,18 @@ _注解（Annotations）_ 存储的形式是键/值对。有效的注解键分
并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。
前缀是可选的。如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，
总计不超过253个字符，后跟斜杠（`/`）。
如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释
如果省略前缀，则假定注解键对用户是私有的。 由系统组件添加的注解
（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl`
或其他第三方组件），必须为终端用户添加注释前缀。
或其他第三方组件），必须为终端用户添加注解前缀。
<!--
The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
For example, here’s the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` :
For example, here's the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` :
-->
`kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。
例如，这是Pod的配置文件，其注释为 `imageregistry: https://hub.docker.com/`：
例如，下面是一个 Pod 的配置文件，其注解中包含 `imageregistry: https://hub.docker.com/`：
```yaml
apiVersion: v1
content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+6 -6
View File
@@ -191,11 +191,11 @@ and the `spec` format for a `Deployment` can be found
## {{% heading "whatsnext" %}}
<!--
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
* [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.
-->
* [Kubernetes API 总览](/zh/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述
* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)
* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)
* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。
* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。
* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。
content/zh/docs/concepts/overview/working-with-objects/labels.md
+5 -3
View File
@@ -307,7 +307,7 @@ and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationc
also use label selectors to specify sets of other resources, such as
[pods](/docs/concepts/workloads/pods/).
-->
### 在 API 对象上设置引用
### 在 API 对象中设置引用
一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/)
和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ，
@@ -323,9 +323,11 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma
-->
#### Service 和 ReplicationController
一个 `Service` 指向的一组 pods 是由标签选择算符定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择算符定义的。
一个 `Service` 指向的一组 Pods 是由标签选择算符定义的。同样，一个 `ReplicationController`
应该管理的 pods 的数量也是由标签选择算符定义的。
两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于等值_ 需求的选择算符：
两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持
_基于等值_ 需求的选择算符：
```json
"selector": {