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

Merge remote-tracking branch 'upstream/master' into dev-1.19

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-08-03 16:09:39 -04:00
parent af4e2fdf2b 243e799580
commit 53c71ad3f9
170 changed files with 10327 additions and 3906 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/_index.md
-133
View File
@@ -19,136 +19,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an
-->
概念部分可以帮助你了解 Kubernetes 的各个组成部分以及 Kubernetes 用来表示集群的一些抽象概念，并帮助你更加深入的理解 Kubernetes 是如何工作的。
<!-- body -->
<!--
## Overview
-->
## 概述
<!--
To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
-->
要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。
<!--
Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
-->
一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：
<!--
* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
* Each individual non-master node in your cluster runs two processes:
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
-->
* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节点上，主控组件通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
* 集群中的每个非 master 节点都运行两个进程：
* **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
* **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
<!--
## Kubernetes Objects
-->
## Kubernetes 对象
<!--
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details.
-->
Kubernetes 包含若干用来表示系统状态的抽象层，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。有关更多详细信息，请参阅[了解 Kubernetes 对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)。
<!--
The basic Kubernetes objects include:
-->
基本的 Kubernetes 对象包括：
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
* [Service](/docs/concepts/services-networking/service/)
* [Volume](/docs/concepts/storage/volumes/)
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
<!--
Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
-->
Kubernetes 也包含大量的被称作 [Controller](/docs/concepts/architecture/controller/) 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
<!--
## Kubernetes Control Plane
-->
## Kubernetes 控制面
<!--
The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
-->
关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。
<!--
For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
-->
比如， 当你通过 Kubernetes API 创建一个 Deployment 对象，你就为系统增加了一个新的目标状态。Kubernetes 控制平面记录着对象的创建，并启动必要的应用然后将它们调度至集群某个节点上来执行你的指令，以此来保持集群的实际状态和目标状态的匹配。
<!--
### Kubernetes Master
-->
### Kubernetes Master 节点
<!--
The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
-->
Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时，使用如 `kubectl` 的命令行工具，就可以直接与 Kubernetes master 节点进行通信。
<!--
> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
-->
> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。
<!--
### Kubernetes Nodes
-->
### Kubernetes Node 节点
<!--
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
-->
集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。
## {{% heading "whatsnext" %}}
<!--
If you would like to write a concept page, see
[Using Page Templates](/docs/home/contribute/page-templates/)
for information about the concept page type and the concept template.
-->
如果你想编写一个概念页面，请参阅[使用页面模板](/docs/home/contribute/page-templates/)获取更多有关概念页面类型和概念模板的信息。
content/zh/docs/concepts/configuration/configmap.md
+6 -6
View File
@@ -19,7 +19,6 @@ ConfigMap 并不提供保密或者加密功能。如果你想存储的数据是
{{< /caution >}}
<!-- body -->
<!--
## Motivation
@@ -59,9 +58,11 @@ The name of a ConfigMap must be a valid
-->
## ConfigMap 对象
ConfigMap 是一个 API [对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)，让你可以存储其他对象所需要使用的配置。和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。
ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)，
让你可以存储其他对象所需要使用的配置。
和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。
ConfigMap 的名字必须是一个合法的 [DNS 子域名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
ConfigMap 的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
<!--
## ConfigMaps and Pods
@@ -216,15 +217,14 @@ ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容
## {{% heading "whatsnext" %}}
<!--
* Read about [Secrets](/docs/concepts/configuration/secret/).
* Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
separating code from configuration.
-->
* 阅读 [Secret](/docs/concepts/configuration/secret/)。
* 阅读 [配置 Pod 来使用 ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。
* 阅读 [配置 Pod 来使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
* 阅读 [Twelve-Factor 应用](https://12factor.net/) 来了解将代码和配置分开的动机。
content/zh/docs/concepts/configuration/manage-resources-containers.md
+27 -31
View File
@@ -9,7 +9,6 @@ feature:
---
<!--
---
title: Managing Resources for Containers
content_type: concept
weight: 40
@@ -17,7 +16,6 @@ feature:
title: Automatic binpacking
description: >
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
---
-->
<!-- overview -->
@@ -35,7 +33,7 @@ at least the _request_ amount of that system resource specifically for that cont
to use.
-->
当你定义 {{< glossary_tooltip term_id="pod" >}} 时可以选择性地为每个
当你定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 时可以选择性地为每个
{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。
最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。
@@ -138,8 +136,8 @@ through the Kubernetes API server.
CPU 和内存统称为*计算资源*，或简称为*资源*。
计算资源的数量是可测量的，可以被请求、被分配、被消耗。
它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。
API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过
它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。
API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过
Kubernetes API 服务器读取和修改的对象。
<!--
@@ -249,8 +247,8 @@ metadata:
name: frontend
spec:
containers:
- name: db
image: mysql
- name: app
image: images.my-company.example/app:v4
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
@@ -261,8 +259,8 @@ spec:
limits:
memory: "128Mi"
cpu: "500m"
- name: wp
image: wordpress
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
@@ -388,9 +386,9 @@ directly or from your monitoring tools.
Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。
如果为集群配置了可选的
[监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，
[监控工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，
则可以直接从
[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
[指标 API](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
或者监控工具获得 Pod 的资源使用情况。
<!--
@@ -417,7 +415,7 @@ mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir
Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。
kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用
[`emptyDir`](/docs/concepts/storage/volumes/#emptydir) 类型的
[`emptyDir`](/zh/docs/concepts/storage/volumes/#emptydir) 类型的
{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。
<!--
@@ -436,7 +434,7 @@ of ephemeral local storage a Pod can consume.
-->
kubelet 也使用此类存储来保存
[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
容器镜像文件、以及运行中容器的可写入层。
{{< caution >}}
@@ -474,7 +472,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储：
（kubelet）来保存数据的。
kubelet 也会生成
[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
并按临时性本地存储的方式对待之。
<!--
@@ -525,7 +523,7 @@ as you like.
无关的其他系统日志）；这个文件系统还可以是根文件系统。
kubelet 也将
[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
写入到第一个文件系统中，并按临时性本地存储的方式对待之。
同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉
@@ -558,7 +556,7 @@ than as local ephemeral storage.
kubelet 能够度量其本地存储的用量。实现度量机制的前提是：
- `LocalStorageCapacityIsolation` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且
- `LocalStorageCapacityIsolation` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且
- 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一
如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。
@@ -617,18 +615,15 @@ metadata:
name: frontend
spec:
containers:
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
- name: app
image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
- name: wp
image: wordpress
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
@@ -650,7 +645,7 @@ The scheduler ensures that the sum of the resource requests of the scheduled Con
当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。
每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。
欲了解更多信息，可参考
[节点可分配资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
节。
调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。
@@ -838,7 +833,7 @@ If you want to use project quotas, you should:
如果你希望使用项目配额，你需要：
* 在 kubelet 配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
* 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS
文件系统都支持项目配额。
@@ -896,7 +891,8 @@ for how to advertise device plugin managed resources on each node.
##### 设备插件管理的资源
有关如何颁布在各节点上由设备插件所管理的资源，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
有关如何颁布在各节点上由设备插件所管理的资源，请参阅
[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
<!--
##### Other resources
@@ -1198,11 +1194,11 @@ with namespaces, it can prevent one team from hogging all the resources.
通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。
可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。
[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core)
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
的 `allocatable` 字段给出了可用于 Pod 的资源量。
有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。
可以配置 [资源配额](/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。
可以配置 [资源配额](/zh/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。
如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。
<!--
@@ -1301,10 +1297,10 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
-->
* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
* 获取将 [分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
* 获取将 [分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
* 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)
* 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。
* 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。
* 阅读 XFS 中关于 [项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。
* 阅读 XFS 中关于 [项目配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。
content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+50 -51
View File
@@ -4,12 +4,10 @@ content_type: concept
weight: 60
---
<!--
---
title: Organizing Cluster Access Using kubeconfig Files
content_type: concept
weight: 60
---
--->
-->
<!-- overview -->
@@ -18,7 +16,7 @@ Use kubeconfig files to organize information about clusters, users, namespaces,
authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
find the information it needs to choose a cluster and communicate with the API server
of a cluster.
--->
-->
使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。
<!--
@@ -27,7 +25,7 @@ A file that is used to configure access to clusters is called
a *kubeconfig file*. This is a generic way of referring to configuration files.
It does not mean that there is a file named `kubeconfig`.
{{< /note >}}
--->
-->
{{< note >}}
用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件
{{< /note >}}
@@ -36,37 +34,37 @@ It does not mean that there is a file named `kubeconfig`.
By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
You can specify other kubeconfig files by setting the `KUBECONFIG` environment
variable or by setting the
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag.
--->
默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。您可以通过设置 `KUBECONFIG` 环境变量或者设置[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。
[`-kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag.
-->
默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。
您可以通过设置 `KUBECONFIG` 环境变量或者设置
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。
<!--
For step-by-step instructions on creating and specifying kubeconfig files, see
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
--->
有关创建和指定 kubeconfig 文件的分步说明，请参阅[配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
-->
有关创建和指定 kubeconfig 文件的分步说明，请参阅
[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
<!-- body -->
<!--
## Supporting multiple clusters, users, and authentication mechanisms
--->
-->
## 支持多集群、用户和身份认证机制
<!--
Suppose you have several clusters, and your users and components authenticate
in a variety of ways. For example:
--->
-->
假设您有多个集群，并且您的用户和组件以多种方式进行身份认证。比如：
<!--
- A running kubelet might authenticate using certificates.
- A user might authenticate using tokens.
- Administrators might have sets of certificates that they provide to individual users.
--->
-->
- 正在运行的 kubelet 可能使用证书在进行认证。
- 用户可能通过令牌进行认证。
- 管理员可能拥有多个证书集合提供给各用户。
@@ -75,12 +73,12 @@ in a variety of ways. For example:
With kubeconfig files, you can organize your clusters, users, and namespaces.
You can also define contexts to quickly and easily switch between
clusters and namespaces.
--->
-->
使用 kubeconfig 文件，您可以组织集群、用户和命名空间。您还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。
<!--
## Context
--->
-->
## 上下文（Context）
<!--
@@ -88,12 +86,12 @@ A *context* element in a kubeconfig file is used to group access parameters
under a convenient name. Each context has three parameters: cluster, namespace, and user.
By default, the `kubectl` command-line tool uses parameters from
the *current context* to communicate with the cluster.
--->
-->
通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。
<!--
To choose the current context:
--->
-->
选择当前上下文
```
kubectl config use-context
@@ -101,7 +99,7 @@ kubectl config use-context
<!--
## The KUBECONFIG environment variable
--->
-->
## KUBECONFIG 环境变量
<!--
@@ -110,25 +108,29 @@ For Linux and Mac, the list is colon-delimited. For Windows, the list
is semicolon-delimited. The `KUBECONFIG` environment variable is not
required. If the `KUBECONFIG` environment variable doesn't exist,
`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`.
--->
`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。`KUBECONFIG` 环境变量不是必要的。如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。
-->
`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。
对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。
`KUBECONFIG` 环境变量不是必要的。
如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。
<!--
If the `KUBECONFIG` environment variable does exist, `kubectl` uses
an effective configuration that is the result of merging the files
listed in the `KUBECONFIG` environment variable.
--->
-->
如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。
<!--
## Merging kubeconfig files
--->
-->
## 合并 kubeconfig 文件
<!--
To see your configuration, enter this command:
--->
-->
要查看配置，输入以下命令：
```shell
kubectl config view
```
@@ -136,16 +138,16 @@ kubectl config view
<!--
As described previously, the output might be from a single kubeconfig file,
or it might be the result of merging several kubeconfig files.
--->
-->
如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。
<!--
Here are the rules that `kubectl` uses when it merges kubeconfig files:
--->
-->
以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。
<!--
1. If the `--kubeconfig` flag is set, use only the specified file. Do not merge.
1. If the `-kubeconfig` flag is set, use only the specified file. Do not merge.
Only one instance of this flag is allowed.
Otherwise, if the `KUBECONFIG` environment variable is set, use it as a
@@ -160,7 +162,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
Example: Preserve the context of the first file to set `current-context`.
Example: If two files specify a `red-user`, use only values from the first file's `red-user`.
Even if the second file has non-conflicting entries under `red-user`, discard them.
--->
-->
1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。
否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件：
@@ -173,20 +175,21 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
<!--
For an example of setting the `KUBECONFIG` environment variable, see
[Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
--->
有关设置 `KUBECONFIG` 环境变量的示例，请参阅[设置 KUBECONFIG 环境变量](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
-->
有关设置 `KUBECONFIG` 环境变量的示例，请参阅
[设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
<!--
Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
--->
-->
否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。
<!--
1. Determine the context to use based on the first hit in this chain:
1. Use the `--context` command-line flag if it exists.
1. Use the `-context` command-line flag if it exists.
2. Use the `current-context` from the merged kubeconfig files.
--->
-->
1. 根据此链中的第一个匹配确定要使用的上下文。
1. 如果存在，使用 `--context` 命令行参数。
@@ -194,7 +197,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
<!--
An empty context is allowed at this point.
--->
-->
这种场景下允许空上下文。
<!--
@@ -204,7 +207,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
1. Use a command-line flag if it exists: `--user` or `--cluster`.
2. If the context is non-empty, take the user or cluster from the context.
--->
-->
1. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。
1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。
@@ -212,7 +215,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
<!--
The user and cluster can be empty at this point.
--->
-->
这种场景下用户和集群可以为空。
<!--
@@ -223,7 +226,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`.
2. If any cluster information attributes exist from the merged kubeconfig files, use them.
3. If there is no server location, fail.
--->
-->
1. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用：
1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。
@@ -238,7 +241,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`.
2. Use the `user` fields from the merged kubeconfig files.
3. If there are two conflicting techniques, fail.
--->
-->
2. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术：
1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。
@@ -248,12 +251,12 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
<!--
3. For any information still missing, use default values and potentially
prompt for authentication information.
--->
-->
3. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。
<!--
## File references
--->
-->
## 文件引用
<!--
@@ -261,21 +264,17 @@ File and path references in a kubeconfig file are relative to the location of th
File references on the command line are relative to the current working directory.
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
are stored absolutely.
--->
kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。命令行上的文件引用是相当对于当前工作目录的。在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
-->
kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。
命令行上的文件引用是相当对于当前工作目录的。
在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
## {{% heading "whatsnext" %}}
<!--
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
--->
* [配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
content/zh/docs/concepts/configuration/overview.md
+65 -63
View File
@@ -1,18 +1,12 @@
---
reviewers:
- mikedanese
title: 配置最佳实践
content_type: concept
weight: 10
---
<!--
---
reviewers:
- mikedanese
title: Configuration Best Practices
content_type: concept
weight: 10
---
-->
<!-- overview -->
@@ -24,9 +18,8 @@ This document highlights and consolidates configuration best practices that are
<!--
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
-->
这是一份活文件。
如果您认为某些内容不在此列表中但可能对其他人有用，请不要犹豫，提交问题或提交 PR。
这是一份不断改进的文件。
如果您认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
<!-- body -->
<!--
@@ -83,15 +76,19 @@ This is a living document. If you think of something that is not on this list bu
<!--
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
-->
- 如果您能避免，不要使用 naked Pods（即，Pod 未绑定到[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 或[Deployment](/docs/concepts/workloads/controllers/deployment/)）。
如果节点发生故障，将不会重新安排 Naked Pods。
- 如果可能，不要使用独立的 Pods（即，未绑定到
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。
如果节点发生故障，将不会重新调度独立的 Pods。
<!--
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
-->
Deployment，它创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用，并指定替换 Pod 的策略(例如 [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))，除了一些显式的[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)场景之外，几乎总是优先考虑直接创建 Pod。
[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 也可能是合适的。
Deployment 会创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用，并指定替换 Pod 的策略
（例如 [RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))，
除了一些显式的[`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
场景之外，几乎总是优先考虑直接创建 Pod。
[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的。
<!--
## Services
@@ -101,9 +98,10 @@ This is a living document. If you think of something that is not on this list bu
<!--
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
-->
- 在其相应的后端工作负载（Deployment 或 ReplicaSet）之前，以及在需要访问它的任何工作负载之前创建[服务](/docs/concepts/services-networking/service/)。
当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。
例如，如果存在名为`foo`当服务，则所有容器将在其初始环境中获取以下变量。
- 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建
[服务](/zh/docs/concepts/services-networking/service/)。
当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。
例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。
```shell
FOO_SERVICE_HOST=<the host the Service is running on>
@@ -113,43 +111,51 @@ This is a living document. If you think of something that is not on this list bu
<!--
*This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated. DNS does not have this restriction.
-->
*这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。
DNS没有此限制。
*这确实意味着在顺序上的要求* - 必须在 `Pod` 本身被创建之前创建 `Pod` 想要访问的任何 `Service`，
否则将环境变量不会生效。DNS 没有此限制。
<!--
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The
DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically.
-->
- 一个可选（尽管强烈推荐）[cluster add-on](/docs/concepts/cluster-administration/addons/)是 DNS 服务器。DNS 服务器为新的`Services`监视 Kubernetes API，并为每个创建一组 DNS 记录。
如果在整个集群中启用了 DNS，则所有`Pods`应该能够自动对`Services`进行名称解析。
- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/)
是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。
如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。
<!--
- Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a `hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`, `hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`.
-->
- 除非绝对必要，否则不要为 Pod 指定`hostPort`。
将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个<`hostIP`, `hostPort`, `protocol`>组合必须是唯一的。如果您没有明确指定`hostIP`和`protocol`，Kubernetes将使用`0.0.0.0`作为默认`hostIP`和`TCP`作为默认`protocol`。
- 除非绝对必要，否则不要为 Pod 指定 `hostPort`。
将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个
`<hostIP, hostPort, protocol>`组合必须是唯一的。
如果您没有明确指定 `hostIP` 和 `protocol`，Kubernetes 将使用 `0.0.0.0` 作为默认
`hostIP` 和 `TCP` 作为默认 `protocol`。
<!--
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
-->
如果您只需要访问端口以进行调试，则可以使用[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或[`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
如果您只需要访问端口以进行调试，则可以使用
[apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
[`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
<!--
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`.
-->
如果您明确需要在节点上公开 Pod 的端口，请在使用`hostPort`之前考虑使用[NodePort](/docs/concepts/services-networking/service/#nodeport) 服务。
如果您明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用
[NodePort](/zh/docs/concepts/services-networking/service/#nodeport) 服务。
<!--
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
-->
- 避免使用`hostNetwork`，原因与`hostPort`相同。
- 避免使用 `hostNetwork`，原因与 `hostPort` 相同。
<!--
- Use [headless Services](/docs/concepts/services-networking/service/#headless-
services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
-->
- 当您不需要`kube-proxy`负载平衡时，使用 [无头服务](/docs/concepts/services-networking/service/#headless-
services) (具有`None`的`ClusterIP`)以便于服务发现。
- 当您不需要 `kube-proxy` 负载均衡时，使用
[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
(`ClusterIP` 被设置为 `None`)以便于服务发现。
<!--
## Using Labels
@@ -159,29 +165,33 @@ services) (具有`None`的`ClusterIP`)以便于服务发现。
<!--
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach.
-->
- 定义并使用[标签](/docs/concepts/overview/working-with-objects/labels/)来识别应用程序或部署的__semantic attributes__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
您可以使用这些标签为其他资源选择合适的 Pod；例如，一个选择所有`tier: frontend` Pod 的服务，或者`app: myapp`的所有`phase: test`组件。
有关此方法的示例，请参阅[留言板](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 。
- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
你可以使用这些标签为其他资源选择合适的 Pod；
例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。
有关此方法的示例，请参阅[guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 。
<!--
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
-->
通过从选择器中省略特定发行版的标签，可以使服务跨越多个部署。
[部署](/docs/concepts/workloads/controllers/deployment/)可以在不停机的情况下轻松更新正在运行的服务。
通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 可以在不停机的情况下轻松更新正在运行的服务。
<!--
A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
-->
部署描述了对象的期望状态，并且如果对该规范的更改是_applied_，则部署控制器以受控速率将实际状态改变为期望状态。
Deployment 描述了对象的期望状态，并且如果对该规范的更改被成功应用，
则 Deployment 控制器以受控速率将实际状态改变为期望状态。
<!--
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
-->
- 您可以操纵标签进行调试。
- 由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签与 Pod 匹配，因此从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod，
从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。
这是在"隔离"环境中调试先前"实时"Pod 的有用方法。
要以交互方式删除或添加标签，请使用[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。
这是在"隔离"环境中调试先前"活跃"的 Pod 的有用方法。
要以交互方式删除或添加标签，请使用 [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。
<!--
## Container Images
@@ -191,38 +201,29 @@ A desired state of an object is described by a Deployment, and if changes to tha
<!--
The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image.
-->
当 [kubelet](/docs/admin/kubelet/)尝试拉取指定的镜像时，[imagePullPolicy](/docs/concepts/containers/images/#升级镜像)和镜像标签会生效。
[imagePullPolicy](/zh/docs/concepts/containers/images/#updating-images)和镜像标签会影响
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 何时尝试拉取指定的镜像。
<!--
- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
-->
- `imagePullPolicy: IfNotPresent`：仅当镜像在本地不存在时镜像才被拉取。
<!--
- `imagePullPolicy: Always`: the image is pulled every time the pod is started.
-->
- `imagePullPolicy: Always`：每次启动 pod 的时候都会拉取镜像。
<!--
- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
-->
- `imagePullPolicy` 省略时，镜像标签为 `:latest` 或不存在，使用 `Always` 值。
<!--
- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied.
-->
- `imagePullPolicy` 省略时，指定镜像标签并且不是 `:latest`，使用 `IfNotPresent` 值。
<!--
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
-->
- `imagePullPolicy: IfNotPresent`：仅当镜像在本地不存在时才被拉取。
- `imagePullPolicy: Always`：每次启动 Pod 的时候都会拉取镜像。
- `imagePullPolicy` 省略时，镜像标签为 `:latest` 或不存在，使用 `Always` 值。
- `imagePullPolicy` 省略时，指定镜像标签并且不是 `:latest`，使用 `IfNotPresent` 值。
- `imagePullPolicy: Never`：假设镜像已经存在本地，不会尝试拉取镜像。
<!--
To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
-->
{{< note >}}
要确保容器始终使用相同版本的镜像，你可以指定其 [摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), 例如`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。
要确保容器始终使用相同版本的镜像，你可以指定其
[摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)，
例如 `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。
摘要唯一地标识出镜像的指定版本，因此除非您更改摘要值，否则 Kubernetes 永远不会更新它。
{{< /note >}}
@@ -230,15 +231,15 @@ To make sure the container always uses the same version of the image, you can sp
You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
-->
{{< note >}}
在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。
在生产中部署容器时应避免使用 `:latest` 标记，因为这样更难跟踪正在运行的镜像版本，并且更难以正确回滚。
{{< /note >}}
<!--
The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
-->
{{< note >}}
底层镜像提供程序的缓存语义甚至使 `imagePullPolicy: Always`变得高效。
例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要镜像下载。
底层镜像驱动程序的缓存语义能够使即便 `imagePullPolicy: Always` 的配置也很高效。
例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要下载。
{{< /note >}}
<!--
@@ -249,19 +250,20 @@ The caching semantics of the underlying image provider make even `imagePullPolic
<!--
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
-->
- 使用`kubectl apply -f <directory>`。
它在`<directory>`中的所有`.yaml`，`.yml`和`.json`文件中查找 Kubernetes 配置，并将其传递给`apply`。
- 使用 `kubectl apply -f <directory>`。
它在 `<directory>` 中的所有` .yaml`、`.yml` 和 `.json` 文件中查找 Kubernetes 配置，并将其传递给 `apply`。
<!--
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
-->
- 使用标签选择器进行`get`和`delete`操作，而不是特定的对象名称。
- 请参阅[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)和[有效使用标签](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
- 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。
- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
[有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
<!--
- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
-->
- 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。
有关示例，请参阅[使用服务访问集群中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster/)。
有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。
content/zh/docs/concepts/configuration/pod-overhead.md
+11 -14
View File
@@ -18,9 +18,6 @@ on top of the container requests & limits.
在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。
_POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。
<!-- body -->
<!--
@@ -36,8 +33,8 @@ time according to the overhead associated with the Pod's
[RuntimeClass](/docs/concepts/containers/runtime-class/).
-->
在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/docs/concepts/containers/runtime-class/) 相关联的开销在
[准入](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。
在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 相关联的开销在
[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。
<!--
When Pod Overhead is enabled, the overhead is considered in addition to the sum of container
@@ -56,7 +53,8 @@ You need to make sure that the `PodOverhead`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is on by default as of 1.18)
across your cluster, and a `RuntimeClass` is utilized which defines the `overhead` field.
-->
您需要确保在集群中启用了 `PodOverhead` [特性门](/docs/reference/command-line-tools-reference/feature-gates/)（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。
您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。
<!--
## Usage example
@@ -68,7 +66,9 @@ To use the PodOverhead feature, you need a RuntimeClass that defines the `overhe
an example, you could use the following RuntimeClass definition with a virtualizing container runtime
that uses around 120MiB per Pod for the virtual machine and the guest OS:
-->
要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass. 作为例子，可以在虚拟机和来宾操作系统中通过一个虚拟化容器运行时来定义 RuntimeClass 如下，其中每个 Pod 大约使用 120MiB:
要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass。
作为例子，可以在虚拟机和寄宿操作系统中通过一个虚拟化容器运行时来定义
RuntimeClass 如下，其中每个 Pod 大约使用 120MiB:
```yaml
---
@@ -123,8 +123,9 @@ updates the workload's PodSpec to include the `overhead` as described in the Run
the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
to include an `overhead`.
-->
在准入阶段 RuntimeClass [准入控制器](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含
RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`.
在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含
RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。
在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`.
<!--
After the RuntimeClass admission controller, you can check the updated PodSpec:
@@ -298,12 +299,8 @@ from source in the meantime.
在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。
该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics.
## {{% heading "whatsnext" %}}
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
* [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
content/zh/docs/concepts/configuration/secret.md
+661 -314
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/concepts/containers/images.md
+1 -1
View File
@@ -33,7 +33,7 @@ The `image` property of a container supports the same syntax as the `docker` com
<!--
## Updating Images
-->
## 升级镜像
## 更新镜像 {#updating-images}
<!--
The default pull policy is `IfNotPresent` which causes the Kubelet to skip
content/zh/docs/concepts/example-concept-template.md
-76
View File
@@ -1,76 +0,0 @@
---
title: 概念模板示例
content_type: concept
toc_hide: true
---
<!--
---
title: Example Concept Template
content_type: concept
toc_hide: true
---
-->
<!-- overview -->
<!--
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
-->
{{< note >}}
确保您的新文档也可以[在目录中创建一个条目](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents)。
{{< /note >}}
<!--
This page explains ...
-->
本页解释了 ...
<!-- body -->
<!--
## Understanding ...
-->
## 了解 ...
<!--
Kubernetes provides ...
-->
Kubernetes 提供 ...
<!--
## Using ...
-->
## 使用 ...
<!--
To use ...
-->
使用 ...
## {{% heading "whatsnext" %}}
<!--
**[Optional Section]**
-->
**[可选章节]**
<!--
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template.
-->
* 了解有关[撰写新主题](/docs/home/contribute/write-new-topic/)的更多信息。
* 有关如何使用此模板的信息，请参阅[使用页面模板 - 概念模板](/docs/home/contribute/page-templates/#concept_template)。
content/zh/docs/concepts/extend-kubernetes/_index.md
+451 -1
View File
@@ -1,4 +1,454 @@
---
title: 扩展 Kubernetes
weight: 40
weight: 110
description: 改变你的 Kubernetes 集群的行为的若干方法。
content_type: concept
no_list: true
---
<!--
title: Extending Kubernetes
weight: 110
description: Different ways to change the behavior of your Kubernetes cluster.
reviewers:
- erictune
- lavalamp
- cheftako
- chenopis
content_type: concept
no_list: true
-->
<!-- overview -->
<!--
Kubernetes is highly configurable and extensible. As a result,
there is rarely a need to fork or submit patches to the Kubernetes
project code.
This guide describes the options for customizing a Kubernetes
cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to
understand how to adapt their Kubernetes cluster to the needs of
their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it
useful as an introduction to what extension points and patterns
exist, and their trade-offs and limitations.
-->
Kubernetes 是高度可配置且可扩展的。因此，大多数情况下，你不需要
派生自己的 Kubernetes 副本或者向项目代码提交补丁。
本指南描述定制 Kubernetes 的可选方式。主要针对的读者是希望了解如何针对自身工作环境
需要来调整 Kubernetes 的{{< glossary_tooltip text="集群管理者" term_id="cluster-operator" >}}。
对于那些充当{{< glossary_tooltip text="平台开发人员" term_id="platform-developer" >}}
的开发人员或 Kubernetes 项目的{{< glossary_tooltip text="贡献者" term_id="contributor" >}}
而言，他们也会在本指南中找到有用的介绍信息，了解系统中存在哪些扩展点和扩展模式，
以及它们所附带的各种权衡和约束等等。
<!-- body -->
<!--
## Overview
Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
-->
## 概述 {#overview}
定制化的方法主要可分为 *配置（Configuration）* 和 *扩展（Extensions）* 两种。
前者主要涉及改变参数标志、本地配置文件或者 API 资源；
后者则需要额外运行一些程序或服务。
本文主要关注扩展。
<!--
## Configuration
*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
* [kubelet](/docs/admin/kubelet/)
* [kube-apiserver](/docs/admin/kube-apiserver/)
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
* [kube-scheduler](/docs/admin/kube-scheduler/).
-->
## Configuration
*配置文件*和*参数标志*的说明位于在线文档的参考章节，按可执行文件组织：
* [kubelet](/docs/admin/kubelet/)
* [kube-apiserver](/docs/admin/kube-apiserver/)
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
* [kube-scheduler](/docs/admin/kube-scheduler/).
<!--
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
-->
在托管的 Kubernetes 服务中或者受控安装的发行版本中，参数标志和配置文件不总是可以
修改的。即使它们是可修改的，通常其修改权限也仅限于集群管理员。
此外，这些内容在将来的 Kubernetes 版本中很可能发生变化，设置新参数或配置文件可能
需要重启进程。
有鉴于此，通常应该在没有其他替代方案时才应考虑更改参数标志和配置文件。
<!--
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
-->
*内置的策略 API*，例如[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、
[PodSecurityPolicies](/zh/docs/concepts/policy/pod-security-policy/)、
[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/)
和基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)）等等
都是内置的 Kubernetes API。
API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。
这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
新的集群配置是可复用的，并且可以当作应用程序来管理。
此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
一种[预定义的支持策略](/zh/docs/reference/deprecation-policy/)。
出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。
<!--
## Extensions
Extensions are software components that extend and deeply integrate with Kubernetes.
They adapt it to support new types and new kinds of hardware.
Most cluster administrators will use a hosted or distribution
instance of Kubernetes. As a result, most Kubernetes users will not need to
install extensions and fewer will need to author new ones.
-->
## 扩展 {#extensions}
扩展（Extensions）是一些扩充 Kubernetes 能力并与之深度集成的软件组件。
它们调整 Kubernetes 的工作方式使之支持新的类型和新的硬件种类。
大多数集群管理员会使用一种托管的 Kubernetes 服务或者其某种发行版本。
因此，大多数 Kubernetes 用户不需要安装扩展，
至于需要自己编写新的扩展的情况就更少了。
<!--
## Extension Patterns
Kubernetes is designed to be automated by writing client programs. Any
program that reads and/or writes to the Kubernetes API can provide useful
automation. *Automation* can run on the cluster or off it. By following
the guidance in this doc you can write highly available and robust automation.
Automation generally works with any Kubernetes cluster, including hosted
clusters and managed installations.
-->
## 扩展模式 {#extension-patterns}
Kubernetes 从设计上即支持通过编写客户端程序来将其操作自动化。
任何能够对 Kubernetes API 发出读写指令的程序都可以提供有用的自动化能力。
*自动化组件*可以运行在集群上，也可以运行在集群之外。
通过遵从本文中的指南，你可以编写高度可用的、运行稳定的自动化组件。
自动化组件通常可以用于所有 Kubernetes 集群，包括托管的集群和受控的安装环境。
<!--
There is a specific pattern for writing client programs that work well with
Kubernetes called the *Controller* pattern. Controllers typically read an
object's `.spec`, possibly do things, and then update the object's `.status`.
A controller is a client of Kubernetes. When Kubernetes is the client and
calls out to a remote service, it is called a *Webhook*. The remote service
is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
failure.
-->
编写客户端程序有一种特殊的*Controller（控制器）*模式，能够与 Kubernetes 很好地
协同工作。控制器通常会读取某个对象的 `.spec`，或许还会执行一些操作，之后更新
对象的 `.status`。
控制器是 Kubernetes 的客户端。当 Kubernetes 充当客户端，调用某远程服务时，对应
的远程组件称作*Webhook*。 远程服务称作*Webhook 后端*。
与控制器模式相似，Webhook 也会在整个架构中引入新的失效点（Point of Failure）。
<!--
In the webhook model, Kubernetes makes a network request to a remote service.
In the *Binary Plugin* model, Kubernetes executes a binary (program).
Binary plugins are used by the kubelet (e.g. [Flex Volume
Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
and [Network
Plugins](/docs/concepts/cluster-administration/network-plugins/))
and by kubectl.
Below is a diagram showing how the extension points interact with the
Kubernetes control plane.
-->
在 Webhook 模式中，Kubernetes 向远程服务发起网络请求。
在*可执行文件插件（Binary Plugin）*模式中，Kubernetes 执行某个可执行文件（程序）。
可执行文件插件在 kubelet （例如，
[FlexVolume 插件](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
和[网络插件](/zh/docs/concepts/cluster-administration/network-plugins/)）
和 kubectl 中使用。
下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
<!--
## Extension Points
This diagram shows the extension points in a Kubernetes system.
-->
## 扩展点 {#extension-points}
此示意图显示的是 Kubernetes 系统中的扩展点。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
<!--
1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
-->
1. 用户通常使用 `kubectl` 与 Kubernetes API 交互。
[kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。
这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。
2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、
基于其内容阻止请求、编辑请求内容、处理删除操作等等。
这些扩展点在 [API 访问扩展](/zh/docs/concepts/overview/extending#api-access-extensions)
节详述。
3. API 服务器向外提供不同类型的*资源（resources）*。
*内置的资源类型*，如 `pods`，是由 Kubernetes 项目所定义的，无法改变。
你也可以添加自己定义的或者其他项目所定义的称作*自定义资源（Custom Resources）*
的资源，正如[自定义资源](/zh/docs/concepts/overview/extending#user-defined-types)节所描述的那样。
自定义资源通常与 API 访问扩展点结合使用。
4. Kubernetes 调度器负责决定 Pod 要放置到哪些节点上执行。
有几种方式来扩展调度行为。这些方法将在
[调度器扩展](/zh/docs/concepts/overview/extending#scheduler-extensions)节中展开。
5. Kubernetes 中的很多行为都是通过称为控制器（Controllers）的程序来实现的，这些程序也都是 API 服务器
的客户端。控制器常常与自定义资源结合使用。
6. 组件 kubelet 运行在各个节点上，帮助 Pod 展现为虚拟的服务器并在集群网络中拥有自己的 IP。
[网络插件](/zh/docs/concepts/overview/extending#network-plugins)使得 Kubernetes 能够采用
不同实现技术来连接 Pod 网络。
7. 组件 kubelet 也会为容器增加或解除存储卷的挂载。
通过[存储插件](/zh/docs/concepts/overview/extending#storage-plugins)，可以支持新的存储类型。
如果你无法确定从何处入手，下面的流程图可能对你有些帮助。
注意，某些方案可能需要同时采用几种类型的扩展。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
<!--
## API Extensions
### User-Defined Types
Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
Do not use a Custom Resource as data storage for application, user, or monitoring data.
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
-->
## API 扩展 {#api-extensions}
### 用户定义的类型 {#user-defined-types}
如果你想要定义新的控制器、应用配置对象或者其他声明式 API，并且使用 Kubernetes
工具（如 `kubectl`）来管理它们，可以考虑向 Kubernetes 添加自定义资源。
不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/api-extension/custom-resources/)。
<!--
### Combining New APIs with Automation
The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
-->
### 结合使用新 API 与自动化组件 {#combinding-new-apis-with-automation}
自定义资源 API 与控制回路的组合称作
[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)。
Operator 模式用来管理特定的、通常是有状态的应用。
这些自定义 API 和控制回路也可用来控制其他资源，如存储或策略。
<!--
### Changing Built-in Resources
When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
-->
### 更改内置资源 {#changing-built-in-resources}
当你通过添加自定义资源来扩展 Kubernetes 时，所添加的资源通常会被放在一个新的
API 组中。你不可以替换或更改现有的 API 组。
添加新的 API 不会直接让你影响现有 API （如 Pods）的行为，不过 API
访问扩展能够实现这点。
<!--
### API Access Extensions
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
Each of these steps offers extension points.
Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
-->
### API 访问扩展 {#api-access-extensions}
当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作，
再之后要经过若干类型的准入控制器的检查。
参见[控制 Kubernetes API 访问](/zh/docs/reference/access-authn-authz/controlling-access/)
以了解此流程的细节。
这些步骤中都存在扩展点。
Kubernetes 提供若干内置的身份认证方法。
它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到
某个远程服务（Webhook）来执行验证操作。
所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
中详细论述。
<!--
### Authentication
[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
-->
### 身份认证 {#authentication}
[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
的头部或证书映射到发出该请求的客户端的用户名。
Kubernetes 提供若干种内置的认证方法，以及
[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
方法以备内置方法无法满足你的要求。
<!--
### Authorization
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources - it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
-->
### 鉴权 {#authorization}
[鉴权](/docs/reference/access-authn-authz/webhook/)操作负责确定特定的用户
是否可以读、写 API 资源或对其执行其他操作。
此操作仅在整个资源集合的层面进行。
换言之，它不会基于对象的特定字段作出不同的判决。
如果内置的鉴权选项无法满足你的需要，你可以使用
[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)来调用用户提供
的代码，执行定制的鉴权操作。
<!--
### Dynamic Admission Control
After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
-->
### 动态准入控制 {#dynamic-admission-control}
请求的鉴权操作结束之后，如果请求的是写操作，还会经过
[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)处理步骤。
除了内置的处理步骤，还存在一些扩展点：
* [Image Policy webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
能够限制容器中可以运行哪些镜像。
* 为了执行任意的准入控制，可以使用一种通用的
[Admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
机制。这类 Webhook 可以拒绝对象创建或更新请求。
<!--
## Infrastructure Extensions
### Storage Plugins
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
) allow users to mount volume types without built-in support by having the
Kubelet call a Binary Plugin to mount the volume.
-->
## 基础设施扩展 {#infrastructure-extensions}
### 存储插件 {#storage-plugins}
[FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
)
卷可以让用户挂载无需内建支持的卷类型，kubelet 会调用可执行文件插件
来挂载对应的存储卷。
<!--
### Device Plugins
Device plugins allow a node to discover new Node resources (in addition to the
builtin ones like cpu and memory) via a [Device
Plugin](/docs/concepts/cluster-administration/device-plugins/).
### Network Plugins
Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
-->
### 设备插件 {#device-plugins}
使用[设备插件](/zh/docs/concepts/cluster-administration/device-plugins/)，
节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。
### 网络插件 {#network-plugins}
通过节点层面的[网络插件](/docs/admin/network-plugins/)，可以支持
不同的网络设施。
<!--
### Scheduler Extensions
The scheduler is a special type of controller that watches pods, and assigns
pods to nodes. The default scheduler can be replaced entirely, while
continuing to use other Kubernetes components, or [multiple
schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
can run at the same time.
This is a significant undertaking, and almost all Kubernetes users find they
do not need to modify the scheduler.
The scheduler also supports a
[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
that permits a webhook backend (scheduler extension) to filter and prioritize
the nodes chosen for a pod.
-->
### 调度器扩展 {#scheduler-extensions}
调度器是一种特殊的控制器，负责监视 Pod 变化并将 Pod 分派给节点。
默认的调度器可以被整体替换掉，同时继续使用其他 Kubernetes 组件。
或者也可以在同一时刻使用
[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。
这是一项非同小可的任务，几乎绝大多数 Kubernetes
用户都会发现其实他们不需要修改调度器。
调度器也支持一种 [webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)，
允许使用某种 Webhook 后端（调度器扩展）来为 Pod
可选的节点执行过滤和优先排序操作。
## {{% heading "whatsnext" %}}
<!--
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
* Learn more about Infrastructure extensions
* [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
* [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
-->
* 进一步了解[自定义资源](/zh/docs/concepts/api-extension/custom-resources/)
* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
* 进一步了解基础设施扩展
* [网络插件](/zh/docs/concepts/cluster-administration/network-plugins/)
* [设备插件](/zh/docs/concepts/cluster-administration/device-plugins/)
* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)
* 了解 [Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)
content/zh/docs/concepts/overview/kubernetes-api.md
+2 -2
View File
@@ -2,6 +2,8 @@
title: Kubernetes API
content_type: concept
weight: 30
description: >
Kubernetes API 使您可以查询和操纵 Kubernetes 中对象的状态。Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。
card:
name: concepts
weight: 30
@@ -270,5 +272,3 @@ Individual resource enablement/disablement is only supported in the `extensions/
出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。
{{< /note >}}
content/zh/docs/concepts/overview/working-with-objects/common-labels.md
+3 -3
View File
@@ -64,7 +64,7 @@ on every resource object.
| Key | Description | Example | Type |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | The name of the application | `mysql` | string |
| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `mysql-abcxzy` | string |
| `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
| `app.kubernetes.io/component` | The component within the architecture | `database` | string |
| `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string |
@@ -73,7 +73,7 @@ on every resource object.
| 键 | 描述 | 示例 | 类型 |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | 应用程序的名称 | `mysql` | 字符串 |
| `app.kubernetes.io/instance` | 用于唯一确定应用实例的名称 | `wordpress-abcxzy` | 字符串 |
| `app.kubernetes.io/instance` | 用于唯一确定应用实例的名称 | `mysql-abcxzy` | 字符串 |
| `app.kubernetes.io/version` | 应用程序的当前版本（例如，语义版本，修订版哈希等） | `5.7.21` | 字符串 |
| `app.kubernetes.io/component` | 架构中的组件 | `database` | 字符串 |
| `app.kubernetes.io/part-of` | 此级别的更高级别应用程序的名称 | `wordpress` | 字符串 |
@@ -89,7 +89,7 @@ kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
content/zh/docs/concepts/configuration/assign-pod-node.md → content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+52 -57
View File
@@ -5,18 +5,11 @@ weight: 50
---
<!--
---
reviewers:
- davidopp
- kevin-wangzefeng
- bsalamat
title: Assigning Pods to Nodes
content_type: concept
weight: 50
---
-->
<!-- overview -->
<!--
@@ -26,14 +19,12 @@ There are several ways to do this, and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
(e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
but there are some circumstances where you may want more control on a node where a pod lands, e.g. to ensure
but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
services that communicate a lot into the same availability zone.
-->
你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可以需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。
你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可以需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。
<!-- body -->
@@ -46,7 +37,8 @@ to run on a node, the node must have each of the indicated key-value pairs as la
additional labels as well). The most common usage is one key-value pair.
-->
`nodeSelector` 是节点选择约束的最简单推荐形式。`nodeSelector` 是 PodSpec 的一个字段。它指定键值对的映射。为了使 pod 可以在节点上运行，节点必须具有每个指定的键值对作为标签（它也可以具有其他标签）。最常用的是一对键值对。
`nodeSelector` 是节点选择约束的最简单推荐形式。`nodeSelector` 是 PodSpec 的一个字段。
它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中必须包含这里的每个键值对（它也可以具有其他标签）。最常见的用法的是一对键值对。
<!--
Let's walk through an example of how to use `nodeSelector`.
@@ -63,38 +55,40 @@ Let's walk through an example of how to use `nodeSelector`.
<!--
This example assumes that you have a basic understanding of Kubernetes pods and that you have [set up a Kubernetes cluster](/docs/setup/).
-->
本示例假设你已基本了解 Kubernetes 的 pod 并且已经[建立一个 Kubernetes 集群](/docs/setup/)。
本示例假设你已基本了解 Kubernetes 的 Pod 并且已经[建立一个 Kubernetes 集群](/zh/docs/setup/)。
<!--
### Step One: Attach label to the node
-->
### 步骤一：添加标签到节点
### 步骤一：添加标签到节点 {#attach-labels-to-node}
<!--
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to, and then run `kubectl label nodes <node-name> <label-key>=<label-value>` to add a label to the node you've chosen. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
-->
执行 `kubectl get nodes` 命令获取集群的节点名称。选择一个你要增加标签的节点，然后执行 `kubectl label nodes <node-name> <label-key>=<label-value>` 命令将标签添加到你所选择的节点上。例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' 并且想要的标签是 'disktype=ssd'，则可以执行 `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。
执行 `kubectl get nodes` 命令获取集群的节点名称。
选择一个你要增加标签的节点，然后执行 `kubectl label nodes <node-name> <label-key>=<label-value>`
命令将标签添加到你所选择的节点上。
例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal'
并且想要的标签是 'disktype=ssd'，则可以执行
`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。
<!--
You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label. You can also use `kubectl describe node "nodename"` to see the full list of labels of the given node.
You can verify that it worked by re-running `kubectl get nodes -show-labels` and checking that the node now has a label. You can also use `kubectl describe node "nodename"` to see the full list of labels of the given node.
-->
你可以通过重新运行 `kubectl get nodes --show-labels` 并且查看节点当前具有了一个标签来验证它是否有效。你也可以使用 `kubectl describe node "nodename"` 命令查看指定节点的标签完整列表。
你可以通过重新运行 `kubectl get nodes --show-labels`，查看节点当前具有了所指定的标签来验证它是否有效。
你也可以使用 `kubectl describe node "nodename"` 命令查看指定节点的标签完整列表。
<!--
### Step Two: Add a nodeSelector field to your pod configuration
-->
### 步骤二：添加 nodeSelector 字段到 pod 配置中
### 步骤二：添加 nodeSelector 字段到 Pod 配置中
<!--
Take whatever pod config file you want to run, and add a nodeSelector section to it, like this. For example, if this is my pod config:
-->
拿任意一个你想运行的 pod 的配置文件，并且在其中添加一个 nodeSelector 部分。例如，如果下面是我的 pod 配置：
选择任何一个你想运行的 Pod 的配置文件，并且在其中添加一个 nodeSelector 部分。
例如，如果下面是我的 pod 配置：
```yaml
apiVersion: v1
@@ -123,32 +117,30 @@ the Pod will get scheduled on the node that you attached the label to. You can
verify that it worked by running `kubectl get pods -o wide` and looking at the
"NODE" that the Pod was assigned to.
-->
当你之后运行 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 命令，pod 将会调度到将标签添加到的节点上。你可以通过运行 `kubectl get pods -o wide` 并查看分配给 pod 的 “NODE” 来验证其是否有效。
当你之后运行 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 命令，
Pod 将会调度到将标签添加到的节点上。你可以通过运行 `kubectl get pods -o wide` 并查看分配给 pod 的 “NODE” 来验证其是否有效。
<!--
## Interlude: built-in node labels {#built-in-node-labels}
-->
## 插曲：内置的节点标签 {#内置的节点标签}
## 插曲：内置的节点标签 {#built-in-node-labels}
<!--
In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
with a standard set of labels. These labels are
-->
除了你[附加](#attach-labels-to-node)的标签外，节点还预先填充了一组标准标签。这些标签是
除了你[附加](#添加标签到节点)的标签外，节点还预先填充了一组标准标签。这些标签是
* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
{{< note >}}
<!--
@@ -190,7 +182,8 @@ For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.
-->
1. 检查是否在使用 Kubernetes v1.11+，以便 NodeRestriction 功能可用。
2. 确保你在使用[节点授权](/docs/reference/access-authn-authz/node/)并且已经_启用_ [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_
[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
3. 将 `node-restriction.kubernetes.io/` 前缀下的标签添加到 Node 对象，然后在节点选择器中使用这些标签。例如，`example.com.node-restriction.kubernetes.io/fips=true` 或 `example.com.node-restriction.kubernetes.io/pci-dss=true`。
<!--
@@ -289,10 +282,13 @@ value is `another-node-label-value` should be preferred.
<!--
You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use
[node taints](/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes.
[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes.
-->
你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符： `In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用[节点污点](/docs/concepts/configuration/taint-and-toleration/)将 pod 从特定节点中驱逐。
你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和语法支持下面的操作符：
`In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。
你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和行为，或者使用
[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)将 pod 从特定节点中驱逐。
<!--
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
@@ -343,7 +339,7 @@ key for the node label that the system uses to denote such a topology domain, e.
in the section [Interlude: built-in node labels](#built-in-node-labels).
-->
pod 间亲和与反亲和使你可以*基于已经在节点上运行的 pod 的标签*来约束 pod 可以调度到的节点，而不是基于节点上的标签。规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的pod，则这个 pod 应该（或者在非亲和的情况下不应该）运行在 X 节点”。Y 表示一个具有可选的关联命令空间列表的 LabelSelector；与节点不同，因为 pod 是命名空间限定的（因此 pod 上的标签也是命名空间限定的），因此作用于 pod 标签的标签选择器必须指定选择器应用在哪个命名空间。从概念上讲，X 是一个拓扑域，如节点，机架，云供应商地区，云供应商区域等。你可以使用 `topologyKey` 来表示它，`topologyKey` 是节点标签的键以便系统用来表示这样的拓扑域。请参阅上面[插曲：内置的节点标签](#内置的节点标签)部分中列出的标签键。
pod 间亲和与反亲和使你可以*基于已经在节点上运行的 pod 的标签*来约束 pod 可以调度到的节点，而不是基于节点上的标签。规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的pod，则这个 pod 应该（或者在非亲和的情况下不应该）运行在 X 节点”。Y 表示一个具有可选的关联命令空间列表的 LabelSelector；与节点不同，因为 pod 是命名空间限定的（因此 pod 上的标签也是命名空间限定的），因此作用于 pod 标签的标签选择器必须指定选择器应用在哪个命名空间。从概念上讲，X 是一个拓扑域，如节点，机架，云供应商地区，云供应商区域等。你可以使用 `topologyKey` 来表示它，`topologyKey` 是节点标签的键以便系统用来表示这样的拓扑域。请参阅上面[插曲：内置的节点标签](#built-in-node-labels)部分中列出的标签键。
{{< note >}}
<!--
@@ -578,10 +574,12 @@ As you can see, all the 3 replicas of the `web-server` are automatically co-loca
```
kubectl get pods -o wide
```
<!--
The output is similar to this:
-->
输出类似于如下内容：
```
NAME READY STATUS RESTARTS AGE IP NODE
redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
@@ -604,8 +602,10 @@ no two instances are located on the same host.
See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique.
-->
上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"` 来部署 redis 集群以便在同一主机上没有两个实例。参阅 [ZooKeeper 教程](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。
上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"`
来部署 redis 集群以便在同一主机上没有两个实例。
参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，
以获取配置反亲和来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。
## nodeName
@@ -617,13 +617,11 @@ kubelet running on the named node tries to run the pod. Thus, if
`nodeName` is provided in the PodSpec, it takes precedence over the
above methods for node selection.
-->
`nodeName` 是节点选择约束的最简单方法，但是由于其自身限制，通常不使用它。`nodeName` 是 PodSpec 的一个字段。如果它不为空，调度器将忽略 pod，并且运行在它指定节点上的 kubelet 进程尝试运行该 pod。因此，如果 `nodeName` 在 PodSpec 中指定了，则它优先于上面的节点选择方法。
<!--
Some of the limitations of using `nodeName` to select nodes are:
-->
使用 `nodeName` 来选择节点的一些限制：
<!--
@@ -635,7 +633,6 @@ Some of the limitations of using `nodeName` to select nodes are:
- Node names in cloud environments are not always predictable or
stable.
-->
- 如果指定的节点不存在，
- 如果指定的节点没有资源来容纳 pod，pod 将会调度失败并且其原因将显示为，比如 OutOfmemory 或 OutOfcpu。
- 云环境中的节点名称并非总是可预测或稳定的。
@@ -643,7 +640,6 @@ Some of the limitations of using `nodeName` to select nodes are:
<!--
Here is an example of a pod config file using the `nodeName` field:
-->
下面的是使用 `nodeName` 字段的 pod 配置文件的例子：
```yaml
@@ -664,16 +660,13 @@ The above pod will run on the node kube-01.
上面的 pod 将运行在 kube-01 节点上。
## {{% heading "whatsnext" %}}
<!--
[Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods.
[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
-->
[污点](/docs/concepts/configuration/taint-and-toleration/)允许节点*排斥*一组 pod。
[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)允许节点*排斥*一组 pod。
<!--
The design documents for
@@ -681,7 +674,8 @@ The design documents for
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features.
-->
[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与 [pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。
[节点亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与
[pod 间亲和/反亲和](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)的设计文档包含这些功能的其他背景信息。
<!--
Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-local resources.
@@ -689,6 +683,7 @@ The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can tak
resource allocation decisions.
-->
一旦 pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。[拓扑管理](/docs/tasks/administer-cluster/topology-manager/)
一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。
[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
可以参与到节点级别的资源分配决定中。
content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+15 -10
View File
@@ -4,13 +4,11 @@ content_type: concept
weight: 70
---
<!--
---
reviewers:
- bsalamat
title: Scheduler Performance Tuning
content_type: concept
weight: 70
---
-->
<!-- overview -->
@@ -22,7 +20,9 @@ weight: 70
is the Kubernetes default scheduler. It is responsible for placement of Pods
on Nodes in a cluster.
-->
作为 kubernetes 集群的默认调度器，[kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) 主要负责将 Pod 调度到集群的 Node 上。
作为 kubernetes 集群的默认调度器，
[kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)
主要负责将 Pod 调度到集群的 Node 上。
<!--
Nodes in a cluster that meet the scheduling requirements of a Pod are
@@ -32,7 +32,10 @@ picking a Node with the highest score among the feasible ones to run
the Pod. The scheduler then notifies the API server about this decision
in a process called _Binding_.
-->
在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度_ Node。调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node打分，之后选出其中得分最高的 Node 来运行 Pod。最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 _绑定_。
在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度_ Node。
调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 打分，
之后选出其中得分最高的 Node 来运行 Pod。
最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做 _绑定（Binding）_。
<!--
This page explains performance tuning optimizations that are relevant for
@@ -40,8 +43,6 @@ large Kubernetes clusters.
-->
这篇文章将会介绍一些在大规模 Kubernetes 集群下调度器性能优化的方式。
<!-- body -->
<!--
@@ -55,7 +56,8 @@ a threshold for scheduling nodes in your cluster.
-->
在大规模集群中，你可以调节调度器的表现来平衡调度的延迟（新 Pod 快速就位）和精度（调度器很少做出糟糕的放置决策）。
你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。
你可以通过设置 kube-scheduler 的 `percentageOfNodesToScore` 来配置这个调优设置。
这个 KubeSchedulerConfiguration 设置决定了调度集群中节点的阈值。
<!--
### Setting the threshold
@@ -117,8 +119,11 @@ enough feasible nodes to exceed the configured percentage, the kube-scheduler
stops searching for more feasible nodes and moves on to the
[scoring phase](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation).
-->
你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果
kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量，kube-scheduler 将停止继续查找可调度节点并继续进行 [打分阶段](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。
你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。
kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果
kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量，
kube-scheduler 将停止继续查找可调度节点并继续进行
[打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。
<!--
[How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
@@ -228,7 +233,7 @@ prefer to run the Pod on any Node as long as it is feasible.
<!--
### How the scheduler iterates over Nodes
-->
### 调度器做调度选择的时候如何覆盖所有的 Node
### 调度器做调度选择的时候如何覆盖所有的 Node {#how-the-scheduler-iterates-over-nodes}
<!--
This section is intended for those who want to understand the internal details
content/zh/docs/concepts/configuration/taint-and-toleration.md → content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
+178 -109
View File
@@ -1,45 +1,48 @@
---
title: Taint 和 Toleration
title: 污点和容忍度
content_type: concept
weight: 40
---
<!-- overview -->
<!--
Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
is a property of *pods* that *attracts* them to a set of nodes (either as a
preference or a hard requirement). Taints are the opposite -- they allow a
*node* to *repel* a set of pods.
is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
hard requirement). Taints are the opposite -they allow a node to repel a set of pods.
-->
节点亲和性（详见[这里](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature)），是 *pod* 的一种属性（偏好或硬性要求），它使 *pod* 被吸引到一类特定的节点。Taint 则相反，它使 *节点* 能够 *排斥* 一类特定的 pod。
节点亲和性（详见[这里](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)）
是 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的一种属性，它使 Pod
被吸引到一类特定的{{< glossary_tooltip text="节点" term_id="node" >}}。
这可能出于一种偏好，也可能是硬性要求。
Taint（污点）则相反，它使节点能够排斥一类特定的 Pod。
<!--
_Tolerations_ are applied to pods, and allow (but do not require) the pods to schedule
onto nodes with matching taints.
Taints and tolerations work together to ensure that pods are not scheduled
onto inappropriate nodes. One or more taints are applied to a node; this
marks that the node should not accept any pods that do not tolerate the taints.
Tolerations are applied to pods, and allow (but do not require) the pods to schedule
onto nodes with matching taints.
-->
Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有匹配 taint 的节点上。
容忍度（Tolerations）是应用于 Pod 上的，允许（但并不要求）Pod
调度到带有与之匹配的污点的节点上。
污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。
每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。
<!-- body -->
<!--
## Concepts
-->
## 概念
<!--
You add a taint to a node using [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
For example,
-->
您可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个 taint。比如，
您可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个污点。比如，
```shell
kubectl taint nodes node1 key=value:NoSchedule
@@ -48,16 +51,25 @@ kubectl taint nodes node1 key=value:NoSchedule
<!--
places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able
to schedule onto `node1`:
-->
给节点 `node1` 增加一个 taint，它的 key 是 `key`，value 是 `value`，effect 是 `NoSchedule`。这表示只有拥有和这个 taint 相匹配的 toleration 的 pod 才能够被分配到 `node1` 这个节点。您可以在 PodSpec 中定义 pod 的 toleration。下面两个 toleration 均与上面例子中使用 `kubectl taint` 命令创建的 taint 相匹配，因此如果一个 pod 拥有其中的任何一个 toleration 都能够被分配到 `node1` ：
<!--
```shell
kubectl taint nodes node1 key:NoSchedule
```
To remove the taint added by the command above, you can run:
```shell
kubectl taint nodes node1 key:NoSchedule-
```
-->
想删除上述命令添加的 taint ，您可以运行：
给节点 `node1` 增加一个污点，它的键名是 `key`，键值是 `value`，效果是 `NoSchedule`。
这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 `node1` 这个节点。
```shell
kubectl taint nodes node1 key:NoSchedule-
```
若要移除上述命令所添加的污点，你可以执行：
```shell
kubectl taint nodes node1 key:NoSchedule-
```
@@ -67,9 +79,9 @@ You specify a toleration for a pod in the PodSpec. Both of the following tolerat
taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able
to schedule onto `node1`:
-->
您可以在 PodSpec 中为容器设定容忍标签。以下两个容忍标签都与上面的 `kubectl taint` 创建的污点“匹配”，
因此具有任一容忍标签的Pod都可以将其调度到 `node1` 上：
您可以在 PodSpec 中定义 Pod 的容忍度。
下面两个容忍度均与上面例子中使用 `kubectl taint` 命令创建的污点相匹配，
因此如果一个 Pod 拥有其中的任何一个容忍度都能够被分配到 `node1` ：
```yaml
tolerations:
@@ -86,55 +98,55 @@ tolerations:
effect: "NoSchedule"
```
<!--
Here’s an example of a pod that uses tolerations:
-->
这里是一个使用了容忍度的 Pod：
{{< codenew file="pods/pod-with-toleration.yaml" >}}
<!--
The default value for `operator` is `Equal`.
-->
`operator` 的默认值是 `Equal`。
<!--
A toleration "matches" a taint if the keys are the same and the effects are the same, and:
* the `operator` is `Exists` (in which case no `value` should be specified), or
* the `operator` is `Equal` and the `value`s are equal
`Operator` defaults to `Equal` if not specified.
-->
一个 toleration 和一个 taint 相“匹配”是指它们有一样的 key 和 effect ，并且：
一个容忍度和一个污点相“匹配”是指它们有一样的键名和效果，并且：
* 如果 `operator` 是 `Exists` （此时 toleration 不能指定 `value`），或者
* 如果 `operator` 是 `Exists` （此时容忍度不能指定 `value`），或者
* 如果 `operator` 是 `Equal` ，则它们的 `value` 应该相等
{{< note >}}
<!--
There are two special cases:
* An empty `key` with operator `Exists` matches all keys, values and effects which means this
An empty `key` with operator `Exists` matches all keys, values and effects which means this
will tolerate everything.
-->
An empty `effect` matches all effects with key `key`.
-->
{{< note >}}
存在两种特殊情况：
* 如果一个 toleration 的 `key` 为空且 operator 为 `Exists`，表示这个 toleration 与任意的 key 、value 和 effect 都匹配，即这个 toleration 能容忍任意 taint。
如果一个容忍度的 `key` 为空且 operator 为 `Exists`，
表示这个容忍度与任意的 key 、value 和 effect 都匹配，即这个容忍度能容忍任意 taint。
```yaml
tolerations:
- operator: "Exists"
```
<!--
* An empty `effect` matches all effects with key `key`.
-->
* 如果一个 toleration 的 `effect` 为空，则 `key` 值与之相同的相匹配 taint 的 `effect` 可以是任意值。
```yaml
tolerations:
- key: "key"
operator: "Exists"
```
如果 `effect` 为空，则可以与所有键名 `key` 的效果相匹配。
{{< /note >}}
<!--
The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a
This is a "preference" or "soft" version of `NoSchedule` - the system will *try* to avoid placing a
pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is
`NoExecute`, described later.
-->
上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。这是“优化”或“软”版本的 `NoSchedule` ——系统会 *尽量* 避免将 pod 调度到存在其不能容忍 taint 的节点上，但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。
上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。
这是“优化”或“软”版本的 `NoSchedule` —— 系统会 *尽量* 避免将 Pod 调度到存在其不能容忍污点的节点上，
但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。
<!--
You can put multiple taints on the same node and multiple tolerations on the same pod.
@@ -142,7 +154,10 @@ The way Kubernetes processes multiple taints and tolerations is like a filter: s
with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the
remaining un-ignored taints have the indicated effects on the pod. In particular,
-->
您可以给一个节点添加多个 taint ，也可以给一个 pod 添加多个 toleration。Kubernetes 处理多个 taint 和 toleration 的过程就像一个过滤器：从一个节点的所有 taint 开始遍历，过滤掉那些 pod 中存在与之相匹配的 toleration 的 taint。余下未被过滤的 taint 的 effect 值决定了 pod 是否会被分配到该节点，特别是以下情况：
您可以给一个节点添加多个污点，也可以给一个 Pod 添加多个容忍度设置。
Kubernetes 处理多个污点和容忍度的过程就像一个过滤器：从一个节点的所有污点开始遍历，
过滤掉那些 Pod 中存在与之相匹配的容忍度的污点。余下未被过滤的污点的 effect 值决定了
Pod 是否会被分配到该节点，特别是以下情况：
<!--
@@ -154,14 +169,19 @@ effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod ont
the node (if it is already running on the node), and will not be
scheduled onto the node (if it is not yet running on the node).
-->
* 如果未被过滤的 taint 中存在至少一个 effect 值为 `NoSchedule` 的 taint，则 Kubernetes 不会将 pod 分配到该节点。
* 如果未被过滤的 taint 中不存在 effect 值为 `NoSchedule` 的 taint，但是存在 effect 值为 `PreferNoSchedule` 的 taint，则 Kubernetes 会 *尝试* 将 pod 分配到该节点。
* 如果未被过滤的 taint 中存在至少一个 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。
* 如果未被过滤的污点中存在至少一个 effect 值为 `NoSchedule` 的污点，
则 Kubernetes 不会将 Pod 分配到该节点。
* 如果未被过滤的污点中不存在 effect 值为 `NoSchedule` 的污点，
但是存在 effect 值为 `PreferNoSchedule` 的污点，
则 Kubernetes 会 *尝试* 将 Pod 分配到该节点。
* 如果未被过滤的污点中存在至少一个 effect 值为 `NoExecute` 的污点，
则 Kubernetes 不会将 Pod 分配到该节点（如果 Pod 还未在节点上运行），
或者将 Pod 从该节点驱逐（如果 Pod 已经在节点上运行）。
<!--
For example, imagine you taint a node like this
-->
例如，假设您给一个节点添加了如下的 taint
例如，假设您给一个节点添加了如下污点
```shell
kubectl taint nodes node1 key1=value1:NoSchedule
@@ -172,7 +192,7 @@ kubectl taint nodes node1 key2=value2:NoSchedule
<!--
And a pod has two tolerations:
-->
然后存在一个 pod，它有两个 toleration：
假定有一个 Pod，它有两个容忍度：
```yaml
tolerations:
@@ -192,7 +212,9 @@ toleration matching the third taint. But it will be able to continue running if
already running on the node when the taint is added, because the third taint is the only
one of the three that is not tolerated by the pod.
-->
在这个例子中，上述 pod 不会被分配到上述节点，因为其没有 toleration 和第三个 taint 相匹配。但是如果在给节点添加上述 taint 之前，该 pod 已经在上述节点运行，那么它还可以继续运行在该节点上，因为第三个 taint 是三个 taint 中唯一不能被这个 pod 容忍的。
在这种情况下，上述 Pod 不会被分配到上述节点，因为其没有容忍度和第三个污点相匹配。
但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行，
那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。
<!--
Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do
@@ -201,7 +223,12 @@ taint will never be evicted. However, a toleration with `NoExecute` effect can s
an optional `tolerationSeconds` field that dictates how long the pod will stay bound
to the node after the taint is added. For example,
-->
通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的 taint，则任何不能忍受这个 taint 的 pod 都会马上被驱逐，任何可以忍受这个 taint 的 pod 都不会被驱逐。但是，如果 pod 存在一个 effect 值为 `NoExecute` 的 toleration 指定了可选属性 `tolerationSeconds` 的值，则表示在给节点添加了上述 taint 之后，pod 还能继续在节点上运行的时间。例如，
通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的污点，
则任何不能忍受这个污点的 Pod 都会马上被驱逐，
任何可以忍受这个污点的 Pod 都不会被驱逐。
但是，如果 Pod 存在一个 effect 值为 `NoExecute` 的容忍度指定了可选属性
`tolerationSeconds` 的值，则表示在给节点添加了上述污点之后，
Pod 还能继续在节点上运行的时间。例如，
```yaml
tolerations:
@@ -217,24 +244,22 @@ means that if this pod is running and a matching taint is added to the node, the
the pod will stay bound to the node for 3600 seconds, and then be evicted. If the
taint is removed before that time, the pod will not be evicted.
-->
这表示如果这个 pod 正在运行，然后一个匹配的 taint 被添加到其所在的节点，那么 pod 还将继续在节点上运行 3600 秒，然后被驱逐。如果在此之前上述 taint 被删除了，则 pod 不会被驱逐。
这表示如果这个 Pod 正在运行，同时一个匹配的污点被添加到其所在的节点，
那么 Pod 还将继续在节点上运行 3600 秒，然后被驱逐。
如果在此之前上述污点被删除了，则 Pod 不会被驱逐。
<!--
## Example Use Cases
-->
## 使用例子
<!--
Taints and tolerations are a flexible way to steer pods *away* from nodes or evict
pods that shouldn't be running. A few of the use cases are
-->
通过 taint 和 toleration，可以灵活地让 pod *避开* 某些节点或者将 pod 从某些节点驱逐。下面是几个使用例子：
通过污点和容忍度，可以灵活地让 Pod *避开* 某些节点或者将 Pod 从某些节点驱逐。下面是几个使用例子：
<!--
* **Dedicated Nodes**: If you want to dedicate a set of nodes for exclusive use by
a particular set of users, you can add a taint to those nodes (say,
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
@@ -247,11 +272,16 @@ to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admi
controller should additionally add a node affinity to require that the pods can only schedule
onto nodes labeled with `dedicated=groupName`.
-->
* **专用节点**：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个 taint（即，
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`），然后给这组用户的 pod 添加一个相对应的 toleration（通过编写一个自定义的 [admission controller](/docs/admin/admission-controllers/)，很容易就能做到）。拥有上述 toleration 的 pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。如果您希望这些 pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述 taint 类似的 label （例如：`dedicated=groupName`），同时 还要在上述 admission controller 中给 pod 增加节点亲和性要求上述 pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。
* **专用节点**：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个污点（即，
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`），
然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。
拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。
如果您希望这些 Pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述
污点类似的 label （例如：`dedicated=groupName`），同时 还要在上述准入控制器中给 Pod
增加节点亲和性要求上述 Pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。
<!--
* **Nodes with Special Hardware**: In a cluster where a small subset of nodes have specialized
hardware (for example GPUs), it is desirable to keep pods that don't need the specialized
hardware off of those nodes, thus leaving room for later-arriving pods that do need the
@@ -274,27 +304,39 @@ on the special hardware nodes. This will make sure that these special hardware
nodes are dedicated for pods requesting such hardware and you don't have to
manually add tolerations to your pods.
-->
* **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中，我们希望不需要这类硬件的 pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 pod 保留资源。要达到这个目的，可以先给配备了特殊硬件的节点添加 taint（例如 `kubectl taint nodes nodename special=true:NoSchedule` or `kubectl taint nodes nodename special=true:PreferNoSchedule`)，然后给使用了这类特殊硬件的 pod 添加一个相匹配的 toleration。和专用节点的例子类似，添加这个 toleration 的最简单的方法是使用自定义 [admission controller](/docs/reference/access-authn-authz/admission-controllers/)。比如，我们推荐使用 [Extended Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) 来表示特殊硬件，给配置了特殊硬件的节点添加 taint 时包含 extended resource 名称，然后运行一个 [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) admission controller。此时，因为节点已经被 taint 了，没有对应 toleration 的 Pod 会被调度到这些节点。但当你创建一个使用了 extended resource 的 Pod 时，`ExtendedResourceToleration` admission controller 会自动给 Pod 加上正确的 toleration ，这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。这样就能够确保这些配置了特殊硬件的节点专门用于运行 需要使用这些硬件的 Pod，并且您无需手动给这些 Pod 添加 toleration。
* **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中，
我们希望不需要这类硬件的 Pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 Pod 保留资源。
要达到这个目的，可以先给配备了特殊硬件的节点添加 taint
（例如 `kubectl taint nodes nodename special=true:NoSchedule` 或
`kubectl taint nodes nodename special=true:PreferNoSchedule`)，
然后给使用了这类特殊硬件的 Pod 添加一个相匹配的 toleration。
和专用节点的例子类似，添加这个容忍度的最简单的方法是使用自定义
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。
比如，我们推荐使用[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)
来表示特殊硬件，给配置了特殊硬件的节点添加污点时包含扩展资源名称，
然后运行一个 [ExtendedResourceToleration](/zh/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
准入控制器。此时，因为节点已经被设置污点了，没有对应容忍度的 Pod
会被调度到这些节点。但当你创建一个使用了扩展资源的 Pod 时，
`ExtendedResourceToleration` 准入控制器会自动给 Pod 加上正确的容忍度，
这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。
这样就能够确保这些配置了特殊硬件的节点专门用于运行需要使用这些硬件的 Pod，
并且您无需手动给这些 Pod 添加容忍度。
<!--
* **Taint based Evictions**: A per-pod-configurable eviction behavior
when there are node problems, which is described in the next section.
-->
* **基于 taint 的驱逐**: 这是在每个 pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性
* **基于污点的驱逐**: 这是在每个 Pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性。
<!--
## Taint based Evictions
-->
## 基于 taint 的驱逐
## 基于污点的驱逐 {#taint-based-evictions}
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
<!--
Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
The `NoExecute` taint effect, which affects pods that are already
running on the node as follows
* pods that do not tolerate the taint are evicted immediately
@@ -303,16 +345,17 @@ running on the node as follows
* pods that tolerate the taint with a specified `tolerationSeconds` remain
bound for the specified amount of time
-->
前文我们提到过 taint 的 effect 值 `NoExecute` ，它会影响已经在节点上运行的 pod
前文提到过污点的 effect 值 `NoExecute`会影响已经在节点上运行的 Pod
* 如果 pod 不能忍受 effect 值为 `NoExecute` 的 taint，那么 pod 将马上被驱逐
* 如果 pod 能够忍受 effect 值为 `NoExecute` 的 taint，但是在 toleration 定义中没有指定 `tolerationSeconds`，则 pod 还会一直在这个节点上运行。
* 如果 pod 能够忍受 effect 值为 `NoExecute` 的 taint，而且指定了 `tolerationSeconds`，则 pod 还能在这个节点上继续运行这个指定的时间长度。
* 如果 Pod 不能忍受 effect 值为 `NoExecute` 的污点，那么 Pod 将马上被驱逐
* 如果 Pod 能够忍受 effect 值为 `NoExecute` 的污点，但是在容忍度定义中没有指定
`tolerationSeconds`，则 Pod 还会一直在这个节点上运行。
* 如果 Pod 能够忍受 effect 值为 `NoExecute` 的污点，而且指定了 `tolerationSeconds`，
则 Pod 还能在这个节点上继续运行这个指定的时间长度。
<!--
In addition, Kubernetes 1.6 introduced alpha support for representing node
problems. In other words, the node controller automatically taints a node when
certain condition is true. The following taints are built in:
The node controller automatically taints a node when certain conditions are
true. The following taints are built in:
* `node.kubernetes.io/not-ready`: Node is not ready. This corresponds to
the NodeCondition `Ready` being "`False`".
@@ -328,40 +371,46 @@ certain condition is true. The following taints are built in:
as unusable. After a controller from the cloud-controller-manager initializes
this node, the kubelet removes this taint.
-->
此外，Kubernetes 1.6 已经支持（alpha阶段）节点问题的表示。换句话说，当某种条件为真时，node controller会自动给节点添加一个 taint。当前内置的 taint 包括：
当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括：
* `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。
* `node.kubernetes.io/unreachable`：node controller 访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。
* `node.kubernetes.io/unreachable`：节点控制器访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。
* `node.kubernetes.io/out-of-disk`：节点磁盘耗尽。
* `node.kubernetes.io/memory-pressure`：节点存在内存压力。
* `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。
* `node.kubernetes.io/network-unavailable`：节点网络不可用。
* `node.kubernetes.io/unschedulable`: 节点不可调度。
* `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" cloud provider，它将给当前节点添加一个 taint 将其标志为不可用。在 cloud-controller-manager 的一个 controller 初始化这个节点后，kubelet 将删除这个 taint。
* `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" 云平台驱动，
它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager
的一个控制器初始化这个节点后，kubelet 将删除这个污点。
<!--
In case a node is to be evicted, the node controller or the kubelet adds relevant taints
with `NoExecute` effect. If the fault condition returns to normal the kubelet or node
controller can remove the relevant taint(s).
-->
在节点被驱逐时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效应的相关污点。如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。
在节点被驱逐时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效应的相关污点。
如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。
{{< note >}}
<!--
To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
behavior of pod evictions due to node problems, the system actually adds the taints
in a rate-limited way. This prevents massive pod evictions in scenarios such
as the master becoming partitioned from the nodes.
-->
为了保证由于节点问题引起的 pod 驱逐[rate limiting](/docs/concepts/architecture/nodes/)行为正常，系统实际上会以 rate-limited 的方式添加 taint。在像 master 和 node 通讯中断等场景下，这避免了 pod 被大量驱逐。
{{< note >}}
为了保证由于节点问题引起的 Pod 驱逐
[速率限制](/zh/docs/concepts/architecture/nodes/)行为正常，
系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下，
这样做可以避免 Pod 被大量驱逐。
{{< /note >}}
<!--
This feature, in combination with `tolerationSeconds`, allows a pod
to specify how long it should stay bound to a node that has one or both of these problems.
-->
使用这个功能特性，结合 `tolerationSeconds`，pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。
使用这个功能特性，结合 `tolerationSeconds`，Pod 就可以指定当节点出现一个
或全部上述问题时还将在这个节点上运行多长的时间。
<!--
For example, an application with a lot of local state might want to stay
@@ -369,7 +418,8 @@ bound to node for a long time in the event of network partition, in the hope
that the partition will recover and thus the pod eviction can be avoided.
The toleration the pod would use in that case would look like
-->
比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间，愿意等待网络恢复以避免被驱逐。在这种情况下，pod 的 toleration 可能是下面这样的：
比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间，
愿意等待网络恢复以避免被驱逐。在这种情况下，Pod 的容忍度可能是下面这样的：
```yaml
tolerations:
@@ -389,17 +439,23 @@ Likewise it adds a toleration for
unless the pod configuration provided
by the user already has a toleration for `node.kubernetes.io/unreachable`.
-->
注意，Kubernetes 会自动给 pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/not-ready` 的 toleration。同样，Kubernetes 会给 pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/unreachable` 的 toleration。
{{< note >}}
Kubernetes 会自动给 Pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的容忍度
并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为
`node.kubernetes.io/not-ready` 的容忍度。
同样，Kubernetes 会给 Pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的容忍度
并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为
`node.kubernetes.io/unreachable` 的容忍度。
{{< /note >}}
<!--
These automatically-added tolerations ensure that
the default pod behavior of remaining bound for 5 minutes after one of these
problems is detected is maintained.
The two default tolerations are added by the [DefaultTolerationSeconds
admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
These automatically-added tolerations mean that Pods remain bound to
Nodes for 5 minutes after one of these problems is detected.
-->
这种自动添加 toleration 机制保证了在其中一种问题被检测到时 pod 默认能够继续停留在当前节点运行 5 分钟。这两个默认 toleration 是由 [DefaultTolerationSeconds
admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds)添加的。
这种自动添加的容忍度意味着在其中一种问题被检测到时 Pod
默认能够继续停留在当前节点运行 5 分钟。
<!--
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
@@ -410,24 +466,25 @@ admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/default
This ensures that DaemonSet pods are never evicted due to these problems.
-->
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 中的 pod 被创建时，针对以下 taint 自动添加的 `NoExecute` 的 toleration 将不会指定 `tolerationSeconds`：
[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时，
针对以下污点自动添加的 `NoExecute` 的容忍度将不会指定 `tolerationSeconds`：
* `node.kubernetes.io/unreachable`
* `node.kubernetes.io/not-ready`
这保证了出现上述问题时 DaemonSet 中的 pod 永远不会被驱逐。
这保证了出现上述问题时 DaemonSet 中的 Pod 永远不会被驱逐。
<!--
## Taint Nodes by Condition
-->
## 基于节点状态添加 taint
## 基于节点状态添加污点
<!--
The node lifecycle controller automatically creates taints corresponding to Node conditions with `NoSchedule` effect.
The node lifecycle controller automatically creates taints corresponding to
Node conditions with `NoSchedule` effect.
Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
The DaemonSet controller automatically adds the
following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
breaking.
@@ -438,19 +495,31 @@ breaking.
* `node.kubernetes.io/network-unavailable` (*host network only*)
-->
Node 生命周期控制器会自动创建与 Node 条件相对应的带有 `NoSchedule` 效应的污点。
同样，调度器不检查节点条件，而是检查节点污点。这确保了节点条件不会影响调度到节点上的内容。用户可以通过添加适当的 Pod 容忍度来选择忽略某些 Node 的问题(表示为 Node 的调度条件)。
同样，调度器不检查节点条件，而是检查节点污点。这确保了节点条件不会影响调度到节点上的内容。
用户可以通过添加适当的 Pod 容忍度来选择忽略某些 Node 的问题(表示为 Node 的调度条件)。
自 Kubernetes 1.8 起， DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` toleration 以防 DaemonSet 崩溃：
DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍度以防 DaemonSet 崩溃：
* `node.kubernetes.io/memory-pressure`
* `node.kubernetes.io/disk-pressure`
* `node.kubernetes.io/out-of-disk` (*只适合 critical pod*)
* `node.kubernetes.io/out-of-disk` (*只适合关键 Pod*)
* `node.kubernetes.io/unschedulable` (1.10 或更高版本)
* `node.kubernetes.io/network-unavailable` (*只适合 host network*)
* `node.kubernetes.io/network-unavailable` (*只适合主机网络配置*)
<!--
Adding these tolerations ensures backward compatibility. You can also add
arbitrary tolerations to DaemonSets.
-->
添加上述 toleration 确保了向后兼容，您也可以选择自由的向 DaemonSet 添加 toleration。
添加上述容忍度确保了向后兼容，您也可以选择自由向 DaemonSet 添加容忍度。
## {{% heading "whatsnext" %}}
<!--
* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
-->
* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
content/zh/docs/concepts/services-networking/connect-applications-service.md
+46 -38
View File
@@ -1,10 +1,9 @@
---
title: 应用连接到 Service
title: 使用 Service 连接到应用
content_type: concept
weight: 30
---
<!-- overview -->
<!--
@@ -24,8 +23,6 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same
既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。
默认情况下，Docker 使用私有主机网络连接，只能与同在一台机器上的容器进行通信。
为了实现容器的跨节点通信，必须在机器自己的 IP 上为这些容器分配端口，为容器进行端口转发或者代理。
@@ -35,10 +32,8 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上
这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。
文档的剩余部分将详述如何在一个网络模型之上运行可靠的服务。
该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的
[Jenkins CI 应用](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
<!-- body -->
@@ -48,7 +43,6 @@ Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上
We did this in a previous example, but let's do it once again and focus on the networking perspective.
Create an nginx Pod, and note that it has a container port specification:
-->
## 在集群中暴露 Pod
我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。
@@ -75,7 +69,6 @@ my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5
<!--
Check your pods' IPs:
-->
检查 Pod 的 IP 地址：
```shell
@@ -89,14 +82,12 @@ You should be able to ssh into any node in your cluster and curl both IPs. Note
You can read more about [how we achieve this](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) if you're curious.
-->
应该能够通过 ssh 登录到集群中的任何一个节点上，使用 curl 也能调通所有 IP 地址。
需要注意的是，容器不会使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。
这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。
像 Docker 一样，端口能够被发布到主机节点的接口上，但是出于网络模型的原因应该从根本上减少这种用法。
如果对此好奇，可以获取更多关于 [如何实现网络模型](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。
如果对此好奇，可以获取更多关于 [如何实现网络模型](/zh/docs/concepts/cluster-administration/networking/#how-to-achieve-this) 的内容。
<!--
## Creating a Service
@@ -107,7 +98,6 @@ A Kubernetes Service is an abstraction which defines a logical set of Pods runni
You can create a Service for your 2 nginx replicas with `kubectl expose`:
-->
## 创建 Service
我们有 Pod 在一个扁平的、集群范围的地址空间中运行 Nginx 服务，可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？
@@ -145,9 +135,11 @@ View [Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/
API object to see the list of supported fields in service definition.
Check your Service:
-->
上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。
查看 [Service API 对象](/docs/api-reference/{{< param "version" >}}/#service-v1-core) 了解 Service 定义支持的字段列表。
上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，
并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service
端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。
查看 [Service API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
了解 Service 定义支持的字段列表。
查看你的 Service 资源:
```shell
@@ -167,7 +159,6 @@ matching the Service's selector will automatically get added to the endpoints.
Check the endpoints, and note that the IPs are the same as the Pods created in
the first step:
-->
正如前面所提到的，一个 Service 由一组 backend Pod 组成。这些 Pod 通过 `endpoints` 暴露出来。
Service Selector 将持续评估，结果被 POST 到一个名称为 `my-nginx` 的 Endpoint 对象上。
当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。
@@ -206,7 +197,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
现在，能够从集群中任意节点上使用 curl 命令请求 Nginx Service `<CLUSTER-IP>:<PORT>` 。
注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，
可以阅读更多关于 [服务代理](/docs/user-guide/services/#virtual-ips-and-service-proxies) 的内容。
可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
的内容。
<!--
## Accessing the Service
@@ -219,22 +211,19 @@ and DNS. The former works out of the box while the latter requires the
## 访问 Service
Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件]
[CoreDNS 集群插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
{{< note >}}
[CoreDNS 集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
<!--
If the service environment variables are not desired (because possible clashing with expected program ones,
too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
-->
{{< note >}}
如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在
[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。
[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。
{{< /note >}}
<!--
### Environment Variables
@@ -324,9 +313,10 @@ The rest of this section will assume you have a Service with a long lived IP
cluster addon), so you can talk to the Service from any pod in your cluster using
standard methods (e.g. gethostbyname). Let's run another curl application to test this:
-->
如果没有在运行，可以 [启用它](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。
本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。
如果没有在运行，可以[启用它](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)。
本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），
一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，
使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。
让我们运行另一个 curl 应用来进行测试：
```shell
@@ -370,9 +360,10 @@ You can acquire all these from the [nginx https example](https://github.com/kube
* https 自签名证书（除非已经有了一个识别身份的证书）
* 使用证书配置的 Nginx server
* 使证书可以访问 Pod 的[秘钥](/docs/user-guide/secrets)
* 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/)
可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下：
可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/)
获取所有上述内容，简明示例如下：
```shell
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
@@ -456,7 +447,8 @@ Noteworthy points about the nginx-secure-app manifest:
关于 nginx-secure-app manifest 值得注意的点如下：
- 它在相同的文件中包含了 Deployment 和 Service 的规格
- [Nginx server](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。
- [Nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf)
处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。
- 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。
```shell
@@ -483,7 +475,8 @@ so we have to tell curl to ignore the CName mismatch. By creating a Service we l
Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service):
-->
注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。
注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，
我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。
通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。
让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）：
@@ -513,15 +506,18 @@ LoadBalancers. The Service created in the last section already used `NodePort`,
so your nginx HTTPS replica is ready to serve traffic on the internet if your
node has a public IP.
-->
## 暴露 Service
对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。
Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。
在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，如果使用一个公网 IP，能够处理 Internet 上的流量。
在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，
如果使用一个公网 IP，能够处理 Internet 上的流量。
```shell
kubectl get svc my-nginx -o yaml | grep nodePort -C 5
```
```
uid: 07191fb3-f61a-11e5-8ae5-42010af00002
spec:
clusterIP: 10.0.162.149
@@ -539,8 +535,12 @@ spec:
selector:
run: my-nginx
```
```shell
kubectl get nodes -o yaml | grep ExternalIP -C 1
```
```
- address: 104.197.41.11
type: ExternalIP
allocatable:
@@ -549,8 +549,14 @@ kubectl get nodes -o yaml | grep ExternalIP -C 1
type: ExternalIP
allocatable:
...
```
$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
```shell
curl https://<EXTERNAL-IP>:<NODE-PORT> -k
```
输出类似于：
```
...
<h1>Welcome to nginx!</h1>
```
@@ -593,13 +599,14 @@ see it. You'll see something like this:
```shell
kubectl describe service my-nginx
```
```
...
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
...
```
## {{% heading "whatsnext" %}}
<!--
@@ -610,3 +617,4 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)
content/zh/docs/concepts/services-networking/dns-pod-service.md
+117 -97
View File
@@ -8,8 +8,7 @@ weight: 20
<!--
This page provides an overview of DNS support by Kubernetes.
-->
该页面概述了Kubernetes对DNS的支持。
本页面提供 Kubernetes 对 DNS 的支持的概述。
<!-- body -->
@@ -47,28 +46,25 @@ For more up-to-date specification, see
## 怎样获取 DNS 名字?
在集群中定义的每个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。
默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的 Namespace 和集群默认域。
通过如下示例可以很好地说明：
默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的名字空间和集群默认域。
如下示例是一个很好的说明：
假设在 Kubernetes 集群的 Namespace `bar` 中，定义了一个Service `foo`。
运行在Namespace `bar` 中的一个 Pod，可以简单地通过 DNS 查询 `foo` 来找到该 Service。
运行在 Namespace `quux` 中的一个 Pod 可以通过 DNS 查询 `foo.bar` 找到该 Service。
假设在 Kubernetes 集群的名字空间 `bar` 中，定义了一个服务 `foo`。
运行在名字空间 `bar` 中的 Pod 可以简单地通过 DNS 查询 `foo` 来找到该服务。
运行在名字空间 `quux` 中的 Pod 可以通过 DNS 查询 `foo.bar` 找到该服务。
以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。
以下各节详细介绍了受支持的记录类型和支持的布局。
其它布局、名称或者查询即使碰巧可以工作，也应视为实现细节，
将来很可能被更改而且不会因此出现警告。
有关最新规范请查看
[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
## 支持的 DNS 模式
下面各段详细说明支持的记录类型和布局。
如果任何其它的布局、名称或查询，碰巧也能够使用，这就需要研究下它们的实现细节，以免后续修改它们又不能使用了。
[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
<!--
## Services
### A records
### A/AAAA records
"Normal" (not headless) Services are assigned a DNS A record for a name of the
"Normal" (not headless) Services are assigned a DNS A or AAAA record for a name of the
form `my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP
of the Service.
@@ -79,16 +75,19 @@ Clients are expected to consume the set or else use standard round-robin
selection from the set.
-->
### Service
### 服务 {#services}
#### A 记录
#### A/AAAA 记录
“正常” Service（除了 Headless Service）会以 `my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 记录。
这会解析成该 Service 的 Cluster IP。
“普通” 服务（除了无头服务）会以 `my-svc.my-namespace.svc.cluster-domain.example`
这种名字的形式被分配一个 DNS A 或 AAAA 记录，取决于服务的 IP 协议族。
该名称会解析成对应服务的集群 IP。
“Headless” Service（没有Cluster IP）也会以 `my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 记录。
不像正常 Service，它会解析成该 Service 选择的一组 Pod 的 IP。
希望客户端能够使用这一组 IP，否则就使用标准的 round-robin 策略从这一组 IP 中进行选择。
“无头（Headless）” 服务（没有集群 IP）也会以
`my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 或 AAAA 记录，
具体取决于服务的 IP 协议族。
与普通服务不同，这一记录会被解析成对应服务所选择的 Pod 集合的 IP。
客户端要能够使用这组 IP，或者使用标准的轮转策略从这组 IP 中进行选择。
<!--
### SRV records
@@ -103,19 +102,33 @@ For a headless service, this resolves to multiple answers, one for each pod
that is backing the service, and contains the port number and the domain name of the pod
of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
-->
#### SRV 记录 {#srv-records}
#### SRV 记录
命名端口需要创建 SRV 记录，这些端口是正常 Service或 [Headless
Services](/docs/concepts/services-networking/service/#headless-services) 的一部分。
Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或
[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)的一部分。
对每个命名端口，SRV 记录具有 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example` 这种形式。
对普通 Service，这会被解析成端口号和 CNAME：`my-svc.my-namespace.svc.cluster-domain.example`。
对 Headless Service，这会被解析成多个结果，Service 对应的每个 backend Pod 各一个，
包含 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` 这种形式 Pod 的端口号和 CNAME。
对普通服务，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。
对无头服务，该记录会被解析成多个结果，服务对应的每个后端 Pod 各一个；
其中包含 Pod 端口号和形为 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`
的域名。
## Pods
<!--
### A/AAAA records
Any pods created by a Deployment or DaemonSet have the following
DNS resolution available:
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
-->
### A/AAAA 记录
经由 Deployment 或者 DaemonSet 所创建的所有 Pods 都会有如下 DNS
解析项与之对应：
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
<!--
### Pod's hostname and subdomain fields
@@ -134,15 +147,22 @@ domain name (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`".
Example:
-->
### Pod的 hostname 和 subdomain 字段
### Pod 的 hostname 和 subdomain 字段
当前，创建 Pod 后，它的主机名是该 Pod 的 `metadata.name` 值。
当前，创建 Pod 时其主机名取自 Pod 的 `metadata.name` 值。
PodSpec 有一个可选的 `hostname` 字段，可以用来指定 Pod 的主机名。当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名。举个例子，给定一个 `hostname` 设置为 "`my-host`" 的 Pod，该 Pod 的主机名将被设置为 "`my-host`"。
Pod 规约中包含一个可选的 `hostname` 字段，可以用来指定 Pod 的主机名。
当这个字段被设置时，它将优先于 Pod 的名字成为该 Pod 的主机名。
举个例子，给定一个 `hostname` 设置为 "`my-host`" 的 Pod，
该 Pod 的主机名将被设置为 "`my-host`"。
PodSpec 还有一个可选的 `subdomain` 字段，可以用来指定 Pod 的子域名。举个例子，一个 Pod 的 `hostname` 设置为 “`foo`”，`subdomain` 设置为 “`bar`”，在 namespace “`my-namespace`” 中对应的完全限定域名（FQDN）为 “`foo.bar.my-namespace.svc.cluster-domain.example`”。
Pod 规约还有一个可选的 `subdomain` 字段，可以用来指定 Pod 的子域名。
举个例子，某 Pod 的 `hostname` 设置为 “`foo`”，`subdomain` 设置为 “`bar`”，
在名字空间 “`my-namespace`” 中对应的完全限定域名（FQDN）为
“`foo.bar.my-namespace.svc.cluster-domain.example`”。
示例：
实例:
```yaml
apiVersion: v1
kind: Service
@@ -153,7 +173,7 @@ spec:
name: busybox
clusterIP: None
ports:
- name: foo # Actually, no port is needed.
- name: foo # 实际上不需要指定端口号
port: 1234
targetPort: 1234
---
@@ -192,30 +212,29 @@ spec:
<!--
If there exists a headless service in the same namespace as the pod and with
the same name as the subdomain, the cluster's KubeDNS Server also returns an A
the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA
record for the Pod's fully qualified hostname.
For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
"`default-subdomain`", and a headless Service named "`default-subdomain`" in
the same namespace, the pod will see its own FQDN as
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an
A record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
"`busybox2`" can have their distinct A records.
A or AAAA record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
"`busybox2`" can have their distinct A or AAAA records.
-->
如果 Headless Service 与 Pod 在同一个 Namespace 中，它们具有相同的子域名，集群的 KubeDNS 服务器也会为该 Pod 的完整合法主机名返回 A 记录。
例如，在同一个 Namespace 中，给定一个主机名为 “busybox-1” 的 Pod，子域名设置为 “default-subdomain”，名称为 “default-subdomain” 的 Headless Service ，Pod 将看到自己的 FQDN 为 “busybox-1.default-subdomain.my-namespace.svc.cluster.local”。
DNS 会为那个名字提供一个 A 记录，指向该 Pod 的 IP。
“busybox1” 和 “busybox2” 这两个 Pod 分别具有它们自己的 A 记录。
如果某无头服务与某 Pod 在同一个名字空间中，且它们具有相同的子域名，
集群的 DNS 服务器也会为该 Pod 的全限定主机名返回 A 记录或 AAAA 记录。
例如，在同一个名字空间中，给定一个主机名为 “busybox-1”、
子域名设置为 “default-subdomain” 的 Pod，和一个名称为 “`default-subdomain`”
的无头服务，Pod 将看到自己的 FQDN 为
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`"。
DNS 会为此名字提供一个 A 记录或 AAAA 记录，指向该 Pod 的 IP。
“`busybox1`” 和 “`busybox2`” 这两个 Pod 分别具有它们自己的 A 或 AAAA 记录。
<!--
The Endpoints object can specify the `hostname` for any endpoint addresses,
along with its IP.
-->
端点对象可以为任何端点地址及其 IP 指定 `hostname`。
{{< note >}}
Endpoints 对象可以为任何端点地址及其 IP 指定 `hostname`。
<!--
Because A records are not created for Pod names, `hostname` is required for the Pod's A
@@ -224,11 +243,15 @@ A record for the headless service (`default-subdomain.my-namespace.svc.cluster-d
pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a
record unless `publishNotReadyAddresses=True` is set on the Service.
-->
{{< note >}}
因为没有为 Pod 名称创建 A 记录或 AAAA 记录，所以要创建 Pod 的 A 记录
或 AAAA 记录需要 `hostname`。
因为没有为 Pod 名称创建A记录，所以要创建 Pod 的 A 记录需要 `hostname` 。
没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。
另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则 Pod 需要准备好 A 记录。
没有设置 `hostname` 但设置了 `subdomain` 的 Pod 只会为
无头服务创建 A 或 AAAA 记录（`default-subdomain.my-namespace.svc.cluster-domain.example`）
指向 Pod 的 IP 地址。
另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则只有 Pod 进入就绪状态
才会有与之对应的记录。
{{< /note >}}
<!--
@@ -256,30 +279,32 @@ following pod-specific DNS policies. These policies are specified in the
See [Pod's DNS config](#pod-s-dns-config) subsection below.
-->
- "`Default`": Pod从运行所在的节点继承名称解析配置。
参考 [相关讨论](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。
- "`ClusterFirst`": 与配置的群集域后缀不匹配的任何DNS查询(例如 “www.kubernetes.io” )都将转发到从节点继承的上游名称服务器。 群集管理员可能配置了额外的存根域和上游DNS服务器。
See [相关讨论](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) 获取如何 DNS 的查询和处理信息的相关资料。
- "`ClusterFirstWithHostNet`": 对于与 hostNetwork 一起运行的 Pod，应显式设置其DNS策略 "`ClusterFirstWithHostNet`"。
- "`None`": 它允许 Pod 忽略 Kubernetes 环境中的 DN S设置。 应该使用 Pod Spec 中的 `dnsConfig` 字段提供所有 DNS 设置。
{{< note >}}
- "`Default`": Pod 从运行所在的节点继承名称解析配置。
参考[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。
- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 “www.kubernetes.io”）
都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
了解在这些场景中如何处理 DNS 查询的信息。
- "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略
"`ClusterFirstWithHostNet`"。
- "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` 字段
所提供的 DNS 设置。
参见 [Pod 的 DNS 配置](#pod-dns-config)节。
<!--
"Default" is not the default DNS policy. If `dnsPolicy` is not
explicitly specified, then “ClusterFirst” is used.
-->
"Default" 不是默认的 DNS 策略。 如果未明确指定 `dnsPolicy`，则使用 “ClusterFirst”。
{{< note >}}
"`Default`" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "`ClusterFirst`"。
{{< /note >}}
<!--
The example below shows a Pod with its DNS policy set to
"`ClusterFirstWithHostNet`" because it has `hostNetwork` set to `true`.
-->
下面的示例显示了一个Pod，其DNS策略设置为 "`ClusterFirstWithHostNet`"，因为它已将 `hostNetwork` 设置为 `true`。
下面的示例显示了一个 Pod，其 DNS 策略设置为 "`ClusterFirstWithHostNet`"，
因为它已将 `hostNetwork` 设置为 `true`。
```yaml
apiVersion: v1
@@ -311,8 +336,7 @@ to be specified.
Below are the properties a user can specify in the `dnsConfig` field:
-->
### Pod 的 DNS 设定
### Pod 的 DNS 配置 {#pod-dns-config}
Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
@@ -339,18 +363,23 @@ Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
Duplicate entries are removed.
-->
- `nameservers`: 将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定3个 IP 地址。 当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。
- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。
重复的域名将被删除。
   Kubernetes最多允许6个搜索域。
- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。
重复的条目将被删除。
- `nameservers`：将用作于 Pod 的 DNS 服务器的 IP 地址列表。
最多可以指定 3 个 IP 地址。当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，
列表必须至少包含一个 IP 地址，否则此属性是可选的。
所列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。
- `searches`：用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。
指定此属性时，所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。
重复的域名将被删除。Kubernetes 最多允许 6 个搜索域。
- `options`：可选的对象列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。
此属性中的内容将合并到从指定的 DNS 策略生成的选项。
重复的条目将被删除。
<!--
The following is an example Pod with custom DNS settings:
-->
以下是具有自定义DNS设置的Pod示例：
以下是具有自定义 DNS 设置的 Pod 示例：
{{< codenew file="service/networking/custom-dns.yaml" >}}
@@ -358,8 +387,7 @@ The following is an example Pod with custom DNS settings:
When the Pod above is created, the container `test` gets the following contents
in its `/etc/resolv.conf` file:
-->
创建上面的Pod后，容器 `test` 会在其 `/etc/resolv.conf` 文件中获取以下内容：
创建上面的 Pod 后，容器 `test` 会在其 `/etc/resolv.conf` 文件中获取以下内容：
```
nameserver 1.2.3.4
@@ -367,12 +395,10 @@ search ns1.svc.cluster-domain.example my.dns.search.suffix
options ndots:2 edns0
```
<!--
For IPv6 setup, search path and name server should be setup like this:
-->
对于IPv6设置，搜索路径和名称服务器应按以下方式设置：
对于 IPv6 设置，搜索路径和名称服务器应按以下方式设置：
```shell
kubectl exec -it dns-example -- cat /etc/resolv.conf
@@ -381,8 +407,9 @@ kubectl exec -it dns-example -- cat /etc/resolv.conf
<!--
The output is similar to this:
-->
有以下输出：
```shell
输出类似于
```
nameserver fd00:79:30::a
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
options ndots:5
@@ -393,29 +420,22 @@ options ndots:5
The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
-->
### 功能的可用性
### 可用功能
Pod DNS 配置和 DNS 策略 "`None`" 的可用版本对应如下所示。
Pod DNS 配置和 DNS 策略 "`None`" 的版本对应如下所示。
| k8s version | Feature support |
| k8s 版本 | 特性支持 |
| :---------: |:-----------:|
| 1.14 | Stable |
| 1.10 | Beta (on by default)|
| 1.14 | 稳定 |
| 1.10 | Beta（默认启用） |
| 1.9 | Alpha |
## {{% heading "whatsnext" %}}
<!--
For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
-->
有关管理 DNS 配置的指导，请查看
[配置 DNS 服务](/docs/tasks/administer-cluster/dns-custom-nameservers/)
[配置 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/)
content/zh/docs/concepts/services-networking/dual-stack.md
+32 -27
View File
@@ -3,26 +3,19 @@ title: IPv4/IPv6 双协议栈
feature:
title: IPv4/IPv6 双协议栈
description: >
Allocation of IPv4 and IPv6 addresses to Pods and Services
为 Pod 和 Service 分配 IPv4 和 IPv6 地址
content_type: concept
weight: 70
---
<!--
---
reviewers:
- lachie83
- khenidak
- aramase
title: IPv4/IPv6 dual-stack
feature:
title: IPv4/IPv6 dual-stack
description: >
Allocation of IPv4 and IPv6 addresses to Pods and Services
content_type: concept
weight: 70
---
-->
<!-- overview -->
@@ -32,14 +25,15 @@ weight: 70
<!--
IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
-->
IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给 {{< glossary_tooltip text="Pods" term_id="pod" >}} 和 {{< glossary_tooltip text="Services" term_id="service" >}}。
IPv4/IPv6 双协议栈能够将 IPv4 和 IPv6 地址分配给
{{< glossary_tooltip text="Pod" term_id="pod" >}} 和
{{< glossary_tooltip text="Service" term_id="service" >}}。
<!--
If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses.
-->
如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，则该集群将支持同时分配 IPv4 和 IPv6 地址。
如果你为 Kubernetes 集群启用了 IPv4/IPv6 双协议栈网络，
则该集群将支持同时分配 IPv4 和 IPv6 地址。
<!-- body -->
@@ -89,7 +83,9 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack
<!--
To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the relevant components of your cluster, and set dual-stack cluster network assignments:
-->
要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)，并且设置双协议栈的集群网络分配：
要启用 IPv4/IPv6 双协议栈，为集群的相关组件启用 `IPv6DualStack`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
并且设置双协议栈的集群网络分配：
* kube-apiserver:
* `--feature-gates="IPv6DualStack=true"`
@@ -113,13 +109,20 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
If your cluster has IPv4/IPv6 dual-stack networking enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} with either an IPv4 or an IPv6 address. You can choose the address family for the Service's cluster IP by setting a field, `.spec.ipFamily`, on that Service.
You can only set this field when creating a new Service. Setting the `.spec.ipFamily` field is optional and should only be used if you plan to enable IPv4 and IPv6 {{< glossary_tooltip text="Services" term_id="service" >}} and {{< glossary_tooltip text="Ingresses" term_id="ingress" >}} on your cluster. The configuration of this field not a requirement for [egress](#egress-traffic) traffic.
-->
如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建 {{< glossary_tooltip text="Services" term_id="service" >}}。你可以通过设置服务的 `.spec.ipFamily` 字段来选择服务的集群 IP 的地址族。你只能在创建新服务时设置该字段。`.spec.ipFamily` 字段的设置是可选的，并且仅当你计划在集群上启用 IPv4 和 IPv6 的 {{< glossary_tooltip text="Services" term_id="service" >}} 和 {{< glossary_tooltip text="Ingresses" term_id="ingress" >}}。对于[出口](#出口流量)流量，该字段的配置不是必须的。
如果你的集群启用了 IPv4/IPv6 双协议栈网络，则可以使用 IPv4 或 IPv6 地址来创建
{{< glossary_tooltip text="Service" term_id="service" >}}。
你可以通过设置服务的 `.spec.ipFamily` 字段来选择服务的集群 IP 的地址族。
你只能在创建新服务时设置该字段。`.spec.ipFamily` 字段的设置是可选的，
并且仅当你计划在集群上启用 IPv4 和 IPv6 的 {{< glossary_tooltip text="Service" term_id="service" >}}
和 {{< glossary_tooltip text="Ingress" term_id="ingress" >}}。
对于[出口](#出口流量)流量，该字段的配置不是必须的。
<!--
The default address family for your cluster is the address family of the first service cluster IP range configured via the `--service-cluster-ip-range` flag to the kube-controller-manager.
The default address family for your cluster is the address family of the first service cluster IP range configured via the `-service-cluster-ip-range` flag to the kube-controller-manager.
-->
{{< note >}}
集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置。
集群的默认地址族是第一个服务集群 IP 范围的地址族，该地址范围通过
`kube-controller-manager` 上的 `--service-cluster-ip-range` 标志设置。
{{< /note >}}
<!--
@@ -158,12 +161,13 @@ For comparison, the following Service specification will be assigned an IPV4 add
<!--
### Type LoadBalancer
-->
### 负载均衡器类型
### LoadBalancer 类型
<!--
On cloud providers which support IPv6 enabled external load balancers, setting the `type` field to `LoadBalancer` in additional to setting `ipFamily` field to `IPv6` provisions a cloud load balancer for your Service.
-->
在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`，将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。
在支持启用了 IPv6 的外部服务均衡器的云驱动上，除了将 `ipFamily` 字段设置为 `IPv6`，
将 `type` 字段设置为 `LoadBalancer`，为你的服务提供云负载均衡。
<!--
## Egress Traffic
@@ -173,7 +177,12 @@ On cloud providers which support IPv6 enabled external load balancers, setting t
<!--
The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
-->
公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层 {{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的（比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈，所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。
公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层
{{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。
如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的
（比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。
[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈，
所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。
<!--
## Known Issues
@@ -181,19 +190,15 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac
## 已知问题
<!--
* Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr)
* Kubenet forces IPv4,IPv6 positional reporting of IPs (-cluster-cidr)
-->
* Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (--cluster-cidr)
* Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`)
## {{% heading "whatsnext" %}}
<!--
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
-->
* [验证 IPv4/IPv6 双协议栈](/docs/tasks/network/validate-dual-stack)网络
* [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络
content/zh/docs/concepts/services-networking/endpoint-slices.md
+33 -35
View File
@@ -1,9 +1,7 @@
---
reviewers:
- freehan
title: Endpoint Slices
title: 端点切片（Endpoint Slices）
feature:
title: Endpoint Slices
title: 端点切片
description: >
Kubernetes 集群中网络端点的可扩展跟踪。
@@ -12,9 +10,6 @@ weight: 10
---
<!--
---
reviewers:
- freehan
title: Endpoint Slices
feature:
title: Endpoint Slices
@@ -23,7 +18,6 @@ feature:
content_type: concept
weight: 10
---
-->
<!-- overview -->
@@ -35,9 +29,8 @@ _Endpoint Slices_ provide a simple way to track network endpoints within a
Kubernetes cluster. They offer a more scalable and extensible alternative to
Endpoints.
-->
_Endpoint Slices_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。
_端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点
（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。
<!-- body -->
@@ -55,7 +48,9 @@ Kubernetes Service.
-->
## Endpoint Slice 资源 {#endpointslice-resource}
在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。
在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。
指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。
这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。
例如，这里是 Kubernetes服务 `example` 的示例 EndpointSlice 资源。
@@ -90,7 +85,14 @@ with Endpoints and Services and have similar performance.
Endpoint Slices can act as the source of truth for kube-proxy when it comes to
how to route internal traffic. When enabled, they should provide a performance
improvement for services with large numbers of endpoints.
-->
默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个端点。
低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1:1 映射，并具有相似的性能。
当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。
启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。
<!--
## Address Types
EndpointSlices support three address types:
@@ -98,7 +100,16 @@ EndpointSlices support three address types:
* IPv4
* IPv6
* FQDN (Fully Qualified Domain Name)
-->
## 地址类型
EndpointSlice 支持三种地址类型：
* IPv4
* IPv6
* FQDN (完全合格的域名)
<!--
## Motivation
The Endpoints API has provided a simple and straightforward way of
@@ -114,38 +125,25 @@ significant amounts of network traffic and processing when Endpoints changed.
Endpoint Slices help you mitigate those issues as well as provide an extensible
platform for additional features such as topological routing.
-->
默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个 endpoints。低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1：1 映射，并具有相似的性能。
当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。
<!--
## Address Types
-->
## 地址类型
EndpointSlice 支持三种地址类型：
* IPv4
* IPv6
* FQDN (完全合格的域名)
## 动机
Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。最值得注意的是，这包含了扩展到更多网络端点的挑战。
Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。
不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。
最值得注意的是，这包含了扩展到更多网络端点的挑战。
由于服务的所有网络端点都存储在单个 Endpoints 资源中，因此这些资源可能会变得很大。这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints 发生更改时导致大量网络流量和处理。Endpoint Slices 可帮助您缓解这些问题并提供可扩展的
由于服务的所有网络端点都存储在单个 Endpoints 资源中，
因此这些资源可能会变得很大。
这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints
发生更改时导致大量网络流量和处理。
Endpoint Slices 可帮助您缓解这些问题并提供可扩展的
附加特性（例如拓扑路由）平台。
## {{% heading "whatsnext" %}}
<!--
* [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-->
* [启用 Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
* 阅读 [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
* [启用端点切片](/zh/docs/tasks/administer-cluster/enabling-endpointslices)
* 阅读[使用服务链接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
content/zh/docs/concepts/services-networking/ingress-controllers.md
+154 -133
View File
@@ -1,134 +1,155 @@
---
title: Ingress 控制器
content_type: concept
weight: 40
---
<!--
---
title: Ingress Controllers
reviewers:
content_type: concept
weight: 40
---
-->
<!-- overview -->
<!--
In order for the Ingress resource to work, the cluster must have an ingress controller running.
Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers
are not started automatically with a cluster. Use this page to choose the ingress controller implementation
that best fits your cluster.
Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
[nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
-->
为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。
基于此页面，您可选择最适合您的集群的 ingress 控制器实现。
Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md)
和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
<!-- body -->
<!--
## Additional controllers
-->
## 其他控制器
<!--
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress
controller with [community](https://www.getambassador.io/docs) or
[commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).
* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
provided and supported by VMware.
* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
* [Istio](https://istio.io/) based ingress controller
[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
[commercial](https://konghq.com/kong-enterprise/) support and maintenance for the
[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
support by [Containous](https://containo.us/services).
-->
* [AKS 应用程序网关 Ingress 控制器]使用 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用[AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。
* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress
控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自 [Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。
* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护。
* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 ingress。
* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 ingress 控制器，它由 VMware 提供和支持。
* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。
* F5 Networks 为 [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供[支持和维护](https://support.f5.com/csp/article/K86859508)。
* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。
* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、由社区驱动的 Ingress 控制器。
* [HAProxy Technologies](https://www.haproxy.com/) 为[用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress) 提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。
* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。
* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。
* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。
* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器
（[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。
<!--
## Using multiple Ingress controllers
-->
## 使用多个 Ingress 控制器
<!--
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
to indicate which ingress controller should be used if more than one exists within your cluster.
If you do not define a class, your cloud provider may use a default ingress controller.
Ideally, all ingress controllers should fulfill this specification, but the various ingress
controllers operate slightly differently.
-->
你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。
创建 ingress 时，应该使用适当的 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress
以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。
如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。
理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。
<!--
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
-->
{{< note >}}
确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
{{< /note >}}
---
title: Ingress 控制器
content_type: concept
weight: 40
---
<!--
title: Ingress Controllers
content_type: concept
weight: 40
-->
<!-- overview -->
<!--
In order for the Ingress resource to work, the cluster must have an ingress controller running.
Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers
are not started automatically with a cluster. Use this page to choose the ingress controller implementation
that best fits your cluster.
Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
[nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
-->
为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。
基于此页面，您可选择最适合您的集群的 ingress 控制器实现。
Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md)
和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。
<!-- body -->
<!--
## Additional controllers
-->
## 其他控制器
<!--
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress
controller with [community](https://www.getambassador.io/docs) or
[commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).
* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
provided and supported by VMware.
-->
* [AKS 应用程序网关 Ingress 控制器]使用
[Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用
[AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。
* [Ambassador](https://www.getambassador.io/) API 网关，一个基于 [Envoy](https://www.envoyproxy.io) 的 Ingress
控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自
[Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。
* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于
[HAProxy](https://www.haproxy.org/) 的 Ingress 控制器
[Voyager](https://appscode.com/products/voyager) 提供支持和维护。
* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)
通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 Ingress。
* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/)
的 Ingress 控制器，它由 VMware 提供和支持。
<!--
* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
* [Istio](https://istio.io/) based ingress controller
[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
-->
* Citrix 为其硬件（MPX），虚拟化（VPX）和
[免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)
提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，
用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和
[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。
* F5 Networks 为
[用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供
[支持和维护](https://support.f5.com/csp/article/K86859508)。
* [Gloo](https://gloo.solo.io) 是一个开源的基于
[Envoy](https://www.envoyproxy.io) 的 Ingress 控制器，它提供了 API 网关功能，
有着来自 [solo.io](https://www.solo.io) 的企业级支持。
* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、
由社区驱动的 Ingress 控制器。
* [HAProxy Technologies](https://www.haproxy.com/) 为
[用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress)
提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。
* 基于 [Istio](https://istio.io/) 的 ingress 控制器
[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。
<!--
* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
[commercial](https://konghq.com/kong-enterprise/) support and maintenance for the
[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
support by [Containous](https://containo.us/services).
-->
* [Kong](https://konghq.com/) 为
[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller)
提供[社区](https://discuss.konghq.com/c/kubernetes)或
[商业](https://konghq.com/kong-enterprise/)支持和维护。
* [NGINX, Inc.](https://www.nginx.com/) 为
[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
提供支持和维护。
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。
* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器
（[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），
并且它也有来自 [Containous](https://containo.us/services) 的商业支持。
<!--
## Using multiple Ingress controllers
-->
## 使用多个 Ingress 控制器
<!--
You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
to indicate which ingress controller should be used if more than one exists within your cluster.
If you do not define a class, your cloud provider may use a default ingress controller.
Ideally, all ingress controllers should fulfill this specification, but the various ingress
controllers operate slightly differently.
-->
你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。
创建 ingress 时，应该使用适当的
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
注解每个 Ingress 以表明在集群中如果有多个 Ingress 控制器时，应该使用哪个 Ingress 控制器。
如果不定义 `ingress.class`，云提供商可能使用默认的 Ingress 控制器。
理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。
<!--
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
-->
{{< note >}}
确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。
{{< /note >}}
## {{% heading "whatsnext" %}}
<!--
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
-->
* 进一步了解 [Ingress](/docs/concepts/services-networking/ingress/)。
* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。
<!--
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
-->
* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。
* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。
content/zh/docs/concepts/services-networking/ingress.md
+164 -135
View File
@@ -4,8 +4,6 @@ content_type: concept
weight: 40
---
<!--
reviewers:
- bprashanth
title: Ingress
content_type: concept
weight: 40
@@ -21,7 +19,7 @@ weight: 40
<!--
## Terminology
-->
## 专用术语
## 术语
<!--
For clarity, this guide defines the following terms:
@@ -36,10 +34,14 @@ For clarity, this guide defines the following terms:
* Service: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
-->
* 节点（Node）: Kubernetes 集群中其中一台工作机器，是集群的一部分。
* 集群（Cluster）: 一组运行程序（这些程序是容器化的，被 Kubernetes 管理的）的节点。 在此示例中，和在大多数常见的Kubernetes部署方案，集群中的节点都不会是公共网络。
* 边缘路由器（Edge router）: 在集群中强制性执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。
* 集群网络（Cluster network）: 一组逻辑或物理的链接，根据 Kubernetes [网络模型](/docs/concepts/cluster-administration/networking/) 在集群内实现通信。
* 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}} 使用 {{< glossary_tooltip text="标签" term_id="label" >}} 选择器（selectors）标识的一组 Pod。除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
* 集群（Cluster）: 一组运行由 Kubernetes 管理的容器化应用程序的节点。
在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。
* 边缘路由器（Edge router）: 在集群中强制执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。
* 集群网络（Cluster network）: 一组逻辑的或物理的连接，根据 Kubernetes
[网络模型](/zh/docs/concepts/cluster-administration/networking/) 在集群内实现通信。
* 服务（Service）：Kubernetes {{< glossary_tooltip text="服务" term_id="service" >}}使用
{{< glossary_tooltip text="标签" term_id="label" >}} 选择算符（selectors）标识的一组 Pod。
除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
<!--
## What is Ingress?
@@ -52,7 +54,8 @@ For clarity, this guide defines the following terms:
Traffic routing is controlled by rules defined on the Ingress resource.
-->
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) 公开了从集群外部到集群内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的 HTTP 和 HTTPS 路由。
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
公开了从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。
流量路由由 Ingress 资源上定义的规则控制。
```none
@@ -66,7 +69,9 @@ Traffic routing is controlled by rules defined on the Ingress resource.
<!--
An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
-->
可以将 Ingress 配置为提供服务外部可访问的 URL、负载均衡流量、终止 SSL / TLS，以及提供基于名称的虚拟主机。[Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。
可以将 Ingress 配置为服务提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及提供基于名称的虚拟主机等能力。
[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。
<!--
An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
@@ -74,23 +79,27 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
-->
Ingress 不会公开任意端口或协议。
将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 或者 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 类型的服务。
将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用
[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport)
或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer)
类型的服务。
<!--
## Prerequisites
You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
-->
## 环境准备
<!--
You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
-->
您必须具有 [ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。仅创建 Ingress 资源无效。
你必须具有 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。
仅创建 Ingress 资源本身没有任何效果。
<!--
You may need to deploy an Ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). You can choose from a number of
[Ingress controllers](/docs/concepts/services-networking/ingress-controllers).
-->
您可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。您可以从许多[Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 中进行选择。
你可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。
你可以从许多 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 中进行选择。
<!--
Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress
@@ -107,12 +116,11 @@ Make sure you review your Ingress controller's documentation to understand the c
<!--
## The Ingress Resource
A minimal Ingress resource example:
-->
## Ingress 资源
<!--
A minimal Ingress resource example:
-->
一个最小的 Ingress 资源示例：
```yaml
@@ -144,10 +152,14 @@ Different [Ingress controller](/docs/concepts/services-networking/ingress-contro
your choice of Ingress controller to learn which annotations are supported.
-->
与所有其他 Kubernetes 资源一样，Ingress 需要使用 `apiVersion`、`kind` 和 `metadata` 字段。
Ingress 对象的命名必须是合法的 [DNS 子域名名称](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
有关使用配置文件的一般信息，请参见[部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)、 [配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[管理资源](/docs/concepts/cluster-administration/manage-deployment/)。
Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如 [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。
不同的 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 支持不同的注解（annotations）。查看文档以供您选择 Ingress 控制器，以了解支持哪些注解（annotations）。
Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
有关使用配置文件的一般信息，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、
[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。
Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如
[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。
不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
支持不同的注解。查看文档以供您选择 Ingress 控制器，以了解支持哪些注解。
<!--
The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
@@ -155,12 +167,15 @@ has all the information needed to configure a load balancer or proxy server. Mos
contains a list of rules matched against all incoming requests. Ingress resource only supports rules
for directing HTTP traffic.
-->
Ingress [规范](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 具有配置负载均衡器或者代理服务器所需的所有信息。最重要的是，它包含与所有传入请求匹配的规则列表。Ingress 资源仅支持用于定向 HTTP 流量的规则。
Ingress [规约](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
提供了配置负载均衡器或者代理服务器所需的所有信息。
最重要的是，其中包含与所有传入请求匹配的规则列表。
Ingress 资源仅支持用于转发 HTTP 流量的规则。
<!--
### Ingress rules
-->
### Ingress 规则
### Ingress 规则 {#ingress-rules}
<!--
Each HTTP rule contains the following information:
@@ -178,43 +193,46 @@ Each HTTP rule contains the following information:
[Service doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
Ingress that matches the host and path of the rule are sent to the listed backend.
-->
* 可选主机。在此示例中，未指定主机，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。如果提供了主机（例如 foo.bar.com），则规则适用于该主机。
* 路径列表（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
* 后端是 [Service 文档](/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。与规则的主机和路径匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的后端。
* 可选主机。在此示例中，未指定主机，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。
如果提供了主机（例如 foo.bar.com），则规则适用于该主机。
* 路径列表（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。
在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
* 后端是 [Service 文档](/zh/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
与规则的主机和路径匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的后端。
<!--
A default backend is often configured in an Ingress controller to service any requests that do not
match a path in the spec.
-->
通常在 Ingress 控制器中配置默认后端，以服务任何不符合规范中路径的请求。
通常在 Ingress 控制器中会配置默认后端，以服务任何不符合规范中路径的请求。
<!--
### Default Backend
-->
### 默认后端
<!--
An Ingress with no rules sends all traffic to a single default backend. The default
backend is typically a configuration option of the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) and is not specified in your Ingress resources.
-->
没有规则的 Ingress 将所有流量发送到单个默认后端。默认后端通常是 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers)的配置选项，并且未在 Ingress 资源中指定。
### 默认后端
没有规则的 Ingress 将所有流量发送到同一个默认后端。
默认后端通常是 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
的配置选项，并且未在 Ingress 资源中指定。
<!--
If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is
routed to your default backend.
-->
如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。
如果主机或路径都没有与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到默认后端。
<!--
### Path Types
-->
### 路径类型
<!--
Each path in an Ingress has a corresponding path type. There are three supported
path types:
-->
Ingress 中的每个路径都有对应的路径类型。支持三种类型：
-->
### 路径类型 {#path-types}
Ingress 中的每个路径都有对应的路径类型。当前支持的路径类型有三种：
<!--
* _`ImplementationSpecific`_ (default): With this path type, matching is up to
@@ -232,14 +250,19 @@ Ingress 中的每个路径都有对应的路径类型。支持三种类型：
last element in request path, it is not a match (for example:
`/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
-->
* _`ImplementationSpecific`_ （默认）：对于这种类型，匹配取决于 IngressClass. 具体实现可以将其作为单独的 `pathType` 处理或者与 `Prefix` 或 `Exact` 类型作相同处理。
* _`ImplementationSpecific`_ （默认）：对于这种类型，匹配取决于 IngressClass。
具体实现可以将其作为单独的 `pathType` 处理或者与 `Prefix` 或 `Exact` 类型作相同处理。
* _`Exact`_：精确匹配 URL 路径且对大小写敏感。
* _`Exact`_：精确匹配 URL 路径，且对大小写敏感。
* _`Prefix`_：基于以 `/` 分割的 URL 路径前缀匹配。匹配对大小写敏感，并且对路径中的元素逐个完成。路径元素指的是由 `/` 分隔符分割的路径中的标签列表。如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。
{{< note >}}
如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配（例如：`/foo/bar` 匹配 `/foo/bar/baz`, 但不匹配 `/foo/barbaz`）。
{{< /note >}}
* _`Prefix`_：基于以 `/` 分隔的 URL 路径前缀匹配。匹配对大小写敏感，并且对路径中的元素逐个完成。
路径元素指的是由 `/` 分隔符分隔的路径中的标签列表。
如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。
{{< note >}}
如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配
（例如：`/foo/bar` 匹配 `/foo/bar/baz`, 但不匹配 `/foo/barbaz`）。
{{< /note >}}
<!--
#### Multiple Matches
@@ -248,22 +271,25 @@ cases precedence will be given first to the longest matching path. If two paths
are still equally matched, precedence will be given to paths with an exact path
type over prefix path type.
-->
#### 多重匹配
#### 多重匹配 {#multiple-matches}
在某些情况下，Ingress 中的多条路径会匹配同一个请求。这种情况下最长的匹配路径优先。如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。
在某些情况下，Ingress 中的多条路径会匹配同一个请求。
这种情况下最长的匹配路径优先。
如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。
<!--
## Ingress Class
-->
## Ingress 类
<!--
Ingresses can be implemented by different controllers, often with different
configuration. Each Ingress should specify a class, a reference to an
IngressClass resource that contains additional configuration including the name
of the controller that should implement the class.
-->
Ingress 可以由不同的控制器实现，通常使用不同的配置。每个 Ingress 应当指定一个类，一个对 IngressClass 资源的引用，该资源包含额外的配置，其中包括应当实现该类的控制器名称。
-->
## Ingress 类 {#ingress-class}
Ingress 可以由不同的控制器实现，通常使用不同的配置。
每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。
IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。
```yaml
apiVersion: networking.k8s.io/v1beta1
@@ -282,21 +308,21 @@ spec:
IngressClass resources contain an optional parameters field. This can be used to
reference additional configuration for this class.
-->
IngressClass 资源包含一个可选的参数字段。可用于引用该类的额外配置。
IngressClass 资源包含一个可选的参数字段，可用于为该类引用额外配置。
<!--
### Deprecated Annotation
-->
### 废弃的注解
<!--
Before the IngressClass resource and `ingressClassName` field were added in
Kubernetes 1.18, Ingress classes were specified with a
`kubernetes.io/ingress.class` annotation on the Ingress. This annotation was
never formally defined, but was widely supported by Ingress controllers.
-->
在 IngressClass 资源和 `ingressClassName` 字段被引入 Kubernetes 1.18 之前，Ingress 类是通过 Ingress 中的一个
`kubernetes.io/ingress.class` 注解来指定的。这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。
-->
### 废弃的注解
在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前，
Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。
这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。
<!--
The newer `ingressClassName` field on Ingresses is a replacement for that
@@ -304,22 +330,26 @@ annotation, but is not a direct equivalent. While the annotation was generally
used to reference the name of the Ingress controller that should implement the
Ingress, the field is a reference to an IngressClass resource that contains
additional Ingress configuration, including the name of the Ingress controller.
-->
Ingress 中新的 `ingressClassName` 字段是该注解的替代品，但并非完全等价。该注解通常用于引用实现该 Ingress 的控制器的名称，
而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用，包括 Ingress 控制器的名称。
-->
Ingress 中新的 `ingressClassName` 字段是该注解的替代品，但并非完全等价。
该注解通常用于引用实现该 Ingress 的控制器的名称，
而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用，
包括 Ingress 控制器的名称。
<!--
### Default Ingress Class
-->
### 默认 Ingress 类
<!--
You can mark a particular IngressClass as default for your cluster. Setting the
`ingressclass.kubernetes.io/is-default-class` annotation to `true` on an
IngressClass resource will ensure that new Ingresses without an
`ingressClassName` field specified will be assigned this default IngressClass.
-->
您可以将一个特定的 IngressClass 标记为集群默认项。将一个 IngressClass 资源的 `ingressclass.kubernetes.io/is-default-class` 注解设置为 `true` 将确保新的未指定 `ingressClassName` 字段的 Ingress 能够分配为这个默认的 IngressClass.
-->
### 默认 Ingress 类 {#default-ingress-class}
您可以将一个特定的 IngressClass 标记为集群默认选项。
将一个 IngressClass 资源的 `ingressclass.kubernetes.io/is-default-class` 注解设置为
`true` 将确保新的未指定 `ingressClassName` 字段的 Ingress 能够分配为这个默认的
IngressClass.
<!--
If you have more than one IngressClass marked as the default for your cluster,
@@ -328,26 +358,26 @@ an `ingressClassName` specified. You can resolve this by ensuring that at most 1
IngressClasess are marked as default in your cluster.
-->
{{< caution >}}
如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 `ingressClassName` 字段的 Ingress 对象。
如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 `ingressClassName`
的 Ingress 对象。
解决这个问题只需确保集群中最多只能有一个 IngressClass 被标记为默认。
{{< /caution >}}
<!--
## Types of Ingress
-->
## Ingress 类型
<!--
### Single Service Ingress
-->
### 单服务 Ingress
<!--
There are existing Kubernetes concepts that allow you to expose a single Service
(see [alternatives](#alternatives)). You can also do this with an Ingress by specifying a
*default backend* with no rules.
-->
现有的 Kubernetes 概念允许您暴露单个 Service (查看[替代方案](#alternatives))，您也可以通过指定无规则的 *默认后端* 来对 Ingress 进行此操作。
## Ingress 类型 {#types-of-ingress}
### 单服务 Ingress {#single-service-ingress}
现有的 Kubernetes 概念允许您暴露单个 Service (查看[替代方案](#alternatives))。
你也可以通过指定无规则的 *默认后端* 来对 Ingress 进行此操作。
{{< codenew file="service/networking/ingress.yaml" >}}
@@ -377,19 +407,19 @@ Ingress controllers and load balancers may take a minute or two to allocate an I
Until that time, you often see the address listed as `<pending>`.
-->
{{< note >}}
入口控制器和负载平衡器可能需要一两分钟才能分配IP地址。 在此之前，您通常会看到地址字段的值被设定为 `<pending>`。
入口控制器和负载平衡器可能需要一两分钟才能分配 IP 地址。在此之前，您通常会看到地址字段的值被设定为
`<pending>`。
{{< /note >}}
<!--
### Simple fanout
-->
### 简单分列
<!--
A fanout configuration routes traffic from a single IP address to more than one Service,
based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
down to a minimum. For example, a setup like:
-->
### 简单分列
一个分列配置根据请求的 HTTP URI 将流量从单个 IP 地址路由到多个服务。
Ingress 允许您将负载均衡器的数量降至最低。例如，这样的设置：
@@ -401,7 +431,7 @@ foo.bar.com -> 178.91.123.132 -> / foo service1:4200
<!--
would require an Ingress such as:
-->
将需要一个 Ingress，例如：
将需要一个如下所示的 Ingress：
```yaml
apiVersion: networking.k8s.io/v1beta1
@@ -428,7 +458,7 @@ spec:
<!--
When you create the Ingress with `kubectl apply -f`:
-->
当您使用 `kubectl apply -f` 创建 Ingress 时：
当你使用 `kubectl apply -f` 创建 Ingress 时：
```shell
kubectl describe ingress simple-fanout-example
@@ -459,9 +489,8 @@ that satisfies the Ingress, as long as the Services (`service1`, `service2`) exi
When it has done so, you can see the address of the load balancer at the
Address field.
-->
Ingress 控制器将提供实现特定的负载均衡器来满足 Ingress，只要 Service (`service1`，`service2`) 存在。
当它这样做了，您会在地址栏看到负载均衡器的地址。
当它这样做了，你会在地址字段看到负载均衡器的地址。
<!--
Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers)
@@ -469,19 +498,18 @@ you are using, you may need to create a default-http-backend
[Service](/docs/concepts/services-networking/service/).
-->
{{< note >}}
根据您使用的 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers)，您可能需要创建默认 HTTP 后端 [Service](/docs/concepts/services-networking/service/)。
取决于你使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)，
你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。
{{< /note >}}
<!--
### Name based virtual hosting
Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
-->
### 基于名称的虚拟托管
<!--
Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
-->
基于名称的虚拟主机支持将 HTTP 流量路由到同一 IP 地址上的多个主机名。
基于名称的虚拟主机支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上。
```none
foo.bar.com --| |-> foo.bar.com service1:80
@@ -489,12 +517,12 @@ foo.bar.com --| |-> foo.bar.com service1:80
bar.foo.com --| |-> bar.foo.com service2:80
```
<!--
The following Ingress tells the backing load balancer to route requests based on
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
-->
以下 Ingress 让后台负载均衡器基于[主机 header](https://tools.ietf.org/html/rfc7230#section-5.4) 路由请求。
以下 Ingress 让后台负载均衡器基于[host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4)
来路由请求。
```yaml
apiVersion: networking.k8s.io/v1beta1
@@ -522,7 +550,8 @@ If you create an Ingress resource without any hosts defined in the rules, then a
web traffic to the IP address of your Ingress controller can be matched without a name based
virtual host being required.
-->
如果您创建的 Ingress 资源没有规则中定义的任何主机，则可以匹配到您 Ingress 控制器 IP 地址的任何网络流量，而无需基于名称的虚拟主机。
如果您创建的 Ingress 资源没有规则中定义的任何主机，则可以匹配指向 Ingress 控制器 IP 地址
的任何网络流量，而无需基于名称的虚拟主机。
<!--
For example, the following Ingress resource will route traffic
@@ -530,7 +559,9 @@ requested for `first.bar.com` to `service1`, `second.foo.com` to `service2`, and
to the IP address without a hostname defined in request (that is, without a request header being
presented) to `service3`.
-->
例如，以下 Ingress 资源会将 `first.bar.com` 请求的流量路由到 `service1`，将 `second.foo.com` 请求的流量路由到 `service2`，而没有在请求中定义主机名的 IP 地址的流量路由（即，不提供请求标头）到 `service3`。
例如，以下 Ingress 资源会将 `first.bar.com` 请求的流量路由到 `service1`，
将 `second.foo.com` 请求的流量路由到 `service2`，
而没有在请求中定义主机名的 IP 地址的流量路由（即，不提供请求标头）到 `service3`。
```yaml
apiVersion: networking.k8s.io/v1beta1
@@ -560,11 +591,7 @@ spec:
<!--
### TLS
-->
### TLS
<!--
You can secure an Ingress by specifying a {{< glossary_tooltip term_id="secret" >}}
that contains a TLS private key and certificate. Currently the Ingress only
supports a single TLS port, 443, and assumes TLS termination. If the TLS
@@ -574,12 +601,16 @@ SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret
must contain keys named `tls.crt` and `tls.key` that contain the certificate
and private key to use for TLS. For example:
-->
### TLS
您可以通过指定包含 TLS 私钥和证书的 secret {{< glossary_tooltip term_id="secret" >}} 来加密 Ingress。
你可以通过设定包含 TLS 私钥和证书的{{< glossary_tooltip text="Secret" term_id="secret" >}}
来保护 Ingress。
目前，Ingress 只支持单个 TLS 端口 443，并假定 TLS 终止。
如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。
TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的密钥，这些密钥包含用于 TLS 的证书和私钥，例如：
如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名
（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。
TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的键名。
这些数据包含用于 TLS 的证书和私钥。例如：
```yaml
apiVersion: v1
@@ -599,7 +630,9 @@ secure the channel from the client to the load balancer using TLS. You need to m
sure the TLS secret you created came from a certificate that contains a Common
Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `sslexample.foo.com`.
-->
在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。您需要确保创建的 TLS secret 来自包含 `sslexample.foo.com` 的公用名称（CN）的证书，也被称为全限定域名（FQDN）。
在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道。
你需要确保创建的 TLS Secret 来自包含 `sslexample.foo.com` 的公用名称（CN）的证书。
这里的公共名称也被称为全限定域名（FQDN）。
```yaml
apiVersion: networking.k8s.io/v1beta1
@@ -629,17 +662,15 @@ controllers. Please refer to documentation on
platform specific Ingress controller to understand how TLS works in your environment.
-->
{{< note >}}
各种 Ingress 控制器所支持的 TLS 功能之间存在差异。请参阅有关文件
各种 Ingress 控制器所支持的 TLS 功能之间存在差异。请参阅有关
[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)、
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) 或者任何其他平台特定的 Ingress 控制器，以了解 TLS 如何在您的环境中工作。
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)
或者任何其他平台特定的 Ingress 控制器的文档，以了解 TLS 如何在你的环境中工作。
{{< /note >}}
<!--
### Loadbalancing
-->
### 负载均衡
<!--
An Ingress controller is bootstrapped with some load balancing policy settings
that it applies to all Ingress, such as the load balancing algorithm, backend
weight scheme, and others. More advanced load balancing concepts
@@ -647,32 +678,36 @@ weight scheme, and others. More advanced load balancing concepts
Ingress. You can instead get these features through the load balancer used for
a Service.
-->
### 负载均衡
Ingress 控制器使用一些适用于所有 Ingress 的负载均衡策略设置进行自举，例如负载均衡算法、后端权重方案和其他等。更高级的负载均衡概念（例如，持久会话、动态权重）尚未通过 Ingress 公开。您可以通过用于服务的负载均衡器来获取这些功能。
Ingress 控制器启动引导时使用一些适用于所有 Ingress 的负载均衡策略设置，
例如负载均衡算法、后端权重方案和其他等。
更高级的负载均衡概念（例如持久会话、动态权重）尚未通过 Ingress 公开。
你可以通过用于服务的负载均衡器来获取这些功能。
<!--
It's also worth noting that even though health checks are not exposed directly
through the Ingress, there exist parallel concepts in Kubernetes such as
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
that allow you to achieve the same end result. Please review the controller
specific documentation to see how they handle health checks (
[nginx](https://git.k8s.io/ingress-nginx/README.md),
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
-->
值得注意的是，即使健康检查不是通过 Ingress 直接暴露的，但是在 Kubernetes 中存在并行概念，比如 [就绪检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，它允许您实现相同的最终结果。
请检查控制器特殊说明文档，以了解他们是怎样处理健康检查的 (
值得注意的是，即使健康检查不是通过 Ingress 直接暴露的，在 Kubernetes
中存在并行概念，比如[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
允许你实现相同的目的。
请检查特定控制器的说明文档，以了解它们是怎样处理健康检查的 (
[nginx](https://git.k8s.io/ingress-nginx/README.md)，
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
<!--
## Updating an Ingress
To update an existing Ingress to add a new Host, you can update it by editing the resource:
-->
## 更新 Ingress
<!--
To update an existing Ingress to add a new Host, you can update it by editing the resource:
-->
要更新现有的 Ingress 以添加新的 Host，可以通过编辑资源来对其进行更新：
```shell
@@ -705,8 +740,7 @@ kubectl edit ingress test
This pops up an editor with the existing configuration in YAML format.
Modify it to include the new Host:
-->
这将弹出具有 YAML 格式的现有配置的编辑器。
这一命令将打开编辑器，允许你以 YAML 格式编辑现有配置。
修改它来增加新的主机：
```yaml
@@ -768,45 +802,42 @@ Events:
<!--
You can achieve the same outcome by invoking `kubectl replace -f` on a modified Ingress YAML file.
-->
您可以通过 `kubectl replace -f` 命令调用修改后的 Ingress yaml 文件来获得同样的结果。
你也可以通过 `kubectl replace -f` 命令调用修改后的 Ingress yaml 文件来获得同样的结果。
<!--
## Failing across availability zones
-->
## 跨可用区失败
<!--
Techniques for spreading traffic across failure domains differs between cloud providers.
Please check the documentation of the relevant [Ingress controller](/docs/concepts/services-networking/ingress-controllers) for details. You can also refer to the [federation documentation](https://github.com/kubernetes-sigs/federation-v2)
for details on deploying Ingress in a federated cluster.
-->
## 跨可用区失败 {#failing-across-availability-zones}
用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。
请查看相关[ Ingress 控制器](/docs/concepts/services-networking/ingress-controllers) 的文档以了解详细信息。
您还可以参考[联邦文档](https://github.com/kubernetes-sigs/federation-v2)，以获取有关在联合集群中部署 Ingress 的详细信息。
不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。
请查看相关[ Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 的文档以了解详细信息。
你还可以参考[联邦文档](https://github.com/kubernetes-sigs/federation-v2)，以获取有关在联合集群中部署 Ingress 的详细信息。
<!--
## Future Work
-->
## 未来工作
<!--
Track [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
for more details on the evolution of Ingress and related resources. You may also track the
[Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the
evolution of various Ingress controllers.
-->
跟踪 [SIG 网络](https://github.com/kubernetes/community/tree/master/sig-network)以获得有关 Ingress 和相关资源演变的更多细节。您还可以跟踪 [Ingress 仓库](https://github.com/kubernetes/ingress/tree/master)以获取有关各种 Ingress 控制器的更多细节。
## 未来工作
跟踪 [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
的活动以获得有关 Ingress 和相关资源演变的更多细节。
你还可以跟踪 [Ingress 仓库](https://github.com/kubernetes/ingress/tree/master)
以获取有关各种 Ingress 控制器的更多细节。
<!--
## Alternatives
-->
## 替代方案
<!--
You can expose a Service in multiple ways that don't directly involve the Ingress resource:
-->
## 替代方案 {#alternatives}
不直接使用 Ingress 资源，也有多种方法暴露 Service：
<!--
@@ -816,8 +847,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* 使用 [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* 使用 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
## {{% heading "whatsnext" %}}
<!--
@@ -825,7 +854,7 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
-->
* 了解更多 [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
* 了解更多 [Ingress 控制器](/docs/concepts/services-networking/ingress-controllers/)
* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)
* 进一步了解 [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)
content/zh/docs/concepts/services-networking/network-policies.md
+21 -25
View File
@@ -5,16 +5,10 @@ weight: 50
---
<!--
---
reviewers:
- thockin
- caseydavenport
- danwinship
title: Network Policies
content_type: concept
weight: 50
---
-->
-->
{{< toc >}}
@@ -30,8 +24,6 @@ NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}
NetworkPolicy 资源使用 {{< glossary_tooltip text="标签" term_id="label">}} 选择 Pod，并定义选定 Pod 所允许的通信规则。
<!-- body -->
<!--
@@ -42,7 +34,9 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k
## 前提
网络策略通过[网络插件](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。
网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。
创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。
<!--
## Isolated and Non-isolated Pods
@@ -53,14 +47,17 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is
Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
-->
## 隔离和非隔离的 Pod
默认情况下，Pod 是非隔离的，它们接受任何来源的流量。
Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，该 Pod 会拒绝网络策略所不允许的连接。 (命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量)
Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod，
该 Pod 会拒绝网络策略所不允许的连接。
（命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量）
网络策略不会冲突，它们是附加的。如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。
网络策略不会冲突，它们是累积的。
如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的
ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。
<!--
## The NetworkPolicy resource {#networkpolicy-resource}
@@ -72,7 +69,7 @@ An example NetworkPolicy might look like this:
## NetworkPolicy 资源 {#networkpolicy-resource}
查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。
查看 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。
下面是一个 NetworkPolicy 的示例:
@@ -138,8 +135,9 @@ __ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules.
__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
-->
__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 `kind` 和 `metadata` 字段。 关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/docs/tasks/configure-pod-container/configure-pod-configmap/),
和 [对象管理](/docs/concepts/overview/working-with-objects/object-management)。
__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、`kind` 和 `metadata` 字段。
关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/),
和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。
__spec__: NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 中包含了在一个命名空间中定义特定网络策略所需的所有信息。
@@ -175,7 +173,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-
* IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16）
3. （Egress 规则）允许从带有 "role=db" 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。
查看 [声明网络策略](/docs/getting-started-guides/network-policy/walkthrough) 来进行更多的示例演练。
查看[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练。
<!--
## Behavior of `to` and `from` selectors
@@ -362,7 +360,9 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will
To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.
When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.
-->
要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…` 来启用 `SCTPSupport` [特性开关](/docs/reference/command-line-tools-reference/feature-gates/)。启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…`
来启用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
<!--
You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
@@ -371,20 +371,16 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha
必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
{{< /note >}}
## {{% heading "whatsnext" %}}
<!--
- See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
walkthrough for further examples.
- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
-->
- 查看 [声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/)
- 查看 [声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
来进行更多的示例演练
- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见 [指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。
- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见
[此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。
content/zh/docs/concepts/services-networking/service.md
+365 -338
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/concepts/storage/dynamic-provisioning.md
+6 -14
View File
@@ -4,16 +4,9 @@ content_type: concept
weight: 40
---
<!--
---
reviewers:
- saad-ali
- jsafrane
- thockin
- msau42
title: Dynamic Volume Provisioning
content_type: concept
weight: 40
---
-->
<!-- overview -->
@@ -29,11 +22,9 @@ automatically provisions storage when it is requested by users.
-->
动态卷供应允许按需创建存储卷。
如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。
然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
<!-- body -->
<!--
@@ -66,12 +57,12 @@ have the ability to select from multiple storage options.
More information on storage classes can be found
[here](/docs/concepts/storage/storage-classes/).
-->
点击[这里](/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
<!--
## Enabling Dynamic Provisioning
-->
## 启用动态卷供应
## 启用动态卷供应 {#enabling-dynamic-provisioning}
<!--
To enable dynamic provisioning, a cluster administrator needs to pre-create
@@ -208,6 +199,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
-->
在[多区域](/docs/setup/multiple-zones)集群中，Pod 可以被分散到多个区域。
在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
单区域存储后端应该被供应到 Pod 被调度到的区域。
这可以通过设置[卷绑定模式](/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
content/zh/docs/concepts/storage/storage-classes.md
+91 -55
View File
@@ -1,14 +1,15 @@
---
reviewers:
- jsafrane
- saad-ali
- thockin
- msau42
title: Storage Classes
title: 存储类
content_type: concept
weight: 30
---
<!--
title: Storage Classes
content_type: concept
weight: 30
-->
<!-- overview -->
<!--
@@ -16,10 +17,8 @@ This document describes the concept of a StorageClass in Kubernetes. Familiarity
with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
-->
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/docs/concepts/storage/volumes/) 和
[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
<!-- body -->
@@ -67,7 +66,8 @@ request any particular class to bind to: see the
for details.
-->
管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
更多详情请参阅
[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
```yaml
apiVersion: storage.k8s.io/v1
@@ -134,7 +134,8 @@ the specification. Some external provisioners are listed under the repository
[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
-->
您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。
您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的
[规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。
外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。
代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
包含一个用于为外部分配器编写功能实现的类库。可以通过下面的代码仓库，查看外部分配器列表。
@@ -182,7 +183,6 @@ allows the users to resize the volume by editing the corresponding PVC object.
The following types of volumes support volume expansion, when the underlying
Storage Class has the field `allowVolumeExpansion` set to true.
-->
PersistentVolume 可以配置为可扩展。将此功能设置为 `true` 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。
当基础存储类的 `allowVolumeExpansion` 字段设置为 true 时，以下类型的卷支持卷扩展。
@@ -207,10 +207,10 @@ Volume type | Required Kubernetes version
{{< /table >}}
{{< note >}}
<!--
You can only use the volume expansion feature to grow a Volume, not to shrink it.
-->
{{< note >}}
此功能仅可用于扩容卷，不能用于缩小卷。
{{< /note >}}
@@ -240,7 +240,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
The `volumeBindingMode` field controls when [volume binding and dynamic
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
-->
`volumeBindingMode` 字段控制了 [卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
`volumeBindingMode` 字段控制了[卷绑定和动态分配](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
应该发生在什么时候。
<!--
@@ -266,10 +266,11 @@ and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration).
-->
集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。
该模式将延迟 PersistentVolume 的绑定和分配，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于 [资源需求](/docs/concepts/configuration/manage-compute-resources-container)，
[节点筛选器](/docs/concepts/configuration/assign-pod-node/#nodeselector)，
[pod 亲和性和互斥性](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
以及 [污点和容忍度](/docs/concepts/configuration/taint-and-toleration).
PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于
[资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、
[节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、
[pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、
以及[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
<!--
The following plugins support `WaitForFirstConsumer` with dynamic provisioning:
@@ -302,14 +303,13 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
to see its supported topology keys and examples.
-->
动态配置和预先创建的 PV 也支持 [CSI卷](/docs/concepts/storage/volumes/#csi)，
动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)，
但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
<!--
### Allowed Topologies
-->
### 允许的拓扑结构
### 允许的拓扑结构 {#allowed-topologies}
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
<!--
@@ -402,14 +402,22 @@ parameters:
encrypting the volume. If none is supplied but `encrypted` is true, a key is
generated by AWS. See AWS docs for valid ARN value.
-->
* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。
* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。
* `zones`(弃用)：以逗号分隔的 AWS 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，并将其限制在 20 000 IOPS（AWS 支持的最高值，请参阅 [AWS 文档](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。
* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见
[AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。
* `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，
通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。
* `zones`(弃用)：以逗号分隔的 AWS 区域列表。
如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
* `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。
AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，
并将其限制在 20000 IOPS（AWS 支持的最高值，请参阅
[AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。
这里需要输入一个字符串，即 `"10"`，而不是 `10`。
* `fsType`：受 Kubernetes 支持的文件类型。默认值：`"ext4"`。
* `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。这里需要输入字符串，即 `"true"`, 而非 `true`。
* `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。
* `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。
这里需要输入字符串，即 `"true"`, 而非 `true`。
* `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。
如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。
{{< note >}}
<!--
@@ -445,8 +453,12 @@ parameters:
* `replication-type`: `none` or `regional-pd`. Default: `none`.
-->
* `type`：`pd-standard` 或者 `pd-ssd`。默认：`pd-standard`
* `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。
* `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。`zone` 和 `zones` 参数不能同时使用。
* `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常
卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
`zone` 和 `zones` 参数不能同时使用。
* `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`，
通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。
`zone` 和 `zones` 参数不能同时使用。
* `fstype`: `ext4` 或 `xfs`。 默认: `ext4`。宿主机操作系统必须支持所定义的文件系统类型。
* `replication-type`：`none` 或者 `regional-pd`。默认值：`none`。
@@ -465,14 +477,18 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the
`zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
managed by the cluster.
-->
如果 `replication-type` 设置为 `regional-pd`，会分配一个 [区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。
{{< note >}}
如果 `replication-type` 设置为 `regional-pd`，会分配一个
[区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。
在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。
如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。
如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。
如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。
<!--
`zone` and `zones` parameters are deprecated and replaced with
[allowedTopologies](#allowed-topologies)
-->
{{< note >}}
`zone` 和 `zones` 已被弃用并被 [allowedTopologies](#allowed-topologies) 取代。
{{< /note >}}
@@ -516,11 +532,14 @@ parameters:
-->
* `resturl`：分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态分配器的必需参数。
如果 Heketi 服务在 openshift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于
如果 Heketi 服务在 OpenShift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于
`http://heketi-storage-project.cloudapps.mystorage.com` 的格式，其中 fqdn 是可解析的 heketi 服务网址。
* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。此选项已弃用，当在指定 `restuser`，`restuserkey`，`secretName` 或 `secretNamespace` 时，身份验证被启用。
* `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。
如果此值为 'true'，则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。
此选项已弃用，当在指定 `restuser`、`restuserkey`、`secretName` 或 `secretNamespace` 时，身份验证被启用。
* `restuser`：在 Gluster 可信池中有权创建卷的 Gluster REST服务/Heketi 用户。
* `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。
* `restuserkey`：Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。
此参数已弃用，取而代之的是 `secretNamespace` + `secretName`。
<!--
* `secretNamespace`, `secretName` : Identification of Secret instance that
@@ -539,7 +558,8 @@ parameters:
[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
-->
* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster REST 服务交互时使用的用户密码。
这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建：
这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。
所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建：
```
kubectl create secret generic heketi-secret \
@@ -547,7 +567,7 @@ parameters:
--namespace=default
```
secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。
Secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。
<!--
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster
@@ -561,9 +581,12 @@ parameters:
specified, the volume will be provisioned with a value between 2000-2147483647
which are defaults for gidMin and gidMax respectively.
-->
* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如：
* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，
Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如：
`"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。
* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。
* `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。
在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。
如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。
<!--
* `volumetype` : The volume type and its parameters can be configured with this
@@ -587,17 +610,17 @@ parameters:
deleted when the persistent volume claim is deleted.
-->
* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由分配器决定卷的类型。
例如：
例如：
'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
'Distribute volume': `volumetype: none`
* 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
* 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
* 'Distribute volume': `volumetype: none`
有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。
当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。
### OpenStack Cinder
@@ -674,7 +697,11 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
specified in the vSphere config file used to initialize the vSphere Cloud
Provider.
-->
`datastore`：用户也可以在 StorageClass 中指定数据存储。卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。该字段是可选的。如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 配置文件中指定的数据存储上创建该卷。
`datastore`：用户也可以在 StorageClass 中指定数据存储。
卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
该字段是可选的。
如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere
配置文件中指定的数据存储上创建该卷。
<!--
3. Storage Policy Management inside kubernetes
@@ -697,7 +724,10 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
-->
* 使用现有的 vCenter SPBM 策略
vSphere 用于存储管理的最重要特性之一是基于策略的管理。基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的跨越广泛的数据服务和存储解决方案。 SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
vSphere 用于存储管理的最重要特性之一是基于策略的管理。
基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
跨越广泛的数据服务和存储解决方案。
SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。
@@ -719,7 +749,10 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
-->
* Kubernetes 内的 Virtual SAN 策略支持
Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN 存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。存储功能需求会转换为 Virtual SAN 策略，然后当 persistent volume（虚拟磁盘）在创建时，会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。
存储功能需求会转换为 Virtual SAN 策略，然后当持久卷（虚拟磁盘）在创建时，
会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
更多有关 persistent volume 管理的存储策略的详细信息，
您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。
@@ -955,7 +988,8 @@ parameters:
* `kind`：可能的值是 `shared`（默认）、`dedicated` 和 `managed`。
当 `kind` 的值是 `shared` 时，所有非托管磁盘都在集群的同一个资源组中的几个共享存储帐户中创建。
当 `kind` 的值是 `dedicated` 时，将为在集群的同一个资源组中新的非托管磁盘创建新的专用存储帐户。
* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。
* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。
若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。
<!--
- Premium VM can attach both Standard_LRS and Premium_LRS disks, while Standard
VM can only attach Standard_LRS disks.
@@ -1015,7 +1049,8 @@ mounting credentials. If the cluster has enabled both
add the `create` permission of resource `secret` for clusterrole
`system:controller:persistent-volume-binder`.
-->
在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 secret。如果集群同时启用了 [RBAC](/docs/admin/authorization/rbac/) 和 [Controller Roles](/docs/admin/authorization/rbac/#controller-roles)，
在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。
<!--
@@ -1075,7 +1110,8 @@ parameters:
* `aggregation_level`：指定卷分配到的块数量，0 表示一个非聚合卷（默认：`0`）。
这里需要填写字符串，即，是 `"0"` 而不是 `0`。
* `ephemeral`：指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true ，
`persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）`true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
`persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）
`true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
### ScaleIO
@@ -1136,8 +1172,8 @@ secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的 PVC
```shell
kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
--from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \
--namespace=default
--from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \
--namespace=default
```
### StorageOS
content/zh/docs/concepts/storage/volume-pvc-datasource.md
+24 -35
View File
@@ -5,16 +5,9 @@ weight: 30
---
<!--
---
reviewers:
- jsafrane
- saad-ali
- thockin
- msau42
title: CSI Volume Cloning
content_type: concept
weight: 30
---
-->
<!-- overview -->
@@ -22,42 +15,40 @@ weight: 30
<!--
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
-->
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/docs/concepts/storage/volumes)。
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/zh/docs/concepts/storage/volumes)。
<!-- body -->
<!--
## Introduction
The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}.
-->
## 介绍
<!--
The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}.
-->
{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 `dataSource` 字段中指定存在的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。
{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在
`dataSource` 字段中指定存在的
{{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}，
来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。
<!--
A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume.
-->
克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。
克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。
唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。
<!--
The implementation of cloning, from the perspective of the Kubernetes API, simply adds the ability to specify an existing PVC as a dataSource during new PVC creation. The source PVC must be bound and available (not in use).
-->
从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound 状态且可用的（不在使用中）。
<!--
Users need to be aware of the following when using this feature:
-->
从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，
增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound
状态且可用的（不在使用中）。
用户在使用该功能时，需要注意以下事项：
<!--
@@ -78,18 +69,15 @@ Users need to be aware of the following when using this feature:
* 仅在同一存储类中支持克隆。
- 目标卷必须和源卷具有相同的存储类
- 可以使用默认的存储类并且 storageClassName 字段在规格中忽略了
* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行（如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。
* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行
（如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。
<!--
## Provisioning
-->
## 供应
<!--
Clones are provisioned just like any other PVC with the exception of adding a dataSource that references an existing PVC in the same namespace.
-->
## 供应
克隆卷与其他任何 PVC 一样配置，除了需要增加 dataSource 来引用同一命名空间中现有的 PVC。
@@ -112,7 +100,8 @@ spec:
```
<!--
You must specify a capacity value for `spec.resources.requests.storage`, and the value you specify must be the same or larger than the capacity of the source volume.
You must specify a capacity value for `spec.resources.requests.storage`,
and the value you specify must be the same or larger than the capacity of the source volume.
-->
{{< note >}}
@@ -127,14 +116,14 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c
<!--
## Usage
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
-->
## 用法
<!--
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
-->
一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。
可以预期的是，新创建的 PVC 是一个独立的对象。
可以独立使用、克隆、快照或删除它，而不需要考虑它的原始数据源 PVC。
这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
content/zh/docs/concepts/storage/volume-snapshots.md
+10 -17
View File
@@ -5,18 +5,9 @@ weight: 20
---
<!--
---
reviewers:
- saad-ali
- thockin
- msau42
- jingxu97
- xing-yang
- yuxiangqian
title: Volume Snapshots
content_type: concept
weight: 20
---
-->
<!-- overview -->
@@ -26,9 +17,8 @@ weight: 20
<!--
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
-->
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes 的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
<!-- body -->
@@ -108,7 +98,9 @@ Instead of using a pre-existing snapshot, you can request that a snapshot to be
-->
#### 动态的 {#dynamic}
可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。在获取快照时，[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)指定要用的特定于存储提供程序的参数。
可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。
在获取快照时，[卷快照类](/zh/docs/concepts/storage/volume-snapshot-classes/)
指定要用的特定于存储提供程序的参数。
<!--
### Binding
@@ -181,12 +173,14 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
-->
`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。
卷快照可以通过指定 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/)
使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
<!--
For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
-->
如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。
对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
```
apiVersion: snapshot.storage.k8s.io/v1beta1
@@ -266,6 +260,5 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
For more details, see
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
-->
更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
更多详细信息，请参阅 [卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
content/zh/docs/concepts/storage/volumes.md
+98 -167
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/concepts/workloads/controllers/job.md
+861
View File
@@ -0,0 +1,861 @@
---
title: Jobs
content_type: concept
feature:
title: 批量执行
description: >
除了服务之外，Kubernetes 还可以管理你的批处理和 CI 工作负载，在期望时替换掉失效的容器。
weight: 60
---
<!--
reviewers:
- erictune
- soltysh
title: Jobs
content_type: concept
feature:
title: Batch execution
description: >
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
weight: 60
-->
<!-- overview -->
<!--
A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
As pods successfully complete, the Job tracks the successful completions. When a specified number
of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up
the Pods it created.
A simple case is to create one Job object in order to reliably run one Pod to completion.
The Job object will start a new Pod if the first Pod fails or is deleted (for example
due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
-->
Job 会创建一个或者多个 Pods，并确保指定数量的 Pods 成功终止。
随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。
当数量达到指定的成功个数阈值时，任务（即 Job）结束。
删除 Job 的操作会清除所创建的全部 Pods。
一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。
当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job
对象会启动一个新的 Pod。
你也可以使用 Job 以并行的方式运行多个 Pod。
<!-- body -->
<!--
## Running an example Job
Here is an example Job config. It computes π to 2000 places and prints it out.
It takes around 10s to complete.
-->
## 运行示例 Job {#running-an-example-job}
下面是一个 Job 配置示例。它负责计算 π 到小数点后 2000 位，并将结果打印出来。
此计算大约需要 10 秒钟完成。
{{< codenew file="controllers/job.yaml" >}}
<!--You can run the example with this command:-->
你可以使用下面的命令来运行此示例：
```shell
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
```
输出类似于：
```
job.batch/pi created
```
<!-- Check on the status of the Job with `kubectl`: -->
使用 `kubectl` 来检查 Job 的状态：
```shell
kubectl describe jobs/pi
```
输出类似于：
```
Name: pi
Namespace: default
Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
job-name=pi
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
Parallelism: 1
Completions: 1
Start Time: Mon, 02 Dec 2019 15:20:11 +0200
Completed At: Mon, 02 Dec 2019 15:21:16 +0200
Duration: 65s
Pods Statuses: 0 Running / 1 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
job-name=pi
Containers:
pi:
Image: perl
Port: <none>
Host Port: <none>
Command:
perl
-Mbignum=bpi
-wle
print bpi(2000)
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7
```
<!--
To view completed Pods of a Job, use `kubectl get pods`.
To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
-->
要查看 Job 对应的已完成的 Pods，可以执行 `kubectl get pods`。
要以机器可读的方式列举隶属于某 Job 的全部 Pods，你可以使用类似下面这条命令：
```shell
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods
```
输出类似于：
```
pi-5rwd7
```
<!--
Here, the selector is the same as the selector for the Job. The `-output=jsonpath` option specifies an expression
that just gets the name from each Pod in the returned list.
View the standard output of one of the pods:
-->
这里，选择算符与 Job 的选择算符相同。`--output=jsonpath` 选项给出了一个表达式，
用来从返回的列表中提取每个 Pod 的 name 字段。
查看其中一个 Pod 的标准输出：
```shell
kubectl logs $pods
```
<!--The output is similar to this:-->
输出类似于：
```
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
<!--
## Writing a Job spec
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
-->
## 编写 Job 规约
与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。
Job 的名字必须时合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
Job 配置还需要一个[`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
<!--
### Pod Template
The `.spec.template` is the only required field of the `.spec`.
The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a Job must specify appropriate
labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
-->
### Pod 模版
Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。
字段 `.spec.template` 的值是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。
其定义规范与 {{< glossary_tooltip text="Pod" term_id="pod" >}}
完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。
除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签
（参见[Pod 选择算符](#pod-selector)）和合适的重启策略。
Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
只能设置为 `Never` 或 `OnFailure` 之一。
<!--
### Pod selector
The `.spec.selector` field is optional. In almost all cases you should not specify it.
See section [specifying your own pod selector](#specifying-your-own-pod-selector).
-->
### Pod 选择算符 {#pod-selector}
字段 `.spec.selector` 是可选的。在绝大多数场合，你都不需要为其赋值。
参阅[设置自己的 Pod 选择算符](#specifying-your-own-pod-selector).
<!--
### Parallel execution for Jobs {#parallel-jobs}
There are three main types of task suitable to run as a Job:
-->
### Job 的并行执行 {#parallel-jobs}
适合以 Job 形式来运行的任务主要有三种：
<!--
1. Non-parallel Jobs
- normally, only one Pod is started, unless the Pod fails.
- the Job is complete as soon as its Pod terminates successfully.
1. Parallel Jobs with a *fixed completion count*:
- specify a non-zero positive value for `.spec.completions`.
- the Job represents the overall task, and is complete when there is one successful Pod for each value in the range 1 to `.spec.completions`.
- **not implemented yet:** Each Pod is passed a different index in the range 1 to `.spec.completions`.
1. Parallel Jobs with a *work queue*:
- do not specify `.spec.completions`, default to `.spec.parallelism`.
- the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
- each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
- when _any_ Pod from the Job terminates with success, no new Pods are created.
- once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
- once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output. They should all be in the process of exiting.
-->
1. 非并行 Job
- 通常只启动一个 Pod，除非该 Pod 失败
- 当 Pod 成功终止时，立即视 Job 为完成状态
1. 具有 *确定完成计数* 的并行 Job
- `.spec.completions` 字段设置为非 0 的正数值
- Job 用来代表整个任务，当对应于 1 和 `.spec.completions` 之间的每个整数都存在
一个成功的 Pod 时，Job 被视为完成
- **尚未实现**：每个 Pod 收到一个介于 1 和 `spec.completions` 之间的不同索引值
1. 带 *工作队列* 的并行 Job
- 不设置 `spec.completions`，默认值为 `.spec.parallelism`
- 多个 Pod 之间必须相互协调，或者借助外部服务确定每个 Pod 要处理哪个工作条目。
例如，任一 Pod 都可以从工作队列中取走最多 N 个工作条目。
- 每个 Pod 都可以独立确定是否其它 Pod 都已完成，进而确定 Job 是否完成
- 当 Job 中 _任何_ Pod 成功终止，不再创建新 Pod
- 一旦至少 1 个 Pod 成功完成，并且所有 Pod 都已终止，即可宣告 Job 成功完成
- 一旦任何 Pod 成功退出，任何其它 Pod 都不应再对此任务执行任何操作或生成任何输出。
所有 Pod 都应启动退出过程。
<!--
For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset. When both are
unset, both are defaulted to 1.
For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed.
You can set `.spec.parallelism`, or leave it unset and it will default to 1.
For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to
a non-negative integer.
For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
-->
对于 _非并行_ 的 Job，你可以不设置 `spec.completions` 和 `spec.parallelism`。
这两个属性都不设置时，均取默认值 1。
对于 _确定完成计数_ 类型的 Job，你应该设置 `.spec.completions` 为所需要的完成个数。
你可以设置 `.spec.parallelism`，也可以不设置。其默认值为 1。
对于一个 _工作队列_ Job，你不可以设置 `.spec.completions`，但要将`.spec.parallelism`
设置为一个非负整数。
关于如何利用不同类型的 Job 的更多信息，请参见 [Job 模式](#job-patterns)一节。
<!--
#### Controlling parallelism
The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
If it is unspecified, it defaults to 1.
If it is specified as 0, then the Job is effectively paused until it is increased.
Actual parallelism (number of pods running at any instant) may be more or less than requested
parallelism, for a variety of reasons:
-->
#### 控制并行性 {#controlling-parallelism}
并行性请求（`.spec.parallelism`）可以设置为任何非负整数。
如果未设置，则默认为 1。
如果设置为 0，则 Job 相当于启动之后便被暂停，直到此值被增加。
实际并行性（在任意时刻运行状态的 Pods 个数）可能比并行性请求略大或略小，
原因如下：
<!--
- For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of
remaining completions. Higher values of `.spec.parallelism` are effectively ignored.
- For _work queue_ Jobs, no new Pods are started after any Pod has succeeded - remaining Pods are allowed to complete, however.
- If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react.
- If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.),
then there may be fewer pods than requested.
- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
- When a Pod is gracefully shut down, it takes time to stop.
-->
- 对于 _确定完成计数_ Job，实际上并行执行的 Pods 个数不会超出剩余的完成数。
如果 `.spec.parallelism` 值较高，会被忽略。
- 对于 _工作队列_ Job，有任何 Job 成功结束之后，不会有新的 Pod 启动。
不过，剩下的 Pods 允许执行完毕。
- 如果 Job {{< glossary_tooltip text="控制器" term_id="controller" >}} 没有来得及作出响应，或者
- 如果 Job 控制器因为任何原因（例如，缺少 `ResourceQuota` 或者没有权限）无法创建 Pods。
Pods 个数可能比请求的数目小。
- Job 控制器可能会因为之前同一 Job 中 Pod 失效次数过多而压制新 Pod 的创建。
- 当 Pod 处于体面终止进程中，需要一定时间才能停止。
<!--
## Handling Pod and container failures
A container in a Pod may fail for a number of reasons, such as because the process in it exited with
a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this
happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays
on the node, but the container is re-run. Therefore, your program needs to handle the case when it is
restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`.
See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`.
-->
## 处理 Pod 和容器失效
Pod 中的容器可能因为多种不同原因失效，例如因为其中的进程退出时返回值非零，
或者容器因为超出内存约束而被杀死等等。
如果发生这类事件，并且 `.spec.template.spec.restartPolicy = "OnFailure"`，
Pod 则继续留在当前节点，但容器会被重新运行。
因此，你的程序需要能够处理在本地被重启的情况，或者要设置
`.spec.template.spec.restartPolicy = "Never"`。
关于 `restartPolicy` 的更多信息，可参阅
[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
<!--
An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node
(node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the
`.spec.template.spec.restartPolicy = "Never"`. When a Pod fails, then the Job controller
starts a new Pod. This means that your application needs to handle the case when it is restarted in a new
pod. In particular, it needs to handle temporary files, locks, incomplete output and the like
caused by previous runs.
-->
整个 Pod 也可能会失败，且原因各不相同。
例如，当 Pod 启动时，节点失效（被升级、被重启、被删除等）或者其中的容器失败而
`.spec.template.spec.restartPolicy = "Never"`。
当 Pod 失败时，Job 控制器会启动一个新的 Pod。
这意味着，你的应用需要处理在一个新 Pod 中被重启的情况。
尤其是应用需要处理之前运行所触碰或产生的临时文件、锁、不完整的输出等问题。
<!--
Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and
`.spec.template.spec.restartPolicy = "Never"`, the same program may
sometimes be started twice.
If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be
multiple pods running at once. Therefore, your pods must also be tolerant of concurrency.
-->
注意，即使你将 `.spec.parallelism` 设置为 1，且将 `.spec.completions` 设置为
1，并且 `.spec.template.spec.restartPolicy` 设置为 "Never"，同一程序仍然有可能被启动两次。
如果你确实将 `.spec.parallelism` 和 `.spec.completions` 都设置为比 1 大的值，
那就有可能同时出现多个 Pod 运行的情况。
为此，你的 Pod 也必须能够处理并发性问题。
<!--
### Pod backoff failure policy
There are situations where you want to fail a Job after some amount of retries
due to a logical error in configuration etc.
To do so, set `.spec.backoffLimit` to specify the number of retries before
considering a Job as failed. The back-off limit is set by default to 6. Failed
Pods associated with the Job are recreated by the Job controller with an
exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
back-off count is reset when a Job's Pod is deleted or successful without any
other Pods for the Job failing around that time.
-->
### Pod 回退失效策略
在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态，因为这很
可能意味着遇到了配置错误。
为了实现这点，可以将 `.spec.backoffLimit` 设置为视 Job 为失败之前的重试次数。
失效回退的限制值默认为 6。
与 Job 相关的失效的 Pod 会被 Job 控制器重建，并且以指数型回退计算重试延迟
（从 10 秒、20 秒到 40 秒，最多 6 分钟）。
当 Job 的 Pod 被删除时，或者 Pod 成功时没有其它 Pod 处于失败状态，失效回退的次数也会被重置（为 0）。
<!--
If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting
`restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output
from failed Jobs is not lost inadvertently.
-->
{{< note >}}
如果你的 Job 的 `restartPolicy` 被设置为 "OnFailure"，就要注意运行该 Job 的容器
会在 Job 到达失效回退次数上限时自动被终止。
这会使得调试 Job 中可执行文件的工作变得非常棘手。
我们建议在调试 Job 时将 `restartPolicy` 设置为 "Never"，
或者使用日志系统来确保失效 Jobs 的输出不会意外遗失。
{{< /note >}}
<!--
## Job termination and cleanup
When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around
allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
The job object also remains after it is completed so that you can view its status. It is up to the user to delete
old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
-->
## Job 终止与清理
Job 完成时不会再创建新的 Pod，不过已有的 Pod 也不会被删除。
保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告
或者其它诊断性输出。
Job 完成时 Job 对象也一样被保留下来，这样你就可以查看它的状态。
在查看了 Job 状态之后删除老的 Job 的操作留给了用户自己。
你可以使用 `kubectl` 来删除 Job（例如，`kubectl delete jobs/pi`
或者 `kubectl delete -f ./job.yaml`）。
当使用 `kubectl` 来删除 Job 时，该 Job 所创建的 Pods 也会被删除。
<!--
By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the
`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will be marked as failed and any running Pods will be terminated.
Another way to terminate a Job is by setting an active deadline.
Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds.
The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`.
-->
默认情况下，Job 会持续运行，除非某个 Pod 失败（`restartPolicy=Never`）
或者某个容器出错退出（`restartPolicy=OnFailure`）。
这时，Job 基于前述的 `spec.backoffLimit` 来决定是否以及如何重试。
一旦重试次数到达 `.spec.backoffLimit` 所设的上限，Job 会被标记为失败，
其中运行的 Pods 都会被终止。
终止 Job 的另一种方式是设置一个活跃期限。
你可以为 Job 的 `.spec.activeDeadlineSeconds` 设置一个秒数值。
该值适用于 Job 的整个生命期，无论 Job 创建了多少个 Pod。
一旦 Job 运行时间达到 `activeDeadlineSeconds` 秒，其所有运行中的 Pod
都会被终止，并且 Job 的状态更新为 `type: Failed`
及 `reason: DeadlineExceeded`。
<!--
Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.
Example:
-->
注意 Job 的 `.spec.activeDeadlineSeconds` 优先级高于其 `.spec.backoffLimit` 设置。
因此，如果一个 Job 正在重试一个或多个失效的 Pod，该 Job 一旦到达
`activeDeadlineSeconds` 所设的时限即不再部署额外的 Pod，即使其重试次数还未
达到 `backoffLimit` 所设的限制。
例如：
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi-with-timeout
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
<!--
Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level.
Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`.
That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
-->
注意 Job 规约和 Job 中的
[Pod 模版规约](/zh/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
都有 `activeDeadlineSeconds` 字段。
请确保你在合适的层次设置正确的字段。
还要注意的是，`restartPolicy` 对应的是 Pod，而不是 Job 本身：
一旦 Job 状态变为 `type: Failed`，就不会再发生 Job 重启的动作。
换言之，由 `.spec.activeDeadlineSeconds` 和 `.spec.backoffLimit` 所触发的 Job 终结机制
都会导致 Job 永久性的失败，而这类状态都需要手工干预才能解决。
<!--
## Clean up finished jobs automatically
Finished Jobs are usually no longer needed in the system. Keeping them around in
the system will put pressure on the API server. If the Jobs are managed directly
by a higher level controller, such as
[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
cleaned up by CronJobs based on the specified capacity-based cleanup policy.
### TTL mechanism for finished Jobs
-->
## 自动清理完成的 Job
完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API
服务器带来额外的压力。
如果 Job 由某种更高级别的控制器来管理，例如
[CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/)，
则 Job 可以被 CronJob 基于特定的根据容量裁定的清理策略清理掉。
### 已完成 Job 的 TTL 机制 {#ttl-mechanisms-for-finished-jobs}
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
<!--
Another way to clean up finished Jobs (either `Complete` or `Failed`)
automatically is to use a TTL mechanism provided by a
[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of
the Job.
When the TTL controller cleans up the Job, it will delete the Job cascadingly,
i.e. delete its dependent objects, such as Pods, together with the Job. Note
that when the Job is deleted, its lifecycle guarantees, such as finalizers, will
be honored.
For example:
-->
自动清理已完成 Job （状态为 `Complete` 或 `Failed`）的另一种方式是使用由
[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
的 TTL 机制。
通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉
已结束的资源。
TTL 控制器清理 Job 时，会级联式地删除 Job 对象。
换言之，它会删除所有依赖的对象，包括 Pod 及 Job 本身。
注意，当 Job 被删除时，系统会考虑其生命周期保障，例如其 Finalizers。
例如：
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi-with-ttl
spec:
ttlSecondsAfterFinished: 100
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
<!--
The Job `pi-with-ttl` will be eligible to be automatically deleted, `100`
seconds after it finishes.
If the field is set to `0`, the Job will be eligible to be automatically deleted
immediately after it finishes. If the field is unset, this Job won't be cleaned
up by the TTL controller after it finishes.
Note that this TTL mechanism is alpha, with feature gate `TTLAfterFinished`. For
more information, see the documentation for
[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
finished resources.
-->
Job `pi-with-ttl` 在结束 100 秒之后，可以成为被自动删除的标的。
如果该字段设置为 `0`，Job 在结束之后立即成为可被自动删除的对象。
如果该字段没有设置，Job 不会在结束之后被 TTL 控制器自动清除。
注意这种 TTL 机制仍然是一种 Alpha 状态的功能特性，需要配合 `TTLAfterFinished`
特性门控使用。有关详细信息，可参考
[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)的文档。
<!--
## Job patterns
The Job object can be used to support reliable parallel execution of Pods. The Job object is not
designed to support closely-communicating parallel processes, as commonly found in scientific
computing. It does support parallel processing of a set of independent but related *work items*.
These might be emails to be sent, frames to be rendered, files to be transcoded, ranges of keys in a
NoSQL database to scan, and so on.
-->
## Job 模式 {#job-patterns}
Job 对象可以用来支持多个 Pod 的可靠的并发执行。
Job 对象不是设计用来支持相互通信的并行进程的，后者一般在科学计算中应用较多。
Job 的确能够支持对一组相互独立而又有所关联的 *工作条目* 的并行处理。
这类工作条目可能是要发送的电子邮件、要渲染的视频帧、要编解码的文件、NoSQL
数据库中要扫描的主键范围等等。
<!--
In a complex system, there may be multiple different sets of work items. Here we are just
considering one set of work items that the user wants to manage together &mdash; a *batch job*.
There are several different patterns for parallel computation, each with strengths and weaknesses.
The tradeoffs are:
-->
在一个复杂系统中，可能存在多个不同的工作条目集合。这里我们仅考虑用户希望一起管理的
工作条目集合之一 &mdash; *批处理作业*。
并行计算的模式有好多种，每种都有自己的强项和弱点。这里要权衡的因素有：
<!--
- One Job object for each work item, vs. a single Job object for all work items. The latter is
better for large numbers of work items. The former creates some overhead for the user and for the
system to manage large numbers of Job objects.
- Number of pods created equals number of work items, vs. each Pod can process multiple work items.
The former typically requires less modification to existing code and containers. The latter
is better for large numbers of work items, for similar reasons to the previous bullet.
- Several approaches use a work queue. This requires running a queue service,
and modifications to the existing program or container to make it use the work queue.
Other approaches are easier to adapt to an existing containerised application.
-->
- 每个工作条目对应一个 Job 或者所有工作条目对应同一 Job 对象。
后者更适合处理大量工作条目的场景；
前者会给用户带来一些额外的负担，而且需要系统管理大量的 Job 对象。
- 创建与工作条目相等的 Pod 或者令每个 Pod 可以处理多个工作条目。
前者通常不需要对现有代码和容器做较大改动；
后者则更适合工作条目数量较大的场合，原因同上。
- 有几种技术都会用到工作队列。这意味着需要运行一个队列服务，并修改现有程序或容器
使之能够利用该工作队列。
与之比较，其他方案在修改现有容器化应用以适应需求方面可能更容易一些。
<!--
The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs.
The pattern names are also links to examples and more detailed description.
-->
下面是对这些权衡的汇总，列 2 到 4 对应上面的权衡比较。
模式的名称对应了相关示例和更详细描述的链接。
| 模式 | 单个 Job 对象 | Pods 数少于工作条目数？ | 直接使用应用无需修改? | 在 Kube 1.1 上可用？|
| ----- |:-------------:|:-----------------------:|:---------------------:|:-------------------:|
| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 | ✓ |
| [Pod 数量可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
| 静态工作分派的单个 Job | ✓ | | ✓ | |
<!--
When you specify completions with `.spec.completions`, each Pod created by the Job controller
has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). This means that
all pods for a task will have the same command line and the same
image, the same volumes, and (almost) the same environment variables. These patterns
are different ways to arrange for pods to work on different things.
This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns.
Here, `W` is the number of work items.
-->
当你使用 `.spec.completions` 来设置完成数时，Job 控制器所创建的每个 Pod
使用完全相同的 [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
这意味着任务的所有 Pod 都有相同的命令行，都使用相同的镜像和数据卷，甚至连
环境变量都（几乎）相同。
这些模式是让每个 Pod 执行不同工作的几种不同形式。
下表显示的是每种模式下 `.spec.parallelism` 和 `.spec.completions` 所需要的设置。
其中，`W` 表示的是工作条目的个数。
| 模式 | `.spec.completions` | `.spec.parallelism` |
| ----- |:-------------------:|:--------------------:|
| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
| [Pod 个数可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
| 基于静态工作分派的单一 Job | W | 任意值 |
<!--
## Advanced usage
### Specifying your own Pod selector {#specifying-your-own-pod-selector}
Normally, when you create a Job object, you do not specify `.spec.selector`.
The system defaulting logic adds this field when the Job is created.
It picks a selector value that will not overlap with any other jobs.
However, in some cases, you might need to override this automatically set selector.
To do this, you can specify the `.spec.selector` of the Job.
-->
## 高级用法 {#advanced-usage}
### 指定你自己的 Pod 选择算符 {#specifying-your-own-pod-selector}
通常，当你创建一个 Job 对象时，你不会设置 `.spec.selector`。
系统的默认值填充逻辑会在创建 Job 时添加此字段。
它会选择一个不会与任何其他 Job 重叠的选择算符设置。
不过，有些场合下，你可能需要重载这个自动设置的选择算符。
为了实现这点，你可以手动设置 Job 的 `spec.selector` 字段。
<!--
Be very careful when doing this. If you specify a label selector which is not
unique to the pods of that Job, and which matches unrelated Pods, then pods of the unrelated
job may be deleted, or this Job may count other Pods as completing it, or one or both
Jobs may refuse to create Pods or run to completion. If a non-unique selector is
chosen, then other controllers (e.g. ReplicationController) and their Pods may behave
in unpredictable ways too. Kubernetes will not stop you from making a mistake when
specifying `.spec.selector`.
-->
做这个操作时请务必小心。
如果你所设定的标签选择算符并不唯一针对 Job 对应的 Pod 集合，甚或该算符还能匹配
其他无关的 Pod，这些无关的 Job 的 Pod 可能会被删除。
或者当前 Job 会将另外一些 Pod 当作是完成自身工作的 Pods，
又或者两个 Job 之一或者二者同时都拒绝创建 Pod，无法运行至完成状态。
如果所设置的算符不具有唯一性，其他控制器（如 RC 副本控制器）及其所管理的 Pod
集合可能会变得行为不可预测。
Kubernetes 不会在你设置 `.spec.selector` 时尝试阻止你犯这类错误。
<!--
Here is an example of a case when you might want to use this feature.
Say Job `old` is already running. You want existing Pods
to keep running, but you want the rest of the Pods it creates
to use a different pod template and for the Job to have a new name.
You cannot update the Job because these fields are not updatable.
Therefore, you delete Job `old` but _leave its pods
running_, using `kubectl delete jobs/old -cascade=false`.
Before deleting it, you make a note of what selector it uses:
-->
下面是一个示例场景，在这种场景下你可能会使用刚刚讲述的特性。
假定名为 `old` 的 Job 已经处于运行状态。
你希望已有的 Pod 继续运行，但你希望 Job 接下来要创建的其他 Pod
使用一个不同的 Pod 模版，甚至希望 Job 的名字也发生变化。
你无法更新现有的 Job，因为这些字段都是不可更新的。
因此，你会删除 `old` Job，但 _允许该 Job 的 Pod 集合继续运行_。
这是通过 `kubectl delete jobs/old --cascade=false` 实现的。
在删除之前，我们先记下该 Job 所使用的选择算符。
```shell
kubectl get job old -o yaml
```
输出类似于：
```
kind: Job
metadata:
name: old
...
spec:
selector:
matchLabels:
controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
...
```
<!--
Then you create a new Job with name `new` and you explicitly specify the same selector.
Since the existing Pods have label `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`,
they are controlled by Job `new` as well.
You need to specify `manualSelector: true` in the new Job since you are not using
the selector that the system normally generates for you automatically.
-->
接下来你会创建名为 `new` 的新 Job，并显式地为其设置相同的选择算符。
由于现有 Pod 都具有标签 `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`，
它们也会被名为 `new` 的 Job 所控制。
你需要在新 Job 中设置 `manualSelector: true`，因为你并未使用系统通常自动为你
生成的选择算符。
```
kind: Job
metadata:
name: new
...
spec:
manualSelector: true
selector:
matchLabels:
controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
...
```
<!--
The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting
`manualSelector: true` tells the system to that you know what you are doing and to allow this
mismatch.
-->
新的 Job 自身会有一个不同于 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 的唯一 ID。
设置 `manualSelector: true` 是在告诉系统你知道自己在干什么并要求系统允许这种不匹配
的存在。
<!--
## Alternatives
### Bare Pods
When the node that a Pod is running on reboots or fails, the pod is terminated
and will not be restarted. However, a Job will create new Pods to replace terminated ones.
For this reason, we recommend that you use a Job rather than a bare Pod, even if your application
requires only a single Pod.
-->
## 替代方案 {#alternatives}
### 裸 Pod {#bare-pods}
当 Pod 运行所在的节点重启或者失败，Pod 会被终止并且不会被重启。
Job 会重新创建新的 Pod 来替代已终止的 Pod。
因为这个原因，我们建议你使用 Job 而不是独立的裸 Pod，
即使你的应用仅需要一个 Pod。
<!--
### Replication Controller
Jobs are complementary to [Replication Controllers](/docs/user-guide/replication-controller).
A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job
manages Pods that are expected to terminate (e.g. batch tasks).
As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` is *only* appropriate
for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
(Note: If `RestartPolicy` is not set, the default value is `Always`.)
-->
### 副本控制器 {#replication-controller}
Job 与[副本控制器](/docs/user-guide/replication-controller)是彼此互补的。
副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。
正如在 [Pod 生命期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
`Job` 仅适合于 `restartPolicy` 设置为 `OnFailure` 或 `Never` 的 Pod。
注意：如果 `restartPolicy` 未设置，其默认值是 `Always`。
<!--
### Single Job starts controller Pod
Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
of custom controller for those Pods. This allows the most flexibility, but may be somewhat
complicated to get started with and offers less integration with Kubernetes.
-->
### 单个 Job 启动控制器 Pod
另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod，因此扮演了一种
后启动 Pod 的控制器的角色。
这种模式的灵活性更高，但是有时候可能会把事情搞得很复杂，很难入门，
并且与 Kubernetes 的集成度很低。
<!--
One example of this pattern would be a Job which starts a Pod which runs a script that in turn
starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), runs a spark
driver, and then cleans up.
An advantage of this approach is that the overall process gets the completion guarantee of a Job
object, but maintains complete control over what Pods are created and how work is assigned to them.
-->
这种模式的实例之一是用 Job 来启动一个运行脚本的 Pod，脚本负责启动 Spark
主控制器（参见 [Spark 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)），
运行 Spark 驱动，之后完成清理工作。
这种方法的优点之一是整个过程得到了 Job 对象的完成保障，
同时维持了对创建哪些 Pod、如何向其分派工作的完全控制能力，
<!--
## Cron Jobs {#cron-jobs}
You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
-->
## Cron Jobs {#cron-jobs}
你可以使用 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/)
创建一个在指定时间/日期运行的 Job，类似于 UNIX 系统上的 `cron` 工具。
content/zh/docs/concepts/workloads/pods/_index.md
+520
View File
@@ -1,4 +1,524 @@
---
title: "Pods"
content_type: concept
weight: 10
no_list: true
card:
name: concepts
weight: 60
---
<!--
reviewers:
- erictune
title: Pods
content_type: concept
weight: 10
no_list: true
card:
name: concepts
weight: 60
-->
<!-- overview -->
<!--
_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
{{< glossary_tooltip text="containers" term_id="container" >}}
with shared storage/network resources, and a specification
for how to run the containers. A Pod's contents are always co-located and
co-scheduled, and run in a shared context. A Pod models an
application-specific "logical host": it contains one or more application
containers which are relatively tightly coupled.
In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
-->
_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）
{{< glossary_tooltip text="容器" term_id="container" >}}；
这些容器共享存储、网络、以及怎样运行这些容器的声明。
Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。
Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，
这些容器是相对紧密的耦合在一起的。
在非云环境中，在相同的物理机或虚拟机上运行的应用类似于
在同一逻辑主机上运行的云应用。
<!--
As well as application containers, a Pod can contain
[init containers](/docs/concepts/workloads/pods/init-containers/) that run
during Pod startup. You can also inject
[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/)
for debugging if your cluster offers this.
-->
除了应用容器，Pod 还可以包含在 Pod 启动期间运行的
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/)
的情况外，为调试的目的注入临时性容器。
<!-- body -->
## 什么是 Pod？ {#what-is-a-pod}
<!--
While Kubernetes supports more
{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}}
than just Docker, [Docker](https://www.docker.com/) is the most commonly known
runtime, and it helps to describe Pods using some terminology from Docker.
-->
{{< note >}}
除了 Docker 之外，Kubernetes 支持
很多其他{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}，
[Docker](https://www.docker.com/) 是最有名的运行时，
使用 Docker 的术语来描述 Pod 会很有帮助。
{{< /note >}}
<!--
The shared context of a Pod is a set of Linux namespaces, cgroups, and
potentially other facets of isolation - the same things that isolate a Docker
container. Within a Pod's context, the individual applications may have
further sub-isolations applied.
In terms of Docker concepts, a Pod is similar to a group of Docker containers
with shared namespaces and shared filesystem volumes.
-->
Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离
方面，即用来隔离 Docker 容器的技术。
在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。
就 Docker 概念的术语而言，Pod 类似于共享名字空间和文件系统卷的一组 Docker
容器。
<!--
## Using Pods
Usually you don't need to create Pods directly, even singleton Pods.
Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
If your Pods need to track state, consider the
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
Pods in a Kubernetes cluster are used in two main ways:
-->
## 使用 Pod {#using-pods}
通常你不需要直接创建 Pod，甚至单实例 Pod。
相反，你会使用诸如
{{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或
{{< glossary_tooltip text="Job" term_id="job" >}} 这类工作负载资源
来创建 Pod。如果 Pod 需要跟踪状态，
可以考虑 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
资源。
Kubernetes 集群中的 Pod 主要有两种用法：
<!--
* **Pods that run a single container**. The "one-container-per-Pod" model is the
most common Kubernetes use case; in this case, you can think of a Pod as a
wrapper around a single container; Kubernetes manages Pods rather than managing
the containers directly.
* **Pods that run multiple containers that need to work together**. A Pod can
encapsulate an application composed of multiple co-located containers that are
tightly coupled and need to share resources. These co-located containers
form a single cohesive unit of service—for example, one container serving data
stored in a shared volume to the public, while a separate _sidecar_ container
refreshes or updates those files.
The Pod wraps these containers, storage resources, and an ephemeral network
identity together as a single unit.
Grouping multiple co-located and co-managed containers in a single Pod is a
relatively advanced use case. You should use this pattern only in specific
instances in which your containers are tightly coupled.
-->
* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；
在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
* **运行多个协同工作的容器的 Pod**。
Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，
而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。
Pod 将这些容器和存储资源打包为一个可管理的实体。
{{< note >}}
将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。
只有在一些场景中，容器之间紧密关联时你才应该使用这种模式。
{{< /note >}}
<!--
Each Pod is meant to run a single instance of a given application. If you want to
scale your application horizontally (to provide more overall resources by running
more instances), you should use multiple Pods, one for each instance. In
Kubernetes, this is typically referred to as _replication_.
Replicated Pods are usually created and managed as a group by a workload resource
and its {{< glossary_tooltip text="controller" term_id="controller" >}}.
See [Pods and controllers](#pods-and-controllers) for more information on how
Kubernetes uses workload resources, and their controllers, to implement application
scaling and auto-healing.
-->
每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例
以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。
在 Kubernetes 中，这通常被称为 _副本（Replication）_。
通常使用一种工作负载资源及其{{< glossary_tooltip text="控制器" term_id="controller" >}}
来创建和管理一组 Pod 副本。
参见 [Pod 和控制器](#pods-and-controllers)以了解 Kubernetes
如何使用工作负载资源及其控制器以实现应用的扩缩和自动修复。
<!--
### How Pods manage multiple containers
Pods are designed to support multiple cooperating processes (as containers) that form
a cohesive unit of service. The containers in a Pod are automatically co-located and
co-scheduled on the same physical or virtual machine in the cluster. The containers
can share resources and dependencies, communicate with one another, and coordinate
when and how they are terminated.
-->
### Pod 怎样管理多个容器
Pod 被设计成支持形成内聚服务单元的多个协作过程（形式为容器）。
Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。
容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。
<!--
For example, you might have a container that
acts as a web server for files in a shared volume, and a separate "sidecar" container
that updates those files from a remote source, as in the following diagram:
-->
例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的
“sidecar（挂斗）”容器负责从远端更新这些文件，如下图所示：
{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
<!--
Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}}
as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}.
Init containers run and complete before the app containers are started.
Pods natively provide two kinds of shared resources for their constituent containers:
[networking](#pod-networking) and [storage](#pod-storage).
-->
有些 Pod 具有 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}} 和
{{< glossary_tooltip text="应用容器" term_id="app-container" >}}。
Init 容器会在启动应用容器之前运行并完成。
Pod 天生地为其成员容器提供了两种共享资源：[网络](#pod-networking)和
[存储](#pod-storage)。
<!--
## Working with Pods
You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This
is because Pods are designed as relatively ephemeral, disposable entities. When
a Pod gets created (directly by you, or indirectly by a
{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is
scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster.
The Pod remains on that node until the Pod finishes execution, the Pod object is deleted,
the Pod is *evicted* for lack of resources, or the node fails.
-->
## 使用 Pod {#working-with-pods}
你很少在 Kubernetes 中直接创建一个个的 Pod，甚至是单实例（Singleton）的 Pod。
这是因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体。
当 Pod 由你或者间接地由 {{< glossary_tooltip text="控制器" term_id="controller" >}}
创建时，它被调度在集群中的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
Pod 会保持在该节点上运行，直到 Pod 结束执行、Pod 对象被删除、Pod 因资源不足而被
*驱逐* 或者节点失效为止。
<!--
Restarting a container in a Pod should not be confused with restarting a Pod. A Pod
is not a process, but an environment for running container(s). A Pod persists until
it is deleted.
-->
{{< note >}}
重启 Pod 中的容器不应与重启 Pod 混淆。
Pod 不是进程，而是容器运行的环境。
在被删除之前，Pod 会一直存在。
{{< /note >}}
<!--
When you create the manifest for a Pod object, make sure the name specified is a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-->
当你为 Pod 对象创建清单时，要确保所指定的 Pod 名称是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
<!--
### Pods and controllers
You can use workload resources to create and manage multiple Pods for you. A controller
for the resource handles replication and rollout and automatic healing in case of
Pod failure. For example, if a Node fails, a controller notices that Pods on that
Node have stopped working and creates a replacement Pod. The scheduler places the
replacement Pod onto a healthy Node.
Here are some examples of workload resources that manage one or more Pods:
-->
### Pod 和控制器 {#pods-and-controllers}
你可以使用工作负载资源来创建和管理多个 Pod。
资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。
例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作，
就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行。
下面是一些管理一个或者多个 Pod 的工作负载资源的示例：
* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
<!--
### Pod templates
Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods
from a _pod template_ and manage those Pods on your behalf.
PodTemplates are specifications for creating Pods, and are included in workload resources such as
[Deployments](/docs/concepts/workloads/controllers/deployment/),
[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
-->
### Pod 模版 {#pod-templates}
{{< glossary_tooltip text="负载" term_id="workload" >}}资源的控制器通常使用 _Pod 模板（Pod Template）_
来替你创建 Pod 并管理它们。
Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
[Job](/zh/docs/concepts/workloads/containers/job/) 和
[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。
<!--
Each controller for a workload resource uses the `PodTemplate` inside the workload
object to make actual Pods. The `PodTemplate` is part of the desired state of whatever
workload resource you used to run your app.
The sample below is a manifest for a simple Job with a `template` that starts one
container. The container in that Pod prints a message then pauses.
-->
工作负载的控制器会使用负载对象中的 `PodTemplate` 来生成实际的 Pod。
`PodTemplate` 是你用来运行应用时指定的负载资源的目标状态的一部分。
下面的示例是一个简单的 Job 的清单，其中的 `template` 指示启动一个容器。
该 Pod 中的容器会打印一条消息之后暂停。
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: hello
spec:
template:
# 这里是 Pod 模版
spec:
containers:
- name: hello
image: busybox
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
# 以上为 Pod 模版
```
<!--
Modifying the pod template or switching to a new pod template has no effect on the
Pods that already exist. Pods do not receive template updates directly. Instead,
a new Pod is created to match the revised pod template.
For example, the deployment controller ensures that the running Pods match the current
pod template for each Deployment object. If the template is updated, the Deployment has
to remove the existing Pods and create new Pods based on the updated template. Each workload
resource implements its own rules for handling changes to the Pod template.
-->
修改 Pod 模版或者切换到新的 Pod 模版都不会对已经存在的 Pod 起作用。
Pod 不会直接收到模版的更新。相反，
新的 Pod 会被创建出来，与更改后的 Pod 模版匹配。
例如，Deployment 控制器针对每个 Deployment 对象确保运行中的 Pod 与当前的 Pod
模版匹配。如果模版被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模版
创建新的 Pod。每个工作负载资源都实现了自己的规则，用来处理对 Pod 模版的更新。
<!--
On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
directly observe or manage any of the details around pod templates and updates; those
details are abstracted away. That abstraction and separation of concerns simplifies
system semantics, and makes it feasible to extend the cluster's behavior without
changing existing code.
-->
在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}并不直接监测
或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。
这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的
前提下就能扩展集群的行为。
<!--
## Resource sharing and communication
Pods enable data sharing and communication among their constituent
containters.
-->
### 资源共享和通信 {#resource-sharing-and-communication}
Pod 使它的成员容器间能够进行数据共享和通信。
<!--
### Storage in Pods {#pod-storage}
A Pod can specify a set of shared storage
{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers
in the Pod can access the shared volumes, allowing those containers to
share data. Volumes also allow persistent data in a Pod to survive
in case one of the containers within needs to be restarted. See
[Storage](/docs/concepts/storage/) for more information on how
Kubernetes implements shared storage and makes it available to Pods.
-->
### Pod 中的存储 {#pod-storage}
一个 Pod 可以设置一组共享的存储{{< glossary_tooltip text="卷" term_id="volume" >}}。
Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。
卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。
有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息，
请参考[卷](/zh/docs/concepts/storage/)。
<!--
### Pod networking
Each Pod is assigned a unique IP address for each address family. Every
container in a Pod shares the network namespace, including the IP address and
network ports. Inside a Pod (and **only** then), the containers that belong to the Pod
can communicate with one another using `localhost`. When containers in a Pod communicate
with entities *outside the Pod*,
they must coordinate how they use the shared network resources (such as ports).
-->
### Pod 联网 {#pod-networking}
每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。
Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。
*Pod 内* 的容器可以使用 `localhost` 互相通信。
当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源
（例如端口）。
<!--
Within a Pod, containers share an IP address and port space, and
can find each other via `localhost`. The containers in a Pod can also communicate
with each other using standard inter-process communications like SystemV semaphores
or POSIX shared memory. Containers in different Pods have distinct IP addresses
and can not communicate by IPC without
[special configuration](/docs/concepts/policy/pod-security-policy/).
Containers that want to interact with a container running in a different Pod can
use IP networking to comunicate.
-->
在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 发现对方。
他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。
不同 Pod 中的容器的 IP 地址互不相同，没有
[特殊配置](/zh/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。
如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。
<!--
Containers within the Pod see the system hostname as being the same as the configured
`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
section.
-->
Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。
[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。
<!--
## Privileged mode for containers
Any container in a Pod can enable privileged mode, using the `privileged` flag on
the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
Processes within a privileged container get almost the same privileges that are available to processes outside a container.
-->
## 容器的特权模式 {#rivileged-mode-for-containers}
Pod 中的任何容器都可以使用容器规约中的
[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
`privileged` 参数启用特权模式。
这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
的容器很有用。
容器内的进程几乎可以获得与容器外的进程相同的特权。
<!--
Your {< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
-->
{{< note >}}
你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持
特权容器的概念才能使用这一配置。
{{< /note >}}
<!--
## Static Pods
_Static Pods_ are managed directly by the kubelet daemon on a specific node,
without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
observing them.
Whereas most Pods are managed by the control plane (for example, a
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static
Pods, the kubelet directly supervises each static Pod (and restarts it if it fails).
-->
## 静态 Pod {#static-pods}
_静态 Pod（Static Pod）_ 直接由特定节点上的 `kubelet` 守护进程管理，
不需要{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}看到它们。
尽管大多数 Pod 都是通过控制面（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
来管理的，对于静态 Pod 而言，`kubelet` 直接监控每个 Pod，并在其失效时重启之。
<!--
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
The main use for static Pods is to run a self-hosted control plane: in other words,
using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
on the Kubernetes API server for each static Pod.
This means that the Pods running on a node are visible on the API server,
but cannot be controlled from there.
-->
静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。
其主要用途是运行自托管的控制面。
在自托管场景中，使用 `kubelet` 来管理各个独立的
[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)。
`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个
{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API
服务器来控制。
## {{% heading "whatsnext" %}}
<!--
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
configure different Pods with different container runtime configurations.
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
* Pod is a top-level resource in the Kubernetes REST API.
The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
object definition describes the object in detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
--
* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [PodPresets](/zh/docs/concepts/workloads/pods/podpreset/)
* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它
来配置不同的 Pod 使用不同的容器运行时配置
* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 了解 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)，以及你
如何可以利用它在出现干扰因素时管理应用的可用性
* Pod 在 Kubernetes REST API 中是一个顶层资源；
[Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
对象的定义中包含了更多的细节信息。
* 博客 [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 中解释了在同一 Pod 中包含多个容器时的几种常见布局。
<!--
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
-->
要了解为什么 Kubernetes 会在其他资源
（如 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：
* [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
* [Borg](https://research.google.com/pubs/pub43438.html)
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
* [Omega](https://research.google/pubs/pub41684/)
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
content/zh/docs/concepts/workloads/pods/pod-overview.md
-265
View File
@@ -1,265 +0,0 @@
---
title: Pod 概览
content_type: concept
weight: 10
card:
name: concepts
weight: 60
---
<!--
---
reviewers:
- erictune
title: Pod Overview
content_type: concept
weight: 10
card:
name: concepts
weight: 60
---
-->
<!--
This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
-->
<!-- overview -->
本节提供了 `Pod` 的概览信息，`Pod` 是最小可部署的 Kubernetes 对象模型。
<!-- body -->
<!--
## Understanding Pods
-->
## 理解 Pod
<!--
A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" >}}.
-->
*Pod* 是 Kubernetes 应用程序的基本执行单元，即它是 Kubernetes 对象模型中创建或部署的最小和最简单的单元。Pod 表示在 {{< glossary_tooltip term_id="cluster" >}} 上运行的进程。
<!--
A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
-->
Pod 封装了应用程序容器（或者在某些情况下封装多个容器）、存储资源、唯一网络 IP 以及控制容器应该如何运行的选项。
Pod 表示部署单元：*Kubernetes 中应用程序的单个实例*，它可能由单个 {{< glossary_tooltip text="容器" term_id="container" >}} 或少量紧密耦合并共享资源的容器组成。
<!--
[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well.
-->
[Docker](https://www.docker.com) 是 Kubernetes Pod 中最常用的容器运行时，但 Pod 也能支持其他的[容器运行时](/docs/setup/production-environment/container-runtimes/)。
<!--
Pods in a Kubernetes cluster can be used in two main ways:
-->
Kubernetes 集群中的 Pod 可被用于以下两个主要用途：
<!--
* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
The [Kubernetes Blog](https://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
-->
* **运行单个容器的 Pod**。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例；在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。
* **运行多个协同工作的容器的 Pod**。
Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。
这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”（sidecar）容器则刷新或更新这些文件。
Pod 将这些容器和存储资源打包为一个可管理的实体。
[Kubernetes 博客](https://kubernetes.io/blog) 上有一些其他的 Pod 用例信息。更多信息请参考：
<!--
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
-->
* [分布式系统工具包：容器组合的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [容器设计模式](https://kubernetes.io/blog/2016/06/container-design-patterns)
<!--
Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information.
-->
每个 Pod 表示运行给定应用程序的单个实例。如果希望横向扩展应用程序（例如，运行多个实例），则应该使用多个 Pod，每个应用实例使用一个 Pod 。在 Kubernetes 中，这通常被称为 _副本_。通常使用一个称为控制器的抽象来创建和管理一组副本 Pod。更多信息请参见 [Pod 和控制器](#pods-and-controllers)。
<!--
### How Pods manage multiple Containers
-->
### Pod 怎样管理多个容器
<!--
Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
-->
Pod 被设计成支持形成内聚服务单元的多个协作过程（作为容器）。
Pod 中的容器被自动的安排到集群中的同一物理或虚拟机上，并可以一起进行调度。
容器可以共享资源和依赖、彼此通信、协调何时以及何种方式终止它们。
<!--
Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:
-->
注意，在单个 Pod 中将多个并置和共同管理的容器分组是一个相对高级的使用方式。
只在容器紧密耦合的特定实例中使用此模式。
例如，您可能有一个充当共享卷中文件的 Web 服务器的容器，以及一个单独的 sidecar 容器，该容器从远端更新这些文件，如下图所示：
{{< figure src="/images/docs/pod.svg" alt="Pod 图例" width="50%" >}}
<!--
Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
-->
有些 Pod 具有 {{< glossary_tooltip text="初始容器" term_id="init-container" >}} 和 {{< glossary_tooltip text="应用容器" term_id="app-container" >}}。初始容器会在启动应用容器之前运行并完成。
<!--
Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*.
-->
Pod 为其组成容器提供了两种共享资源：*网络* 和 *存储*。
<!--
#### Networking
-->
#### 网络
<!--
Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports).
-->
每个 Pod 分配一个唯一的 IP 地址。
Pod 中的每个容器共享网络命名空间，包括 IP 地址和网络端口。
*Pod 内的容器* 可以使用 `localhost` 互相通信。
当 Pod 中的容器与 *Pod 之外* 的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。
<!--
#### Storage
-->
#### 存储
<!--
A Pod can specify a set of shared storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod.
-->
一个 Pod 可以指定一组共享存储{{< glossary_tooltip text="卷" term_id="volume" >}}。
Pod 中的所有容器都可以访问共享卷，允许这些容器共享数据。
卷还允许 Pod 中的持久数据保留下来，以防其中的容器需要重新启动。
有关 Kubernetes 如何在 Pod 中实现共享存储的更多信息，请参考[卷](/docs/concepts/storage/volumes/)。
<!--
## Working with Pods
-->
## 使用 Pod
<!--
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the Node fails.
-->
你很少在 Kubernetes 中直接创建单独的 Pod，甚至是单个存在的 Pod。
这是因为 Pod 被设计成了相对短暂的一次性的实体。
当 Pod 由您创建或者间接地由控制器创建时，它被调度在集群中的 {{< glossary_tooltip term_id="node" >}} 上运行。
Pod 会保持在该节点上运行，直到进程被终止、Pod 对象被删除、Pod 因资源不足而被 *驱逐* 或者节点失效为止。
<!--
Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
-->
{{< note >}}
重启 Pod 中的容器不应与重启 Pod 混淆。Pod 本身不运行，而是作为容器运行的环境，并且一直保持到被删除为止。
{{< /note >}}
<!--
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
-->
Pod 本身并不能自愈。
如果 Pod 被调度到失败的节点，或者如果调度操作本身失败，则删除该 Pod；同样，由于缺乏资源或进行节点维护，Pod 在被驱逐后将不再生存。
Kubernetes 使用了一个更高级的称为 *控制器* 的抽象，由它处理相对可丢弃的 Pod 实例的管理工作。
因此，虽然可以直接使用 Pod，但在 Kubernetes 中，更为常见的是使用控制器管理 Pod。
有关 Kubernetes 如何使用控制器实现 Pod 伸缩和愈合的更多信息，请参考 [Pod 和控制器](#pods-and-controllers)。
<!--
### Pods and Controllers
-->
### Pod 和控制器 {#pods-and-controllers}
<!--
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.
-->
控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。
例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。
<!--
Some examples of Controllers that contain one or more pods include:
-->
包含一个或多个 Pod 的控制器一些示例包括：
<!--
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-->
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
<!--
In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
-->
控制器通常使用您提供的 Pod 模板来创建它所负责的 Pod。
<!--
## Pod Templates
-->
## Pod 模板
<!--
Pod templates are pod specifications which are included in other objects, such as
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Controllers use Pod Templates to make actual pods.
The sample below is a simple manifest for a Pod which contains a container that prints
a message.
-->
Pod 模板是包含在其他对象中的 Pod 规范，例如
[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) 和
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/)。
控制器使用 Pod 模板来制作实际使用的 Pod。
下面的示例是一个简单的 Pod 清单，它包含一个打印消息的容器。
```yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
```
<!--
Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no "quantum entanglement". Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.
-->
Pod 模板就像饼干切割器，而不是指定所有副本的当前期望状态。
一旦饼干被切掉，饼干就与切割器没有关系。
没有“量子纠缠”。
随后对模板的更改或甚至切换到新的模板对已经创建的 Pod 没有直接影响。
类似地，由副本控制器创建的 Pod 随后可以被直接更新。
这与 Pod 形成有意的对比，Pod 指定了属于 Pod 的所有容器的当前期望状态。
这种方法从根本上简化了系统语义，增加了原语的灵活性。
<!--
* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
* Learn more about Pod behavior:
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-->
## {{% heading "whatsnext" %}}
* 详细了解 [Pod](/docs/concepts/workloads/pods/pod/)
* 了解有关 Pod 行为的更多信息：
* [Pod 的终止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)
content/zh/docs/concepts/workloads/pods/pod.md
-387
View File
@@ -1,387 +0,0 @@
---
title: Pods
content_type: concept
weight: 20
---
<!--
reviewers:
title: Pods
content_type: concept
weight: 20
-->
<!-- overview -->
<!--
_Pods_ are the smallest deployable units of computing that can be created and
managed in Kubernetes.
-->
_Pod_ 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
<!-- body -->
<!--
## What is a Pod?
-->
## Pod 是什么？
<!--
A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
{{< glossary_tooltip text="containers" term_id="container" >}} (such as
Docker containers), with shared storage/network, and a specification
for how to run the containers. A Pod's contents are always co-located and
co-scheduled, and run in a shared context. A Pod models an
application-specific "logical host" - it contains one or more application
containers which are relatively tightly coupled &mdash; in a pre-container
world, being executed on the same physical or virtual machine would mean being
executed on the same logical host.
-->
_Pod_ （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）{{< glossary_tooltip text="容器" term_id="container" >}}（例如 Docker 容器），这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。
Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起 &mdash; 在容器出现之前，在相同的物理机或虚拟机上运行意味着在相同的逻辑主机上运行。
<!--
While Kubernetes supports more container runtimes than just Docker, Docker is
the most commonly known runtime, and it helps to describe Pods in Docker terms.
-->
虽然 Kubernetes 支持多种容器运行时，但 Docker 是最常见的一种运行时，它有助于使用 Docker 术语来描述 Pod。
<!--
The shared context of a Pod is a set of Linux namespaces, cgroups, and
potentially other facets of isolation - the same things that isolate a Docker
container. Within a Pod's context, the individual applications may have
further sub-isolations applied.
-->
Pod 的共享上下文是一组 Linux 命名空间、cgroups、以及其他潜在的资源隔离相关的因素，这些相同的东西也隔离了 Docker 容器。在 Pod 的上下文中，单个应用程序可能还会应用进一步的子隔离。
<!--
Containers within a Pod share an IP address and port space, and
can find each other via `localhost`. They can also communicate with each
other using standard inter-process communications like SystemV semaphores or
POSIX shared memory. Containers in different Pods have distinct IP addresses
and can not communicate by IPC without
[special configuration](/docs/concepts/policy/pod-security-policy/).
These containers usually communicate with each other via Pod IP addresses.
Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined
as part of a Pod and are made available to be mounted into each application's
filesystem.
-->
Pod 中的所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 互相发现。他们也能通过标准的进程间通信（如 SystemV 信号量或 POSIX 共享内存）方式进行互相通信。不同 Pod 中的容器的 IP 地址互不相同，没有 [特殊配置](/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。这些容器之间经常通过 Pod IP 地址进行通信。
Pod 中的应用也能访问共享 {{< glossary_tooltip text="卷" term_id="volume" >}}，共享卷是 Pod 定义的一部分，可被用来挂载到每个应用的文件系统上。
<!--
In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as
a group of Docker containers with shared namespaces and shared filesystem
volumes.
-->
在 [Docker](https://www.docker.com/) 体系的术语中，Pod 被建模为一组具有共享命名空间和共享文件系统[卷](/docs/concepts/storage/volumes/) 的 Docker 容器。
<!--
Like individual application containers, Pods are considered to be relatively
ephemeral (rather than durable) entities. As discussed in
[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and
scheduled to nodes where they remain until termination (according to restart
policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are
scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not
"rescheduled" to a new node; instead, it can be replaced by an identical Pod,
with even the same name if desired, but with a new UID (see [replication
controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details).
-->
与单个应用程序容器一样，Pod 被认为是相对短暂的（而不是持久的）实体。如 [Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) 所讨论的那样：Pod 被创建、给它指定一个唯一 ID （UID）、被调度到节点、在节点上存续直到终止（取决于重启策略）或被删除。如果 {{< glossary_tooltip term_id="node" >}} 宕机，调度到该节点上的 Pod 会在一个超时周期后被安排删除。给定 Pod （由 UID 定义）不会重新调度到新节点；相反，它会被一个完全相同的 Pod 替换掉，如果需要甚至连 Pod 名称都可以一样，除了 UID 是新的(更多信息请查阅 [副本控制器（replication
controller）](/docs/concepts/workloads/controllers/replicationcontroller/)。
<!--
When something is said to have the same lifetime as a Pod, such as a volume,
that means that it exists as long as that Pod (with that UID) exists. If that
Pod is deleted for any reason, even if an identical replacement is created, the
related thing (e.g. volume) is also destroyed and created anew.
-->
当某些东西被说成与 Pod（如卷）具有相同的生命周期时，这表明只要 Pod（具有该 UID）存在，它就存在。如果出于任何原因删除了该 Pod，即使创建了相同的 Pod，相关的内容（例如卷）也会被销毁并重新创建。
{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
<!--
*A multi-container Pod that contains a file puller and a
web server that uses a persistent volume for shared storage between the containers.*
-->
*一个多容器 Pod，其中包含一个文件拉取器和一个 Web 服务器，该 Web 服务器使用持久卷在容器之间共享存储*
<!--
## Motivation for pods
-->
## 设计 Pod 的目的
<!--
### Management
-->
### 管理
<!--
Pods are a model of the pattern of multiple cooperating processes which form a
cohesive unit of service. They simplify application deployment and management
by providing a higher-level abstraction than the set of their constituent
applications. Pods serve as unit of deployment, horizontal scaling, and
replication. Colocation (co-scheduling), shared fate (e.g. termination),
coordinated replication, resource sharing, and dependency management are
handled automatically for containers in a Pod.
-->
Pod 是形成内聚服务单元的多个协作过程模式的模型。它们提供了一个比它们的应用组成集合更高级的抽象，从而简化了应用的部署和管理。Pod 可以用作部署、水平扩展和制作副本的最小单元。在 Pod 中，系统自动处理多个容器的在并置运行（协同调度）、生命期共享（例如，终止），协同复制、资源共享和依赖项管理。
<!--
### Resource sharing and communication
-->
### 资源共享和通信
<!--
Pods enable data sharing and communication among their constituents.
-->
Pod 使它的组成容器间能够进行数据共享和通信。
<!--
The applications in a Pod all use the same network namespace (same IP and port
space), and can thus "find" each other and communicate using `localhost`.
Because of this, applications in a Pod must coordinate their usage of ports.
Each Pod has an IP address in a flat shared networking space that has full
communication with other physical computers and Pods across the network.
-->
Pod 中的应用都使用相同的网络命名空间（相同 IP 和 端口空间），而且能够互相“发现”并使用 `localhost` 进行通信。因此，在 Pod 中的应用必须协调它们的端口使用情况。每个 Pod 在扁平的共享网络空间中具有一个 IP 地址，该空间通过网络与其他物理计算机和 Pod 进行全面通信。
<!--
Containers within the Pod see the system hostname as being the same as the configured
`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/)
section.
-->
Pod 中的容器获取的系统主机名与为 Pod 配置的 `name` 相同。[网络](/docs/concepts/cluster-administration/networking/) 部分提供了更多有关此内容的信息。
<!--
In addition to defining the application containers that run in the Pod, the Pod
specifies a set of shared storage volumes. Volumes enable data to survive
container restarts and to be shared among the applications within the Pod.
-->
Pod 除了定义了 Pod 中运行的应用程序容器之外，Pod 还指定了一组共享存储卷。该共享存储卷能使数据在容器重新启动后继续保留，并能在 Pod 内的应用程序之间共享。
<!--
## Uses of pods
-->
## 使用 Pod
<!--
Pods can be used to host vertically integrated application stacks (e.g. LAMP),
but their primary motivation is to support co-located, co-managed helper
programs, such as:
* content management systems, file and data loaders, local cache managers, etc.
* log and checkpoint backup, compression, rotation, snapshotting, etc.
* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
* proxies, bridges, and adapters
* controllers, managers, configurators, and updaters
-->
Pod 可以用于托管垂直集成的应用程序栈（例如，LAMP），但最主要的目的是支持位于同一位置的、共同管理的工具程序，例如：
* 内容管理系统、文件和数据加载器、本地缓存管理器等。
* 日志和检查点备份、压缩、旋转、快照等。
* 数据更改监视器、日志跟踪器、日志和监视适配器、事件发布器等。
* 代理、桥接器和适配器
* 控制器、管理器、配置器和更新器
<!--
Individual Pods are not intended to run multiple instances of the same
application, in general.
-->
通常，不会用单个 Pod 来运行同一应用程序的多个实例。
<!--
For a longer explanation, see [The Distributed System ToolKit: Patterns for
Composite
Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
-->
有关详细说明，请参考 [分布式系统工具包：组合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)。
<!--
## Alternatives considered
-->
## 可考虑的备选方案
<!--
_Why not just run multiple programs in a single (Docker) container?_
1. Transparency. Making the containers within the Pod visible to the
infrastructure enables the infrastructure to provide services to those
containers, such as process management and resource monitoring. This
facilitates a number of conveniences for users.
1. Decoupling software dependencies. The individual containers may be
versioned, rebuilt and redeployed independently. Kubernetes may even support
live updates of individual containers someday.
1. Ease of use. Users don't need to run their own process managers, worry about
signal and exit-code propagation, etc.
1. Efficiency. Because the infrastructure takes on more responsibility,
containers can be lighter weight.
-->
_为什么不在单个（Docker）容器中运行多个程序？_
1. 透明度。Pod 内的容器对基础设施可见，使得基础设施能够向这些容器提供服务，例如流程管理和资源监控。这为用户提供了许多便利。
1. 解耦软件依赖关系。可以独立地对单个容器进行版本控制、重新构建和重新部署。Kubernetes 有一天甚至可能支持单个容器的实时更新。
1. 易用性。用户不需要运行他们自己的进程管理器、也不用担心信号和退出代码传播等。
1. 效率。因为基础结构承担了更多的责任，所以容器可以变得更加轻量化。
<!--
_Why not support affinity-based co-scheduling of containers?_
-->
_为什么不支持基于亲和性的容器协同调度？_
<!--
That approach would provide co-location, but would not provide most of the
benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and
simplified management.
-->
这种处理方法尽管可以提供同址，但不能提供 Pod 的大部分好处，如资源共享、IPC、有保证的命运共享和简化的管理。
<!--
## Durability of pods (or lack thereof)
-->
## Pod 的持久性（或稀缺性）
<!--
Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
-->
不得将 Pod 视为持久实体。它们无法在调度失败、节点故障或其他驱逐策略（例如由于缺乏资源或在节点维护的情况下）中生存。
<!--
In general, users shouldn't need to create Pods directly. They should almost
always use controllers even for singletons, for example,
[Deployments](/docs/concepts/workloads/controllers/deployment/).
Controllers provide self-healing with a cluster scope, as well as replication
and rollout management.
Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)
can also provide support to stateful Pods.
-->
一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的 Pod 创建也一样使用控制器，例如 [Deployments](/docs/concepts/workloads/controllers/deployment/)。
控制器提供集群范围的自修复以及副本数和滚动管理。
像 [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) 这样的控制器还可以提供支持有状态的 Pod。
<!--
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
-->
在集群调度系统中，使用 API 合集作为面向用户的主要原语是比较常见的，包括 [Borg](https://research.google.com/pubs/pub43438.html)、[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、和 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)。
<!--
Pod is exposed as a primitive in order to facilitate:
-->
Pod 暴露为原语是为了便于：
<!--
* scheduler and controller pluggability
* support for pod-level operations without the need to "proxy" them via controller APIs
* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping
* decoupling of controllers and services &mdash; the endpoint controller just watches Pods
* clean composition of Kubelet-level functionality with cluster-level functionality &mdash; Kubelet is effectively the "pod controller"
* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.
-->
* 调度器和控制器可插拔性
* 支持 Pod 级别的操作，而不需要通过控制器 API "代理" 它们
* Pod 生命与控制器生命的解耦，如自举
* 控制器和服务的解耦 &mdash; 端点控制器只监视 Pod
* kubelet 级别的功能与集群级别功能的清晰组合 &mdash; kubelet 实际上是 "Pod 控制器"
* 高可用性应用程序期望在 Pod 终止之前并且肯定要在 Pod 被删除之前替换 Pod，例如在计划驱逐或镜像预先拉取的情况下。
<!--
## Termination of Pods
-->
## Pod 的终止
<!--
Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
-->
因为 Pod 代表在集群中的节点上运行的进程，所以当不再需要这些进程时（与被 KILL 信号粗暴地杀死并且没有机会清理相比），允许这些进程优雅地终止是非常重要的。
用户应该能够请求删除并且知道进程何时终止，但是也能够确保删除最终完成。当用户请求删除 Pod 时，系统会记录在允许强制删除 Pod 之前所期望的宽限期，并向每个容器中的主进程发送 TERM 信号。一旦过了宽限期，KILL 信号就发送到这些进程，然后就从 API 服务器上删除 Pod。如果 Kubelet 或容器管理器在等待进程终止时发生重启，则终止操作将以完整的宽限期进行重试。
<!--
An example flow:
-->
流程示例：
<!--
1. User sends command to delete Pod, with default grace period (30s)
1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
1. Pod shows up as "Terminating" when listed in client commands
1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process.
1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters.
1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.
-->
1. 用户发送命令删除 Pod，使用的是默认的宽限期（30秒）
1. API 服务器中的 Pod 会随着宽限期规定的时间进行更新，过了这个时间 Pod 就会被认为已 "死亡"。
1. 当使用客户端命令查询 Pod 状态时，Pod 显示为 "Terminating"。
1. （和第 3 步同步进行）当 Kubelet 看到 Pod 由于步骤 2 中设置的时间而被标记为 terminating 状态时，它就开始执行关闭 Pod 流程。
1. 如果 Pod 定义了 [preStop 钩子](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)，就在 Pod 内部调用它。如果宽限期结束了，但是 `preStop` 钩子还在运行，那么就用小的（2 秒）扩展宽限期调用步骤 2。
1. 给 Pod 内的进程发送 TERM 信号。请注意，并不是所有 Pod 中的容器都会同时收到 TERM 信号，如果它们关闭的顺序很重要，则每个容器可能都需要一个 `preStop` 钩子。
1. （和第 3 步同步进行）从服务的端点列表中删除 Pod，Pod 也不再被视为副本控制器的运行状态的 Pod 集的一部分。因为负载均衡器（如服务代理）会将其从轮换中删除，所以缓慢关闭的 Pod 无法继续为流量提供服务。
1. 当宽限期到期时，仍在 Pod 中运行的所有进程都会被 SIGKILL 信号杀死。
1. kubelet 将通过设置宽限期为 0 （立即删除）来完成在 API 服务器上删除 Pod 的操作。该 Pod 从 API 服务器中消失，并且在客户端中不再可见。
<!--
By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=<seconds>` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod.
You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions.
-->
默认情况下，所有删除操作宽限期是 30 秒。`kubectl delete` 命令支持 `--grace-period=<seconds>` 选项，允许用户覆盖默认值并声明他们自己的宽限期。设置为 `0` 会[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) Pod。您必须指定一个附加标志 `--force` 和 `--grace-period=0` 才能执行强制删除操作。
<!--
### Force deletion of pods
-->
### Pod 的强制删除
<!--
Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
-->
强制删除 Pod 被定义为从集群状态与 etcd 中立即删除 Pod。当执行强制删除时，API 服务器并不会等待 kubelet 的确认信息，该 Pod 已在所运行的节点上被终止了。强制执行删除操作会从 API 服务器中立即清除 Pod， 因此可以用相同的名称创建一个新的 Pod。在节点上，设置为立即终止的 Pod 还是会在被强制删除前设置一个小的宽限期。
<!--
Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-->
强制删除对某些 Pod 可能具有潜在危险，因此应该谨慎地执行。对于 StatefulSet 管理的 Pod，请参考 [从 StatefulSet 中删除 Pod](/docs/tasks/run-application/force-delete-stateful-set-pod/) 的任务文档。
<!--
## Privileged mode for pod containers
-->
## Pod 容器的特权模式
<!--
Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet.
-->
Pod 中的任何容器都可以使用容器规范 [security context](/docs/tasks/configure-pod-container/security-context/) 上的 `privileged` 参数启用特权模式。这对于想要使用 Linux 功能（如操纵网络堆栈和访问设备）的容器很有用。容器内的进程几乎可以获得与容器外的进程相同的特权。使用特权模式，将网络和卷插件编写为不需要编译到 kubelet 中的独立的 Pod 应该更容易。
<!--
Your container runtime must support the concept of a privileged container for this setting to be relevant.
-->
{{< note >}}
您的容器运行时必须支持特权容器模式才能使用此设置。
{{< /note >}}
<!--
## API Object
-->
## API 对象
<!--
Pod is a top-level resource in the Kubernetes REST API.
The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
describes the object in detail.
-->
Pod 是 Kubernetes REST API 中的顶级资源。
[Pod API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)定义详细描述了该 Pod 对象。
content/zh/docs/contribute/advanced.md
+7 -7
View File
@@ -30,11 +30,11 @@ client and other tools for some of these tasks.
<!--
## Propose improvements
SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members) can propose improvements.
-->
## 提出改进建议
SIG Docs 的 [成员](/zh/docs/contribute/participating/#members) 可以提出改进建议。
SIG Docs 的 [成员](/zh/docs/contribute/participate/roles-and-responsibilities/#members) 可以提出改进建议。
<!--
After you've been contributing to the Kubernetes documentation for a while, you
@@ -82,13 +82,13 @@ Kubernetes 版本发布协调文档工作。
<!--
Each Kubernetes release is coordinated by a team of people participating in the
sig-release Special Interest Group (SIG). Others on the release team for a given
release include an overall release lead, as well as representatives from sig-pm,
sig-testing, and others. To find out more about Kubernetes release processes,
release include an overall release lead, as well as representatives from
sig-testing and others. To find out more about Kubernetes release processes,
refer to
[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release).
-->
每一个 Kubernetes 版本都是由参与 sig-release 的 SIG（特别兴趣小组）的一个团队协调的。
指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-pm、sig-testing 的代表等。
指定版本的发布团队中还包括总体发布牵头人，以及来自 sig-testing 的代表等。
要了解更多关于 Kubernetes 版本发布的流程，请参考
[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)。
@@ -185,7 +185,7 @@ organization. The contributor's membership needs to be backed by two sponsors
who are already reviewers.
-->
新的贡献者针对一个或多个 Kubernetes 项目仓库成功提交了 5 个实质性 PR 之后，
就有资格申请 Kubernetes 组织的[成员身份](/zh/docs/contribute/participating#members)。
就有资格申请 Kubernetes 组织的[成员身份](/zh/docs/contribute/participate/roles-and-responsibilities/#members)。
贡献者的成员资格需要同时得到两位评审人的保荐。
<!--
@@ -211,7 +211,7 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term
-->
## 担任 SIG 联合主席
SIG Docs [批准人（Approvers）](/zh/docs/contribute/participating/#approvers)
SIG Docs [批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers)
可以担任 SIG Docs 的联合主席。
### 前提条件
content/zh/docs/contribute/generate-ref-docs/_index.md
+1 -1
View File
@@ -22,5 +22,5 @@ To build the reference documentation, see the following guide:
本节的主题是描述如何生成 Kubernetes 参考指南。
要生成参考文档，请参考下面的指南：
* [生成参考文档快速入门](/docs/contribute/generate-ref-docs/quickstart/)
* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/)
content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
+6 -6
View File
@@ -29,8 +29,8 @@ API or the `kube-*` components from the upstream code, see the following instruc
-->
如果您仅想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明：
- [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)
- [生成 Kubernetes 组件和工具的参考文档](/docs/contribute/generate-ref-docs/kubernetes-components/)
- [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/)
- [生成 Kubernetes 组件和工具的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)
## {{% heading "prerequisites" %}}
@@ -395,7 +395,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
-->
现在，您可以按照
[生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)
[生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/)
指南来生成
[已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
@@ -406,7 +406,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
-->
* [生成 Kubernetes API 的参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generated-reference/kubernetes-components/)
* [生成 kubectl 命令的参考文档](/docs/home/contribute/generated-reference/kubectl/)
* [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/)
* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)
* [生成 kubectl 命令的参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/)
content/zh/docs/contribute/generate-ref-docs/kubectl.md
+6 -6
View File
@@ -35,8 +35,8 @@ reference page, see
本主题描述了如何为 [kubectl 命令](/docs/reference/generated/kubectl/kubectl-commands)
生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和
[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。
本主题没有讨论如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl/) 组件选项的参考页面。
相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/docs/home/contribute/generated-reference/kubernetes-components/)。
本主题没有讨论如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 组件选项的参考页面。
相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)。
{{< /note >}}
## {{% heading "prerequisites" %}}
@@ -412,7 +412,7 @@ topics will be visible in the
对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。
继续跟踪你的 PR，直到它被合入。
在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/docs/home/)中。
在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/zh/docs/home/)中。
## {{% heading "whatsnext" %}}
@@ -421,7 +421,7 @@ topics will be visible in the
* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
-->
* [生成参考文档快速入门](/docs/home/contribute/generate-ref-docs/quickstart/)
* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-components/)
* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-api/)
* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/)
* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)
* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/)
content/zh/docs/contribute/generate-ref-docs/kubernetes-api.md
+6 -6
View File
@@ -31,7 +31,7 @@ Kubernetes API 参考文档是从
构建的，而工具是从
[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 构建的。
如果您在生成的文档中发现错误，则需要[在上游修复](/docs/contribute/generate-ref-docs/contribute-upstream/)。
如果您在生成的文档中发现错误，则需要[在上游修复](/zh/docs/contribute/generate-ref-docs/contribute-upstream/)。
如果您只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页。
@@ -280,12 +280,12 @@ In `<web-base>` run `git add` and `git commit` to commit the change.
<!--
Submit your changes as a
[pull request](/docs/contribute/start/) to the
[pull request](/docs/contribute/new-content/open-a-pr/) to the
[kubernetes/website](https://github.com/kubernetes/website) repository.
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
-->
基于你所生成的更改[创建 PR](/docs/contribute/start/)，
基于你所生成的更改[创建 PR](/zh/docs/contribute/new-content/open-a-pr/)，
提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。
监视您提交的 PR，并根据需要回复 reviewer 的评论。继续监视您的 PR，直到合并为止。
@@ -296,7 +296,7 @@ to monitor your pull request until it has been merged.
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
-->
* [生成参考文档快速入门](/docs/home/contribute/generate-ref-docs/quickstart/)
* [为 Kubernetes 组件和工具生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-components/)
* [为 kubectl 命令集生成参考文档](/docs/home/contribute/generate-ref-docs/kubectl/)
* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/)
* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)
* [为 kubectl 命令集生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/)
content/zh/docs/contribute/generate-ref-docs/kubernetes-components.md
+6 -6
View File
@@ -23,7 +23,7 @@ This page shows how to build the Kubernetes component and tool reference pages.
Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)
in the Reference Documentation Quickstart guide.
-->
阅读参考文档快速入门指南中的[准备工作](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。
阅读参考文档快速入门指南中的[准备工作](/zh/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。
<!-- steps -->
@@ -31,7 +31,7 @@ in the Reference Documentation Quickstart guide.
Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
to generate the Kubernetes component and tool reference pages.
-->
按照[参考文档快速入门](/docs/contribute/generate-ref-docs/quickstart/)
按照[参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/)
指引，生成 Kubernetes 组件和工具的参考文档。
## {{% heading "whatsnext" %}}
@@ -43,8 +43,8 @@ to generate the Kubernetes component and tool reference pages.
* [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/)
-->
* [生成参考文档快速入门](/docs/home/contribute/generate-ref-docs/quickstart/)
* [为 kubectll 命令生成参考文档](/docs/home/contribute/generate-ref-docs/kubectl/)
* [为 Kubernetes API 生成参考文档](/docs/home/contribute/generate-ref-docs/kubernetes-api/)
* [为上游 Kubernetes 项目做贡献以改进文档](/docs/contribute/generate-ref-docs/contribute-upstream/)
* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/)
* [为 kubectll 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/)
* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/)
* [为上游 Kubernetes 项目做贡献以改进文档](/zh/docs/contribute/generate-ref-docs/contribute-upstream/)
content/zh/docs/contribute/generate-ref-docs/quickstart.md
+6 -6
View File
@@ -57,7 +57,7 @@ see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contrib
{{< note>}}
如果你希望更改构建工具和 API 参考资料，可以阅读
[上游贡献指南](/docs/contribute/generate-ref-docs/contribute-upstream).
[上游贡献指南](/zh/docs/contribute/generate-ref-docs/contribute-upstream).
{{< /note >}}
<!--
@@ -185,7 +185,7 @@ Single page Markdown documents, imported by the tool, must adhere to
the [Documentation Style Guide](/docs/contribute/style/style-guide/).
-->
通过工具导入的单页面的 Markdown 文档必须遵从
[文档样式指南](/docs/contribute/style/style-guide/)。
[文档样式指南](/zh/docs/contribute/style/style-guide/)。
<!--
## Customizing reference.yml
@@ -385,7 +385,7 @@ topics will be visible in the
继续监视该 PR 直到其被合并为止。
当你的 PR 被合并几分钟之后，你所做的对参考文档的变更就会出现
[发布的文档](/docs/home/)上。
[发布的文档](/zh/docs/home/)上。
## {{% heading "whatsnext" %}}
@@ -399,7 +399,7 @@ running the build targets, see the following guides:
-->
要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南：
* [为 Kubernetes 组件和工具生成参考文档](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [为 kubeclt 命令生成参考文档](/docs/contribute/generate-ref-docs/kubectl/)
* [为 Kubernetes API 生成参考文档](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)
* [为 kubeclt 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/)
* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/)
content/zh/docs/contribute/localization.md
+4 -4
View File
@@ -62,7 +62,7 @@ First, [create your own fork](/docs/contribute/start/#improve-existing-content)
### 派生（fork）并且克隆仓库 {#fork-and-clone-the-repo}
首先，为 [kubernetes/website](https://github.com/kubernetes/website) 仓库
[创建你自己的副本](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。
[创建你自己的副本](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
<!--
Then, clone your fork and `cd` into it:
@@ -359,7 +359,7 @@ Site strings | [All site strings in a new localized TOML file](https://github.co
-----|-----
主页 | [所有标题和副标题网址](/zh/docs/home/)
安装 | [所有标题和副标题网址](/zh/docs/setup/)
教程 | [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh/docs/tutorials/stateless-application/hello-minikube/)
教程 | [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh/docs/tutorials/hello-minikube/)
网站字符串 | [新的本地化 TOML 文件中的所有网站字符串](https://github.com/kubernetes/website/tree/master/i18n)
<!--
@@ -545,11 +545,11 @@ For more information about working from forks or directly from the repository, s
<!--
## Upstream contributions
SIG Docs welcomes [upstream contributions and corrections](/docs/contribute/intermediate#localize-content) to the English source.
SIG Docs welcomes upstream contributions and corrections to the English source.
-->
### 上游贡献 {#upstream-contributions}
Sig Docs 欢迎对英文原文的[上游贡献和修正](/zh/docs/contribute/intermediate#localize-content)。
Sig Docs 欢迎对英文原文的上游贡献和修正。
<!--
## Help an existing localization
content/zh/docs/contribute/new-content/open-a-pr.md
+1 -3
View File
@@ -1,6 +1,5 @@
---
title: 发起拉取请求（PR）
slug: new-content
content_type: concept
weight: 10
card:
@@ -9,7 +8,6 @@ card:
---
<!--
title: Opening a pull request
slug: new-content
content_type: concept
weight: 10
card:
@@ -879,5 +877,5 @@ PR，也可以添加对它们的链接。你可以多少了解该团队的流程
<!--
- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
-->
- 阅读[评阅](/zh/docs/contribute/review/revewing-prs)节，学习评阅过程。
- 阅读[评阅](/zh/docs/contribute/review/reviewing-prs)节，学习评阅过程。
content/zh/docs/contribute/participate/_index.md
+4 -4
View File
@@ -206,7 +206,7 @@ SIG Docs 批准人。下面是合并的工作机制：
- 所有 Kubernetes 成员可以通过 `/lgtm` 评论添加 `lgtm` 标签。
- 只有 SIG Docs 批准人可以通过评论 `/approve` 合并 PR。
某些批准人还会执行一些其他角色，例如
[PR 管理者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 或
[PR 管理者](/zh/docs/contribute/participate/pr-wranglers/) 或
[SIG Docs 主席](#sig-docs-chairperson)等。
## {{% heading "whatsnext" %}}
@@ -220,6 +220,6 @@ For more information about contributing to the Kubernetes documentation, see:
-->
关于贡献 Kubernetes 文档的更多信息，请参考：
- [贡献新内容](/docs/contribute/overview/)
- [评阅内容](/docs/contribute/review/reviewing-prs)
- [文档样式指南](/docs/contribute/style/)
- [贡献新内容](/zh/docs/contribute/new-content/overview/)
- [评阅内容](/zh/docs/contribute/review/reviewing-prs)
- [文档样式指南](/zh/docs/contribute/style/)
content/zh/docs/contribute/participate/pr-wranglers.md
+13 -10
View File
@@ -81,31 +81,34 @@ These queries exclude localization PRs. All queries are against the main branch
这些查询都不包含本地化的 PR，并仅包含主分支上的 PR（除了最后一个查询）。
<!--
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
- [Needs LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
Lists PRs that need an `/approve` comment to merge.
- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
- [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
-->
- [未签署 CLA，不可合并的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen)：
- [未签署 CLA，不可合并的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen)：
提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。
**在作者没有签署 CLA 之前，不要审阅他们的 PR！**
- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+)：
- [需要 LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm)：
列举需要来自成员的 LGTM 评论的 PR。
如果需要技术审查，请告知机器人所建议的审阅者。
如果 PR 继续改进，就地提供更改建议或反馈。
- [已有 LGTM标签，需要 Docs 团队批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm)：
- [已有 LGTM标签，需要 Docs 团队批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+)：
列举需要 `/approve` 评论来合并的 PR。
- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)：
- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22)：
列举针对主分支的、没有明确合并障碍的 PR。
在浏览 PR 时，可以将 "XS" 尺寸标签更改为 "S"、"M"、"L"、"XL"、"XXL"。
- [非主分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)：
- [非主分支的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster)：
如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。
请添加带有 `/assign @<负责人的 github 账号>`，将其指派给
[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)。
content/zh/docs/contribute/participate/roles-and-responsibilties.md → content/zh/docs/contribute/participate/roles-and-responsibilities.md
+1 -1
View File
@@ -58,7 +58,7 @@ For more information, see [contributing new content](/docs/contribute/new-conten
[`kubernetes/website`](https://github.com/kubernetes/website) 上报告 Issue。
- 对某 PR 给出无约束力的反馈信息
- 为本地化提供帮助
- 在 [Slack](http://slack.k8s.io/) 或
- 在 [Slack](https://slack.k8s.io/) 或
[SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
上提出改进建议。
content/zh/docs/contribute/review/for-approvers.md
+8 -7
View File
@@ -15,7 +15,7 @@ weight: 20
<!-- overview -->
<!--
SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
SIG Docs [Reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers) and [Approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) do a few extra things when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
@@ -26,8 +26,9 @@ requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
-->
SIG Docs [评阅人（Reviewers）](/docs/contribute/participating/#reviewers)
和[批准人（Approvers）](/docs/contribute/participating/#approvers)
SIG Docs
[评阅人（Reviewers）](/zh/docs/contribute/participate/roles-and-responsibilities/#reviewers)
和[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers)
在对变更进行评审时需要做一些额外的事情。
每周都有一个特定的文档批准人自愿负责对 PR 进行分类和评阅。
@@ -50,7 +51,7 @@ Everything described in [Reviewing a pull request](/docs/contribute/review/revie
Kubernetes 文档遵循 [Kubernetes 代码评阅流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。
[评阅 PR](/docs/contribute/review/reviewing-prs) 文档中所描述的所有规程都适用，
[评阅 PR](/zh/docs/contribute/review/reviewing-prs/) 文档中所描述的所有规程都适用，
不过评阅人和批准人还要做以下工作：
<!--
@@ -73,7 +74,7 @@ when it comes to requesting technical review from code contributors.
你可以查看 Markdown 文件的文件头，其中的 `reviewers` 字段给出了哪些人可以为文档提供技术审核。
{{< /note >}}
- 确保 PR 遵从[内容指南](/docs/contribute/style/content-guide/)和[样式指南](/docs/contribute/style/style-guide/)；
- 确保 PR 遵从[内容指南](/zh/docs/contribute/style/content-guide/)和[样式指南](/zh/docs/contribute/style/style-guide/)；
如果 PR 没有达到要求，指引作者阅读指南中的相关部分。
- 适当的时候使用 GitHub **Request Changes** 选项，建议 PR 作者实施所建议的修改。
- 当你所提供的建议被采纳后，在 GitHub 中使用 `/approve` 或 `/lgtm` Prow 命令，改变评审状态。
@@ -406,9 +407,9 @@ Sample response to a request for support:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](http://slack.k8s.io/). You can also search
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
content/zh/docs/contribute/review/reviewing-prs.md
+7 -7
View File
@@ -34,9 +34,9 @@ Before reviewing, it's a good idea to:
在评阅之前，可以考虑：
- 阅读[内容指南](/docs/contribute/style/content-guide/)和
[样式指南](/docs/contribute/style/style-guide/)以便给出有价值的评论。
- 了解 Kubernetes 文档社区中不同的[角色和职责](/docs/contribute/participating/#roles-and-responsibilities)。
- 阅读[内容指南](/zh/docs/contribute/style/content-guide/)和
[样式指南](/zh/docs/contribute/style/style-guide/)以便给出有价值的评论。
- 了解 Kubernetes 文档社区中不同的[角色和职责](/zh/docs/contribute/participate/roles-and-responsibilities/)。
<!-- body -->
<!--
@@ -90,7 +90,7 @@ In general, review pull requests for content and style in English.
2. 使用以下标签（组合）对待处理 PRs 进行过滤：
- `cncf-cla: yes` （建议）：由尚未签署 CLA 的贡献者所发起的 PRs 不可以合并。
参考[签署 CLA](/docs/contribute/new-content/overview/#sign-the-cla) 以了解更多信息。
参考[签署 CLA](/zh/docs/contribute/new-content/overview/#sign-the-cla) 以了解更多信息。
- `language/en` （建议）：仅查看英语语言的 PRs。
- `size/<尺寸>`：过滤特定尺寸（规模）的 PRs。如果你刚入门，可以从较小的 PR 开始。
@@ -153,7 +153,7 @@ When reviewing, use the following as a starting point.
- 是否存在明显的语言或语法错误？对某事的描述有更好的方式？
- 是否存在一些过于复杂晦涩的用词，本可以用简单词汇来代替？
- 是否有些用词、术语或短语可以用不带歧视性的表达方式代替？
- 用词和大小写方面是否遵从了[样式指南](/docs/contribute/style/style-guide/)？
- 用词和大小写方面是否遵从了[样式指南](/zh/docs/contribute/style/style-guide/)？
- 是否有些句子太长，可以改得更短、更简单？
- 是否某些段落过长，可以考虑使用列表或者表格来表达？
@@ -188,10 +188,10 @@ For small issues with a PR, like typos or whitespace, prefix your comments with
如果是这样，PR 是否会导致出现新的失效链接？
是否有其他的办法，比如改变页面标题但不改变其 slug？
- PR 是否引入新的页面？如果是：
- 该页面是否使用了正确的[页面内容类型](/docs/contribute/style/page-content-types/)
- 该页面是否使用了正确的[页面内容类型](/zh/docs/contribute/style/page-content-types/)
及相关联的 Hugo 短代码（shortcodes）？
- 该页面能否在对应章节的侧面导航中显示？显示得正确么？
- 该页面是否应出现在[网站主页面](/docs/home/)的列表中？
- 该页面是否应出现在[网站主页面](/zh/docs/home/)的列表中？
- 变更是否正确出现在 Netlify 预览中了？
要对列表、代码段、表格、注释和图像等元素格外留心
content/zh/docs/contribute/style/hugo-shortcodes/index.md
+7 -5
View File
@@ -358,7 +358,7 @@ println "This is tab 2."
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
{{< tab name="Content File #2" include="example2" />}}
{{< tab name="JSON File" include="podtemplate" />}}
{{< tab name="JSON File" include="podtemplate.json" />}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
@@ -367,11 +367,13 @@ println "This is tab 2."
* Learn about [Hugo](https://gohugo.io/).
* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/).
* Learn about [page content types](/docs/home/contribute/style/page-content-types/).
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
* Learn about [advanced contributing](/docs/contribute/advanced/).
-->
* 了解 [Hugo](https://gohugo.io/)。
* 了解 [撰写新的话题](/zh/docs/contribute/write-new-topic/)。
* 了解 [使用页面类型](/zh/docs/contribute/style/page-content-types/)。
* 了解 [发起 PR](/zh/docs/contribute/new-content/create-a-pr/)。
* 了解[撰写新的话题](/zh/docs/contribute/style/write-new-topic/)。
* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/)。
* 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)。
* 了解[高级贡献](/zh/docs/contribute/advanced/)。
content/zh/docs/contribute/style/page-content-types.md
+1 -1
View File
@@ -354,7 +354,7 @@ An example of a published tutorial topic is
阅读的主题。
已发布的教程主题的一个例子是
[使用 Deployment 运行无状态应用](/zh/docs/tutorials/stateless-application/run-stateless-application-deployment/).
[使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/).
<!--
### Reference
content/zh/docs/contribute/style/style-guide.md
+5 -3
View File
@@ -38,12 +38,14 @@ discussion.
<!-- body -->
<!--
Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
Kubernetes documentation uses [Goldmark Markdown Renderer](https://github.com/yuin/goldmark)
with some adjustments along with a few
[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support glossary entries, tabs,
and representing feature state.
-->
{{< note >}}
Kubernetes 文档 [Blackfriday Markdown 解释器](https://github.com/russross/blackfriday)
和一些 [Hugo 短代码](/zh/docs/home/contribute/includes/) 来支持词汇表项、Tab
Kubernetes 文档使用带调整的 [Goldmark Markdown 解释器](https://github.com/yuin/goldmark/)
和一些 [Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/) 来支持词汇表项、Tab
页以及特性门控标注。
{{< /note >}}
content/zh/docs/contribute/style/write-new-topic.md
+1 -1
View File
@@ -285,7 +285,7 @@ For an example of a topic that uses this technique, see
[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/).
-->
有关使用此技术的主题的示例，请参见
[运行单实例有状态的应用](/zh/docs/tutorials/stateful-application/run-stateful-application/)。
[运行单实例有状态的应用](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)。
<!--
## Adding images to a topic
content/zh/docs/reference/access-authn-authz/admission-controllers.md
+1 -1
View File
@@ -83,7 +83,7 @@ other admission controllers.
最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。
增加使用配额就是一个典型的示例，说明了这样做的必要性。
此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请能否通过所有其它准入控制器。
此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。
<!--
## Why do I need them?
content/zh/docs/reference/access-authn-authz/controlling-access.md
+1 -1
View File
@@ -5,7 +5,7 @@ approvers:
title: Kubernetes API 访问控制
---
用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。
用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。
请求到达 API 服务器后会经过几个阶段，具体说明如图：
![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
content/zh/docs/reference/access-authn-authz/node.md
+1 -1
View File
@@ -43,7 +43,7 @@ Read operations:
* endpoints
* nodes
* pods
* secrets、configmaps、以及绑定到 kubelet 的节点的 pod 的持久卷申领和持久卷
* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷
<!--
* services
content/zh/docs/reference/kubectl/cheatsheet.md
+1 -1
View File
@@ -780,6 +780,6 @@ Verbosity | Description
-->
* 进一步了解 [kubectl 概述](/docs/reference/kubectl/overview/)。
* 参阅 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如果在可复用的脚本中使用它。
* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。
* 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
content/zh/docs/setup/best-practices/certificates.md
+1 -4
View File
@@ -55,7 +55,7 @@ Kubernetes 需要 PKI 才能执行以下操作：
* API 服务器的客户端证书，用于和 etcd 的会话
* 控制器管理器的客户端证书/kubeconfig，用于和 API server 的会话
* 调度器的客户端证书/kubeconfig，用于和 API server 的会话
* [前端代理][proxy] 的客户端及服务端证书
* [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书
{{< note >}}
<!--
@@ -280,6 +280,3 @@ These files are used as follows:
[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
content/zh/docs/setup/independent/create-cluster-kubeadm.md
+1 -1
View File
@@ -388,7 +388,7 @@ support [Network Policy](/docs/concepts/services-networking/networkpolicies/). S
- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9. -->
**网络必须在部署任何应用之前部署好。此外，在网络安装之前是 CoreDNS 不会启用的。
**网络必须在部署任何应用之前部署好。此外，在网络安装之前 CoreDNS 是不会启用的。
kubeadm 只支持基于容器网络接口（CNI）的网络而且不支持 kubenet 。**
有一些项目为 Kubernetes 提供使用 CNI 的 Pod 网络，其中一些也支持[网络策略](/docs/concepts/services-networking/networkpolicies/).
content/zh/docs/setup/production-environment/turnkey/clc.md
+532
View File
@@ -0,0 +1,532 @@
---
title: 在 CenturyLink Cloud 上运行 Kubernetes
---
<!--
---
title: Running Kubernetes on CenturyLink Cloud
---
--->
<!--
These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
--->
这些脚本适用于在 CenturyLink Cloud 上创建、删除和扩展 Kubernetes 集群。
您可以使用单个命令完成所有任务。我们提供了用于执行这些任务的 Ansible 手册 [点击这里](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
<!--
## Find Help
If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
- Submit a github issue
- Send an email to Kubernetes AT ctl DOT io
- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
--->
## 寻求帮助
如果运行出现问题或者想要寻求帮助，我们非常乐意帮忙。通过以下方式获取帮助：
- 提交 github issue
- 给 Kubernetes AT ctl DOT io 发送邮件
- 访问 [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
<!--
## Clusters of VMs or Physical Servers, your choice.
- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
- Physical serves are only available in the VA1 and GB3 data centers.
- VMs are available in all 13 of our public cloud locations
--->
## 基于 VM 或物理服务器的集群可供选择
- 我们在虚拟机或物理服务器上都支持 Kubernetes 集群。如果要将物理服务器用于辅助 Node（minions），则只需使用 --minion_type=bareMetal 标志。
- 有关物理服务器的更多信息，请访问： [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
- 仅在 VA1 和 GB3 数据中心提供物理服务。
- 13个公共云位置都可以使用虚拟机。
<!--
## Requirements
The requirements to run this script are:
- A linux administrative host (tested on ubuntu and macOS)
- python 2 (tested on 2.7.11)
- pip (installed with python as of 2.7.9)
- git
- A CenturyLink Cloud account with rights to create new hosts
- An active VPN connection to the CenturyLink Cloud from your linux host
--->
## 要求
运行此脚本的要求有：
- Linux 管理主机（在 ubuntu 和 macOS 上测试）
- python 2（在 2.7.11 版本上测试）
- pip（从 2.7.9 版开始与 python 一起安装）
- git
- 具有新建主机权限的 CenturyLink Cloud 帐户
- 从 Linux 主机到 CenturyLink Cloud 的有效 VPN 连接
<!--
## Script Installation
After you have all the requirements met, please follow these instructions to install this script.
1) Clone this repository and cd into it.
--->
## 脚本安装
满足所有要求后，请按照以下说明安装此脚本。
1）克隆此存储库并通过 cd 进入。
```shell
git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
```
<!--
2) Install all requirements, including
--->
2）安装所有要求的部分，包括
* Ansible
* CenturyLink Cloud SDK
* Ansible Modules
```shell
sudo pip install -r ansible/requirements.txt
```
<!--
3) Create the credentials file from the template and use it to set your ENV variables
--->
3）从模板创建凭证文件，并使用它来设置您的 ENV 变量
```shell
cp ansible/credentials.sh.template ansible/credentials.sh
vi ansible/credentials.sh
source ansible/credentials.sh
```
<!--
4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)
--->
4）使用内网的虚拟机或 [ 配置与 CenturyLink Cloud 网络的 VPN 连接.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/) 授予您的计算机对 CenturyLink Cloud 网络的访问权限。
<!--
#### Script Installation Example: Ubuntu 14 Walkthrough
If you use an ubuntu 14, for your convenience we have provided a step by step guide to install the requirements and install the script.
--->
#### 脚本安装示例：Ubuntu 14 演练
如果您使用 Ubuntu 14，为方便起见，我们会提供分步指导帮助安装必备条件和脚本。
```shell
# system
apt-get update
apt-get install -y git python python-crypto
curl -O https://bootstrap.pypa.io/get-pip.py
python get-pip.py
# installing this repository
mkdir -p ~home/k8s-on-clc
cd ~home/k8s-on-clc
git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
cd adm-kubernetes-on-clc/
pip install -r requirements.txt
# getting started
cd ansible
cp credentials.sh.template credentials.sh; vi credentials.sh
source credentials.sh
```
<!--
## Cluster Creation
To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete
list of script options and some examples are listed below.
--->
## 创建集群
要创建一个新的 Kubernetes 集群，只需运行 ```kube-up.sh``` 脚本即可。以下是一套完整的脚本选项列表和一些示例。
```shell
CLC_CLUSTER_NAME=[name of kubernetes cluster]
cd ./adm-kubernetes-on-clc
bash kube-up.sh -c="$CLC_CLUSTER_NAME"
```
<!--
It takes about 15 minutes to create the cluster. Once the script completes, it
will output some commands that will help you setup kubectl on your machine to
point to the new cluster.
When the cluster creation is complete, the configuration files for it are stored
locally on your administrative host, in the following directory
--->
创建集群大约需要15分钟。脚本完成后，它将输出一些命令，这些命令将帮助您在计算机上设置 kubectl 以指向新集群。
完成集群创建后，其配置文件会存储在本地管理主机的以下目录中
```shell
> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/
```
<!--
#### Cluster Creation: Script Options
--->
#### 创建集群：脚本选项
```shell
Usage: kube-up.sh [OPTIONS]
Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
order to access the CenturyLinkCloud API
All options (both short and long form) require arguments, and must include "="
between option name and option value.
-h (--help) display this help and exit
-c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names
-t= (--minion_type=) standard -> VM (default), bareMetal -> physical]
-d= (--datacenter=) VA1 (default)
-m= (--minion_count=) number of kubernetes minion nodes
-mem= (--vm_memory=) number of GB ram for each minion
-cpu= (--vm_cpu=) number of virtual cps for each minion node
-phyid= (--server_conf_id=) physical server configuration id, one of
physical_server_20_core_conf_id
physical_server_12_core_conf_id
physical_server_4_core_conf_id (default)
-etcd_separate_cluster=yes create a separate cluster of three etcd nodes,
otherwise run etcd on the master node
```
<!--
## Cluster Expansion
To expand an existing Kubernetes cluster, run the ```add-kube-node.sh```
script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options).
This script must be run from the same host that created the cluster (or a host
that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```).
--->
## 扩展集群
要扩展现有的Kubernetes集群，请运行```add-kube-node.sh``` 脚本。脚本选项的完整列表和一些示例在 [下面](#cluster-expansion-script-options) 列出。该脚本必须运行在创建集群的同一个主机（或储存集群工件文件的 ```~/.clc_kube/$cluster_name``` 主机）。
```shell
cd ./adm-kubernetes-on-clc
bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
```
<!--
#### Cluster Expansion: Script Options
--->
#### 扩展集群：脚本选项
```shell
Usage: add-kube-node.sh [OPTIONS]
Create servers in the CenturyLinkCloud environment and add to an
existing CLC kubernetes cluster
Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
order to access the CenturyLinkCloud API
-h (--help) display this help and exit
-c= (--clc_cluster_name=) set the name of the cluster, as used in CLC group names
-m= (--minion_count=) number of kubernetes minion nodes to add
```
<!--
## Cluster Deletion
There are two ways to delete an existing cluster:
1) Use our python script:
--->
## 删除集群
有两种方法可以删除集群：
1）使用 Python 脚本：
```shell
python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1
```
<!--
2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
Cloud control portal and delete the parent server group that contains the
Kubernetes Cluster. We hope to add a scripted option to do this soon.
--->
2）使用 CenturyLink Cloud UI。要删除集群，请登录 CenturyLink Cloud 控制页面并删除包含 Kubernetes 集群的父服务器组。我们希望能够添加脚本选项以尽快完成此操作。
<!--
## Examples
Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
--->
## 示例
在 VA1 中创建一个集群，名称为 k8s_1，具备1个主 Node 和3个辅助 Minion（在物理机上）
```shell
bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
```
<!--
Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
--->
在 VA1 中创建一个 ha etcd 集群，名称为 k8s_2，运行在3个虚拟机和6个辅助 Minion（在虚拟机上）
```shell
bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
```
<!--
Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
--->
在 UC1 中创建一个集群，名称为k8s_3，具备1个主 Node 和10个具有更高 mem/cpu 的辅助 Minion（在虚拟机上）：
```shell
bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
```
<!--
## Cluster Features and Architecture
We configure the Kubernetes cluster with the following features:
* KubeDNS: DNS resolution and service discovery
* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
* Grafana: Kubernetes/Docker metric dashboard
* KubeUI: Simple web interface to view Kubernetes state
* Kube Dashboard: New web interface to interact with your cluster
--->
## 集群功能和架构
我们使用以下功能配置 Kubernetes 集群：
* KubeDNS：DNS 解析和服务发现
* Heapster / InfluxDB：用于指标收集，是 Grafana 和 auto-scaling 需要的。
* Grafana：Kubernetes/Docker 指标仪表板
* KubeUI：用于查看 Kubernetes 状态的简单 Web 界面
* Kube 仪表板：新的 Web 界面可与您的集群进行交互
<!--
We use the following to create the Kubernetes cluster:
--->
使用以下工具创建 Kubernetes 集群：
* Kubernetes 1.1.7
* Ubuntu 14.04
* Flannel 0.5.4
* Docker 1.9.1-0~trusty
* Etcd 2.2.2
<!--
## Optional add-ons
* Logging: We offer an integrated centralized logging ELK platform so that all
Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
and configure Kubernetes to send logs to it, follow [the log
aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as
the footprint isn't trivial.
--->
## 可选附件
* 日志记录：我们提供了一个集成的集中式日志记录 ELK 平台，以便将所有 Kubernetes 和 docker 日志发送到 ELK 堆栈。要安装 ELK 堆栈并配置 Kubernetes 向其发送日志，请遵循 [日志聚合文档](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md)。注意：默认情况下我们不安装此程序，因为占用空间并不小。
<!--
## Cluster management
The most widely used tool for managing a Kubernetes cluster is the command-line
utility ```kubectl```. If you do not already have a copy of this binary on your
administrative machine, you may run the script ```install_kubectl.sh``` which will
download it and install it in ```/usr/bin/local```.
--->
## 管理集群
管理 Kubernetes 集群最常用工具是 command-line 实用程序 ```kubectl```。如果您的管理器上还没有此二进制文件的副本，可以运行脚本 ```install_kubectl.sh```，它将下载该脚本并将其安装在 ```/usr/bin/local``` 中。
<!--
The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
authentication certificates for the particular cluster. The configuration file is
written to the ```${CLC_CLUSTER_HOME}/kube``` directory
--->
该脚本要求定义环境变量 ```CLC_CLUSTER_NAME```。```install_kubectl.sh``` 还将写入一个配置文件，该文件为特定集群嵌入必要的认证证书。配置文件被写入 ```${CLC_CLUSTER_HOME}/kube``` 目录中
```shell
export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
kubectl version
kubectl cluster-info
```
<!--
### Accessing the cluster programmatically
It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
--->
### 以编程方式访问集群
可以使用本地存储的客户端证书来访问 apiserver。例如，您可以使用 [Kubernetes API 客户端库](/docs/reference/using-api/client-libraries/) 选择编程语言对 Kubernetes 集群进行编程。
为了演示如何使用这些本地存储的证书，我们提供以下示例，使用 ```curl``` 通过 https 与主 apiserver 进行通信：
```shell
curl \
--cacert ${CLC_CLUSTER_HOME}/pki/ca.crt \
--key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
--cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt https://${MASTER_IP}:6443
```
<!--
But please note, this *does not* work out of the box with the ```curl``` binary
distributed with macOS.
--->
但是请注意，这 *不能* 与 MacOS 一起发行的 ```curl``` 二进制文件分开使用。
<!--
### Accessing the cluster with a browser
We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you
create a cluster, the script should output URLs for these interfaces like this:
kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
--->
### 使用浏览器访问集群
安装 [Kubernetes 仪表板](/docs/tasks/web-ui-dashboard/)。创建集群时，脚本会为这些接口输出 URL，如下所示：
kubernetes-dashboard 在以下位置运行 ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```
<!--
Note on Authentication to the UIs:
The cluster is set up to use basic authentication for the user _admin_.
Hitting the url at ```https://${MASTER_IP}:6443``` will
require accepting the self-signed certificate
from the apiserver, and then presenting the admin
password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
--->
对 UI 进行身份验证的注意事项：
群集设置为对用户 _admin_ 使用基本的身份验证。进入 URL ```https://${MASTER_IP}:6443``` 获取从 apiserver 上接收的自签名证书，然后出示管理员密码并写入文件 ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
<!--
### Configuration files
Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
to access the cluster from machines other than where you created the cluster from.
--->
### 配置文件
多个配置文件被写入几个子目录，子目录在 ```.clc_kube/${CLC_CLUSTER_NAME}``` 下的主目录 *CLC_CLUSTER_HOME* 中。使用这些文件可以从创建群集的计算机之外的其他计算机访问群集。
<!--
* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
* ```hosts/```: hosts files listing access information for the Ansible playbooks
* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API
* ```pki/```: public key infrastructure files enabling TLS communication in the cluster
* ```ssh/```: SSH keys for root access to the hosts
--->
* ```config/```：Ansible 变量文件，包含描述主机和从机的参数
* ```hosts/```: 主机文件，列出了 Ansible 手册的访问信息
* ```kube/```: ```kubectl``` 配置文件，包含管理员访问 Kubernetes API 所需的基本身份验证密码
* ```pki/```: 公钥基础结构文件，用于在集群中启用 TLS 通信
* ```ssh/```: 对主机进行根访问的 SSH 密钥
<!--
## ```kubectl``` usage examples
There are a great many features of _kubectl_. Here are a few examples
List existing nodes, pods, services and more, in all namespaces, or in just one:
--->
## ```kubectl``` 使用示例
_kubectl_ 有很多功能，例如
列出所有或者一个命名空间中存在的 Node，Pod，服务等。
```shell
kubectl get nodes
kubectl get --all-namespaces pods
kubectl get --all-namespaces services
kubectl get --namespace=kube-system replicationcontrollers
```
<!--
The Kubernetes API server exposes services on web URLs, which are protected by requiring
client certificates. If you run a kubectl proxy locally, ```kubectl``` will provide
the necessary certificates and serve locally over http.
--->
Kubernetes API 服务器在 Web URL 上公开服务，这些 URL 受客户端证书的保护。如果您在本地运行 kubectl 代理，```kubectl``` 将提供必要的证书，并通过 http 在本地提供服务。
```shell
kubectl proxy -p 8001
```
<!--
Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser.
--->
然后，您可以访问 ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` 之类的 URL，不再需要浏览器中的客户端证书 。
<!--
## What Kubernetes features do not work on CenturyLink Cloud
These are the known items that don't work on CenturyLink cloud but do work on other cloud providers:
- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016.
- At this time, there is no support for persistent storage volumes provided by
CenturyLink Cloud. However, customers can bring their own persistent storage
offering. We ourselves use Gluster.
--->
## Kubernetes 的哪些功能无法在 CenturyLink Cloud 上使用
这些是已知的在 CenturyLink Cloud 上不能使用，但在其他云提供商中可以使用：
- 目前，没有 [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)类型的支持服务。我们正在为此积极努力，并希望在2016年4月左右发布更改。
- 目前，不支持 CenturyLink Cloud 提供的永久存储卷。但是，客户可以自带永久性存储产品。我们自己使用 Gluster。
<!--
## Ansible Files
If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
--->
## Ansible 文件
如果您想了解有关 Ansible 文件的更多信息，请 [浏览此文件](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
<!--
## Further reading
Please see the [Kubernetes docs](/docs/) for more details on administering
and using a Kubernetes cluster.
--->
## 更多
有关管理和使用 Kubernetes 集群的更多详细信息，请参见 [Kubernetes 文档](/docs/)
content/zh/docs/tasks/access-application-cluster/ingress-minikube.md
+421
View File
@@ -0,0 +1,421 @@
---
title: 在 Minikube 环境中使用 NGINX Ingress 控制器配置 Ingress
content_type: task
weight: 100
---
<!--
title: Set up Ingress on Minikube with the NGINX Ingress Controller
content_type: task
weight: 100
-->
<!-- overview -->
<!--
An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access
to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.
This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
-->
[Ingress](/zh/docs/concepts/services-networking/ingress/)是一种 API 对象，其中定义了一些规则使得集群中的
服务可以从集群外访问。
[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
负责满足 Ingress 中所设置的规则。
本节为你展示如何配置一个简单的 Ingress，根据 HTTP URI 将服务请求路由到
服务 `web` 或 `web2`。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
## Create a Minikube cluster
1. Click **Launch Terminal**
-->
## 创建一个 Minikube 集群
1. 点击 **Launch Terminal**
{{< kat-button >}}
<!--
1. (Optional) If you installed Minikube locally, run the following command:
-->
2. （可选操作）如果你在本地安装了 Minikube，运行下面的命令：
```shell
minikube start
```
<!--
## Enable the Ingress controller
1. To enable the NGINX Ingress controller, run the following command:
-->
## 启用 Ingress 控制器
1. 为了启用 NGINIX Ingress 控制器，可以运行下面的命令：
```shell
minikube addons enable ingress
```
<!--
1. Verify that the NGINX Ingress controller is running
-->
2. 检查验证 NGINX Ingress 控制器处于运行状态：
```shell
kubectl get pods -n kube-system
```
<!-- This can take up to a minute. -->
{{< note >}}这一操作可供需要近一分钟时间。{{< /note >}}
输出：
```shell
NAME READY STATUS RESTARTS AGE
default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m
kube-addon-manager-minikube 1/1 Running 0 3m
kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m
kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
storage-provisioner 1/1 Running 0 2m
```
<!--
## Deploy a hello, world app
1. Create a Deployment using the following command:
-->
## 部署一个 Hello World 应用
1. 使用下面的命令创建一个 Deployment：
```shell
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
```
<!--Output:-->
输出：
```
deployment.apps/web created
```
<!--
1. Expose the Deployment:
-->
2. 将 Deployment 暴露出来：
```shell
kubectl expose deployment web --type=NodePort --port=8080
```
<!-- Output: -->
输出：
```
service/web exposed
```
<!--
1. Verify the Service is created and is available on a node port:
-->
3. 验证 Service 已经创建，并且可能从节点端口访问：
```shell
kubectl get service web
```
<!-- Output: -->
输出：
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
```
<!--
1. Visit the service via NodePort:
-->
4. 使用节点端口信息访问服务：
```shell
minikube service web --url
```
<!-- Output: -->
输出：
```shell
http://172.17.0.15:31637
```
<!--
Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.
-->
{{< note >}}
如果使用的是 Katacoda 环境，在终端面板顶端，请点击加号标志。
然后点击 **Select port to view on Host 1**。
输入节点和端口号（这里是`31637`），之后点击 **Display Port**。
{{< /note >}}
<!-- Output: -->
输出：
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
<!--
You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
the app using the Ingress resource.
-->
你现在应该可以通过 Minikube 的 IP 地址和节点端口来访问示例应用了。
下一步是让自己能够通过 Ingress 资源来访问应用。
<!--
## Create an Ingress resource
The following file is an Ingress resource that sends traffic to your Service via hello-world.info.
1. Create `example-ingress.yaml` from the following file:
-->
## 创建一个 Ingress 资源
下面是一个 Ingress 资源的配置文件，负责通过 `hello-world.info` 将服务请求
转发到你的服务。
1. 根据下面的 YAML 创建文件 `example-ingress.yaml`：
```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: hello-world.info
http:
paths:
- path: /
backend:
serviceName: web
servicePort: 8080
```
<!--
1. Create the Ingress resource by running the following command:
-->
2. 通过运行下面的命令创建 Ingress 资源：
```shell
kubectl apply -f example-ingress.yaml
```
<!-- Output: -->
输出：
```shell
ingress.networking.k8s.io/example-ingress created
```
<!--
1. Verify the IP address is set:
-->
3. 验证 IP 地址已被设置：
```shell
kubectl get ingress
```
<!-- This can take a couple of minutes. -->
{{< note >}}此操作可能需要几分钟时间。{{< /note >}}
```shell
NAME HOSTS ADDRESS PORTS AGE
example-ingress hello-world.info 172.17.0.15 80 38s
```
<!--
1. Add the following line to the bottom of the `/etc/hosts` file.
-->
4. 在 `/etc/hosts` 文件的末尾添加以下内容：
<!--
If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.
-->
{{< note >}}
如果你在本地运行 Minikube 环境，需要使用 `minikube ip` 获得外部 IP 地址。
Ingress 列表中显示的 IP 地址会是内部 IP 地址。
{{< /note >}}
```
172.17.0.15 hello-world.info
```
<!-- This sends requests from hello-world.info to Minikube. -->
此设置使得来自 `hello-world.info` 的请求被发送到 Minikube。
<!--
1. Verify that the Ingress controller is directing traffic:
-->
5. 验证 Ingress 控制器能够转发请求流量：
```shell
curl hello-world.info
```
<!-- Output: -->
输出：
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
<!--
If you are running Minikube locally, you can visit hello-world.info from your browser.
-->
{{< note >}}
如果你在使用本地 Minikube 环境，你可以从浏览器中访问 hellow-world.info。
{{< /note >}}
<!--
## Create Second Deployment
1. Create a v2 Deployment using the following command:
-->
## 创建第二个 Deployment
1. 使用下面的命令创建 v2 的 Deployment：
```shell
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
```
<!-- Output: -->
输出：
```shell
deployment.apps/web2 created
```
<!--
1. Expose the Deployment:
-->
2. 将 Deployment 暴露出来：
```shell
kubectl expose deployment web2 --port=8080 --type=NodePort
```
<!-- Output: -->
输出：
```shell
service/web2 exposed
```
<!--
## Edit Ingress
1. Edit the existing `example-ingress.yaml` and add the following lines:
-->
## 编辑 Ingress
1. 编辑现有的 `example-ingress.yaml`，添加以下行：
```yaml
- path: /v2
backend:
serviceName: web2
servicePort: 8080
```
<!--
1. Apply the changes:
-->
2. 应用所作变更：
```shell
kubectl apply -f example-ingress.yaml
```
<!-- Output: -->
输出：
```shell
ingress.networking/example-ingress configured
```
<!--
## Test Your Ingress
1. Access the 1st version of the Hello World app.
-->
## 测试你的 Ingress
1. 访问 HelloWorld 应用的第一个版本：
```shell
curl hello-world.info
```
<!-- Output: -->
输出：
```
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
<!--
1. Access the 2nd version of the Hello World app.
-->
2. 访问 HelloWorld 应用的第二个版本：
```shell
curl hello-world.info/v2
```
<!-- Output: -->
输出：
```
Hello, world!
Version: 2.0.0
Hostname: web2-75cd47646f-t8cjk
```
<!--
If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser
-->
{{< note >}}
如果你在本地运行 Minikube 环境，你可以使用浏览器来访问
hellow-world.info 和 hello-world.info/v2。
{{< /note >}}
## {{% heading "whatsnext" %}}
<!--
* Read more about [Ingress](/docs/concepts/services-networking/ingress/)
* Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* Read more about [Services](/docs/concepts/services-networking/service/)
-->
* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。
* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
* 进一步了解[服务](/zh/docs/concepts/services-networking/service/)
content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+1 -1
View File
@@ -22,7 +22,7 @@ content_type: task
## 为什么要更改 PersistentVolume 的回收策略
`PersistentVolumes` 可以有多种回收策略，包括 "Retain"、"Recycle" 和 "Delete"。对于动态配置的 `PersistentVolumes` 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 `PersistentVolumeClaim` 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 "Retain" 策略。使用 "Retain" 时，如果用户删除 `PersistentVolumeClaim`，对应的 `PersistentVolume` 不会被删除。相反，它将变为 `Released` 状态，表示所有的数据可以被手动恢复。
PersistentVolumes 可以有多种回收策略，包括 "Retain"、"Recycle" 和 "Delete"。对于动态配置的 PersistentVolumes 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 PersistentVolumeClaim 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 "Retain" 策略。使用 "Retain" 时，如果用户删除 PersistentVolumeClaim，对应的 PersistentVolume 不会被删除。相反，它将变为 Released 状态，表示所有的数据可以被手动恢复。
## 更改 PersistentVolume 的回收策略
content/zh/docs/tasks/administer-cluster/declare-network-policy.md
+146 -71
View File
@@ -1,53 +1,93 @@
---
approvers:
- caseydavenport
- danwinship
title: 声明网络策略
content_type: task
---
<!--
reviewers:
- caseydavenport
- danwinship
title: Declare Network Policy
min-kubernetes-server-version: v1.8
content_type: task
-->
<!-- overview -->
本文可以帮助您开始使用 Kubernetes 的 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信
<!--
This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
-->
本文可以帮助您开始使用 Kubernetes 的 [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Make sure you've configured a network provider with network policy support. There are a number of network providers that support NetworkPolicy, including:
* [Calico](/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
* [Cilium](/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
* [Kube-router](/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
-->
您首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括：
* [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
* [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
* [Weave 网络](/docs/tasks/configure-pod-container/weave-network-policy/)
**注意**：以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的
* [Calico](/zh/docs/tasks/configure-pod-container/calico-network-policy/)
* [Cilium](/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
* [Kube-router](/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
* [Romana](/zh/docs/tasks/configure-pod-container/romana-network-policy/)
* [Weave 网络](/zh/docs/tasks/configure-pod-container/weave-network-policy/)
<!--
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
-->
{{< note >}}
以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。
下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的
{{< /note >}}
<!-- steps -->
<!--
## Create an `nginx` deployment and expose it via a service
## 创建一个`nginx` deployment 并且通过服务将其暴露
To see how Kubernetes network policy works, start off by creating an `nginx` Deployment.
-->
## 创建一个`nginx` Deployment 并且通过服务将其暴露
为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` deployment 并且通过服务将其暴露开始
```console
$ kubectl create deployment nginx --image=nginx
kubectl create deployment nginx --image=nginx
```
```none
deployment "nginx" created
$ kubectl expose deployment nginx --port=80
```
<!--
Expose the Deployment through a Service called `nginx`.
-->
将此 Deployment 以名为 `nginx` 的 Service 暴露出来：
```console
kubectl expose deployment nginx --port=80
```
```none
service "nginx" exposed
```
在 default 命名空间下运行了两个 `nginx` pod，而且通过一个名字为 `nginx` 的服务进行了暴露
<!--
The above commands create a Deployment with an nginx Pod and expose the Deployment through a Service named `nginx`. The `nginx` Pod and Deployment are found in the `default` namespace.
-->
上述命令创建了一个带有一个 nginx 的 Deployment，并将之通过名为 `nginx` 的
Service 暴露出来。名为 `nginx` 的 Pod 和 Deployment 都位于 `default`
名字空间内。
```console
$ kubectl get svc,pod
kubectl get svc,pod
```
```none
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes 10.100.0.1 <none> 443/TCP 46m
svc/nginx 10.100.0.16 <none> 80/TCP 33s
@@ -56,93 +96,128 @@ NAME READY STATUS RESTARTS AGE
po/nginx-701339712-e0qfq 1/1 Running 0 35s
```
<!--
## Test the service by accessing it from another Pod
## 测试服务能够被其它的 pod 访问
You should be able to access the new `nginx` service from other Pods. To access the `nginx` Service from another Pod in the `default` namespace, start a busybox container:
-->
## 通过从 Pod 访问服务对其进行测试
您应该可以从其它的 pod 访问这个新的 `nginx` 服务。为了验证它，从 default 命名空间下的其它 pod 来访问该服务。请您确保在该命名空间下没有执行孤立动作。
启动一个 busybox 容器，然后在容器中使用 `wget` 命令去访问 `nginx` 服务：
您应该可以从其它的 Pod 访问这个新的 `nginx` 服务。
要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
```console
$ kubectl run busybox --rm -ti --image=busybox /bin/sh
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Hit enter for command prompt
<!--
In your shell, run the following command:
-->
在你的 Shell 中，运行下面的命令：
/ # wget --spider --timeout=1 nginx
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
/ #
remote file exists
```
<!--
## Limit access to the `nginx` service
## 限制访问 `nginx` 服务
To limit the access to the `nginx` service so that only Pods with the label `access: true` can query it, create a NetworkPolicy object as follows:
-->
## 限制 `nginx` 服务的访问
如果想限制对 `nginx` 服务的访问，只让那些拥有标签 `access: true` 的 Pod 访问它，
那么可以创建一个如下所示的 NetworkPolicy 对象：
如果说您想限制 `nginx` 服务，只让那些拥有标签 `access: true` 的 pod 访问它，那么您可以创建一个只允许从那些 pod 连接的 `NetworkPolicy`：
{{< codenew file="service/networking/nginx-policy.yaml" >}}
```yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: access-nginx
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
access: "true"
```
<!--
The name of a NetworkPolicy object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-->
NetworkPolicy 对象的名称必须是一个合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
<!--
NetworkPolicy includes a `podSelector` which selects the grouping of Pods to which the policy applies. You can see this policy selects Pods with the label `app=nginx`. The label was automatically added to the Pod in the `nginx` Deployment. An empty `podSelector` selects all pods in the namespace.
-->
{{< note >}}
NetworkPolicy 中包含选择策略所适用的 Pods 集合的 `podSelector`。
你可以看到上面的策略选择的是带有标签 `app=nginx` 的 Pods。
此标签是被自动添加到 `nginx` Deployment 中的 Pod 上的。
如果 `podSelector` 为空，则意味着选择的是名字空间中的所有 Pods。
{{< /note >}}
<!--
## Assign the policy to the service
Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file:
-->
## 为服务指定策略
使用 kubectl 工具根据上面的 nginx-policy.yaml 文件创建一个 NetworkPolicy：
使用 kubectl 根据上面的 `nginx-policy.yaml` 文件创建一个 NetworkPolicy：
```console
$ kubectl create -f nginx-policy.yaml
networkpolicy "access-nginx" created
kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
```
```none
networkpolicy.networking.k8s.io/access-nginx created
```
<!--
## Test access to the service when access label is not defined
## 当访问标签没有定义时测试访问服务
When you attempt to access the `nginx` Service from a Pod without the correct labels, the request times out:
-->
## 测试没有定义访问标签时访问服务
如果您尝试从没有设定正确标签的 pod 中去访问 `nginx` 服务，请求将会超时：
如果你尝试从没有设定正确标签的 Pod 中去访问 `nginx` 服务，请求将会超时：
```console
$ kubectl run busybox --rm -ti --image=busybox /bin/sh
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
```
Hit enter for command prompt
<!--
In your shell, run the command:
-->
在 Shell 中运行命令：
/ # wget --spider --timeout=1 nginx
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
wget: download timed out
/ #
```
<!--
## Define access label and test again
You can create a Pod with the correct labels to see that the request is allowed:
-->
## 定义访问标签后再次测试
创建一个拥有正确标签的 pod，您将看到请求是被允许的：
创建一个拥有正确标签的 Pod，你将看到请求是被允许的：
```console
$ kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
```
<!--
In your shell, run the command:
-->
在 Shell 中运行命令：
Hit enter for command prompt
/ # wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
/ #
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
```
content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+404 -347
View File
@@ -28,10 +28,12 @@ please refer to following pages instead:
要查看 kubeadm 创建的有关旧版本集群升级的信息，请参考以下页面：
<!--
- [Upgrading kubeadm cluster from 1.16 to 1.17](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [Upgrading kubeadm cluster from 1.15 to 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [Upgrading kubeadm cluster from 1.14 to 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
- [Upgrading kubeadm cluster from 1.13 to 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
-->
- [将 kubeadm 集群从 1.16 升级到 1.17](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [将 kubeadm 集群从 1.15 升级到 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [将 kubeadm 集群从 1.14 升级到 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
- [将 kubeadm 集群从 1.13 升级到 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
@@ -43,17 +45,14 @@ The upgrade workflow at high level is the following:
1. Upgrade additional control plane nodes.
1. Upgrade worker nodes.
-->
高版本升级工作流如下：
升级工作的基本流程如下：
1. 升级主控制平面节点。
1. 升级其他控制平面节点。
1. 升级工作节点。
## {{% heading "prerequisites" %}}
<!--
- You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later.
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
@@ -84,8 +83,6 @@ The upgrade workflow at high level is the following:
- 您只能从一个次版本升级到下一个次版本，或者同样次版本的补丁版。也就是说，升级时无法跳过版本。
例如，您只能从 1.y 升级到 1.y+1，而不能从 from 1.y 升级到 1.y+2。
<!-- steps -->
<!--
@@ -94,335 +91,362 @@ The upgrade workflow at high level is the following:
## 确定要升级到哪个版本
<!--
1. Find the latest stable 1.17 version:
Find the latest stable 1.18 version:
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt update
apt-cache policy kubeadm
# find the latest 1.17 version in the list
# it should look like 1.17.x-00, where x is the latest patch
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# find the latest 1.18 version in the list
# it should look like 1.18.x-00, where x is the latest patch
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# find the latest 1.17 version in the list
# it should look like 1.17.x-0, where x is the latest patch
{{% /tab %}}
{{< /tabs >}}
# find the latest 1.18 version in the list
# it should look like 1.18.x-0, where x is the latest patch
{{% /tab %}}
{{< /tabs >}}
-->
1. 找到最新的稳定版 1.17:
找到最新的稳定版 1.18：
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt update
apt-cache policy kubeadm
# 在列表中查找最新的 1.17 版本
# 它看起来应该是 1.17.x-00 ，其中 x 是最新的补丁
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 在列表中查找最新的 1.18 版本
# 它看起来应该是 1.18.x-00 ，其中 x 是最新的补丁
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# 在列表中查找最新的 1.17 版本
# 它看起来应该是 1.17.x-0 ，其中 x 是最新的补丁
{{% /tab %}}
{{< /tabs >}}
# 在列表中查找最新的 1.18 版本
# 它看起来应该是 1.18.x-0 ，其中 x 是最新的补丁版本
{{% /tab %}}
{{< /tabs >}}
<!--
## Upgrade the first control plane node
## Upgrade the control plane node
### Upgrade the first control plane node
-->
## 升级第一个控制平面节点
## 升级控制平面节点
### 升级第一个控制面节点
<!--
1. On your first control plane node, upgrade kubeadm:
- On your first control plane node, upgrade kubeadm:
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.17.x-00 with the latest patch version
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.18.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.17.x-00 && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.17.x-0 with the latest patch version
yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.18.x-0 with the latest patch version
yum install -y kubeadm-1.18.x-0 -disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
-->
1. 在第一个控制平面节点上，升级 kubeadm :
- 在第一个控制平面节点上，升级 kubeadm :
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 x
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# 用最新的修补程序版本替换 1.18.x-00 中的 x
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.17.x-00 && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 用最新的修补程序版本替换 1.17.x-0 中的 x
yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 用最新的修补程序版本替换 1.18.x-0 中的 x
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<!--
1. Verify that the download works and has the expected version:
- Verify that the download works and has the expected version:
```shell
kubeadm version
```
```shell
kubeadm version
```
-->
1. 验证 kubeadm 版本：
- 验证下载操作正常，并且 kubeadm 版本正确：
```shell
kubeadm version
```
```shell
kubeadm version
```
<!--
1. Drain the control plane node:
- Drain the control plane node:
```shell
# replace <cp-node-name> with the name of your control plane node
kubectl drain $CP_NODE -ignore-daemonsets
```
-->
1. 腾空控制平面节点：
- 腾空控制平面节点：
```shell
kubectl drain $CP_NODE --ignore-daemonsets
```
```shell
# 将 <cp-node-name> 替换为你自己的控制面节点名称
kubectl drain <cp-node-name> --ignore-daemonsets
```
<!--
1. On the control plane node, run:
- On the control plane node, run:
-->
1. 在主节点上，运行:
- 在控制面节点上，运行:
```shell
sudo kubeadm upgrade plan
```
```shell
sudo kubeadm upgrade plan
```
<!--
You should see output similar to this:
-->
您应该可以看到与下面类似的输出：
<!--
You should see output similar to this:
-->
您应该可以看到与下面类似的输出：
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.16.0
[upgrade/versions] kubeadm version: v1.17.0
```none
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/versions] Latest stable version: v1.18.0
[upgrade/versions] Latest version in the v1.17 series: v1.18.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.16.0 v1.17.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.17.3 v1.18.0
Upgrade to the latest version in the v1.13 series:
Upgrade to the latest version in the v1.17 series:
COMPONENT CURRENT AVAILABLE
API Server v1.16.0 v1.17.0
Controller Manager v1.16.0 v1.17.0
Scheduler v1.16.0 v1.17.0
Kube Proxy v1.16.0 v1.17.0
CoreDNS 1.6.2 1.6.5
Etcd 3.3.15 3.4.3-0
COMPONENT CURRENT AVAILABLE
API Server v1.17.3 v1.18.0
Controller Manager v1.17.3 v1.18.0
Scheduler v1.17.3 v1.18.0
Kube Proxy v1.17.3 v1.18.0
CoreDNS 1.6.5 1.6.7
Etcd 3.4.3 3.4.3-0
You can now apply the upgrade by executing the following command:
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.17.0
kubeadm upgrade apply v1.18.0
_____________________________________________________________________
```
_____________________________________________________________________
```
<!--
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
-->
此命令检查您的集群是否可以升级，并可以获取到升级的版本。
<!--
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
-->
此命令检查您的集群是否可以升级，并可以获取到升级的版本。
<!--
1. Choose a version to upgrade to, and run the appropriate command. For example:
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
To opt-out of certificate renewal the flag `-certificate-renewal=false` can be used.
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
-->
1. 选择要升级到的版本，然后运行相应的命令。例如:
```shell
sudo kubeadm upgrade apply v1.17.x
```
<!--
- Replace `x` with the patch version you picked for this ugprade.
-->
- 将 `x` 替换为您为此升级选择的修补程序版本。
<!--
You should see output similar to this:
-->
您应该可以看见与下面类似的输出：
```shell
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.17.0"
[upgrade/versions] Cluster version: v1.16.0
[upgrade/versions] kubeadm version: v1.17.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.17.0"...
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-controller-manager-myhost hash: 8ee730c1a5607a87f35abb2183bf03f2
Static pod: kube-scheduler-myhost hash: 4b52d75cab61380f07c0c5a69fb371d4
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239
Static pod: etcd-myhost hash: 877025e7dd7adae8a04ee20ca4ecb239
Static pod: etcd-myhost hash: 64a28f011070816f4beb07a9c96d73b6
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests043818770"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-apiserver-myhost hash: 6436b0d8ee0136c9d9752971dda40400
Static pod: kube-apiserver-myhost hash: b8a6533e241a8c6dab84d32bb708b8a1
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-myhost hash: 8ee730c1a5607a87f35abb2183bf03f2
Static pod: kube-controller-manager-myhost hash: 6f77d441d2488efd9fc2d9a9987ad30b
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-03-14-20-52-44/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-myhost hash: 4b52d75cab61380f07c0c5a69fb371d4
Static pod: kube-scheduler-myhost hash: a24773c92bb69c3748fcce5e540b7574
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.17" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.17" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.17.0". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
{{< note >}}
`kubeadm upgrade` 也会自动对它在此节点上管理的证书进行续约。
如果选择不对证书进行续约，可以使用标志 `--certificate-renewal=false`。
关于更多细节信息，可参见[证书管理指南](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。
{{</ note >}}
<!--
1. Manually upgrade your CNI provider plugin.
-->
1. 手动升级你的 CNI 供应商插件。
- Choose a version to upgrade to, and run the appropriate command. For example:
```shell
# replace x with the patch version you picked for this upgrade
sudo kubeadm upgrade apply v1.18.x
```
-->
- 选择要升级到的版本，然后运行相应的命令。例如:
```shell
# 将 x 替换为你为此次升级所选的补丁版本号
sudo kubeadm upgrade apply v1.18.x
```
<!--
You should see output similar to this:
-->
您应该可以看见与下面类似的输出：
```none
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade/version] You have chosen to change the cluster version to "v1.18.0"
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"...
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
[upgrade/etcd] Upgrading to TLS for etcd
[upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012"
W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Renewing apiserver certificate
[upgrade/staticpods] Renewing apiserver-kubelet-client certificate
[upgrade/staticpods] Renewing front-proxy-client certificate
[upgrade/staticpods] Renewing apiserver-etcd-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
<!--
- Manually upgrade your CNI provider plugin.
<!--
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
find your CNI provider and see whether additional upgrade steps are required.
-->
您的容器网络接口（CNI）应该提供了程序自身的升级说明。
检查[插件](/docs/concepts/cluster-administration/addons/)页面查找您 CNI 所提供的程序，并查看是否需要其他升级步骤。
<!--
This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.
-->
如果 CNI 提供程序作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。
-->
- 手动升级你的 CNI 驱动插件。
您的容器网络接口（CNI）驱动应该提供了程序自身的升级说明。
检查[插件](/docs/concepts/cluster-administration/addons/)页面查找您 CNI 所提供的程序，并查看是否需要其他升级步骤。
如果 CNI 提供程序作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。
<!--
1. Uncordon the control plane node
-->
1. 取消对控制面节点的保护
- Uncordon the control plane node
```shell
kubectl uncordon $CP_NODE
```
<!--
1. Upgrade the kubelet and kubectl on the control plane node:
-->
1. 升级控制平面节点上的 kubelet 和 kubectl ：
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 x
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \
apt-mark hold kubelet kubectl
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 x
yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<!--
1. Restart the kubelet
-->
1. 重启 kubelet
```shell
sudo systemctl restart kubelet
# replace <cp-node-name> with the name of your control plane node
kubectl uncordon <cp-node-name>
```
-->
- 取消对控制面节点的保护
```shell
# 将 <cp-node-name> 替换为你的控制面节点名称
kubectl uncordon <cp-node-name>
```
<!--
## Upgrade additional control plane nodes
-->
## 升级其他控制平面节点
### Upgrade additional control plane nodes
<!--
1. Same as the first control plane node but use:
Same as the first control plane node but use:
-->
1. 与第一个控制平面节点相同，但使用：
### 升级其他控制面节点
与第一个控制面节点类似，不过使用下面的命令：
```
sudo kubeadm upgrade node experimental-control-plane
sudo kubeadm upgrade node
```
<!-- instead of: -->
而不是：
```
sudo kubeadm upgrade apply
```
<!-- Also `sudo kubeadm upgrade plan` is not needed. -->
同时，也不需要执行 `sudo kubeadm upgrade plan`。
<!--
Also `sudo kubeadm upgrade plan` is not needed.
### Upgrade kubelet and kubectl
-->
也不需要 `sudo kubeadm upgrade plan` 。
### 升级 kubelet 和 kubectl
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
# 用最新的补丁版本替换 1.18.x-00 中的 x
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl
-
# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS、RHEL 或 Fedora" %}}
# 用最新的补丁版本替换 1.18.x-00 中的 x
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<!--
Restart the kubelet
-->
重启 kubelet
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
<!--
## Upgrade worker nodes
-->
## 升级工作节点
<!--
The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
without compromising the minimum required capacity for running your workloads.
-->
## 升级工作节点
工作节点上的升级过程应该一次执行一个节点，或者一次执行几个节点，以不影响运行工作负载所需的最小容量。
<!--
@@ -431,35 +455,39 @@ without compromising the minimum required capacity for running your workloads.
### 升级 kubeadm
<!--
1. Upgrade kubeadm on all worker nodes:
- Upgrade kubeadm on all worker nodes:
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.17.x-00 with the latest patch version
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.18.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.17.x-00 && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.17.x-0 with the latest patch version
yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.18.x-0 with the latest patch version
yum install -y kubeadm-1.18.x-0 -disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
-->
1. 在所有工作节点升级 kubeadm :
- 在所有工作节点升级 kubeadm:
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 x
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
# 将 1.18.x-00 中的 x 替换为最新的补丁版本
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.17.x-00 && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 x
yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
-
# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS、RHEL 或 Fedora" %}}
# 用最新的补丁版本替换 1.18.x-00 中的 x
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<!--
### Cordon the node
@@ -470,8 +498,8 @@ without compromising the minimum required capacity for running your workloads.
1. Prepare the node for maintenance by marking it unschedulable and evicting the workloads. Run:
```shell
kubectl drain $NODE --ignore-daemonsets
```
# replace <node-to-drain> with the name of your node you are draining
kubectl drain <node-to-drain> --ignore-daemonsets
You should see output similar to this:
@@ -481,22 +509,23 @@ without compromising the minimum required capacity for running your workloads.
node/ip-172-31-85-18 drained
```
-->
1. 通过将节点标记为不可调度并逐出工作负载，为维护做好准备。运行：
- 通过将节点标记为不可调度并逐出工作负载，为维护做好准备。运行：
```shell
kubectl drain $NODE --ignore-daemonsets
```
```shell
# 将 <node-to-drain> 替换为你正在腾空的节点的名称
kubectl drain <node-to-drain> --ignore-daemonsets
```
<!--
You should see output similar to this:
-->
您应该可以看见与下面类似的输出：
<!--
You should see output similar to this:
-->
你应该可以看见与下面类似的输出：
```shell
node/ip-172-31-85-18 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
node/ip-172-31-85-18 drained
```
```shell
node/ip-172-31-85-18 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
node/ip-172-31-85-18 drained
```
<!--
### Upgrade the kubelet config
@@ -507,22 +536,14 @@ without compromising the minimum required capacity for running your workloads.
1. Upgrade the kubelet config:
```shell
sudo kubeadm upgrade node config --kubelet-version v1.14.x
sudo kubeadm upgrade node
```
Replace `x` with the patch version you picked for this ugprade.
-->
1. 升级 kubelet 配置:
```shell
sudo kubeadm upgrade node config --kubelet-version v1.14.x
```
<!--
Replace `x` with the patch version you picked for this ugprade.
-->
用最新的修补程序版本替换 1.14.x-00 中的 x
- 升级 kubelet 配置:
```shell
sudo kubeadm upgrade node
```
<!--
### Upgrade kubelet and kubectl
@@ -530,66 +551,60 @@ without compromising the minimum required capacity for running your workloads.
### 升级 kubelet 与 kubectl
<!--
1. Upgrade the Kubernetes package version by running the Linux package manager for your distribution:
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.17.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \
apt-mark hold kubelet kubectl
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.17.x-0 with the latest patch version
yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
- Upgrade the kubelet and kubectl on all worker nodes:
-->
1. 通过运行适用于您的 Linux 发行版包管理器升级 Kubernetes 软件包版本：
- 在所有工作节点上升级 kubelet 和 kubectl：
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 xs
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
# 将 1.18.x-00 中的 x 替换为最新的补丁版本
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 用最新的修补程序版本替换 1.17.x-00 中的 x
yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
-
# 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# 将 1.18.x-00 中的 x 替换为最新的补丁版本
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<!--
1. Restart the kubelet
- Restart the kubelet
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
-->
1. 重启 kubelet
```shell
sudo systemctl restart kubelet
```
- 重启 kubelet
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
<!--
### Uncordon the node
-->
### 取消对节点的保护
<!--
1. Bring the node back online by marking it schedulable:
- Bring the node back online by marking it schedulable:
```shell
kubectl uncordon $NODE
# replace <node-to-drain> with the name of your node
kubectl uncordon <node-to-drain>
```
-->
1. 通过将节点标记为可调度，让节点重新上线:
- 通过将节点标记为可调度，让节点重新上线:
```shell
kubectl uncordon $NODE
```
```shell
# 将 <node-to-drain> 替换为当前节点的名称
kubectl uncordon <node-to-drain>
```
<!--
## Verify the status of the cluster
@@ -613,8 +628,6 @@ The `STATUS` column should show `Ready` for all your nodes, and the version numb
-->
`STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。
<!--
## Recovering from a failure state
@@ -629,6 +642,35 @@ To recover from a bad state, you can also run `kubeadm upgrade --force` without
此命令是幂等的，并最终确保实际状态是您声明的所需状态。
要从故障状态恢复，您还可以运行 `kubeadm upgrade --force` 而不去更改集群正在运行的版本。
<!--
During upgrade kubeadm writes the following backup folders under `/etc/kubernetes/tmp`:
- `kubeadm-backup-etcd-<date>-<time>`
- `kubeadm-backup-manifests-<date>-<time>`
`kubeadm-backup-etcd` contains a backup of the local etcd member data for this control-plane Node.
In case of an etcd upgrade failure and if the automatic rollback does not work, the contents of this folder
can be manually restored in `/var/lib/etcd`. In case external etcd is used this backup folder will be empty.
`kubeadm-backup-manifests` contains a backup of the static Pod manifest files for this control-plane Node.
In case of a upgrade failure and if the automatic rollback does not work, the contents of this folder can be
manually restored in `/etc/kubernetes/manifests`. If for some reason there is no difference between a pre-upgrade
and post-upgrade manifest file for a certain component, a backup file for it will not be written.
-->
在升级期间，kubeadm 向 `/etc/kubernetes/tmp` 目录下的如下备份文件夹写入数据：
- `kubeadm-backup-etcd-<date>-<time>`
- `kubeadm-backup-manifests-<date>-<time>`
`kubeadm-backup-etcd` 包含当前控制面节点本地 etcd 成员数据的备份。
如果 etcd 升级失败并且自动回滚也无法修复，则可以将此文件夹中的内容复制到
`/var/lib/etcd` 进行手工修复。如果使用的是外部的 etcd，则此备份文件夹为空。
`kubeadm-backup-manifests` 包含当前控制面节点的静态 Pod 清单文件的备份版本。
如果升级失败并且无法自动回滚，则此文件夹中的内容可以复制到
`/etc/kubernetes/manifests` 目录实现手工恢复。
如果由于某些原因，在升级前后某个组件的清单未发生变化，则 kubeadm 也不会为之
生成备份版本。
<!--
## How it works
@@ -644,27 +686,42 @@ To recover from a bad state, you can also run `kubeadm upgrade --force` without
- Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created.
- Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days.
-->
## 它是怎么工作的
## 工作原理
`kubeadm upgrade apply` 做了以下工作：
- 检查您的集群是否处于可升级状态:
- API 服务器是可访问的
- 所有节点处于 `Ready` 状态
- 控制平面是健康的
- 控制面是健康的
- 强制执行版本 skew 策略。
- 确保控制平面的镜像是可用的或可拉取到服务器上。
- 升级控制平面组件或回滚（如果其中任何一个组件无法启动）。
- 确保控制面的镜像是可用的或可拉取到服务器上。
- 升级控制面组件或回滚（如果其中任何一个组件无法启动）。
- 应用新的 `kube-dns` 和 `kube-proxy` 清单，并强制创建所有必需的 RBAC 规则。
- 如果旧文件在 180 天后过期，将创建 API 服务器的新证书和密钥文件并备份旧文件。
<!--
`kubeadm upgrade node experimental-control-plane` does the following on additional control plane nodes:
`kubeadm upgrade node` does the following on additional control plane nodes:
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
- Optionally backups the kube-apiserver certificate.
- Upgrades the static Pod manifests for the control plane components.
- Upgrades the kubelet configuration for this node.
-->
`kubeadm upgrade node experimental-control-plane` 在其他控制平面节点上执行以下操作：
`kubeadm upgrade node` 在其他控制平节点上执行以下操作：
- 从集群中获取 kubeadm `ClusterConfiguration`。
- 可选地备份 kube-apiserver 证书。
- 升级控制平面组件的静态 Pod 清单。
- 为本节点升级 kubelet 配置
<!--
`kubeadm upgrade node` does the following on worker nodes:
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
- Upgrades the kubelet configuration for this node.
-->
`kubeadm upgrade node` 在工作节点上完成以下工作：
- 从集群取回 kubeadm `ClusterConfiguration`。
- 为本节点升级 kubelet 配置
content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
+55 -85
View File
@@ -5,6 +5,7 @@ reviewers:
- dashpole
title: 为系统守护进程预留计算资源
content_type: task
min-kubernetes-server-version: 1.8
---
<!--
---
@@ -14,6 +15,7 @@ reviewers:
- dashpole
title: Reserve Compute Resources for System Daemons
content_type: task
min-kubernetes-server-version: 1.8
---
-->
@@ -31,18 +33,23 @@ compute resources for system daemons. Kubernetes recommends cluster
administrators to configure `Node Allocatable` based on their workload density
on each node.
-->
Kubernetes 的节点可以按照 `Capacity` 调度。默认情况下 pod 能够使用节点全部可用容量。这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。除非为这些系统守护进程留出资源，否则它们将与 pod 争夺资源并导致节点资源短缺问题。
`kubelet` 公开了一个名为 `Node Allocatable` 的特性，有助于为系统守护进程预留计算资源。Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 `Node Allocatable`。
Kubernetes 的节点可以按照 `Capacity` 调度。默认情况下 pod 能够使用节点全部可用容量。
这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。
除非为这些系统守护进程留出资源，否则它们将与 pod 争夺资源并导致节点资源短缺问题。
`kubelet` 公开了一个名为 `Node Allocatable` 的特性，有助于为系统守护进程预留计算资源。
Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 `Node Allocatable`。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Your Kubernetes server must be at or later than version 1.17 to use
the kubelet command line option `--reserved-cpus` to set an
[explicitly reserved CPU list](#explicitly-reserved-cpu-list).
-->
您的 kubernetes 服务器版本必须至少是 1.17 版本，才能使用 kubelet 命令行选项 `--reserved-cpus` 来设置 [显式 CPU 保留列表](#explicitly-reserved-cpu-list)
<!-- steps -->
@@ -94,7 +101,8 @@ Resources can be reserved for two categories of system daemons in the `kubelet`.
---------------------------
```
Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。调度器不会超额申请 `Allocatable`。目前支持 `CPU`, `memory` 和 `ephemeral-storage` 这几个参数。
Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。调度器不会超额申请 `Allocatable`。
目前支持 `CPU`, `memory` 和 `ephemeral-storage` 这几个参数。
可分配的节点暴露为 API 中 `v1.Node` 对象的一部分，也是 CLI 中 `kubectl describe node` 的一部分。
@@ -110,7 +118,8 @@ under a cgroup hierarchy managed by the `kubelet`.
-->
### 启用 QoS 和 Pod 级别的 cgroups
为了恰当的在节点范围实施 node allocatable，您必须通过 `--cgroups-per-qos` 标志启用新的 cgroup 层次结构。这个标志是默认启用的。启用后，`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 pod。
为了恰当的在节点范围实施 node allocatable，您必须通过 `--cgroups-per-qos` 标志启用新的 cgroup 层次结构。
这个标志是默认启用的。启用后，`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 Pod。
<!--
### Configuring a cgroup driver
@@ -141,7 +150,8 @@ be configured to use the `systemd` cgroup driver.
* `cgroupfs` 是默认的驱动，在主机上直接操作 cgroup 文件系统以对 cgroup 沙箱进行管理。
* `systemd` 是可选的驱动，使用 init 系统支持的资源的瞬时切片管理 cgroup 沙箱。
取决于相关容器运行时的配置，操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。例如如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时，必须配置 `kubelet` 使用 `systemd` cgroup 驱动。
取决于相关容器运行时的配置，操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。
例如如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时，必须配置 `kubelet` 使用 `systemd` cgroup 驱动。
<!--
### Kube Reserved
@@ -152,13 +162,7 @@ be configured to use the `systemd` cgroup driver.
`kube-reserved` is meant to capture resource reservation for kubernetes system
daemons like the `kubelet`, `container runtime`, `node problem detector`, etc.
It is not meant to reserve resources for system daemons that are run as pods.
`kube-reserved` is typically a function of `pod density` on the nodes. [This
performance dashboard](http://node-perf-dash.k8s.io/#/builds) exposes `cpu` and
`memory` usage profiles of `kubelet` and `docker engine` at multiple levels of
pod density. [This blog
post](https://kubernetes.io/blog/2016/11/visualize-kubelet-performance-with-node-dashboard)
explains how the dashboard can be interpreted to come up with a suitable
`kube-reserved` reservation.
`kube-reserved` is typically a function of `pod density` on the nodes.
In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for
@@ -185,14 +189,14 @@ exist. Kubelet will fail if an invalid cgroup is specified.
`kube-reserved` 是为了给诸如 `kubelet`、`container runtime`、`node problem detector` 等 kubernetes 系统守护进程争取资源预留。
这并不代表要给以 pod 形式运行的系统守护进程保留资源。`kube-reserved` 通常是节点上的一个 `pod 密度` 功能。
[这个性能仪表盘](http://node-perf-dash.k8s.io/#/builds) 从 pod 密度的多个层面展示了 `kubelet` 和 `docker engine` 的 `cpu` 和 `内存` 使用情况。
[这个博文](https://kubernetes.io/blog/2016/11/visualize-kubelet-performance-with-node-dashboard)解释了如何仪表板以提出合适的 `kube-reserved` 预留。
除了 `cpu`，`内存` 和 `ephemeral-storage` 之外，`pid` 可能是指定为 kubernetes 系统守护进程预留指定数量的进程 ID。
要选择性的在系统守护进程上执行 `kube-reserved`，需要把 kubelet 的 `--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。
推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的 `runtime.slice`）。理想情况下每个系统守护进程都应该在其自己的子控制组中运行。请参考[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，获取更过关于推荐控制组层次结构的细节。
推荐将 kubernetes 系统守护进程放置于顶级控制组之下（例如 systemd 机器上的 `runtime.slice`）。
理想情况下每个系统守护进程都应该在其自己的子控制组中运行。
请参考[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)，获取更过关于推荐控制组层次结构的细节。
请注意，如果 `--kube-reserved-cgroup` 不存在，Kubelet 将**不会**创建它。如果指定了一个无效的 cgroup，Kubelet 将会失败。
@@ -243,7 +247,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
<!--
### Explicitly Reserved CPU List
-->
### 明确保留的 CPU 列表
### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list}
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
- **Kubelet Flag**: `--reserved-cpus=0-3`
@@ -272,7 +276,10 @@ defined by this option, other mechanism outside Kubernetes should be used.
For example: in Centos, you can do this using the tuned toolset.
-->
此选项是专门为 Telco 或 NFV 用例设计的，在这些用例中不受控制的中断或计时器可能会影响其工作负载性能。
可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset，因此系统上的其余 CPU 可以专门用于工作负载，而不受不受控制的中断或计时器的影响较小。要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上，应使用 Kubernetes 之外的其他机制。
可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset，因此系统上的
其余 CPU 可以专门用于工作负载，而不受不受控制的中断或计时器的影响较小。
要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上，
应使用 Kubernetes 之外的其他机制。
例如：在 Centos 系统中，可以使用 tuned 工具集来执行此操作。
<!--
@@ -283,7 +290,7 @@ For example: in Centos, you can do this using the tuned toolset.
Memory pressure at the node level leads to System OOMs which affects the entire
node and all pods running on it. Nodes can go offline temporarily until memory
has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet
provides [`Out of Resource`](./out-of-resource.md) management. Evictions are
provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are
supported for `memory` and `ephemeral-storage` only. By reserving some memory via
`--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory
availability on the node drops below the reserved value. Hypothetically, if
@@ -296,7 +303,9 @@ available for pods.
- **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]`
节点级别的内存压力将导致系统内存不足，这将影响到整个节点及其上运行的所有 pod。节点可以暂时离线直到内存已经回收为止。
为了防止（或减少可能性）系统内存不足，kubelet 提供了[资源不足](./out-of-resource.md)管理。驱逐操作只支持 `memory` 和 `ephemeral-storage`。
为了防止（或减少可能性）系统内存不足，kubelet 提供了
[资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)管理。
驱逐操作只支持 `memory` 和 `ephemeral-storage`。
通过 `--eviction-hard` 标志预留一些内存后，当节点上的可用内存降至保留值以下时，`kubelet` 将尝试`驱逐` pod。
假设，如果节点上不存在系统守护进程，pod 将不能使用超过 `capacity-eviction-hard` 的资源。因此，为驱逐而预留的资源对 pod 是不可用的。
@@ -310,7 +319,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods.
`kubelet` enforce `Allocatable` across pods by default. Enforcement is performed
by evicting pods whenever the overall usage across all pods exceeds
`Allocatable`. More details on eviction policy can be found
[here](./out-of-resource.md#eviction-policy). This enforcement is controlled by
[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
@@ -326,9 +335,14 @@ respectively.
调度器将 `Allocatable` 按 pod 的可用 `capacity` 对待。
`kubelet` 默认在 pod 中执行 `Allocatable`。无论何时，如果所有 pod 的总用量超过了 `Allocatable`，驱逐 pod 的措施将被执行。有关驱逐策略的更多细节可以在[这里](./out-of-resource.md#eviction-policy)找到。请通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
`kubelet` 默认在 Pod 中执行 `Allocatable`。无论何时，如果所有 pod 的总用量超过了 `Allocatable`，
驱逐 pod 的措施将被执行。有关驱逐策略的更多细节可以在
[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy).找到。
请通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
可选的，通过在相同标志中同时指定 `kube-reserved` 和 `system-reserved` 值能够使 `kubelet` 执行 `kube-reserved` 和 `system-reserved`。请注意，要想执行 `kube-reserved` 或者 `system-reserved` 时，需要分别指定 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`。
可选的，通过在相同标志中同时指定 `kube-reserved` 和 `system-reserved` 值能够使 `kubelet`
执行 `kube-reserved` 和 `system-reserved`。请注意，要想执行 `kube-reserved` 或者 `system-reserved` 时，
需要分别指定 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`。
<!--
## General Guidelines
@@ -359,17 +373,23 @@ So expect a drop in `Allocatable` capacity in future releases.
-->
## 一般原则
系统守护进程期望被按照类似 `Guaranteed` pod 一样对待。系统守护进程可以在其范围控制组中爆发式增长，您需要将这个行为作为 kubernetes 部署的一部分进行管理。
例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。然而，如果执行了 `kube-reserved`，则 kubelet 不能突然爆发并耗尽节点的所有可用资源。
系统守护进程期望被按照类似 `Guaranteed` pod 一样对待。系统守护进程可以在其范围控制组中爆发式增长，
您需要将这个行为作为 kubernetes 部署的一部分进行管理。
例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。
然而，如果执行了 `kube-reserved`，则 kubelet 不能突然爆发并耗尽节点的所有可用资源。
在执行 `system-reserved` 预留操作时请加倍小心，因为它可能导致节点上的关键系统服务 CPU 资源短缺或因为内存不足而被终止。
建议只有当用户详尽地描述了他们的节点以得出精确的估计时才强制执行 `system-reserved`，并且如果该组中的任何进程都是 oom_killed，则对他们恢复的能力充满信心。
在执行 `system-reserved` 预留操作时请加倍小心，因为它可能导致节点上的关键系统服务 CPU 资源短缺
或因为内存不足而被终止。
建议只有当用户详尽地描述了他们的节点以得出精确的估计时才强制执行 `system-reserved`，
并且如果该组中的任何进程都是 oom_killed，则对他们恢复的能力充满信心。
* 在 `pods` 上执行 `Allocatable` 作为开始。
* 一旦足够用于追踪系统守护进程的监控和告警的机制到位，请尝试基于用量探索方式执行 `kube-reserved`。
* 随着时间推进，如果绝对必要，可以执行 `system-reserved`。
随着时间的增长以及越来越多特性的加入，kube 系统守护进程对资源的需求可能也会增加。以后 kubernetes 项目将尝试减少对节点系统守护进程的利用，但目前那并不是优先事项。所以，请期待在将来的发布中将 `Allocatable` 容量降低。
随着时间的增长以及越来越多特性的加入，kube 系统守护进程对资源的需求可能也会增加。
以后 kubernetes 项目将尝试减少对节点系统守护进程的利用，但目前那并不是优先事项。
所以，请期待在将来的发布中将 `Allocatable` 容量降低。
@@ -408,58 +428,8 @@ usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
在这个场景下，`Allocatable` 将会是 `14.5 CPUs`、`28.5Gi` 内存以及 `88Gi` 本地存储。
调度器保证这个节点上的所有 pod `请求`的内存总量不超过 `28.5Gi`，存储不超过 `88Gi`。
当 pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，Kubelet 将会驱逐它们。如果节点上的所有进程都尽可能多的使用 CPU，则 pod 加起来不能使用超过 `14.5 CPUs` 的资源。
当没有执行 `kube-reserved` 和/或 `system-reserved` 且系统守护进程使用量超过其预留时，如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，kubelet 将会驱逐 pod。
<!--
## Feature Availability
As of Kubernetes version 1.2, it has been possible to **optionally** specify
`kube-reserved` and `system-reserved` reservations. The scheduler switched to
using `Allocatable` instead of `Capacity` when available in the same release.
As of Kubernetes version 1.6, `eviction-thresholds` are being considered by
computing `Allocatable`. To revert to the old behavior set
`--experimental-allocatable-ignore-eviction` kubelet flag to `true`.
As of Kubernetes version 1.6, `kubelet` enforces `Allocatable` on pods using
control groups. To revert to the old behavior unset `--enforce-node-allocatable`
kubelet flag. Note that unless `--kube-reserved`, or `--system-reserved` or
`--eviction-hard` flags have non-default values, `Allocatable` enforcement does
not affect existing deployments.
As of Kubernetes version 1.6, `kubelet` launches pods in their own cgroup
sandbox in a dedicated part of the cgroup hierarchy it manages. Operators are
required to drain their nodes prior to upgrade of the `kubelet` from prior
versions in order to ensure pods and their associated containers are launched in
the proper part of the cgroup hierarchy.
As of Kubernetes version 1.7, `kubelet` supports specifying `storage` as a resource
for `kube-reserved` and `system-reserved`.
As of Kubernetes version 1.8, the `storage` key name was changed to `ephemeral-storage`
for the alpha release.
-->
## 可用特性
截至 Kubernetes 1.2 版本，已经可以**可选**的指定 `kube-reserved` 和 `system-reserved` 预留。当在相同的发布中都可用时，调度器将转为使用 `Allocatable` 替代 `Capacity`。
截至 Kubernetes 1.6 版本，`eviction-thresholds` 是通过计算 `Allocatable` 进行考虑。要使用旧版本的行为，请设置 `--experimental-allocatable-ignore-eviction` kubelet 标志为 `true`。
截至 Kubernetes 1.6 版本，`kubelet` 使用控制组在 pod 上执行 `Allocatable`。要使用旧版本行为，请取消设置 `--enforce-node-allocatable` kubelet 标志。请注意，除非 `--kube-reserved` 或者 `--system-reserved` 或者 `--eviction-hard` 标志没有默认参数，否则 `Allocatable` 的实施不会影响已经存在的 deployment。
截至 Kubernetes 1.6 版本，`kubelet` 在 pod 自己的 cgroup 沙箱中启动它们，这个 cgroup 沙箱在 `kubelet` 管理的 cgroup 层次结构中的一个独占部分中。在从前一个版本升级 kubelet 之前，要求操作员 drain 节点，以保证 pod 及其关联的容器在 cgroup 层次结构中合适的部分中启动。
截至 Kubernetes 1.7 版本，`kubelet` 支持指定 `storage` 为 `kube-reserved` 和 `system-reserved` 的资源。
截至 Kubernetes 1.8 版本，对于 alpha 版本，`storage` 键值名称已更改为 `ephemeral-storage`。
<!--
As of Kubernetes version 1.17, you can optionally specify
explicit cpuset by `reserved-cpus` as CPUs reserved for OS system
daemons/interrupts/timers and Kubernetes daemons.
-->
从 Kubernetes 1.17 版本开始，可以选择将 `reserved-cpus` 显式 cpuset 指定为操作系统守护程序、中断、计时器和 Kubernetes 守护程序保留的 CPU。
当 pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，Kubelet 将会驱逐它们。
如果节点上的所有进程都尽可能多的使用 CPU，则 pod 加起来不能使用超过 `14.5 CPUs` 的资源。
当没有执行 `kube-reserved` 和/或 `system-reserved` 且系统守护进程使用量超过其预留时，
如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，kubelet 将会驱逐 pod。
content/zh/docs/tasks/extend-kubernetes/http-proxy-access-api.md
+1 -1
View File
@@ -31,7 +31,7 @@ This page shows how to use an HTTP proxy to access the Kubernetes API.
* 如果您的集群中还没有任何应用，使用如下命令启动一个 Hello World 应用：
```shell
kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
kubectl create deployment node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
```
content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md
+2 -7
View File
@@ -78,7 +78,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.
1. Use kubectl to get your resource. When run, kubectl should return "No resources found.". This message indicates that everything worked but you currently have no objects of that resource type created.
-->
1. 确保启用了 APIService API（检查 `--runtime-config`）。默认应该是启用的，除非被特意关闭了。
1. 您可能需要制定一个 RBAC 规则，以允许您添加 APIService 对象，或让您的集群管理员创建一个。（由于 API 扩展会影响整个集群，因此不建议在实时集群中对 API 扩展进行测试/开发/调试）
@@ -94,7 +94,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `system:auth-delegator` 集群角色，以将 auth 决策委派给 Kubernetes 核心 API 服务器。
1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `extension-apiserver-authentication-reader` 角色。这将让您的扩展 api-server 能够访问 `extension-apiserver-authentication` configmap。
1. 创建一个 Kubernetes apiservice。上述的 CA 证书应该使用 base64 编码，剥离新行并用作 apiservice 中的 spec.caBundle。这不应该是命名空间化的。如果使用了 [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)，那么只需要传入 PEM 编码的 CA 绑定，因为 base 64 编码已经完成了。
1. 使用 kubectl 来获得您的资源。它应该返回 "找不到资源"。这意味着一切正常，但您目前还没有创建该资源类型的对象。
1. 使用 kubectl 来获得您的资源。它应该返回 "找不到资源"。此消息表示一切正常，但您目前还没有创建该资源类型的对象。
@@ -109,8 +109,3 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
* 如果你还未配置，请 [配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 并启用 apiserver 的相关参数。
* 高级概述，请参阅 [使用聚合层扩展 Kubernetes API](/docs/concepts/api-extension/apiserver-aggregation)。
* 了解如何 [使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。
content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -74,7 +74,7 @@ Dockerfile 内容如下：
```
FROM php:5-apache
ADD index.php /var/www/html/index.php
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
<!--
content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+2 -4
View File
@@ -40,7 +40,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
* 您必须启用 Kubernetes 集群的 DNS 功能。
* 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}}，则可能已经启用了集群 DNS。
* 如果您正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。
* [安装和设置 v1.7 或更高版本的 kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。
* [安装和设置 v1.7 或更高版本的 kubectl](/zh/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。
* 安装 v2.7.0 或更高版本的 [Helm](http://helm.sh/)。
* 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。
* 如果已经安装了适当版本的 Helm，请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。
@@ -142,7 +142,7 @@ Install Service Catalog from the root of the Helm repository using the following
-->
使用以下命令从 Helm 存储库的根目录安装 Service Catalog：
{{< tabs name="helm-versions" >}}
{{< tabs name="helm-versions" >}}
{{% tab name="Helm version 3" %}}
```shell
helm install catalog svc-cat/catalog --namespace catalog
@@ -163,5 +163,3 @@ helm install svc-cat/catalog --name catalog --namespace catalog
-->
* 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。
* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。