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

Merge remote-tracking branch 'upstream/main' into dev-1.24

Browse Source
This commit is contained in:
Nate W
2022-04-19 15:45:28 -07:00
parent eb71e596a3 f23de579b3
commit 0135d3642b
163 changed files with 7079 additions and 2699 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/architecture/nodes.md
+390 -180
View File
@@ -52,21 +52,20 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP
1. The kubelet on a node self-registers to the control plane
2. You, or another human user, manually add a Node object
After you create a Node object, or the kubelet on a node self-registers, the
control plane checks whether the new Node object is valid. For example, if you
try to create a Node from the following JSON manifest:
After you create a Node {{< glossary_tooltip text="object" term_id="object" >}},
or the kubelet on a node self-registers, the control plane checks whether the new Node object is
valid. For example, if you try to create a Node from the following JSON manifest:
-->
## 管理 {#management}
向 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver"
>}}添加节点的方式主要有两种：
向 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}添加节点的方式主要有两种：
1. 节点上的 `kubelet` 向控制面执行自注册；
2. 你，或者别的什么人，手动添加一个 Node 对象。
在你创建了 Node 对象或者节点上的 `kubelet` 执行了自注册操作之后，
控制面会检查新的 Node 对象是否合法。例如，如果你使用下面的 JSON
对象来创建 Node 对象：
在你创建了 Node {{< glossary_tooltip text="object" term_id="object" >}}或者节点上的
`kubelet` 执行了自注册操作之后，控制面会检查新的 Node 对象是否合法。
例如，如果你尝试使用下面的 JSON 对象来创建 Node 对象：
```json
{
@@ -93,13 +92,14 @@ Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernete
如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。
否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。
{{< note >}}
<!--
Kubernetes keeps the object for the invalid Node and continues checking to see whether
it becomes healthy.
You, or a {{< glossary_tooltip term_id="controller" text="controller">}}, must explicitly
delete the Node object to stop that health checking.
-->
{{< note >}}
Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经
变得健康。
你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必需显式地
@@ -113,6 +113,27 @@ The name of a Node object must be a valid
Node 对象的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
<!--
### Node name uniqueness
The [name](/docs/concepts/overview/working-with-objects/names#names) identifies a Node. Two Nodes
cannot have the same name at the same time. Kubernetes also assumes that a resource with the same
name is the same object. In case of a Node, it is implicitly assumed that an instance using the
same name will have the same state (e.g. network settings, root disk contents)
and attributes like node labels. This may lead to
inconsistencies if an instance was modified without changing its name. If the Node needs to be
replaced or updated significantly, the existing Node object needs to be removed from API server
first and re-added after the update.
-->
### 节点名称唯一性 {#node-name-uniqueness}
节点的[名称](/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。
没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。
就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容）
和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。
如果某个 Node 需要被替换或者大量变更，需要从 API 服务器移除现有的 Node 对象，
之后再在更新之后重新将其加入。
<!--
### Self-registration of Nodes
@@ -129,37 +150,64 @@ For self-registration, the kubelet is started with the following options:
对于自注册模式，kubelet 使用下列参数启动：
<!--
- `--kubeconfig` - Path to credentials to authenticate itself to the API server.
- `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself.
- `--register-node` - Automatically register with the API server.
- `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`).
- `--kubeconfig` - Path to credentials to authenticate itself to the API server.
- `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself.
- `--register-node` - Automatically register with the API server.
- `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`).
No-op if `register-node` is false.
- `--node-ip` - IP address of the node.
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
- `--node-ip` - IP address of the node.
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
-->
- `--kubeconfig` - 用于向 API 服务器表明身份的凭据路径。
- `--cloud-provider` - 与某{{< glossary_tooltip text="云驱动" term_id="cloud-provider" >}}
进行通信以读取与自身相关的元数据的方式。
- `--register-node` - 自动向 API 服务注册。
- `--register-with-taints` - 使用所给的污点列表（逗号分隔的 `<key>=<value>:<effect>`）注册节点。
当 `register-node` 为 false 时无效。
- `--node-ip` - 节点 IP 地址。
- `--node-labels` - 在集群中注册节点时要添加的
{{< glossary_tooltip text="标签" term_id="label" >}}。
（参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。
- `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。
- `--kubeconfig` - 用于向 API 服务器执行身份认证所用的凭据的路径。
- `--cloud-provider` - 与某{{< glossary_tooltip text="云驱动" term_id="cloud-provider" >}}
进行通信以读取与自身相关的元数据的方式。
- `--register-node` - 自动向 API 服务注册。
- `--register-with-taints` - 使用所给的{{< glossary_tooltip text="污点" term_id="taint" >}}列表
（逗号分隔的 `<key>=<value>:<effect>`）注册节点。当 `register-node` 为 false 时无效。
- `--node-ip` - 节点 IP 地址。
- `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。
（参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。
- `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。
<!--
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
kubelets are only authorized to create/modify their own Node resource.
-->
启用[节点授权模式](/zh/docs/reference/access-authn-authz/node/)和
启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和
[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
时，仅授权 `kubelet` 创建或修改其自己的节点资源。
{{< note >}}
<!--
As mentioned in the [Node name uniqueness](#node-name-uniqueness) section,
when Node configuration needs to be updated, it is a good practice to re-register
the node with the API server. For example, if the kubelet being restarted with
the new set of `--node-labels`, but the same Node name is used, the change will
not take an effect, as labels are being set on the Node registration.
-->
正如[节点名称唯一性](#node-name-uniqueness)一节所述，当 Node 的配置需要被更新时，
一种好的做法是重新向 API 服务器注册该节点。例如，如果 kubelet 重启时其 `--node-labels`
是新的值集，但同一个 Node 名称已经被使用，则所作变更不会起作用，
因为节点标签是在 Node 注册时完成的。
<!--
Pods already scheduled on the Node may misbehave or cause issues if the Node
configuration will be changed on kubelet restart. For example, already running
Pod may be tainted against the new labels assigned to the Node, while other
Pods, that are incompatible with that Pod will be scheduled based on this new
label. Node re-registration ensures all Pods will be drained and properly
re-scheduled.
-->
如果在 kubelet 重启期间 Node 配置发生了变化，已经被调度到某 Node 上的 Pod
可能会出现行为不正常或者出现其他问题，例如，已经运行的 Pod
可能通过污点机制设置了与 Node 上新设置的标签相排斥的规则，也有一些其他 Pod，
本来与此 Pod 之间存在不兼容的问题，也会因为新的标签设置而被调到到同一节点。
节点重新注册操作可以确保节点上所有 Pod 都被排空并被正确地重新调度。
{{< /note >}}
<!--
### Manual Node administration
@@ -192,34 +240,35 @@ preparatory step before a node reboot or other maintenance.
To mark a Node unschedulable, run:
-->
你可以结合使用节点上的标签和 Pod 上的选择算符来控制调度。
你可以结合使用 Node 上的标签和 Pod 上的选择算符来控制调度。
例如，你可以限制某 Pod 只能在符合要求的节点子集上运行。
如果标记节点为不可调度（unschedulable），将阻止新 Pod 调度到该节点之上，但不会
影响任何已经在其上的 Pod。
如果标记节点为不可调度（unschedulable），将阻止新 Pod 调度到该 Node 之上，
但不会影响任何已经在其上的 Pod。
这是重启节点或者执行其他维护操作之前的一个有用的准备步骤。
要标记一个节点为不可调度，执行以下命令：
要标记一个 Node 为不可调度，执行以下命令：
```shell
kubectl cordon $NODENAME
```
<!--
See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/)
for more details.
-->
更多细节参考[安全腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
{{< note >}}
<!--
Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate
being run on an unschedulable Node. DaemonSets typically provide node-local services
that should run on the Node even if it is being drained of workload applications.
-->
{{< note >}}
被 {{< glossary_tooltip term_id="daemonset" text="DaemonSet" >}} 控制器创建的 Pod
能够容忍节点的不可调度属性。
DaemonSet 通常提供节点本地的服务，即使节点上的负载应用已经被腾空，这些服务也仍需
运行在节点之上。
DaemonSet 通常提供节点本地的服务，即使节点上的负载应用已经被腾空，
这些服务也仍需运行在节点之上。
{{< /note >}}
<!--
@@ -263,11 +312,11 @@ The usage of these fields varies depending on your cloud provider or bare metal
这些字段的用法取决于你的云服务商或者物理机配置。
<!--
* HostName: The as reported by the node's kernel. Can be overridden via the kubelet `-hostname-override` parameter.
* HostName: The hostname as reported by the node's kernel. Can be overridden via the kubelet `-hostname-override` parameter.
* ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster).
* InternalIP: Typichostnameally the IP address of the node that is routable only within the cluster.
-->
* HostName：由节点的内核设置。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
* HostName：由节点的内核报告。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
* ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
* InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
@@ -301,14 +350,14 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` |
{{< /table >}}
{{< note >}}
<!--
If you use command-line tools to print details of a cordoned Node, the Condition includes
`SchedulingDisabled`. `SchedulingDisabled` is not a Condition in the Kubernetes API; instead,
cordoned nodes are marked Unschedulable in their spec.
-->
{{< note >}}
如果使用命令行工具来打印已保护（Cordoned）节点的细节，其中的 Condition 字段可能
包括 `SchedulingDisabled`。`SchedulingDisabled` 不是 Kubernetes API 中定义的
如果使用命令行工具来打印已保护（Cordoned）节点的细节，其中的 Condition 字段可能包括
`SchedulingDisabled`。`SchedulingDisabled` 不是 Kubernetes API 中定义的
Condition，被保护起来的节点在其规约中被标记为不可调度（Unschedulable）。
{{< /note >}}
@@ -340,16 +389,20 @@ than the `pod-eviction-timeout` (an argument passed to the
{{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}}
for all Pods assigned to that node. The default eviction timeout duration is
**five minutes**.
-->
如果 Ready 状况的 `status` 处于 `Unknown` 或者 `False` 状态的时间超过了
`pod-eviction-timeout` 值（一个传递给
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
的参数），[节点控制器](#node-controller) 会对节点上的所有 Pod 触发
{{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
默认的逐出超时时长为 **5 分钟**。
<!--
In some cases when the node is unreachable, the API server is unable to communicate
with the kubelet on the node. The decision to delete the pods cannot be communicated to
the kubelet until communication with the API server is re-established. In the meantime,
the pods that are scheduled for deletion may continue to run on the partitioned node.
-->
如果 Ready 条件的 `status` 处于 `Unknown` 或者 `False` 状态的时间超过了 `pod-eviction-timeout` 值，
（一个传递给 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 的参数），
[节点控制器](#node-controller) 会对节点上的所有 Pod 触发
{{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
默认的逐出超时时长为 **5 分钟**。
某些情况下，当节点不可达时，API 服务器不能和其上的 kubelet 通信。
删除 Pod 的决定不能传达给 kubelet，直到它重新建立和 API 服务器的连接为止。
与此同时，被计划删除的 Pod 可能会继续在游离的节点上运行。
@@ -370,15 +423,24 @@ names.
从 Kubernetes 删除节点对象将导致 API 服务器删除节点上所有运行的 Pod 对象并释放它们的名字。
<!--
The node lifecycle controller automatically creates
[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions.
When problems occur on nodes, the Kubernetes control plane automatically creates
[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions
affecting the node.
The scheduler takes the Node's taints into consideration when assigning a Pod to a Node.
Pods can also have tolerations which let them tolerate a Node's taints.
Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let
them run on a Node even though it has a specific taint.
-->
节点生命周期控制器会自动创建代表状况的
当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的
[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
当调度器将 Pod 指派给某节点时，会考虑节点上的污点。
Pod 则可以通过容忍度（Toleration）表达所能容忍的污点。
调度器在将 Pod 指派到某 Node 时会考虑 Node 上的污点设置。
Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}}，
以便能够在设置了特定污点的 Node 上运行。
<!--
See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)
for more details.
-->
进一步的细节可参阅[根据状况为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。
<!--
### Capacity and Allocatable {#capacity}
@@ -386,9 +448,9 @@ Pod 则可以通过容忍度（Toleration）表达所能容忍的污点。
Describes the resources available on the node: CPU, memory and the maximum
number of pods that can be scheduled onto the node.
-->
### 容量与可分配 {#capacity}
### 容量（Capacity）与可分配（Allocatable） {#capacity}
描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
这两个值描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
<!--
The fields in the capacity block indicate the total amount of resources that a
@@ -415,34 +477,51 @@ The kubelet gathers this information from the node and publishes it into
the Kubernetes API.
-->
### 信息 {#info}
### 信息（Info） {#info}
描述节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
Info 指的是节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
容器运行时详细信息，以及 节点使用的操作系统。
`kubelet` 从节点收集这些信息并将其发布到 Kubernetes API。
<!--
## Heartbeats
Heartbeats, sent by Kubernetes nodes, help your cluster determine the
availability of each node, and to take action when failures are detected.
For nodes there are two forms of heartbeats:
-->
## 心跳 {#heartbeats}
Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。
对于节点，有两种形式的心跳:
<!--
* updates to the `.status` of a Node
* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) objects
within the `kube-node-lease`
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
Each Node has an associated Lease object.
-->
* 更新节点的 `.status`
* `kube-node-lease` {{<glossary_tooltip term_id="namespace" text="命名空间">}}中的
[Lease（租约）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
每个节点都有一个关联的 Lease 对象。
<!--
Compared to updates to `.status` of a Node, a Lease is a lightweight resource.
Using Leases for heartbeats reduces the performance impact of these updates
for large clusters.
The kubelet is responsible for creating and updating the `.status` of Nodes,
and for updating their related Leases.
-->
与 Node 的 `.status` 更新相比，Lease 是一种轻量级资源。
使用 Lease 来表达心跳在大型集群中可以减少这些更新对性能的影响。
kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 Lease。
<!--
- The kubelet updates the node's `.status` either when there is change in status
or if there has been no update for a configured interval. The default interval
for `.status` updates to Nodes is 5 minutes, which is much longer than the 40
@@ -452,27 +531,12 @@ and for updating their related Leases.
updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
-->
## 心跳 {#heartbeats}
Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。
对于节点，有两种形式的心跳:
* 更新节点的 `.status`
* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 对象
在 `kube-node-lease` {{<glossary_tooltip term_id="namespace" text="命名空间">}}中。
每个节点都有一个关联的 Lease 对象。
与 Node 的 `.status` 更新相比，`Lease` 是一种轻量级资源。
使用 `Leases` 心跳在大型集群中可以减少这些更新对性能的影响。
kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 `Lease`。
- 当状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `.status`。
`.status` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。
- `kubelet` 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。
`Lease` 更新独立于 `NodeStatus` 更新而发生。
如果 `Lease` 的更新操作失败，`kubelet` 会采用指数回退机制，从 200 毫秒开始
重试，最长重试间隔为 7 秒钟。
- 当节点状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `.status`。
`.status` 更新的默认间隔为 5 分钟（比节点不可达事件的 40 秒默认超时时间长很多）。
- `kubelet` 会创建并每 10 秒（默认更新间隔时间）更新 Lease 对象。
Lease 的更新独立于 Node 的 `.status` 更新而发生。
如果 Lease 的更新操作失败，kubelet 会采用指数回退机制，从 200 毫秒开始重试，
最长重试间隔为 7 秒钟。
<!--
## Node Controller
@@ -485,8 +549,8 @@ CIDR block to the node when it is registered (if CIDR assignment is turned on).
-->
## 节点控制器 {#node-controller}
节点{{< glossary_tooltip text="控制器" term_id="controller" >}}是
Kubernetes 控制面组件，管理节点的方方面面。
节点{{< glossary_tooltip text="控制器" term_id="controller" >}}是 Kubernetes 控制面组件，
管理节点的方方面面。
节点控制器在节点的生命周期中扮演多个角色。
第一个是当节点注册时为它分配一个 CIDR 区段（如果启用了 CIDR 分配）。
@@ -505,6 +569,7 @@ controller deletes the node from its list of nodes.
<!--
The third is monitoring the nodes' health. The node controller is
responsible for:
- In the case that a node becomes unreachable, updating the NodeReady condition
of within the Node's `.status`. In this case the node controller sets the
NodeReady condition to `ConditionUnknown`.
@@ -516,12 +581,13 @@ responsible for:
The node controller checks the state of each node every `-node-monitor-period` seconds.
-->
第三个是监控节点的健康状况。 节点控制器是负责：
- 在节点节点不可达的情况下，在 Node 的 `.status` 中更新 `NodeReady` 状况。
在这种情况下，节点控制器将 `NodeReady` 状况更新为 `ConditionUnknown` 。
- 如果节点仍然无法访问：对于不可达节点上的所有 Pod触发
第三个是监控节点的健康状况。节点控制器负责：
- 在节点不可达的情况下，在 Node 的 `.status` 中更新 NodeReady 状况。
在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown` 。
- 如果节点仍然无法访问：对于不可达节点上的所有 Pod 触发
[API-发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)。
默认情况下，节点控制器 在将节点标记为 `ConditionUnknown` 后等待 5 分钟 提交第一个驱逐请求。
默认情况下，节点控制器在将节点标记为 `Unknown` 后等待 5 分钟提交第一个驱逐请求。
节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
@@ -542,29 +608,33 @@ The node eviction behavior changes when a node in a given availability zone
becomes unhealthy. The node controller checks what percentage of nodes in the zone
are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
the same time:
-->
当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `Unknown` 或 `False`）
的节点的百分比：
<!--
- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold`
(default 0.55), then the eviction rate is reduced.
- If the cluster is small (i.e. has less than or equal to
`--large-cluster-size-threshold` nodes - default 50), then evictions are stopped.
- Otherwise, the eviction rate is reduced to `--secondary-node-eviction-rate`
(default 0.01) per second.
-->
- 如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
驱逐速率将会降低。
- 如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个节点 - 默认为 50），
驱逐操作将会停止。
- 否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
<!--
The reason these policies are implemented per availability zone is because one
availability zone might become partitioned from the master while the others remain
connected. If your cluster does not span multiple cloud provider availability zones,
then the eviction mechanism does not take per-zone unavailability into account.
-->
当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `ConditionUnknown` 或 `ConditionFalse`）
的节点的百分比：
- 如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
驱逐速率将会降低。
- 如果集群较小（意即小于等于 `--large-cluster-size-threshold`
个节点 - 默认为 50），驱逐操作将会停止。
- 否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域
可能仍然保持连接。
在逐个可用区域中实施这些策略的原因是，
当一个可用区域可能从控制面脱离时其它可用区域可能仍然保持连接。
如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。
<!--
@@ -583,8 +653,8 @@ evict pods from the remaining nodes that are unhealthy or unreachable).
因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率
`--node-eviction-rate` 进行驱逐操作。
在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，
节点控制器将假设控制面与节点间的连接出了某些问题，它将停止所有驱逐动作（如果故障后部分节点重新连接，
节点控制器会从剩下不健康或者不可达节点中驱逐 `pods`）。
节点控制器将假设控制面与节点间的连接出了某些问题，它将停止所有驱逐动作
（如果故障后部分节点重新连接，节点控制器会从剩下不健康或者不可达节点中驱逐 Pod）。
<!--
The Node Controller is also responsible for evicting pods running on nodes with
@@ -595,8 +665,8 @@ that the scheduler won't place Pods onto unhealthy nodes.
-->
节点控制器还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 Pod，
除非这些 Pod 能够容忍此污点。
节点控制器还负责根据节点故障（例如节点不可访问或没有就绪）为其添加
{{< glossary_tooltip text="污点" term_id="taint" >}}。
节点控制器还负责根据节点故障（例如节点不可访问或没有就绪）
为其添加{{< glossary_tooltip text="污点" term_id="taint" >}}。
这意味着调度器不会将 Pod 调度到不健康的节点上。
<!--
@@ -612,8 +682,8 @@ you need to set the node's capacity information when you add it.
Node 对象会跟踪节点上资源的容量（例如可用内存和 CPU 数量）。
通过[自注册](#self-registration-of-nodes)机制生成的 Node 对象会在注册期间报告自身容量。
如果你[手动](#manual-node-administration)添加了 Node，你就需要在添加节点时
手动设置节点容量。
如果你[手动](#manual-node-administration)添加了 Node，
你就需要在添加节点时手动设置节点容量。
<!--
The Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} ensures that
@@ -623,18 +693,19 @@ The sum of requests includes all containers started by the kubelet, but excludes
containers started directly by the container runtime, and also excludes any
process running outside of the kubelet's control.
-->
Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}保证节点上
有足够的资源供其上的所有 Pod 使用。它会检查节点上所有容器的请求的总和不会超过节点的容量。
Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}
保证节点上有足够的资源供其上的所有 Pod 使用。
它会检查节点上所有容器的请求的总和不会超过节点的容量。
总的请求包括由 kubelet 启动的所有容器，但不包括由容器运行时直接启动的容器，
也不包括不受 `kubelet` 控制的其他进程。
{{< note >}}
<!--
If you want to explicitly reserve resources for non-Pod processes, follow this tutorial to
[reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
-->
{{< note >}}
如果要为非 Pod 进程显式保留资源。请参考
[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
如果要为非 Pod 进程显式保留资源。
请参考[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
{{< /note >}}
<!--
@@ -653,8 +724,7 @@ for more information.
-->
如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
`kubelet` 可以在作出资源分配决策时使用拓扑提示。
参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
了解详细信息。
参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)了解详细信息。
<!--
## Graceful node shutdown {#graceful-node-shutdown}
@@ -666,11 +736,14 @@ for more information.
<!--
The kubelet attempts to detect node system shutdown and terminates pods running on the node.
Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown.
Kubelet ensures that pods follow the normal
[pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
during the node shutdown.
-->
kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的 Pods。
在节点终止期间，kubelet 保证 Pod 遵从常规的 [Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
在节点终止期间，kubelet 保证 Pod 遵从常规的
[Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
<!--
The graceful node shutdown feature depends on systemd since it takes advantage of
@@ -678,7 +751,7 @@ The graceful node shutdown feature depends on systemd since it takes advantage o
delay the node shutdown with a given duration.
-->
体面节点关闭特性依赖于 systemd，因为它要利用
[systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)
[systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)机制，
在给定的期限内延迟节点关闭。
<!--
@@ -687,8 +760,8 @@ Graceful node shutdown is controlled with the `GracefulNodeShutdown`
enabled by default in 1.21.
-->
体面节点关闭特性受 `GracefulNodeShutdown`
[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)
控制，在 1.21 版本中是默认启用的。
[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)控制，
在 1.21 版本中是默认启用的。
<!--
Note that by default, both configuration options described below,
@@ -697,8 +770,7 @@ thus not activating Graceful node shutdown functionality.
To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values.
-->
注意，默认情况下，下面描述的两个配置选项，`ShutdownGracePeriod` 和
`ShutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活
体面节点关闭功能。
`ShutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活体面节点关闭功能。
要激活此功能特性，这两个 kubelet 配置选项要适当配置，并设置为非零值。
<!--
@@ -707,7 +779,7 @@ During a graceful shutdown, kubelet terminates pods in two phases:
1. Terminate regular pods running on the node.
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
-->
在体面关闭节点过程中，kubelet 分两个阶段来终止 Pods：
在体面关闭节点过程中，kubelet 分两个阶段来终止 Pod：
1. 终止在节点上运行的常规 Pod。
2. 终止在节点上运行的[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
@@ -723,11 +795,10 @@ Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/
[`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项：
* `ShutdownGracePeriod`：
* 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod 还是
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
* 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod
还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
* `ShutdownGracePeriodCriticalPods`：
* 在节点关闭期间指定用于终止
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
* 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
的持续时间。该值应小于 `ShutdownGracePeriod`。
<!--
@@ -740,8 +811,7 @@ reserved for terminating [critical pods](/docs/tasks/administer-cluster/guarante
例如，如果设置了 `ShutdownGracePeriod=30s` 和 `ShutdownGracePeriodCriticalPods=10s`，
则 kubelet 将延迟 30 秒关闭节点。
在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod，
而保留最后 10 秒用于终止
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
而保留最后 10 秒用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
<!--
When pods were evicted during the graceful node shutdown, they are marked as failed.
@@ -749,62 +819,200 @@ Running `kubectl get pods` shows the status of the the evicted pods as `Shutdown
And `kubectl describe pod` indicates that the pod was evicted because of node shutdown:
```
Status: Failed
Reason: Shutdown
Message: Node is shutting, evicting pods
Reason: Terminated
Message: Pod was terminated in response to imminent node shutdown.
```
Failed pod objects will be preserved until explicitly deleted or [cleaned up by the GC](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection).
This is a change of behavior compared to abrupt node termination.
-->
{{< note >}}
当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为 `failed`。
运行 `kubectl get pods` 将被驱逐的 pod 的状态显示为 `Shutdown`。
并且 `kubectl describe pod` 表示 pod 因节点关闭而被驱逐：
当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为已经失败（Failed）。
运行 `kubectl get pods` 时，被驱逐的 Pod 的状态显示为 `Shutdown`。
并且 `kubectl describe pod` 表示 Pod 因节点关闭而被驱逐：
```
Status: Failed
Reason: Shutdown
Message: Node is shutting, evicting pods
Reason: Terminated
Message: Pod was terminated in response to imminent node shutdown.
```
`Failed` 的 pod 对象将被保留，直到被明确删除或
[由 GC 清理](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)。
与突然的节点终止相比这是一种行为变化。
{{< /note >}}
<!--
### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown}
-->
### 基于 Pod 优先级的体面节点关闭 {#pod-priority-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
<!--
To provide more flexibility during graceful node shutdown around the ordering
of pods during shutdown, graceful node shutdown honors the PriorityClass for
Pods, provided that you enabled this feature in your cluster. The feature
allows cluster administers to explicitly define the ordering of pods
during graceful node shutdown based on
[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
-->
为了在体面节点关闭期间提供更多的灵活性，尤其是处理关闭期间的 Pod 排序问题，
体面节点关闭机制能够关注 Pod 的 PriorityClass 设置，前提是你已经在集群中启用了此功能特性。
此功能特性允许集群管理员基于 Pod
的[优先级类（Priority Class）](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
显式地定义体面节点关闭期间 Pod 的处理顺序。
<!--
The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described
above, shuts down pods in two phases, non-critical pods, followed by critical
pods. If additional flexibility is needed to explicitly define the ordering of
pods during shutdown in a more granular way, pod priority based graceful
shutdown can be used.
-->
前文所述的[体面节点关闭](#graceful-node-shutdown)特性能够分两个阶段关闭 Pod，
首先关闭的是非关键的 Pod，之后再处理关键 Pod。
如果需要显式地以更细粒度定义关闭期间 Pod 的处理顺序，需要一定的灵活度，
这时可以使用基于 Pod 优先级的体面关闭机制。
<!--
When graceful node shutdown honors pod priorities, this makes it possible to do
graceful node shutdown in multiple phases, each phase shutting down a
particular priority class of pods. The kubelet can be configured with the exact
phases and shutdown time per phase.
-->
当体面节点关闭能够处理 Pod 优先级时，体面节点关闭的处理可以分为多个阶段，
每个阶段关闭特定优先级类的 Pod。kubelet 可以被配置为按确切的阶段处理 Pod，
且每个阶段可以独立设置关闭时间。
<!--
Assuming the following custom pod
[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
in a cluster,
-->
假设集群中存在以下自定义的 Pod
[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。
| Pod 优先级类名称 | Pod 优先级类数值 |
|-------------------------|------------------------|
|`custom-class-a` | 100000 |
|`custom-class-b` | 10000 |
|`custom-class-c` | 1000 |
|`regular/unset` | 0 |
<!--
Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
the settings for `shutdownGracePeriodByPodPriority` could look like:
-->
在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中，
`shutdownGracePeriodByPodPriority` 可能看起来是这样：
| Pod 优先级类数值 | 关闭期限 |
|------------------------|-----------|
| 100000 | 10 秒 |
| 10000 | 180 秒 |
| 1000 | 120 秒 |
| 0 | 60 秒 |
<!--
The corresponding kubelet config YAML configuration would be:
-->
对应的 kubelet 配置 YAML 将会是：
```yaml
shutdownGracePeriodByPodPriority:
- priority: 100000
shutdownGracePeriodSeconds: 10
- priority: 10000
shutdownGracePeriodSeconds: 180
- priority: 1000
shutdownGracePeriodSeconds: 120
- priority: 0
shutdownGracePeriodSeconds: 60
```
<!--
The above table implies that any pod with `priority` value >= 100000 will get
just 10 seconds to stop, any pod with value >= 10000 and < 100000 will get 180
seconds to stop, any pod with value >= 1000 and < 10000 will get 120 seconds to stop.
Finally, all other pods will get 60 seconds to stop.
One doesn't have to specify values corresponding to all of the classes. For
example, you could instead use these settings:
-->
上面的表格表明，所有 `priority` 值大于等于 100000 的 Pod 会得到 10 秒钟期限停止，
所有 `priority` 值介于 10000 和 100000 之间的 Pod 会得到 180 秒钟期限停止，
所有 `priority` 值介于 1000 和 10000 之间的 Pod 会得到 120 秒钟期限停止，
所有其他 Pod 将获得 60 秒的时间停止。
用户不需要为所有的优先级类都设置数值。例如，你也可以使用下面这种配置：
| Pod 优先级类数值 | 关闭期限 |
|------------------------|-----------|
| 100000 | 300 秒 |
| 1000 | 120 秒 |
| 0 | 60 秒 |
<!--
In the above case, the pods with `custom-class-b` will go into the same bucket
as `custom-class-c` for shutdown.
If there are no pods in a particular range, then the kubelet does not wait
for pods in that priority range. Instead, the kubelet immediately skips to the
next priority class value range.
-->
在上面这个场景中，优先级类为 `custom-class-b` 的 Pod 会与优先级类为 `custom-class-c`
的 Pod 在关闭时按相同期限处理。
如果在特定的范围内不存在 Pod，则 kubelet 不会等待对应优先级范围的 Pod。
kubelet 会直接跳到下一个优先级数值范围进行处理。
<!--
If this feature is enabled and no configuration is provided, then no ordering
action will be taken.
Using this feature, requires enabling the
`GracefulNodeShutdownBasedOnPodPriority` feature gate, and setting the kubelet
config's `ShutdownGracePeriodByPodPriority` to the desired configuration
containing the pod priority class values and their respective shutdown periods.
-->
如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。
使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 功能特性，
并将 kubelet 配置中的 `ShutdownGracePeriodByPodPriority` 设置为期望的配置，
其中包含 Pod 的优先级类数值以及对应的关闭期限。
<!--
Metrics `graceful_shutdown_start_time_seconds` and `graceful_shutdown_end_time_seconds`
are emitted under the kubelet subsystem to monitor node shutdowns.
-->
kubelet 子系统中会生成 `graceful_shutdown_start_time_seconds` 和
`graceful_shutdown_end_time_seconds` 度量指标以便监视节点关闭行为。
<!--
## Swap memory management {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
Prior to Kubernetes 1.22, nodes did not support the use of swap memory, and a
kubelet would by default fail to start if swap was detected on a node. In 1.22
onwards, swap memory support can be enabled on a per-node basis.
To enable swap on a node, the `NodeSwap` feature gate must be enabled on
the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn`
[configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
must be set to false.
A user can also optionally configure `memorySwap.swapBehavior` in order to
specify how a node will use swap memory. For example,
-->
## 交换内存管理 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
在 Kubernetes 1.22 之前，节点不支持使用交换内存，并且
默认情况下，如果在节点上检测到交换内存配置，kubelet 将无法启动。 在 1.22
以后，可以在每个节点的基础上启用交换内存支持。
<!--
Prior to Kubernetes 1.22, nodes did not support the use of swap memory, and a
kubelet would by default fail to start if swap was detected on a node. In 1.22
onwards, swap memory support can be enabled on a per-node basis.
-->
在 Kubernetes 1.22 之前，节点不支持使用交换内存，并且默认情况下，
如果在节点上检测到交换内存配置，kubelet 将无法启动。
在 1.22 以后，可以逐个节点地启用交换内存支持。
<!--
To enable swap on a node, the `NodeSwap` feature gate must be enabled on
the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn`
[configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
must be set to false.
-->
要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控，
同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
设置为false。
设置为 false。
用户还可以选择配置 `memorySwap.swapBehavior` 以指定节点使用交换内存的方式。 例如:
<!--
A user can also optionally configure `memorySwap.swapBehavior` in order to
specify how a node will use swap memory. For example,
-->
用户还可以选择配置 `memorySwap.swapBehavior` 以指定节点使用交换内存的方式。例如:
```yaml
memorySwap:
@@ -818,41 +1026,43 @@ The available configuration options for `swapBehavior` are:
use. Workloads on the node not managed by Kubernetes can still swap.
- `UnlimitedSwap`: Kubernetes workloads can use as much swap memory as they
request, up to the system limit.
-->
可用的 `swapBehavior` 的配置选项有：
- `LimitedSwap`：Kubernetes 工作负载的交换内存会受限制。
不受 Kubernetes 管理的节点上的工作负载仍然可以交换。
- `UnlimitedSwap`：Kubernetes 工作负载可以使用尽可能多的交换内存请求，
一直到达到系统限制为止。
<!--
If configuration for `memorySwap` is not specified and the feature gate is
enabled, by default the kubelet will apply the same behaviour as the
`LimitedSwap` setting.
The behaviour of the `LimitedSwap` setting depends if the node is running with
v1 or v2 of control groups (also known as "cgroups"):
-->
如果启用了特性门控但是未指定 `memorySwap` 的配置，默认情况下 kubelet 将使用
`LimitedSwap` 设置。
`LimitedSwap` 这种设置的行为取决于节点运行的是 v1 还是 v2 的控制组（也就是 `cgroups`）：
<!--
- **cgroupsv1:** Kubernetes workloads can use any combination of memory and
swap, up to the pod's memory limit, if set.
- **cgroupsv2:** Kubernetes workloads cannot use swap memory.
-->
- **cgroupsv1:** Kubernetes 工作负载可以使用内存和交换，上限为 Pod 的内存限制值（如果设置了的话）。
- **cgroupsv2:** Kubernetes 工作负载不能使用交换内存。
<!--
For more information, and to assist with testing and provide feedback, please
see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md).
-->
已有的 `swapBehavior` 的配置选项有：
- `LimitedSwap`：Kubernetes 工作负载的交换内存会受限制。
不受 Kubernetes 管理的节点上的工作负载仍然可以交换。
- `UnlimitedSwap`：Kubernetes 工作负载可以使用尽可能多的交换内存
请求，一直到系统限制。
如果启用了特性门控但是未指定 `memorySwap` 的配置，默认情况下 kubelet 将使用
`LimitedSwap` 设置。
`LimitedSwap` 设置的行为还取决于节点运行的是 v1 还是 v2 的控制组（也就是 `cgroups`）：
- **cgroupsv1:** Kubernetes 工作负载可以使用内存和
交换，达到 pod 的内存限制（如果设置）。
- **cgroupsv2:** Kubernetes 工作负载不能使用交换内存。
如需更多信息以及协助测试和提供反馈，请
参见 [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 及其
[设计方案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)。
如需更多信息以及协助测试和提供反馈，请参见
[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400)
及其[设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)。
## {{% heading "whatsnext" %}}
@@ -863,10 +1073,10 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
-->
* 了解有关节点[组件](/zh/docs/concepts/overview/components/#node-components)。
* 进一步了解节点[组件](/zh/docs/concepts/overview/components/#node-components)。
* 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。
* 阅读架构设计文档中有关
[节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
的章节。
* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
content/zh/docs/concepts/cluster-administration/addons.md
+5
View File
@@ -31,6 +31,7 @@ Add-ons 扩展了 Kubernetes 的功能。
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
* [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes.
@@ -54,6 +55,10 @@ Add-ons 扩展了 Kubernetes 的功能。
同时支持路由（routing）和覆盖/封装（overlay/encapsulation）模式。
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，
例如：Flannel、Calico、Canal、Romana 或者 Weave。
* [Contiv](https://contivpp.io/) 为各种用例和丰富的策略框架提供可配置的网络
（使用 BGP 的本机 L3、使用 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI）。
Contiv 项目完全[开源](https://github.com/contiv)。
[安装程序](https://github.com/contiv/install) 提供了基于 kubeadm 和非 kubeadm 的安装选项。
* 基于 [Tungsten Fabric](https://tungsten.io) 的
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)
是一个开源的多云网络虚拟化和策略管理平台，Contrail 和 Tungsten Fabric 与业务流程系统
content/zh/docs/concepts/containers/images.md
+18 -167
View File
@@ -45,8 +45,7 @@ and possibly a port number as well; for example: `fictional.registry.example:104
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
After the image name part you can add a _tag_ (as also using with commands such
as `docker` and `podman`).
After the image name part you can add a _tag_ (in the same way you would when using with commands like `docker` or `podman`).
Tags let you identify different versions of the same series of images.
-->
## 镜像名称 {#image-names}
@@ -57,8 +56,7 @@ Tags let you identify different versions of the same series of images.
如果你不指定仓库的主机名，Kubernetes 认为你在使用 Docker 公共仓库。
在镜像名称之后，你可以添加一个 _标签（Tag）_ （就像在 `docker` 或 `podman`
中也在用的那样）。
在镜像名称之后，你可以添加一个标签（Tag）（与使用 `docker` 或 `podman` 等命令时的方式相同）。
使用标签能让你辨识同一镜像序列中的不同版本。
<!--
@@ -169,7 +167,7 @@ replace `<image-name>:<tag>` with `<image-name>@<digest>`
将 `<image-name>:<tag>` 替换为 `<image-name>@<digest>`，例如 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。
<!--
When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image fixes the code that you run so that a change at the registry cannot lead to that mix of versions.
When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image by digest fixes the code that you run so that a change at the registry cannot lead to that mix of versions.
There are third-party [admission controllers](/docs/reference/access-authn-authz/admission-controllers/)
that mutate Pods (and pod templates) when they are created, so that the
@@ -179,7 +177,7 @@ running the same code no matter what tag changes happen at the registry.
-->
当使用镜像标签时，如果镜像仓库修改了代码所对应的镜像标签，可能会出现新旧代码混杂在 Pod 中运行的情况。
镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。
指定一个镜像可以固定你所运行的代码，这样镜像仓库的变化就不会导致版本的混杂。
通过摘要指定镜像可固定你运行的代码，这样镜像仓库的变化就不会导致版本的混杂。
有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。
@@ -346,17 +344,12 @@ These options are explained in more detail below.
<!--
### Configuring nodes to authenticate to a private registry
If you run Docker on your nodes, you can configure the Docker container
runtime to authenticate to a private container registry.
This approach is suitable if you can control node configuration.
Specific instructions for setting credentials depends on the container runtime and registry you chose to use. You should refer to your solution's documentation for the most accurate information.
-->
### 配置 Node 对私有仓库认证
如果你在节点上运行的是 Docker，你可以配置 Docker
容器运行时来向私有容器仓库认证身份。
此方法适用于能够对节点进行配置的场合。
设置凭据的具体说明取决于你选择使用的容器运行时和仓库。
你应该参考解决方案的文档来获取最准确的信息。
<!--
Default Kubernetes only supports the `auths` and `HttpHeaders` section in Docker configuration.
@@ -368,154 +361,13 @@ Kubernetes 默认仅支持 Docker 配置中的 `auths` 和 `HttpHeaders` 部分
{{< /note >}}
<!--
Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file. If you put the same file
in the search paths list below, kubelet uses it as the credential provider when pulling images.
For an example of configuring a private container image registry, see the
[Pull an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry)
task. That example uses a private registry in Docker Hub.
-->
Docker 将私有仓库的密钥保存在 `$HOME/.dockercfg` 或 `$HOME/.docker/config.json`
文件中。如果你将相同的文件放在下面所列的搜索路径中，`kubelet` 会在拉取镜像时将其用作凭据
数据来源：
<!--
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{cwd of kubelet}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{cwd of kubelet}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
-->
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{kubelet 当前工作目录}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{kubelet 当前工作目录}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
<!--
You may have to set `HOME=/root` explicitly in the environment of the kubelet process.
-->
{{< note >}}
你可能不得不为 `kubelet` 进程显式地设置 `HOME=/root` 环境变量。
{{< /note >}}
<!--
Here are the recommended steps to configuring your nodes to use a private registry. In this
example, run these on your desktop/laptop:
-->
推荐采用如下步骤来配置节点以便访问私有仓库。以下示例中，在 PC 或笔记本电脑中操作：
<!--
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json` on your PC.
1. View `$HOME/.docker/config.json` in an editor to ensure it contains only the credentials you want to use.
1. Get a list of your nodes; for example:
- if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
- if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
1. Copy your local `.docker/config.json` to one of the search paths list above.
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
-->
1. 针对你要使用的每组凭据，运行 `docker login [服务器]` 命令。这会更新
你本地环境中的 `$HOME/.docker/config.json` 文件。
1. 在编辑器中打开查看 `$HOME/.docker/config.json` 文件，确保其中仅包含你要
使用的凭据信息。
1. 获得节点列表；例如：
- 如果想要节点名称：`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
- 如果想要节点 IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
1. 将本地的 `.docker/config.json` 拷贝到所有节点，放入如上所列的目录之一：
- 例如，可以试一下：`for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
<!--
For production clusters, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
-->
{{< note >}}
对于产品环境的集群，可以使用配置管理工具来将这些设置应用到
你所期望的节点上。
{{< /note >}}
<!--
Verify by creating a Pod that uses a private image; for example:
-->
创建使用私有镜像的 Pod 来验证。例如：
```shell
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: private-image-test-1
spec:
containers:
- name: uses-private-image
image: $PRIVATE_IMAGE_NAME
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
```
输出类似于：
```
pod/private-image-test-1 created
```
<!--
If everything is working, then, after a few moments, you can run:
```shell
kubectl logs private-image-test-1
```
and see that the command outputs:
```
SUCCESS
```
-->
如果一切顺利，那么一段时间后你可以执行：
```shell
kubectl logs private-image-test-1
```
然后可以看到命令的输出：
```
SUCCESS
```
<!--
If you suspect that the command failed, you can run:
-->
如果你怀疑命令失败了，你可以运行：
```shell
kubectl describe pods/private-image-test-1 | grep 'Failed'
```
<!--
In case of failure, the output is similar to:
-->
如果命令确实失败，输出类似于：
```
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
<!--
You must ensure all nodes in the cluster have the same `.docker/config.json`. Otherwise, pods will run on
some nodes and fail to run on others. For example, if you use node autoscaling, then each instance
template needs to include the `.docker/config.json` or mount a drive that contains it.
All pods will have read access to images in any private registry once private
registry keys are added to the `.docker/config.json`.
-->
你必须确保集群中所有节点的 `.docker/config.json` 文件内容相同。
否则，Pod 会能在一些节点上正常运行而无法在另一些节点上启动。
例如，如果使用节点自动扩缩，那么每个实例模板都需要包含 `.docker/config.json`，
或者挂载一个包含该文件的驱动器。
在 `.docker/config.json` 中配置了私有仓库密钥后，所有 Pod 都将能读取私有仓库中的镜像。
有关配置私有容器镜像仓库的示例，请参阅任务
[从私有镜像库中提取图像](/zh/docs/tasks/configure-pod-container/pull-image-private-registry)。
该示例使用 Docker Hub 中的私有注册表。
<!--
### Interpretation of config.json {#config-json}
@@ -686,18 +538,17 @@ Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。
<!--
#### Creating a Secret with a Docker config
You need to know the username, registry password and client email address for authenticating
to the registry, as well as its hostname.
Run the following command, substituting the appropriate uppercase values:
-->
#### 使用 Docker Config 创建 Secret {#creating-a-secret-with-docker-config}
运行以下命令，将大写字母代替为合适的值：
你需要知道用于向仓库进行身份验证的用户名、密码和客户端电子邮件地址，以及它的主机名。
运行以下命令，注意替换适当的大写值：
```shell
kubectl create secret docker-registry <名称> \
--docker-server=DOCKER_REGISTRY_SERVER \
--docker-username=DOCKER_USER \
--docker-password=DOCKER_PASSWORD \
--docker-email=DOCKER_EMAIL
kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
```
<!--
content/zh/docs/concepts/containers/runtime-class.md
+3 -4
View File
@@ -213,11 +213,10 @@ handler 需要配置在 runtimes 块中：
```
<!--
See containerd's config documentation for more details:
https://github.com/containerd/cri/blob/master/docs/config.md
See the containerd [CRI Plugin Config Guide](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) for more details.
-->
更详细信息，请查阅 containerd 配置文档：
https://github.com/containerd/cri/blob/master/docs/config.md
更详细信息，请查阅 containerd
[CRI 插件配置指南](https://github.com/containerd/cri/blob/master/docs/config.md)
#### [cri-o](https://cri-o.io/)
content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+501 -508
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/concepts/security/pod-security-standards.md
+1 -1
View File
@@ -884,7 +884,7 @@ in the Pod manifest, and represent parameters to the container runtime.
<!--
Security profiles are control plane mechanisms to enforce specific settings in the Security Context,
as well as other related parameters outside the Security Context. As of July 2021,
[Pod Security Policies](/docs/concepts/profile/pod-security-profile/) are deprecated in favor of the
[Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/).
Other alternatives for enforcing security profiles are being developed in the Kubernetes
content/zh/docs/concepts/services-networking/dns-pod-service.md
-15
View File
@@ -565,21 +565,6 @@ a list of search domains of up to 2048 characters.
如果启用 kube-apiserver 和 kubelet 的特性门控 `ExpandedDNSConfig`，Kubernetes 将可以有最多 32 个
搜索域以及一个最多 2048 个字符的搜索域列表。
<!--
### Feature availability
The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
-->
### 功能的可用性
Pod DNS 配置和 DNS 策略 "`None`" 的可用版本对应如下所示。
| k8s 版本 | 特性支持 |
| :---------: |:-----------:|
| 1.14 | 稳定 |
| 1.10 | Beta（默认启用） |
| 1.9 | Alpha |
## {{% heading "whatsnext" %}}
<!--
content/zh/docs/concepts/services-networking/network-policies.md
+1 -36
View File
@@ -121,42 +121,7 @@ An example NetworkPolicy might look like this:
下面是一个 NetworkPolicy 的示例:
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
```
{{< codenew file="service/networking/networkpolicy.yaml" >}}
<!--
POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
content/zh/docs/concepts/workloads/controllers/deployment.md
+414 -220
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
+4 -4
View File
@@ -311,7 +311,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl wi
for it to delete each pod before deleting the ReplicationController itself. If this kubectl
command is interrupted, it can be restarted.
When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
When using the REST API or [client library](/docs/reference/using-api/client-libraries), you need to do the steps explicitly (scale replicas to
0, wait for pod deletions, then delete the ReplicationController).
-->
## 使用 ReplicationController {#working-with-replicationcontrollers}
@@ -323,7 +323,7 @@ When using the REST API or Go client library, you need to do the steps explicitl
kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
如果这个 kubectl 命令被中断，可以重新启动它。
当使用 REST API 或 Go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、
当使用 REST API 或[客户端库](/zh/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
等待 Pod 删除，之后删除 ReplicationController 资源）。
<!--
@@ -333,7 +333,7 @@ You can delete a ReplicationController without affecting any of its pods.
Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
When using the REST API or Go client library, simply delete the ReplicationController object.
When using the REST API or [client library](/docs/reference/using-api/client-libraries), you can delete the ReplicationController object.
-->
### 只删除 ReplicationController
@@ -341,7 +341,7 @@ When using the REST API or Go client library, simply delete the ReplicationContr
使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=orphan` 选项。
当使用 REST API 或 Go 客户端库时，只需删除 ReplicationController 对象。
当使用 REST API 或客户端库(/zh/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
<!--
Once the original is deleted, you can create a new ReplicationController to replace it. As long
content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+4 -2
View File
@@ -498,7 +498,8 @@ apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
@@ -589,7 +590,8 @@ apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
+6 -1
View File
@@ -40,6 +40,8 @@ You need to have these tools installed:
- [Golang](https://golang.org/doc/install) version 1.13+
- [Docker](https://docs.docker.com/engine/installation/)
- [etcd](https://github.com/coreos/etcd/)
- [make](https://www.gnu.org/software/make/)
- [gcc compiler/linker](https://gcc.gnu.org/)
-->
- 你需要安装以下工具：
@@ -47,6 +49,8 @@ You need to have these tools installed:
- [Golang](https://golang.org/doc/install) 的 1.13 版本或更高
- [Docker](https://docs.docker.com/engine/installation/)
- [etcd](https://github.com/coreos/etcd/)
- [make](https://www.gnu.org/software/make/)
- [gcc compiler/linker](https://gcc.gnu.org/)
<!--
- Your $GOPATH environment variable must be set, and the location of `etcd`
@@ -237,8 +241,9 @@ hack/update-generated-protobuf.sh
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/openapi-spec/v3/apis__apps__v1_openapi.json
modified: pkg/generated/openapi/zz_generated.openapi.go
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types.go
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
```
content/zh/docs/reference/access-authn-authz/admission-controllers.md
+1 -1
View File
@@ -534,7 +534,7 @@ imagePolicy:
kubeConfigFile: /path/to/kubeconfig/for/backend
# 以秒计的时长，控制批准请求的缓存时间
allowTTL: 50
# 以秒计的时长，控制批准请求的缓存时间
# 以秒计的时长，控制拒绝请求的缓存时间
denyTTL: 50
# 以毫秒计的时长，控制重试间隔
retryBackoff: 500
content/zh/docs/reference/access-authn-authz/rbac.md
+1 -1
View File
@@ -50,7 +50,7 @@ kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选
The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_,
_RoleBinding_ and _ClusterRoleBinding_. You can
[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
or amend them, using tools such as `kubectl,` just like any other Kubernetes object.
or amend them, using tools such as `kubectl`, just like any other Kubernetes object.
-->
## API 对象 {#api-overview}
content/zh/docs/reference/command-line-tools-reference/feature-gates.md
+488 -295
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/reference/config-api/client-authentication.v1.md
+7 -2
View File
@@ -76,6 +76,10 @@ of CertificateAuthority, since CA data will always be passed to the plugin as by
Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需
的信息。
为了确保该结构体包含需要与 Kubernetes 集群进行通信的所有内容（就像通过 Kubeconfig 一样），
除了证书授权之外，该字段应该映射到 "k8s.io/client-go/tools/clientcmd/api/v1".cluster，
由于 CA 数据将始终以字节形式传递给插件。
<table class="table">
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
<tbody>
@@ -167,7 +171,7 @@ clusters:
只是针对不同集群会有一些细节上的差异，例如 audience。
此字段使得特定于集群的配置可以直接使用集群信息来设置。
不建议使用此字段来保存 Secret 数据，因为 exec 插件的主要优势之一是不需要在
kubeconfig 中保存 Secret 数据。
kubeconfig 中保存 Secret 数据。</p>
</td>
</tr>
</tbody>
@@ -222,6 +226,7 @@ ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的
<!--
**Appears in:**
-->
**出现在：**
- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential)
@@ -235,7 +240,7 @@ itself should at least be protected via file permissions.
<p>ExecCredentialStatus 中包含传输组件要使用的凭据。</p>
<p>字段 token 和 clientKeyData 都是敏感字段。此数据只能在
客户端与 exec 插件进程之间使用内存来传递。exec 插件本身至少
应通过文件访问许可来实施保护。</p>》
应通过文件访问许可来实施保护。</p>
<table class="table">
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
content/zh/docs/reference/config-api/client-authentication.v1beta1.md
+117 -35
View File
@@ -1,12 +1,22 @@
---
title: Client Authentication (v1beta1)
title: 客户端身份认证（Client Authentication）(v1beta1)
content_type: tool-reference
package: client.authentication.k8s.io/v1beta1
auto_generated: true
---
<!--
title: Client Authentication (v1beta1)
content_type: tool-reference
package: client.authentication.k8s.io/v1beta1
auto_generated: true
-->
<!--
## Resource Types
-->
## 资源类型 {#resource-types}
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
@@ -20,11 +30,14 @@ auto_generated: true
<!--
ExecCredential is used by exec-based plugins to communicate credentials to
HTTP transports.
-->
ExecCredential 由基于 exec 的插件使用，与 HTTP 传输组件沟通凭据信息。
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
<tbody>
<tr><td><code>apiVersion</code><br/>string</td><td><code>client.authentication.k8s.io/v1beta1</code></td></tr>
@@ -33,11 +46,13 @@ HTTP transports.
<tr><td><code>spec</code> <B>[Required]</B><br/>
<tr><td><code>spec</code> <B><!--[Required]-->[必需]</B><br/>
<a href="#client-authentication-k8s-io-v1beta1-ExecCredentialSpec"><code>ExecCredentialSpec</code></a>
</td>
<td>
Spec holds information passed to the plugin by the transport.</td>
<!--Spec holds information passed to the plugin by the transport.-->
字段 spec 包含由 HTTP 传输组件传递给插件的信息。
</td>
</tr>
@@ -45,8 +60,10 @@ HTTP transports.
<a href="#client-authentication-k8s-io-v1beta1-ExecCredentialStatus"><code>ExecCredentialStatus</code></a>
</td>
<td>
Status is filled in by the plugin and holds the credentials that the transport
should use to contact the API.</td>
<!--Status is filled in by the plugin and holds the credentials that the transport
should use to contact the API.-->
字段 status 由插件填充，包含传输组件与 API 服务器连接时需要提供的凭据。
</td>
</tr>
@@ -60,11 +77,13 @@ should use to contact the API.</td>
**Appears in:**
<!--**Appears in:**-->
**出现在：**
- [ExecCredentialSpec](#client-authentication-k8s-io-v1beta1-ExecCredentialSpec)
<!--
Cluster contains information to allow an exec plugin to communicate
with the kubernetes cluster being authenticated to.
@@ -72,18 +91,27 @@ To ensure that this struct contains everything someone would need to communicate
with a kubernetes cluster (just like they would via a kubeconfig), the fields
should shadow "k8s.io/client-go/tools/clientcmd/api/v1".Cluster, with the exception
of CertificateAuthority, since CA data will always be passed to the plugin as bytes.
-->
Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需
的信息。
为了确保该结构体包含需要与 Kubernetes 集群进行通信的所有内容（就像通过 Kubeconfig 一样），
该字段应该映射到 "k8s.io/client-go/tools/clientcmd/api/v1".cluster，
除了证书授权之外，由于 CA 数据将始终以字节形式传递给插件。
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
<tbody>
<tr><td><code>server</code> <B>[Required]</B><br/>
<tr><td><code>server</code> <B><!--[Required]-->[必需]</B><br/>
<code>string</code>
</td>
<td>
Server is the address of the kubernetes cluster (https://hostname:port).</td>
<!--Server is the address of the kubernetes cluster (https://hostname:port).-->
字段 server 是 Kubernetes 集群的地址（https://hostname:port）。
</td>
</tr>
@@ -91,9 +119,14 @@ of CertificateAuthority, since CA data will always be passed to the plugin as by
<code>string</code>
</td>
<td>
<!--
TLSServerName is passed to the server for SNI and is used in the client to
check server certificates against. If ServerName is empty, the hostname
used to contact the server is used.</td>
used to contact the server is used.
-->
tls-server-name 是用来提供给服务器用作 SNI 解析的，客户端以此检查服务器的证书。
如此字段为空，则使用链接服务器时使用的主机名。
</td>
</tr>
@@ -101,8 +134,13 @@ used to contact the server is used.</td>
<code>bool</code>
</td>
<td>
<!--
InsecureSkipTLSVerify skips the validity check for the server's certificate.
This will make your HTTPS connections insecure.</td>
This will make your HTTPS connections insecure.
-->
设置此字段之后，会令客户端跳过对服务器端证书的合法性检查。
这会使得你的 HTTPS 链接不再安全。
</td>
</tr>
@@ -110,8 +148,13 @@ This will make your HTTPS connections insecure.</td>
<code>[]byte</code>
</td>
<td>
<!--
CAData contains PEM-encoded certificate authority certificates.
If empty, system roots should be used.</td>
If empty, system roots should be used.
-->
此字段包含 PEM 编码的证书机构（CA）证书。
如果为空，则使用系统的根证书。
</td>
</tr>
@@ -119,8 +162,9 @@ If empty, system roots should be used.</td>
<code>string</code>
</td>
<td>
ProxyURL is the URL to the proxy to be used for all requests to this
cluster.</td>
<!--ProxyURL is the URL to the proxy to be used for all requests to this cluster.-->
此字段用来设置向集群发送所有请求时要使用的代理服务器。
</td>
</tr>
@@ -128,27 +172,40 @@ cluster.</td>
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime/#RawExtension"><code>k8s.io/apimachinery/pkg/runtime.RawExtension</code></a>
</td>
<td>
<!--
Config holds additional config data that is specific to the exec
plugin with regards to the cluster being authenticated to.
This data is sourced from the clientcmd Cluster object's
extensions[client.authentication.k8s.io/exec] field:
extensions[client.authentication.k8s.io/exec] field:
-->
<p>此字段包含一些额外的、特定于 exec 插件和所连接的集群的数据，</p>
<p>此字段来自于 clientcmd 集群对象的 <code>extensions[client.authentication.k8s.io/exec]</code>
字段：</p>
<pre>
clusters:
- name: my-cluster
cluster:
...
extensions:
- name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
- name: client.authentication.k8s.io/exec # 针对每个集群 exec 配置所预留的扩展名称
extension:
audience: 06e3fbd18de8 # arbitrary config
audience: 06e3fbd18de8 # 任意配置信息
</pre>
<!--
In some environments, the user config may be exactly the same across many clusters
(i.e. call this exec plugin) minus some details that are specific to each cluster
such as the audience. This field allows the per cluster config to be directly
specified with the cluster info. Using this field to store secret data is not
recommended as one of the prime benefits of exec plugins is that no secrets need
to be stored directly in the kubeconfig.</td>
to be stored directly in the kubeconfig.
-->
<p>在某些环境中，用户配置可能对很多集群而言都完全一样（即调用同一个 exec 插件），
只是针对不同集群会有一些细节上的差异，例如 audience。
此字段使得特定于集群的配置可以直接使用集群信息来设置。
不建议使用此字段来保存 Secret 数据，因为 exec 插件的主要优势之一是不需要在
kubeconfig 中保存 Secret 数据。</p>
</td>
</tr>
@@ -162,16 +219,20 @@ to be stored directly in the kubeconfig.</td>
**Appears in:**
<!-- **Appears in:** -->
**出现在：**
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
<!--
ExecCredentialSpec holds request and runtime specific information provided by
the transport.
the transport.
-->
ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的信息。
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
<tbody>
@@ -180,10 +241,16 @@ the transport.
<a href="#client-authentication-k8s-io-v1beta1-Cluster"><code>Cluster</code></a>
</td>
<td>
<!--
Cluster contains information to allow an exec plugin to communicate with the
kubernetes cluster being authenticated to. Note that Cluster is non-nil only
when provideClusterInfo is set to true in the exec provider config (i.e.,
ExecConfig.ProvideClusterInfo).</td>
ExecConfig.ProvideClusterInfo).
-->
此字段中包含的信息使得 exec 插件能够与要访问的 Kubernetes 集群通信。
注意，cluster 字段只有在 exec 驱动的配置中 provideClusterInfo
（即：ExecConfig.ProvideClusterInfo）被设置为 true 时才不能为空。
</td>
</tr>
@@ -197,20 +264,27 @@ ExecConfig.ProvideClusterInfo).</td>
**Appears in:**
<!-- **Appears in:** -->
**出现在：**
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
<!--
ExecCredentialStatus holds credentials for the transport to use.
Token and ClientKeyData are sensitive fields. This data should only be
transmitted in-memory between client and exec plugin process. Exec plugin
itself should at least be protected via file permissions.
-->
<p>ExecCredentialStatus 中包含传输组件要使用的凭据。</p>
<p>字段 token 和 clientKeyData 都是敏感字段。
此数据只能在客户端与 exec 插件进程之间使用内存来传递。
exec 插件本身至少应通过文件访问许可来实施保护。</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
@@ -218,31 +292,39 @@ itself should at least be protected via file permissions.
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#time-v1-meta"><code>meta/v1.Time</code></a>
</td>
<td>
ExpirationTimestamp indicates a time when the provided credentials expire.</td>
<!-- ExpirationTimestamp indicates a time when the provided credentials expire. -->
给出所提供的凭据到期的时间。
</td>
</tr>
<tr><td><code>token</code> <B>[Required]</B><br/>
<tr><td><code>token</code> <B><!--[Required]-->[必需]</B><br/>
<code>string</code>
</td>
<td>
Token is a bearer token used by the client for request authentication.</td>
<!-- Token is a bearer token used by the client for request authentication. -->
客户端用做请求身份认证的持有者令牌。
</td>
</tr>
<tr><td><code>clientCertificateData</code> <B>[Required]</B><br/>
<tr><td><code>clientCertificateData</code> <B><!--[Required]-->[必需]</B><br/>
<code>string</code>
</td>
<td>
PEM-encoded client TLS certificates (including intermediates, if any).</td>
<!-- PEM-encoded client TLS certificates (including intermediates, if any). -->
PEM 编码的客户端 TLS 证书（如果有临时证书，也会包含）。
</td>
</tr>
<tr><td><code>clientKeyData</code> <B>[Required]</B><br/>
<tr><td><code>clientKeyData</code> <B><!--[Required]-->[必需]</B><br/>
<code>string</code>
</td>
<td>
PEM-encoded private key for the above certificate.</td>
<!-- PEM-encoded private key for the above certificate. -->
与上述证书对应的、PEM 编码的私钥。
</td>
</tr>
content/zh/docs/reference/kubernetes-api/authentication-resources/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "身份认证资源"
weight: 4
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/authorization-resources/_index.md
+7
View File
@@ -0,0 +1,7 @@
---
title: "鉴权资源"
weight: 5
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/cluster-resources/_index.md
+7
View File
@@ -0,0 +1,7 @@
---
title: "集群资源"
weight: 8
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/common-definitions/object-meta.md
+400
View File
@@ -0,0 +1,400 @@
---
api_metadata:
apiVersion: ""
import: "k8s.io/apimachinery/pkg/apis/meta/v1"
kind: "ObjectMeta"
content_type: "api_reference"
description: "ObjectMeta 是所有持久化资源必须具有的元数据，其中包括用户必须创建的所有对象。"
title: "ObjectMeta"
weight: 7
auto_generated: true
---
<!--
api_metadata:
apiVersion: ""
import: "k8s.io/apimachinery/pkg/apis/meta/v1"
kind: "ObjectMeta"
content_type: "api_reference"
description: "ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create."
title: "ObjectMeta"
weight: 7
auto_generated: true
-->
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference content, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
`import "k8s.io/apimachinery/pkg/apis/meta/v1"`
<!--
ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create.
-->
ObjectMeta 是所有持久化资源必须具有的元数据，其中包括用户必须创建的所有对象。
<hr>
- **name** (string)
<!--
Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names
-->
name 在命名空间内必须是唯一的。创建资源时需要，尽管某些资源可能允许客户端请求自动地生成适当的名称。
名称主要用于创建幂等性和配置定义。无法更新。
更多信息：http://kubernetes.io/docs/user-guide/identifiers#names
- **generateName** (string)
<!--
GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.
-->
generateName 是一个可选前缀，由服务器使用，**仅在**未提供 name 字段时生成唯一名称。
如果使用此字段，则返回给客户端的名称将与传递的名称不同。该值还将与唯一的后缀组合。
提供的值与 name 字段具有相同的验证规则，并且可能会根据所需的后缀长度被截断，以使该值在服务器上唯一。
<!--
If this field is specified and the generated name exists, the server will NOT return a 409 - instead, it will either return 201 Created or 500 with Reason ServerTimeout indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header).
Applied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency
-->
如果指定了此字段并且生成的名称存在，则服务器将不会返回 409 ——相反，它将返回 201 Created 或 500，
原因是 ServerTimeout 指示在分配的时间内找不到唯一名称，客户端应重试（可选，在 Retry-After 标头中指定的时间之后）。
仅在未指定 name 时应用。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency
- **namespace** (string)
<!--
Namespace defines the space within which each name must be unique. An empty namespace is equivalent to the "default" namespace, but "default" is the canonical representation. Not all objects are required to be scoped to a namespace - the value of this field for those objects will be empty.
Must be a DNS_LABEL. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/namespaces
-->
namespace 定义了一个值空间，其中每个名称必须唯一。空命名空间相当于 “default” 命名空间，但 “default” 是规范表示。
并非所有对象都需要限定在命名空间中——这些对象的此字段的值将为空。
必须是 DNS_LABEL。无法更新。更多信息：http://kubernetes.io/docs/user-guide/namespaces
- **labels** (map[string]string)
<!--
Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: http://kubernetes.io/docs/user-guide/labels
-->
可用于组织和分类（确定范围和选择）对象的字符串键和值的映射。
可以匹配 ReplicationControllers 和 Service 的选择器。更多信息：http://kubernetes.io/docs/user-guide/labels
- **annotations** (map[string]string)
<!--
Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: http://kubernetes.io/docs/user-guide/annotations
-->
annotations 是一个非结构化的键值映射，存储在资源中，可以由外部工具设置以存储和检索任意元数据。
它们不可查询，在修改对象时应保留。更多信息：http://kubernetes.io/docs/user-guide/annotations
<!-- ### System {#System} -->
### 系统字段 {#System}
- **finalizers** ([]string)
<!--
Must be empty before the object is deleted from the registry. Each entry is an identifier for the responsible component that will remove the entry from the list. If the deletionTimestamp of the object is non-nil, entries in this list can only be removed. Finalizers may be processed and removed in any order. Order is NOT enforced because it introduces significant risk of stuck finalizers. finalizers is a shared field, any actor with permission can reorder it. If the finalizer list is processed in order, then this can lead to a situation in which the component responsible for the first finalizer in the list is waiting for a signal (field value, external system, or other) produced by a component responsible for a finalizer later in the list, resulting in a deadlock. Without enforced ordering finalizers are free to order amongst themselves and are not vulnerable to ordering changes in the list.
-->
在从注册表中删除对象之前该字段必须为空。
每个条目都是负责的组件的标识符，各组件将从列表中删除自己对应的条目。
如果对象的 deletionTimestamp 非空，则只能删除此列表中的条目。
终结器可以按任何顺序处理和删除。**没有**按照顺序执行，
因为它引入了终结器卡住的重大风险。finalizers 是一个共享字段，
任何有权限的参与者都可以对其进行重新排序。如果按顺序处理终结器列表，
那么这可能导致列表中第一个负责终结器的组件正在等待列表中靠后负责终结器的组件产生的信号（字段值、外部系统或其他），
从而导致死锁。在没有强制排序的情况下，终结者可以在它们之间自由排序，
并且不容易受到列表中排序更改的影响。
- **managedFields** ([]ManagedFieldsEntry)
<!--
ManagedFields maps workflow-id and version to the set of fields that are managed by that workflow. This is mostly for internal housekeeping, and users typically shouldn't need to set or understand this field. A workflow can be the user's name, a controller's name, or the name of a specific apply path like "ci-cd". The set of fields is always in the version that the workflow used when modifying the object.
-->
managedFields 将 workflow-id 和版本映射到由该工作流管理的字段集。
这主要用于内部管理，用户通常不需要设置或理解该字段。
工作流可以是用户名、控制器名或特定应用路径的名称，如 “ci-cd”。
字段集始终存在于修改对象时工作流使用的版本。
<a name="ManagedFieldsEntry"></a>
<!--
*ManagedFieldsEntry is a workflow-id, a FieldSet and the group version of the resource that the fieldset applies to.*
-->
ManagedFieldsEntry 是一个 workflow-id，一个 FieldSet，也是该字段集适用的资源的组版本。
- **managedFields.apiVersion** (string)
<!--
APIVersion defines the version of this resource that this field set applies to. The format is "group/version" just like the top-level APIVersion field. It is necessary to track the version of a field set because it cannot be automatically converted.
-->
apiVersion 定义此字段集适用的资源的版本。
格式是 “group/version”，就像顶级 apiVersion 字段一样。
必须跟踪字段集的版本，因为它不能自动转换。
- **managedFields.fieldsType** (string)
<!--
FieldsType is the discriminator for the different fields format and version. There is currently only one possible value: "FieldsV1"
-->
FieldsType 是不同字段格式和版本的鉴别器。
目前只有一个可能的值：“FieldsV1”
- **managedFields.fieldsV1** (FieldsV1)
<!-- FieldsV1 holds the first JSON version format as described in the "FieldsV1" type. -->
FieldsV1 包含类型 “FieldsV1” 中描述的第一个 JSON 版本格式。
<a name="FieldsV1"></a>
<!--
*FieldsV1 stores a set of fields in a data structure like a Trie, in JSON format.
Each key is either a '.' representing the field itself, and will always map to an empty set,
or a string representing a sub-field or item. The string will follow one of these four formats:
'f:<name>', where <name> is the name of a field in a struct, or key in a map
'v:<value>', where <value> is the exact json formatted value of a list item
'i:<index>', where <index> is position of a item in a list
'k:<keys>', where <keys> is a map of a list item's key fields to their unique values
If a key maps to an empty Fields value, the field that key represents is part of the set.
The exact format is defined in sigs.k8s.io/structured-merge-diff*
-->
FieldsV1 以 JSON 格式将一组字段存储在像 Trie 这样的数据结构中。
每个键或是 `.` 表示字段本身，并且始终映射到一个空集，
或是一个表示子字段或元素的字符串。该字符串将遵循以下四种格式之一：
1. `f:<name>`，其中 `<name>` 是结构中字段的名称，或映射中的键
2. `v:<value>`，其中 `<value>` 是列表项的精确 json 格式值
3. `i:<index>`，其中 `<index>` 是列表中项目的位置
4. `k:<keys>`，其中 `<keys>` 是列表项的关键字段到其唯一值的映射
如果一个键映射到一个空的 Fields 值，则该键表示的字段是集合的一部分。
确切的格式在 sigs.k8s.io/structured-merge-diff 中定义。
- **managedFields.manager** (string)
<!-- Manager is an identifier of the workflow managing these fields. -->
manager 是管理这些字段的工作流的标识符。
- **managedFields.operation** (string)
<!--
Operation is the type of operation which lead to this ManagedFieldsEntry being created. The only valid values for this field are 'Apply' and 'Update'.
-->
operation 是导致创建此 managedFields 表项的操作类型。
此字段的仅有合法值是 “Apply” 和 “Update”。
- **managedFields.subresource** (string)
<!--
Subresource is the name of the subresource used to update that object, or empty string if the object was updated through the main resource. The value of this field is used to distinguish between managers, even if they share the same name. For example, a status update will be distinct from a regular update using the same manager name. Note that the APIVersion field is not related to the Subresource field and it always corresponds to the version of the main resource.
-->
subresource 是用于更新该对象的子资源的名称，如果对象是通过主资源更新的，则为空字符串。
该字段的值用于区分管理者，即使他们共享相同的名称。例如，状态更新将不同于使用相同管理者名称的常规更新。
请注意，apiVersion 字段与 subresource 字段无关，它始终对应于主资源的版本。
- **managedFields.time** (Time)
<!--
Time is timestamp of when these fields were set. It should always be empty if Operation is 'Apply'
-->
time 是设置这些字段的时间戳。如果 operation 为 “Apply”，则它应始终为空
<a name="Time"></a>
<!--
*Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.*
-->
time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。
为 time 包提供的许多工厂方法提供了包装类。
- **ownerReferences** ([]OwnerReference)
<!--
*Patch strategy: merge on key `uid`*
List of objects depended by this object. If ALL objects in the list have been deleted, this object will be garbage collected. If this object is managed by a controller, then an entry in this list will point to this controller, with the controller field set to true. There cannot be more than one managing controller.
-->
补丁策略：在键 `uid` 上执行合并操作
此对象所依赖的对象列表。如果列表中的所有对象都已被删除，则该对象将被垃圾回收。
如果此对象由控制器管理，则此列表中的条目将指向此控制器，controller 字段设置为 true。
管理控制器不能超过一个。
<a name="OwnerReference"></a>
<!--
*OwnerReference contains enough information to let you identify an owning object. An owning object must be in the same namespace as the dependent, or be cluster-scoped, so there is no namespace field.*
-->
OwnerReference 包含足够可以让你识别拥有对象的信息。
拥有对象必须与依赖对象位于同一命名空间中，或者是集群作用域的，因此没有命名空间字段。
- **ownerReferences.apiVersion** (string)，<!-- required -->必选
<!-- API version of the referent. -->
被引用资源的 API 版本。
- **ownerReferences.kind** (string)，<!-- required -->必选
<!-- Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds -->
被引用资源的类别。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
- **ownerReferences.name** (string)，<!-- required -->必选
<!-- Name of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#names -->
被引用资源的名称。更多信息：http://kubernetes.io/docs/user-guide/identifiers#names
- **ownerReferences.uid** (string)，<!-- required -->必选
<!-- UID of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#uids -->
被引用资源的 uid。更多信息：http://kubernetes.io/docs/user-guide/identifiers#uids
- **ownerReferences.blockOwnerDeletion** (boolean)
<!--
If true, AND if the owner has the "foregroundDeletion" finalizer, then the owner cannot be deleted from the key-value store until this reference is removed. Defaults to false. To set this field, a user needs "delete" permission of the owner, otherwise 422 (Unprocessable Entity) will be returned.
-->
如果为 true，**并且**如果所有者具有 “foregroundDeletion” 终结器，
则在删除此引用之前，无法从键值存储中删除所有者。
默认为 false。要设置此字段，用户需要所有者的 “delete” 权限，
否则将返回 422 (Unprocessable Entity)。
- **ownerReferences.controller** (boolean)
<!-- If true, this reference points to the managing controller. -->
如果为 true，则此引用指向管理的控制器。
<!-- ### Read-only {#Read-only} -->
### 只读字段 {#Read-only}
- **creationTimestamp** (Time)
<!--
CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC.
Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
-->
creationTimestamp 是一个时间戳，表示创建此对象时的服务器时间。
不能保证在单独的操作中按发生前的顺序设置。
客户端不得设置此值。它以 RFC3339 形式表示，并采用 UTC。
由系统填充。只读。列表为空。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
<a name="Time"></a>
<!--
*Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.*
-->
time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。
为 time 包提供的许多工厂方法提供了包装类。
- **deletionGracePeriodSeconds** (int64)
<!--
Number of seconds allowed for this object to gracefully terminate before it will be removed from the system. Only set when deletionTimestamp is also set. May only be shortened. Read-only.
-->
此对象从系统中删除之前允许正常终止的秒数。
仅当设置了 deletionTimestamp 时才设置。
只能缩短。只读。
- **deletionTimestamp** (Time)
<!--
DeletionTimestamp is RFC 3339 date and time at which this resource will be deleted. This field is set by the server when a graceful deletion is requested by the user, and is not directly settable by a client. The resource is expected to be deleted (no longer visible from resource lists, and not reachable by name) after the time in this field, once the finalizers list is empty. As long as the finalizers list contains items, deletion is blocked. Once the deletionTimestamp is set, this value may not be unset or be set further into the future, although it may be shortened or the resource may be deleted prior to this time. For example, a user may request that a pod is deleted in 30 seconds. The Kubelet will react by sending a graceful termination signal to the containers in the pod. After that 30 seconds, the Kubelet will send a hard termination signal (SIGKILL) to the container and after cleanup, remove the pod from the API. In the presence of network partitions, this object may still exist after this timestamp, until an administrator or automated process can determine the resource is fully terminated. If not set, graceful deletion of the object has not been requested.
Populated by the system when a graceful deletion is requested. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
-->
deletionTimestamp 是删除此资源的 RFC 3339 日期和时间。
该字段在用户请求优雅删除时由服务器设置，客户端不能直接设置。
一旦 finalizers 列表为空，该资源预计将在此字段中的时间之后被删除
（不再从资源列表中可见，并且无法通过名称访问）。
只要 finalizers 列表包含项目，就阻止删除。一旦设置了 deletionTimestamp，
该值可能不会被取消设置或在未来进一步设置，尽管它可能会缩短或在此时间之前可能会删除资源。
例如，用户可能要求在 30 秒内删除一个 Pod。
Kubelet 将通过向 Pod 中的容器发送优雅的终止信号来做出反应。
30 秒后，Kubelet 将向容器发送硬终止信号（SIGKILL），
并在清理后从 API 中删除 Pod。在网络存在分区的情况下，
此对象可能在此时间戳之后仍然存在，直到管理员或自动化进程可以确定资源已完全终止。
如果未设置，则未请求优雅删除该对象。
请求优雅删除时由系统填充。只读。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
<a name="Time"></a>
<!--
*Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.*
-->
“Time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。
为 time 包提供的许多工厂方法提供了包装类。”
- **generation** (int64)
<!--
A sequence number representing a specific generation of the desired state. Populated by the system. Read-only.
-->
表示期望状态的特定生成的序列号。由系统填充。只读。
- **resourceVersion** (string)
<!--
An opaque value that represents the internal version of this object that can be used by clients to determine when objects have changed. May be used for optimistic concurrency, change detection, and the watch operation on a resource or set of resources. Clients must treat these values as opaque and passed unmodified back to the server. They may only be valid for a particular resource or set of resources.
Populated by the system. Read-only. Value must be treated as opaque by clients and . More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
-->
一个不透明的值，表示此对象的内部版本，客户端可以使用该值来确定对象是否已被更改。
可用于乐观并发、变更检测以及对资源或资源集的监听操作。
客户端必须将这些值视为不透明的，且未更改地传回服务器。
它们可能仅对特定资源或一组资源有效。
由系统填充。只读。客户端必须将值视为不透明。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
- **selfLink** (string)
<!--
SelfLink is a URL representing this object. Populated by the system. Read-only.
DEPRECATED Kubernetes will stop propagating this field in 1.20 release and the field is planned to be removed in 1.21 release.
-->
selfLink 是表示此对象的 URL。由系统填充。只读。
**已弃用**。Kubernetes 将在 1.20 版本中停止传播该字段，并计划在 1.21 版本中删除该字段。
- **uid** (string)
<!--
UID is the unique in time and space value for this object. It is typically generated by the server on successful creation of a resource and is not allowed to change on PUT operations.
Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-guide/identifiers#uids
-->
UID 是该对象在时间和空间上的唯一值。它通常由服务器在成功创建资源时生成，并且不允许使用 PUT 操作更改。
由系统填充。只读。更多信息：http://kubernetes.io/docs/user-guide/identifiers#uids
<!-- ### Ignored {#Ignored} -->
### 忽略字段 {#Ignored}
- **clusterName** (string)
<!--
The name of the cluster which the object belongs to. This is used to distinguish resources with same name and namespace in different clusters. This field is not set anywhere right now and apiserver is going to ignore it if set in create or update request.
-->
对象所属的集群的名称。这用于区分不同集群中具有相同名称和命名空间的资源。
该字段现在没有在任何地方设置，如果在创建或更新请求中设置，apiserver 将忽略它。
content/zh/docs/reference/kubernetes-api/common-definitions/status.md
+208
View File
@@ -0,0 +1,208 @@
---
api_metadata:
apiVersion: ""
import: "k8s.io/apimachinery/pkg/apis/meta/v1"
kind: "Status"
content_type: "api_reference"
description: "状态（Status）是不返回其他对象的调用的返回值。"
title: "Status"
weight: 12
auto_generated: true
---
<!--
api_metadata:
apiVersion: ""
import: "k8s.io/apimachinery/pkg/apis/meta/v1"
kind: "Status"
content_type: "api_reference"
description: "Status is a return value for calls that don't return other objects."
title: "Status"
weight: 12
auto_generated: true
-->
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference content, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
`import "k8s.io/apimachinery/pkg/apis/meta/v1"`
<!-- Status is a return value for calls that don't return other objects. -->
状态（Status）是不返回其他对象的调用的返回值。
<hr>
- **apiVersion** (string)
<!--
APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
-->
APIVersion 定义对象表示的版本化模式。
服务器应将已识别的模式转换为最新的内部值，并可能拒绝无法识别的值。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
- **code** (int32)
<!-- Suggested HTTP return code for this status, 0 if not set. -->
此状态的建议 HTTP 返回代码，如果未设置，则为 0。
- **details** (StatusDetails)
<!--
Extended data associated with the reason. Each reason may define its own extended details.
This field is optional and the data returned is not guaranteed to conform to any schema except that defined by the reason type.
-->
与原因（Reason）相关的扩展数据。每个原因都可以定义自己的扩展细节。
此字段是可选的，并且不保证返回的数据符合任何模式，除非由原因类型定义。
<a name="StatusDetails"></a>
<!--
*StatusDetails is a set of additional properties that MAY be set by the server to provide additional information about a response.
The Reason field of a Status object defines what attributes will be set.
Clients must ignore fields that do not match the defined type of each attribute,
and should assume that any attribute may be empty, invalid, or under defined.*
-->
*StatusDetails 是一组附加属性，可以由服务器设置以提供有关响应的附加信息。*
*状态对象的原因字段定义将设置哪些属性。*
*客户端必须忽略与每个属性的定义类型不匹配的字段，并且应该假定任何属性可能为空、无效或未定义。*
- **details.causes** ([]StatusCause)
<!--
The Causes array includes more details associated with the StatusReason failure.
Not all StatusReasons may provide detailed causes.
-->
Causes 数组包含与 StatusReason 故障相关的更多详细信息。
并非所有 StatusReasons 都可以提供详细的原因。
<a name="StatusCause"></a>
<!--
*StatusCause provides more information about an api.Status failure, including cases when multiple errors are encountered.*
-->
*StatusCause 提供有关 api.Status 失败的更多信息，包括遇到多个错误的情况。*
- **details.causes.field** (string)
<!--
The field of the resource that has caused this error, as named by its JSON serialization.
May include dot and postfix notation for nested attributes. Arrays are zero-indexed.
Fields may appear more than once in an array of causes due to fields having multiple errors. Optional.
-->
导致此错误的资源字段，由其 JSON 序列化命名。
可能包括嵌套属性的点和后缀表示法。数组是从零开始索引的。
由于字段有多个错误，字段可能会在一系列原因中出现多次。可选。
<!--
Examples:
"name" - the field "name" on the current resource
"items[0].name" - the field "name" on the first array entry in "items"
-->
示例：
- “name”：当前资源上的字段 “name”
- “items[0].name”：“items” 中第一个数组条目上的字段 “name”
- **details.causes.message** (string)
<!-- A human-readable description of the cause of the error. This field may be presented as-is to a reader. -->
对错误原因的可读描述。该字段可以按原样呈现给读者。
- **details.causes.reason** (string)
<!-- A machine-readable description of the cause of the error. If this value is empty there is no information available. -->
错误原因的机器可读描述。如果此值为空，则没有可用信息。
- **details.group** (string)
<!-- The group attribute of the resource associated with the status StatusReason. -->
与状态 StatusReason 关联的资源的组属性。
- **details.kind** (string)
<!--
The kind attribute of the resource associated with the status StatusReason.
On some operations may differ from the requested resource Kind.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
-->
与状态 StatusReason 关联的资源的种类属性。
在某些操作上可能与请求的资源种类不同。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
- **details.name** (string)
<!-- The name attribute of the resource associated with the status StatusReason (when there is a single name which can be described). -->
与状态 StatusReason 关联的资源的名称属性（当有一个可以描述的名称时）。
- **details.retryAfterSeconds** (int32)
<!--
If specified, the time in seconds before the operation should be retried.
Some errors may indicate the client must take an alternate action -
for those errors this field may indicate how long to wait before taking the alternate action.
-->
如果指定，则应重试操作前的时间（以秒为单位）。
一些错误可能表明客户端必须采取替代操作——对于这些错误，此字段可能指示在采取替代操作之前等待多长时间。
- **details.uid** (string)
<!--
UID of the resource. (when there is a single resource which can be described).
More info: http://kubernetes.io/docs/user-guide/identifiers#uids
-->
资源的 UID（当有单个可以描述的资源时）。
更多信息：http://kubernetes.io/docs/user-guide/identifiers#uids
- **kind** (string)
<!--
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated. In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
-->
Kind 是一个字符串值，表示此对象表示的 REST 资源。
服务器可以从客户端提交请求的端点推断出这一点。
无法更新。驼峰式规则。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
- **message** (string)
<!-- A human-readable description of the status of this operation. -->
此操作状态的人类可读描述。
- **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta</a>)
<!-- Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds -->
标准列表元数据。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
- **reason** (string)
<!--
A machine-readable description of why this operation is in the "Failure" status.
If this value is empty there is no information available.
A Reason clarifies an HTTP status code but does not override it.
-->
机器可读的说明，说明此操作为何处于“失败”状态。
如果此值为空，则没有可用信息。
Reason 澄清了 HTTP 状态代码，但不会覆盖它。
- **status** (string)
<!--
Status of the operation. One of: "Success" or "Failure". More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
-->
操作状态。“Success”或“Failure” 之一。
更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
content/zh/docs/reference/kubernetes-api/common-parameters/common-parameters.md
+220
View File
@@ -0,0 +1,220 @@
---
api_metadata:
apiVersion: ""
import: ""
kind: "Common Parameters"
content_type: "api_reference"
description: ""
title: "常用参数"
weight: 10
auto_generated: true
---
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference content, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
## allowWatchBookmarks {#allowWatchBookmarks}
<!--
allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored.
<hr>
-->
allowWatchBookmarks 字段请求类型为 BOOKMARK 的监视事件。
没有实现书签的服务器可能会忽略这个标志，并根据服务器的判断发送书签。
客户端不应该假设书签会在任何特定的时间间隔返回，也不应该假设服务器会在会话期间发送任何书签事件。
如果当前请求不是 watch 请求，则忽略该字段。
<hr>
## continue {#continue}
<!--
The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 ResourceExpired error together with a continue token.
-->
当需要从服务器检索更多结果时，应该设置 continue 选项。由于这个值是服务器定义的，
客户端只能使用先前查询结果中具有相同查询参数的 continue 值(continue值除外)，
服务器可能拒绝它识别不到的 continue 值。
如果指定的 continue 值不再有效，无论是由于过期(通常是 5 到 15 分钟)
还是服务器上的配置更改，服务器将响应 "410 ResourceExpired" 错误和一个 continue 令牌。
<!--
If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key".
-->
如果客户端需要一个一致的列表，它必须在没有 continue 字段的情况下重新发起 list 请求。
否则，客户端可能会发送另一个带有 410 错误令牌的 list 请求，服务器将响应从下一个键开始的列表，
但列表数据来自最新的快照，这与之前
的列表结果不一致。第一个列表请求之后的对象创建，修改，或删除的对象将被包含在响应中，
只要他们的键是在“下一个键”之后。
<!--
This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.
-->
当 watch 字段为 true 时，不支持此字段。客户端可以从服务器返回的最后一个 resourceVersion 值开始监视，就不会错过任何修改。
<hr>
## dryRun {#dryRun}
<!--
When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
<hr>
-->
表示不应该持久化所请求的修改。无效或无法识别的 dryRun 指令将导致错误响应，
并且服务器不再对请求进行进一步处理。有效值为:
- All: 将处理所有的演练阶段
<hr>
## fieldManager {#fieldManager}
<!--
fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
<hr>
-->
fieldManager 是与进行这些更改的参与者或实体相关联的名称。
长度小于或128个字符且仅包含可打印字符，如 https://golang.org/pkg/unicode/#IsPrint 所定义。
<hr>
## fieldSelector {#fieldSelector}
<!--
A selector to restrict the list of returned objects by their fields. Defaults to everything.
<hr>
-->
根据返回对象的字段限制返回对象列表的选择器。默认为返回所有字段。
<hr>
## force {#force}
<!--
Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.
<hr>
-->
Force 将“强制”应用请求。这意味着用户将重新获得他人拥有的冲突领域。
对于非应用补丁请求，Force 标志必须不设置。
<hr>
## gracePeriodSeconds {#gracePeriodSeconds}
<!--
The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.
<hr>
-->
删除对象前的持续时间(秒数)。值必须为非负整数。取值为 0 表示立即删除。
如果该值为 nil，将使用指定类型的默认宽限期。如果没有指定，默认为每个对象的设置值。0 表示立即删除。
<hr>
## labelSelector {#labelSelector}
<!--
A selector to restrict the list of returned objects by their labels. Defaults to everything.
<hr>
-->
通过标签限制返回对象列表的选择器。默认为返回所有对象。
<hr>
## limit {#limit}
<!--
limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results.
-->
limit 是一个列表调用返回的最大响应数。如果有更多的条目，服务器会将列表元数据上的
'continue' 字段设置为一个值，该值可以用于相同的初始查询来检索下一组结果。
<!--
Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.
-->
设置 limit 可能会在所有请求的对象被过滤掉的情况下返回少于请求的条目数量(下限为零)，
并且客户端应该只根据 continue 字段是否存在来确定是否有更多的结果可用。
服务器可能选择不支持 limit 参数，并将返回所有可用的结果。
如果指定了 limit 并且 continue 字段为空，客户端可能会认为没有更多的结果可用。
如果 watch 为 true，则不支持此字段。
<!--
The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests.
-->
服务器保证在使用 continue 时返回的对象将与不带 limit 的列表调用相同，——
也就是说，在发出第一个请求后所创建、修改或删除的对象将不包含在任何后续的继续请求中。
<!--
This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.
<hr>
-->
这有时被称为一致性快照，确保使用 limit 的客户端在分块接收非常大的结果的客户端能够看到所有可能的对象。
如果对象在分块列表期间被更新，则返回计算第一个列表结果时存在的对象版本。
<hr>
## namespace {#namespace}
<!--
object name and auth scope, such as for teams and projects
<hr>
-->
对象名称和身份验证范围，例如用于团队和项目。
<hr>
## pretty {#pretty}
<!--
If 'true', then the output is pretty printed.
<hr>
-->
如果设置为 'true' ，那么输出是规范的打印。
<hr>
## propagationPolicy {#propagationPolicy}
<!--
Whether and how garbage collection will be performed. Either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.
<hr>
-->
该字段决定是否以及如何执行垃圾收集。可以设置此字段或 OrphanDependents，但不能同时设置。
默认策略由 metadata.finalizers 和特定资源的默认策略设置决定。可接受的值是：
- 'Orphan'：孤立依赖项；
- 'Background'：允许垃圾回收器后台删除依赖；
- 'Foreground'：一个级联策略，前台删除所有依赖项。
<hr>
## resourceVersion {#resourceVersion}
<!--
resourceVersion sets a constraint on what resource versions a request may be served from. See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details.
Defaults to unset
<hr>
-->
resourceVersion 对请求所针对的资源版本设置约束。
详情请参见 https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions。
默认不设置
<hr>
## resourceVersionMatch {#resourceVersionMatch}
<!--
resourceVersionMatch determines how resourceVersion is applied to list calls. It is highly recommended that resourceVersionMatch be set for list calls where resourceVersion is set See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details.
Defaults to unset
<hr>
-->
resourceVersionMatch 字段决定如何将 resourceVersion 应用于列表调用。
强烈建议对设置了 resourceVersion 的列表调用设置 resourceVersion 匹配，
具体请参见 https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions。
默认不设置
<hr>
## timeoutSeconds {#timeoutSeconds}
<!--
Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.
<hr>
-->
list/watch 调用的超时秒数。这选项限制调用的持续时间，无论是否有活动。
<hr>
## watch {#watch}
<!--
Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.
<hr>
-->
监视对所述资源的更改，并将其这类变更以添加、更新和删除通知流的形式返回。指定 resourceVersion。
<hr>
content/zh/docs/reference/kubernetes-api/config-and-storage-resources/_index.md
+7
View File
@@ -0,0 +1,7 @@
---
title: "配置和存储资源"
weight: 3
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/extend-resources/_index.md
+8
View File
@@ -0,0 +1,8 @@
---
title: "扩展资源"
weight: 7
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/policy-resources/_index.md
+7
View File
@@ -0,0 +1,7 @@
---
title: "策略资源"
weight: 6
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/service-resources/_index.md
+7
View File
@@ -0,0 +1,7 @@
---
title: "Service 资源"
weight: 2
auto_generated: true
---
content/zh/docs/reference/kubernetes-api/workload-resources/_index.md
+6
View File
@@ -0,0 +1,6 @@
---
title: "工作负载资源"
weight: 1
auto_generated: true
---
content/zh/docs/reference/scheduling/config.md
+460 -155
View File
@@ -22,7 +22,7 @@ file and passing its path as a command line argument.
<!--
A scheduling Profile allows you to configure the different stages of scheduling
in the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}.
Each stage is exposed in a extension point. Plugins provide scheduling behaviors
Each stage is exposed in an extension point. Plugins provide scheduling behaviors
by implementing one or more of these extension points.
-->
调度模板（Profile）允许你配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
@@ -31,17 +31,19 @@ by implementing one or more of these extension points.
<!--
You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
using the
[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
or [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
struct.
-->
你可以通过运行 `kube-scheduler --config <filename>` 来设置调度模板，
使用 [KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 结构体。
使用 KubeSchedulerConfiguration （[v1beta2](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
或者 [v1beta3](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)） 结构体。
<!-- A minimal configuration looks as follows: -->
最简单的配置如下：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
@@ -77,62 +79,74 @@ extension points:
调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的：
<!--
1. `QueueSort`: These plugins provide an ordering function that is used to
1. `queueSort`: These plugins provide an ordering function that is used to
sort pending Pods in the scheduling queue. Exactly one queue sort plugin
may be enabled at a time.
-->
1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。
1. `queueSort`：这些插件对调度队列中的悬决的 Pod 排序。
一次只能启用一个队列排序插件。
<!--
2. `PreFilter`: These plugins are used to pre-process or check information
2. `preFilter`: These plugins are used to pre-process or check information
about a Pod or the cluster before filtering. They can mark a pod as
unschedulable.
-->
2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
2. `preFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
它们可以将 Pod 标记为不可调度。
<!--
3. `Filter`: These plugins are the equivalent of Predicates in a scheduling
3. `filter`: These plugins are the equivalent of Predicates in a scheduling
Policy and are used to filter out nodes that can not run the Pod. Filters
are called in the configured order. A pod is marked as unschedulable if no
nodes pass all the filters.
-->
3. `Filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。
3. `filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。
过滤器的调用顺序是可配置的。
如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。
<!--
4. `PreScore`: This is an informational extension point that can be used
4. `postFilter`: These plugins are called in their configured order when no
feasible nodes were found for the pod. If any `postFilter` plugin marks the
Pod _schedulable_, the remaining plugins are not called.
-->
4. `postFilter`：当无法为 Pod 找到可用节点时，按照这些插件的配置顺序调用他们。
如果任何 `postFilter` 插件将 Pod 标记为“可调度”，则不会调用其余插件。
<!--
1. `preScore`: This is an informational extension point that can be used
for doing pre-scoring work.
-->
4. `PreScore`：这是一个信息扩展点，可用于预打分工作。
5. `preScore`：这是一个信息扩展点，可用于预打分工作。
<!--
5. `Score`: These plugins provide a score to each node that has passed the
6. `score`: These plugins provide a score to each node that has passed the
filtering phase. The scheduler will then select the node with the highest
weighted scores sum.
-->
5. `Score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
6. `score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
<!--
6. `Reserve`: This is an informational extension point that notifies plugins
7. `reserve`: This is an informational extension point that notifies plugins
when resources have been reserved for a given Pod. Plugins also implement an
`Unreserve` call that gets called in the case of failure during or after
`Reserve`.
-->
6. `Reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。
7. `reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。
这些插件还实现了 `Unreserve` 接口，在 `Reserve` 期间或之后出现故障时调用。
<!-- 7. `Permit`: These plugins can prevent or delay the binding of a Pod. -->
7. `Permit`：这些插件可以阻止或延迟 Pod 绑定。
<!-- 8. `PreBind`: These plugins perform any work required before a Pod is bound.-->
8. `PreBind`：这些插件在 Pod 绑定节点之前执行。
<!-- 8. `permit`: These plugins can prevent or delay the binding of a Pod. -->
8. `permit`：这些插件可以阻止或延迟 Pod 绑定。
<!-- 9. `preBind`: These plugins perform any work required before a Pod is bound.-->
9. `preBind`：这些插件在 Pod 绑定节点之前执行。
<!--
9. `Bind`: The plugins bind a Pod to a Node. Bind plugins are called in order
10. `bind`: The plugins bind a Pod to a Node. Bind plugins are called in order
and once one has done the binding, the remaining plugins are skipped. At
least one bind plugin is required.
-->
9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
10. `bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
<!--
10. `PostBind`: This is an informational extension point that is called after
11. `postBind`: This is an informational extension point that is called after
a Pod has been bound.
-->
10. `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。
11. `postBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。
<!--
12. `multiPoint`: This is a config-only field that allows plugins to be enabled
or disabled for all of their applicable extension points simultaneously.
-->
12. `multiPoint`：这是一个仅配置字段，允许同时为所有适用的扩展点启用或禁用插件。
<!--
For each extension point, you could disable specific [default plugins](#scheduling-plugins)
@@ -141,13 +155,13 @@ or enable your own. For example:
对每个扩展点，你可以禁用[默认插件](#scheduling-plugins)或者是启用自己的插件，例如：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- plugins:
score:
disabled:
- name: NodeResourcesLeastAllocated
- name: PodTopologySpread
enabled:
- name: MyCustomPluginA
weight: 2
@@ -164,16 +178,7 @@ desired.
如果需要，这个字段也可以用来对插件重新顺序。
<!-- ### Scheduling plugins -->
### 调度插件 {#scheduling-plugin}
<!--
1. `UnReserve`: This is an informational extension point that is called if
a Pod is rejected after being reserved and put on hold by a `Permit` plugin.
-->
1. `UnReserve`：这是一个信息扩展点，如果一个 Pod 在预留后被拒绝，并且被 `Permit` 插件搁置，它就会被调用。
<!-- ## Scheduling plugins -->
## 调度插件 {#scheduling-plugins}
### 调度插件 {#scheduling-plugins}
<!--
The following plugins, enabled by default, implement one or more of these
@@ -181,200 +186,175 @@ extension points:
-->
下面默认启用的插件实现了一个或多个扩展点：
<!--
- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
{{< glossary_tooltip text="Services" term_id="service" >}},
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}.
Extension points: `PreScore`, `Score`.
-->
- `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。
实现的扩展点：`PreScore`，`Score`。
<!--
- `ImageLocality`: Favors nodes that already have the container images that the
Pod runs.
Extension points: `Score`.
Extension points: `score`.
-->
- `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。
实现的扩展点：`Score`。
实现的扩展点：`score`。
<!--
- `TaintToleration`: Implements
[taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
Implements extension points: `Filter`, `Prescore`, `Score`.
Implements extension points: `filter`, `prescore`, `score`.
-->
- `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
实现的扩展点：`Filter`，`Prescore`，`Score`。
实现的扩展点：`filter`，`prescore`，`score`。
<!--
- `NodeName`: Checks if a Pod spec node name matches the current node.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `NodePorts`: Checks if a node has free ports for the requested Pod ports.
Extension points: `PreFilter`, `Filter`.
Extension points: `preFilter`, `filter`.
-->
- `NodePorts`：检查 Pod 请求的端口在节点上是否可用。
实现的扩展点：`PreFilter`，`Filter`。
<!--
- `NodePreferAvoidPods`: Scores nodes according to the node
{{< glossary_tooltip text=" " term_id="annotation" >}}
`scheduler.alpha.kubernetes.io/preferAvoidPods`.
Extension points: `Score`.
-->
- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}}
`scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。
实现的扩展点：`preFilter`，`filter`。
实现的扩展点：`Score`。
<!--
- `NodeAffinity`: Implements
[node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
Extension points: `Filter`, `Score`.
Extension points: `filter`, `score`.
-->
- `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。
实现的扩展点：`Filter`，`Score`.
实现的扩展点：`filter`，`score`.
<!--
- `PodTopologySpread`: Implements
[Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
Extension points: `preFilter`, `filter`, `preScore`, `score`.
-->
- `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。
<!--
- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
true.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is
requesting.
Extension points: `PreFilter`, `Filter`.
requesting. The score can use one of three strategies: `LeastAllocated`
(default), `MostAllocated` and `RequestedToCapacityRatio`.
Extension points: `preFilter`, `filter`, `score`.
-->
- `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。
得分可以使用以下三种策略之一：`LeastAllocated`（默认）、`MostAllocated`
和`RequestedToCapacityRatio`。
实现的扩展点：`PreFilter`，`Filter`。
实现的扩展点：`preFilter`，`filter`，`score`。
<!--
- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more
balanced resource usage if the Pod is scheduled there.
Extension points: `Score`.
Extension points: `score`.
-->
- `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。
实现的扩展点：`Score`。
<!--
- `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of
resources.
Extension points: `Score`.
-->
- `NodeResourcesLeastAllocated`：选择资源分配较少的节点。
实现的扩展点：`score`。
实现的扩展点：`Score`。
<!--
- `VolumeBinding`: Checks if the node has or if it can bind the requested
{{< glossary_tooltip text="volumes" term_id="volume" >}}.
Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
Extension points: `preFilter`, `filter`, `reserve`, `preBind`, `score`.
{{< note >}}
`Score` extension point is enabled when `VolumeCapacityPriority` feature is
`score` extension point is enabled when `VolumeCapacityPriority` feature is
enabled. It prioritizes the smallest PVs that can fit the requested volume
size.
{{< /note >}}
-->
- `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。
实现的扩展点: `PreFilter`、`Filter`、`Reserve`、`PreBind` 和 `Score`。
实现的扩展点: `preFilter`、`filter`、`reserve`、`preBind` 和 `score`。
{{< note >}}
当 `VolumeCapacityPriority` 特性被启用时，`Score` 扩展点也被启用。
当 `VolumeCapacityPriority` 特性被启用时，`score` 扩展点也被启用。
它优先考虑可以满足所需卷大小的最小 PV。
{{< /note >}}
<!--
- `VolumeRestrictions`: Checks that volumes mounted in the node satisfy
restrictions that are specific to the volume provider.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `VolumeZone`: Checks that volumes requested satisfy any zone requirements they
might have.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `VolumeZone`：检查请求的卷是否在任何区域都满足。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `NodeVolumeLimits`: Checks that CSI volume limits can be satisfied for the
node.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `EBSLimits`: Checks that AWS EBS volume limits can be satisfied for the node.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `GCEPDLimits`: Checks that GCP-PD volume limits can be satisfied for the node.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `AzureDiskLimits`: Checks that Azure disk volume limits can be satisfied for
the node.
Extension points: `Filter`.
Extension points: `filter`.
-->
- `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。
实现的扩展点：`Filter`。
实现的扩展点：`filter`。
<!--
- `InterPodAffinity`: Implements
[inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity).
Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
Extension points: `preFilter`, `filter`, `preScore`, `score`.
-->
- `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。
实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。
<!--
- `PrioritySort`: Provides the default priority based sorting.
Extension points: `QueueSort`.
Extension points: `queueSort`.
-->
- `PrioritySort`：提供默认的基于优先级的排序。
实现的扩展点：`QueueSort`。
实现的扩展点：`queueSort`。
<!--
- `DefaultBinder`: Provides the default binding mechanism.
Extension points: `Bind`.
Extension points: `bind`.
-->
- `DefaultBinder`：提供默认的绑定机制。
实现的扩展点：`Bind`。
实现的扩展点：`bind`。
<!--
- `DefaultPreemption`: Provides the default preemption mechanism.
Extension points: `PostFilter`.
-->
- `DefaultPreemption`：提供默认的抢占机制。
实现的扩展点：`PostFilter`。
实现的扩展点：`postFilter`。
<!--
You can also enable the following plugins, through the component config APIs,
@@ -382,53 +362,29 @@ that are not enabled by default:
-->
你也可以通过组件配置 API 启用以下插件（默认不启用）:
<!--
- `NodeResourcesMostAllocated`: Favors nodes that have a high allocation of
resources.
Extension points: `Score`.
<!--
- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
{{< glossary_tooltip text="Services" term_id="service" >}},
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}.
Extension points: `preScore`, `score`.
-->
- `NodeResourcesMostAllocated`：选择已分配资源多的节点。
- `SelectorSpread`：偏向把属于
{{< glossary_tooltip text="Services" term_id="service" >}}，
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod 跨节点分布。
实现的扩展点：`Score`。
<!--
- `RequestedToCapacityRatio`: Favor nodes according to a configured function of
the allocated resources.
Extension points: `Score`.
实现的扩展点：`preScore`，`score`。
<!--
- `CinderLimits`: Checks that [OpenStack Cinder](https://docs.openstack.org/cinder/)
volume limits can be satisfied for the node.
Extension points: `filter`.
-->
- `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。
- `CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/)
卷限制
实现的扩展点：`Score`。
<!--
- `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied
for the node.
Extension points: `Filter`.
-->
- `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。
实现的扩展点：`Filter`。
<!--
- `NodeLabel`: Filters and / or scores a node according to configured
{{< glossary_tooltip text="label(s)" term_id="label" >}}.
Extension points: `Filter`, `Score`.
-->
- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}}
过滤节点和/或给节点打分。
实现的扩展点：`Filter`，`Score`。
<!--
- `ServiceAffinity`: Checks that Pods that belong to a
{{< glossary_tooltip term_id="service" >}} fit in a set of nodes defined by
configured labels. This plugin also favors spreading the Pods belonging to a
Service across nodes.
Extension points: `PreFilter`, `Filter`, `Score`.
-->
- `ServiceAffinity`：检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod
与配置的标签所定义的节点集是否适配。
这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。
实现的扩展点：`PreFilter`，`Filter`，`Score`。
<!-- ### Multiple profiles -->
### 多配置文件 {#multiple-profiles}
<!--
@@ -447,7 +403,7 @@ disabled.
使用下面的配置样例，调度器将运行两个配置文件：一个使用默认插件，另一个禁用所有打分插件。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
@@ -496,23 +452,372 @@ Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController
{{< note >}}
<!--
All profiles must use the same plugin in the QueueSort extension point and have
All profiles must use the same plugin in the queueSort extension point and have
the same configuration parameters (if applicable). This is because the scheduler
only has one pending pods queue.
-->
所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。
所有配置文件必须在 queueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。
这是因为调度器只有一个保存 pending 状态 Pod 的队列。
{{< /note >}}
<!--
### Plugins that apply to multiple extension points {#multipoint}
-->
### 应用于多个扩展点的插件 {#multipoint}
<!--
Starting from `kubescheduler.config.k8s.io/v1beta3`, there is an additional field in the
profile config, `multiPoint`, which allows for easily enabling or disabling a plugin
across several extension points. The intent of `multiPoint` config is to simplify the
configuration needed for users and administrators when using custom profiles.
-->
从 `kubescheduler.config.k8s.io/v1beta3` 开始，配置文件配置中有一个附加字段 `multiPoint`，它允许跨多个扩展点轻松启用或禁用插件。
`multiPoint` 配置的目的是简化用户和管理员在使用自定义配置文件时所需的配置。
<!--
Consider a plugin, `MyPlugin`, which implements the `preScore`, `score`, `preFilter`,
and `filter` extension points. To enable `MyPlugin` for all its available extension
points, the profile config looks like:
-->
考虑一个插件，`MyPlugin`，它实现了 `preScore`、`score`、`preFilter` 和 `filter` 扩展点。
要为其所有可用的扩展点启用 `MyPlugin`，配置文件配置如下所示：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: MyPlugin
```
<!--
This would equate to manually enabling `MyPlugin` for all of its extension
points, like so:
-->
这相当于为所有扩展点手动启用`MyPlugin`，如下所示：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
preScore:
enabled:
- name: MyPlugin
score:
enabled:
- name: MyPlugin
preFilter:
enabled:
- name: MyPlugin
filter:
enabled:
- name: MyPlugin
```
<!--
One benefit of using `multiPoint` here is that if `MyPlugin` implements another
extension point in the future, the `multiPoint` config will automatically enable it
for the new extension.
-->
在这里使用 `multiPoint` 的一个好处是，如果 `MyPlugin` 将来实现另一个扩展点，`multiPoint` 配置将自动为新扩展启用它。
<!--
Specific extension points can be excluded from `MultiPoint` expansion using
the `disabled` field for that extension point. This works with disabling default
plugins, non-default plugins, or with the wildcard (`'*'`) to disable all plugins.
An example of this, disabling `Score` and `PreScore`, would be:
-->
可以使用该扩展点的 `disabled` 字段将特定扩展点从 `MultiPoint` 扩展中排除。
这适用于禁用默认插件、非默认插件或使用通配符 (`'*'`) 来禁用所有插件。
禁用 `Score` 和 `PreScore` 的一个例子是：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'MyPlugin'
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
<!--
In `v1beta3`, all [default plugins](#scheduling-plugins) are enabled internally through `MultiPoint`.
However, individual extension points are still available to allow flexible
reconfiguration of the default values (such as ordering and Score weights). For
example, consider two Score plugins `DefaultScore1` and `DefaultScore2`, each with
a weight of `1`. They can be reordered with different weights like so:
-->
在 `v1beta3` 中，所有 [默认插件](#scheduling-plugins) 都通过 `MultiPoint` 在内部启用。
但是，仍然可以使用单独的扩展点来灵活地重新配置默认值（例如排序和分数权重）。
例如，考虑两个Score插件 `DefaultScore1` 和 `DefaultScore2` ，每个插件的权重为 `1` 。
它们可以用不同的权重重新排序，如下所示：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
score:
enabled:
- name: 'DefaultScore2'
weight: 5
```
<!--
In this example, it's unnecessary to specify the plugins in `MultiPoint` explicitly
because they are default plugins. And the only plugin specified in `Score` is `DefaultScore2`.
This is because plugins set through specific extension points will always take precedence
over `MultiPoint` plugins. So, this snippet essentially re-orders the two plugins
without needing to specify both of them.
-->
在这个例子中，没有必要在 `MultiPoint` 中明确指定插件，因为它们是默认插件。
`Score` 中指定的唯一插件是 `DefaultScore2`。
这是因为通过特定扩展点设置的插件将始终优先于 `MultiPoint` 插件。
因此，此代码段实质上重新排序了这两个插件，而无需同时指定它们。
<!--
The general hierarchy for precedence when configuring `MultiPoint` plugins is as follows:
-->
配置 `MultiPoint` 插件时优先级的一般层次结构如下：
<!--
1. Specific extension points run first, and their settings override whatever is set elsewhere
-->
1. 特定的扩展点首先运行，它们的设置会覆盖其他地方的设置
<!--2. Plugins manually configured through `MultiPoint` and their settings
-->
2. 通过 `MultiPoint` 手动配置的插件及其设置
<!--3. Default plugins and their default settings
-->
3. 默认插件及其默认设置
<!--
To demonstrate the above hierarchy, the following example is based on these plugins:
-->
为了演示上述层次结构，以下示例基于这些插件：
|插件|扩展点|
|---|---|
|`DefaultQueueSort`|`QueueSort`|
|`CustomQueueSort`|`QueueSort`|
|`DefaultPlugin1`|`Score`, `Filter`|
|`DefaultPlugin2`|`Score`|
|`CustomPlugin1`|`Score`, `Filter`|
|`CustomPlugin2`|`Score`, `Filter`|
<!--
A valid sample configuration for these plugins would be:
-->
这些插件的一个有效示例配置是：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'CustomQueueSort'
- name: 'CustomPlugin1'
weight: 3
- name: 'CustomPlugin2'
disabled:
- name: 'DefaultQueueSort'
filter:
disabled:
- name: 'DefaultPlugin1'
score:
enabled:
- name: 'DefaultPlugin2'
```
<!--
Note that there is no error for re-declaring a `MultiPoint` plugin in a specific
extension point. The re-declaration is ignored (and logged), as specific extension points
take precedence.
-->
请注意，在特定扩展点中重新声明 `MultiPoint` 插件不会出错。
重新声明被忽略（并记录），因为特定的扩展点优先。
<!--
Besides keeping most of the config in one spot, this sample does a few things:
-->
除了将大部分配置保存在一个位置之外，此示例还做了一些事情：
<!--
* Enables the custom `queueSort` plugin and disables the default one
* Enables `CustomPlugin1` and `CustomPlugin2`, which will run first for all of their extension points
* Disables `DefaultPlugin1`, but only for `filter`
* Reorders `DefaultPlugin2` to run first in `score` (even before the custom plugins)
-->
* 启用自定义 `queueSort` 插件并禁用默认插件
* 启用 `CustomPlugin1` 和 `CustomPlugin2`，这将首先为它们的所有扩展点运行
* 禁用 `DefaultPlugin1`，但仅适用于 `filter`
* 重新排序 `DefaultPlugin2` 以在 `score` 中首先运行（甚至在自定义插件之前）
<!--
In versions of the config before `v1beta3`, without `multiPoint`, the above snippet would equate to this:
-->
在 `v1beta3` 之前的配置版本中，没有 `multiPoint`，上面的代码片段等同于：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
# Disable the default QueueSort plugin
queueSort:
enabled:
- name: 'CustomQueueSort'
disabled:
- name: 'DefaultQueueSort'
# Enable custom Filter plugins
filter:
enabled:
- name: 'CustomPlugin1'
- name: 'CustomPlugin2'
- name: 'DefaultPlugin2'
disabled:
- name: 'DefaultPlugin1'
# Enable and reorder custom score plugins
score:
enabled:
- name: 'DefaultPlugin2'
weight: 1
- name: 'DefaultPlugin1'
weight: 3
```
<!--
While this is a complicated example, it demonstrates the flexibility of `MultiPoint` config
as well as its seamless integration with the existing methods for configuring extension points.
-->
虽然这是一个复杂的例子，但它展示了 `MultiPoint` 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。
<!--
## Scheduler configuration migrations
-->
## 调度程序配置迁移
{{< tabs name="tab_with_md" >}}
{{% tab name="v1beta1 → v1beta2" %}}
<!--
* With the v1beta2 configuration version, you can use a new score extension for the
`NodeResourcesFit` plugin.
The new extension combines the functionalities of the `NodeResourcesLeastAllocated`,
`NodeResourcesMostAllocated` and `RequestedToCapacityRatio` plugins.
For example, if you previously used the `NodeResourcesMostAllocated` plugin, you
would instead use `NodeResourcesFit` (enabled by default) and add a `pluginConfig`
with a `scoreStrategy` that is similar to:
-->
* 在 v1beta2 配置版本中，你可以为 `NodeResourcesFit` 插件使用新的 score 扩展。
新的扩展结合了 `NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated` 和 `RequestedToCapacityRatio` 插件的功能。
例如，如果你之前使用了 `NodeResourcesMostAllocated` 插件，
则可以改用 `NodeResourcesFit`（默认启用）并添加一个 `pluginConfig` 和 `scoreStrategy`，类似于：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- args:
scoringStrategy:
resources:
- name: cpu
weight: 1
type: MostAllocated
name: NodeResourcesFit
```
<!--
* The scheduler plugin `NodeLabel` is deprecated; instead, use the [`NodeAffinity`](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) plugin (enabled by default) to achieve similar behavior.
-->
* 调度器插件 `NodeLabel` 已弃用；
相反，要使用 [`NodeAffinity`](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
插件（默认启用）来实现类似的行为。
<!--
* The scheduler plugin `ServiceAffinity` is deprecated; instead, use the [`InterPodAffinity`](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) plugin (enabled by default) to achieve similar behavior.
-->
* 调度程序插件 `ServiceAffinity` 已弃用；
相反，使用 [`InterPodAffinity`](/zh/doc/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
插件（默认启用）来实现类似的行为。
<!--
* The scheduler plugin `NodePreferAvoidPods` is deprecated; instead, use [node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to achieve similar behavior.
-->
* 调度器插件 `NodePreferAvoidPods` 已弃用；
相反，使用 [节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) 来实现类似的行为。
<!--
* A plugin enabled in a v1beta2 configuration file takes precedence over the default configuration for that plugin.
-->
* 在 v1beta2 配置文件中启用的插件优先于该插件的默认配置。
<!--
* Invalid `host` or `port` configured for scheduler healthz and metrics bind address will cause validation failure.
-->
* 调度器的健康检查和审计的绑定地址，所配置的 `host` 或 `port` 无效将导致验证失败。
{{% /tab %}}
{{% tab name="v1beta2 → v1beta3" %}}
<!--
* Three plugins' weight are increased by default:
* `InterPodAffinity` from 1 to 2
* `NodeAffinity` from 1 to 2
* `TaintToleration` from 1 to 3
-->
* 默认增加三个插件的权重：
* `InterPodAffinity` 从 1 到 2
* `NodeAffinity` 从 1 到 2
* `TaintToleration` 从 1 到 3
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
<!--
* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
* Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/)
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference
* Read the [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference
* Read the [kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
-->
* 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
* 阅读 [kube-scheduler 配置 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) 参考
* 阅读 [kube-scheduler 配置 (v1beta2)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) 参考
* 阅读 [kube-scheduler 配置 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) 参考
content/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+9 -2
View File
@@ -47,9 +47,16 @@ kubeadm 目前不支持对 CoreDNS 部署进行定制。
有关更多详细信息，请参阅[在 kubeadm 中使用 init phases](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases).
{{< /note >}}
<!-- body -->
{{< note >}}
<!--
To reconfigure a cluster that has already been created see
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
-->
{{< feature-state for_k8s_version="1.12" state="stable" >}}
要重新配置已创建的集群，请参阅[重新配置 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)。
{{< /note >}}
<!-- body -->
<!--
## Customizing the control plane with flags in `ClusterConfiguration`
content/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
+14 -9
View File
@@ -81,10 +81,12 @@ kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=
```
<!--
To make things clearer, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the primary dual-stack control plane node.
To make things clearer, here is an example kubeadm
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
`kubeadm-config.yaml` for the primary dual-stack control plane node.
-->
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)，
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)，
该文件用于双协议栈控制面的主控制节点。
```yaml
@@ -138,14 +140,15 @@ The `--apiserver-advertise-address` flag does not support dual-stack.
Before joining a node, make sure that the node has IPv6 routable network interface and allows IPv6 forwarding.
Here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining a worker node to the cluster.
Here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
`kubeadm-config.yaml` for joining a worker node to the cluster.
-->
### 向双协议栈集群添加节点 {#join-a-node-to-dual-stack-cluster}
在添加节点之前，请确保该节点具有 IPv6 可路由的网络接口并且启用了 IPv6 转发。
下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
示例用于向集群中添加工作节点。
```yaml
@@ -164,10 +167,11 @@ nodeRegistration:
```
<!--
Also, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining another control plane node to the cluster.
Also, here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
`kubeadm-config.yaml` for joining another control plane node to the cluster.
-->
下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
示例用于向集群中添加另一个控制面节点。
```yaml
@@ -215,13 +219,14 @@ You can deploy a single-stack cluster that has the dual-stack networking feature
{{< /note >}}
<!--
To make things more clear, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the single-stack control plane node.
To make things more clear, here is an example kubeadm
[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
`kubeadm-config.yaml` for the single-stack control plane node.
-->
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)示例，
[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)示例，
该文件用于单协议栈控制面节点。
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+24 -16
View File
@@ -27,6 +27,8 @@ For information on how to create a cluster with kubeadm once you have performed
有关在执行此安装过程后如何使用 kubeadm 创建集群的信息，请参见
[使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 页面。
{{% dockershim-removal %}}
## {{% heading "prerequisites" %}}
<!--
@@ -117,15 +119,15 @@ For more details please see the [Network Plugin Requirements](/docs/concepts/ext
## Check required ports
These
[required ports](/docs/reference/ports-and-protocols/)
need to be open in order for Kubernetes components to communicate with each other. You can use telnet to check if a port is open. For example:
need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
-->
## 检查所需端口{#check-required-ports}
启用这些[必要的端口](/zh/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。可以使用 telnet 来检查端口是否启用，例如：
启用这些[必要的端口](/zh/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。可以使用 netcat 之类的工具来检查端口是否启用，例如：
```shell
telnet 127.0.0.1 6443
nc 127.0.0.1 6443
```
<!--
@@ -156,7 +158,7 @@ to interface with your chosen container runtime.
If you don't specify a runtime, kubeadm automatically tries to detect an installed
container runtime by scanning through a list of well known Unix domain sockets.
The following table lists container runtimes and their associated socket paths:
The following table lists container runtimes that kubeadm looks for, and their associated socket paths:
| Runtime | Domain Socket |
|------------|---------------------------------|
@@ -170,33 +172,33 @@ The following table lists container runtimes and their associated socket paths:
如果你不指定运行时，则 kubeadm 会自动尝试检测到系统上已经安装的运行时，
方法是扫描一组众所周知的 Unix 域套接字。
下面的表格列举了一些容器运行时及其对应的套接字路径：
下面的表格列举了一些 kubeadm 查找的容器运行时及其对应的套接字路径：
| 运行时 | 域套接字 |
|------------|----------------------------------|
| Docker | /var/run/dockershim.sock |
| containerd | /run/containerd/containerd.sock |
| CRI-O | /var/run/crio/crio.sock |
| Docker Engine | `/var/run/dockershim.sock` |
| containerd | `/run/containerd/containerd.sock` |
| CRI-O | `/var/run/crio/crio.sock` |
<!--
<br />
If both Docker and containerd are detected, Docker takes precedence. This is
If both Docker Engine and containerd are detected, kubeadm will give precedence to Docker Engine. This is
needed because Docker 18.09 ships with containerd and both are detectable even if you only
installed Docker.
If any other two or more runtimes are detected, kubeadm exits with an error.
**If any other two or more runtimes are detected, kubeadm exits with an error.**
The kubelet integrates with Docker through the built-in `dockershim` CRI implementation.
The kubelet can integrate with Docker Engine using the deprecated `dockershim` adapter (the dockershim is part of the kubelet itself).
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
for more information.
-->
<br/>
如果同时检测到 Docker 和 containerd，则优先选择 Docker。
如果同时检测到 Docker Engine 和 containerd，kubeadm 将优先考虑 Docker Engine。
这是必然的，因为 Docker 18.09 附带了 containerd 并且两者都是可以检测到的，
即使你仅安装了 Docker。
如果检测到其他两个或多个运行时，kubeadm 输出错误信息并退出。
**如果检测到其他两个或多个运行时，kubeadm 输出错误信息并退出。**
kubelet 通过内置的 `dockershim` CRI 实现与 Docker 集成。
kubelet 可以使用已弃用的 dockershim 适配器与 Docker Engine 集成（dockershim 是 kubelet 本身的一部分）。
参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
以了解更多信息。
@@ -205,13 +207,13 @@ kubelet 通过内置的 `dockershim` CRI 实现与 Docker 集成。
{{% tab name="其它操作系统" %}}
<!--
By default, kubeadm uses {{< glossary_tooltip term_id="docker" >}} as the container runtime.
The kubelet integrates with Docker through the built-in `dockershim` CRI implementation.
The kubelet can integrate with Docker Engine using the deprecated `dockershim` adapter (the dockershim is part of the kubelet itself).
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
for more information.
-->
默认情况下， kubeadm 使用 {{< glossary_tooltip term_id="docker" >}} 作为容器运行时。
kubelet 通过内置的 `dockershim` CRI 实现与 Docker 集成。
kubelet 可以使用已弃用的 dockershim 适配器与 Docker Engine 集成（dockershim 是 kubelet 本身的一部分）。
参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
以了解更多信息。
@@ -355,6 +357,9 @@ sudo systemctl enable --now kubelet
You have to do this until SELinux support is improved in the kubelet.
- You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
- If the `baseurl` fails because your Red Hat-based distribution cannot interpret `basearch`, replace `\$basearch` with your computer's architecture.
Type `uname -m` to see that value.
For example, the `baseurl` URL for `x86_64` could be: `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`.
-->
**请注意：**
@@ -365,6 +370,9 @@ sudo systemctl enable --now kubelet
你必须这么做，直到 kubelet 做出对 SELinux 的支持进行升级为止。
- 如果你知道如何配置 SELinux 则可以将其保持启用状态，但可能需要设定 kubeadm 不支持的部分配置
- 如果由于该 Red Hat 的发行版无法解析 `basearch` 导致获取 `baseurl` 失败，请将 `\$basearch` 替换为你计算机的架构。
输入 `uname -m` 以查看该值。
例如，`x86_64` 的 `baseurl` URL 可以是：`https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`。
{{% /tab %}}
{{% tab name="无包管理器的情况" %}}
content/zh/docs/tasks/administer-cluster/access-cluster-api.md
+22 -30
View File
@@ -18,7 +18,6 @@ This page shows how to access clusters using the Kubernetes API.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@@ -56,11 +55,11 @@ kubectl config view
<!--
Many of the [examples](https://github.com/kubernetes/examples/tree/master/) provide an introduction to using
kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/).
-->
许多[样例](https://github.com/kubernetes/examples/tree/master/)
提供了使用 kubectl 的介绍。完整文档请见 [kubectl 手册](/zh/docs/reference/kubectl/overview/)。
提供了使用 kubectl 的介绍。完整文档请见 [kubectl 手册](/zh/docs/reference/kubectl/)。
<!--
### Directly accessing the REST API
@@ -76,7 +75,7 @@ kubectl 处理对 API 服务器的定位和身份验证。如果你想通过 htt
1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
1. Alternatively, you can provide the location and credentials directly to the http client. This works with client code that is confused by proxies. To protect against man in the middle attacks, you'll need to import a root cert into your browser.
-->
1. 以代理模式运行 kubectl（推荐）。
1. 以代理模式运行 kubectl（推荐）。
推荐使用此方法，因为它用存储的 apiserver 位置并使用自签名证书验证 API 服务器的标识。
使用这种方法无法进行中间人（MITM）攻击。
2. 另外，你可以直接为 HTTP 客户端提供位置和身份认证。
@@ -160,8 +159,25 @@ export CLUSTER_NAME="some_server_name"
# 指向引用该集群名称的 API 服务器
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
# 获得令牌
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 -d)
# 创建一个 secret 来保存默认服务账户的令牌
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: default-token
annotations:
kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF
# 等待令牌控制器使用令牌填充 secret:
while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
echo "waiting for token..." >&2
sleep 1
done
# 获取令牌
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
# 使用令牌玩转 API
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
@@ -185,30 +201,6 @@ curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
}
```
<!-- Using `jsonpath` approach: -->
使用 `jsonpath` 方式：
```shell
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```
```json
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "10.0.1.149:443"
}
]
}
```
<!--
The above example uses the `--insecure` flag. This leaves it subject to MITM
attacks. When kubectl accesses the cluster it uses a stored root certificate
content/zh/docs/tasks/administer-cluster/declare-network-policy.md
+3 -3
View File
@@ -108,7 +108,7 @@ You should be able to access the new `nginx` service from other Pods. To access
要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
```shell
kubectl run busybox --rm -ti --image=busybox /bin/sh
kubectl run busybox --rm -ti --image=busybox:1.28 /bin/sh
```
<!--
@@ -180,7 +180,7 @@ When you attempt to access the `nginx` Service from a Pod without the correct la
如果你尝试从没有设定正确标签的 Pod 中去访问 `nginx` 服务，请求将会超时：
```shell
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
```
<!--
@@ -207,7 +207,7 @@ You can create a Pod with the correct labels to see that the request is allowed:
创建一个拥有正确标签的 Pod，你将看到请求是被允许的：
```shell
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh
```
<!--
In your shell, run the command:
content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+3 -2
View File
@@ -25,9 +25,10 @@ You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can m
混合使用运行于 Linux 上的 Pod 和运行于 Windows 上的 Pod。
本页面展示如何将 Windows 节点注册到你的集群。
## {{% heading "prerequisites" %}}
{{% dockershim-removal %}}
{{< version-check >}}
## {{% heading "prerequisites" %}}
{{< version-check >}}
<!--
* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
+509
View File
@@ -0,0 +1,509 @@
---
title: 重新配置 kubeadm 集群
content_type: task
weight: 10
---
<!--
reviewers:
- sig-cluster-lifecycle
title: Reconfiguring a kubeadm cluster
content_type: task
weight: 10
-->
<!-- overview -->
<!--
kubeadm does not support automated ways of reconfiguring components that
were deployed on managed nodes. One way of automating this would be
by using a custom [operator](/docs/concepts/extend-kubernetes/operator/).
-->
kubeadm 不支持自动重新配置部署在托管节点上的组件的方式。
一种自动化的方法是使用自定义的
[operator](/zh/docs/concepts/extend-kubernetes/operator/)。
<!--
To modify the components configuration you must manually edit associated cluster
objects and files on disk.
This guide shows the correct sequence of steps that need to be performed
to achieve kubeadm cluster reconfiguration.
-->
要修改组件配置，你必须手动编辑磁盘上关联的集群对象和文件。
本指南展示了实现 kubeadm 集群重新配置所需执行的正确步骤顺序。
## {{% heading "prerequisites" %}}
<!--
- You need a cluster that was deployed using kubeadm
- Have administrator credentials (`/etc/kubernetes/admin.conf`) and network connectivity
to a running kube-apiserver in the cluster from a host that has kubectl installed
- Have a text editor installed on all hosts
-->
- 你需要一个使用 kubeadm 部署的集群
- 拥有管理员凭据（`/etc/kubernetes/admin.conf`）
和从安装了 kubectl 的主机到集群中正在运行的 kube-apiserver 的网络连接
- 在所有主机上安装文本编辑器
<!-- steps -->
<!--
## Reconfiguring the cluster
kubeadm writes a set of cluster wide component configuration options in
ConfigMaps and other objects. These objects must be manually edited. The command `kubectl edit`
can be used for that.
-->
## 重新配置集群
kubeadm 在 ConfigMap 和其他对象中写入了一组集群范围的组件配置选项。
这些对象必须手动编辑，可以使用命令 `kubectl edit`。
<!--
The `kubectl edit` command will open a text editor where you can edit and save the object directly.
You can use the environment variables `KUBECONFIG` and `KUBE_EDITOR` to specify the location of
the kubectl consumed kubeconfig file and preferred text editor.
For example:
-->
`kubectl edit` 命令将打开一个文本编辑器，你可以在其中直接编辑和保存对象。
你可以使用环境变量 `KUBECONFIG` 和 `KUBE_EDITOR` 来指定 kubectl
使用的 kubeconfig 文件和首选文本编辑器的位置。
例如：
```
KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <parameters>
```
{{< note >}}
<!--
Upon saving any changes to these cluster objects, components running on nodes may not be
automatically updated. The steps below instruct you on how to perform that manually.
-->
保存对这些集群对象的任何更改后，节点上运行的组件可能不会自动更新。
以下步骤将指导你如何手动执行该操作。
{{< /note >}}
{{< warning >}}
<!--
Component configuration in ConfigMaps is stored as unstructured data (YAML string).
This means that validation will not be performed upon updating the contents of a ConfigMap.
You have to be careful to follow the documented API format for a particular
component configuration and avoid introducing typos and YAML indentation mistakes.
-->
ConfigMaps 中的组件配置存储为非结构化数据（YAML 字符串）。 这意味着在更新
ConfigMap 的内容时不会执行验证。 你必须小心遵循特定组件配置的文档化 API 格式，
并避免引入拼写错误和 YAML 缩进错误。
{{< /warning >}}
<!--
### Applying cluster configuration changes
#### Updating the `ClusterConfiguration`
During cluster creation and upgrade, kubeadm writes its
[`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta3/)
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace.
To change a particular option in the `ClusterConfiguration` you can edit the ConfigMap with this command:
The configuration is located under the `data.ClusterConfiguration` key.
-->
### 应用集群配置更改
#### 更新 `ClusterConfiguration`
在集群创建和升级期间，kubeadm 将其
[`ClusterConfiguration`](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
写入 `kube-system` 命名空间中名为 `kubeadm-config` 的 ConfigMap。
要更改 `ClusterConfiguration` 中的特定选项，你可以使用以下命令编辑 ConfigMap：
```shell
kubectl edit cm -n kube-system kubeadm-config
```
配置位于 `data.ClusterConfiguration` 键下。
{{< note >}}
<!--
The `ClusterConfiguration` includes a variety of options that affect the configuration of individual
components such as kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS, etcd and kube-proxy.
Changes to the configuration must be reflected on node components manually.
-->
`ClusterConfiguration` 包括各种影响单个组件配置的选项， 例如
kube-apiserver、kube-scheduler、kube-controller-manager、
CoreDNS、etcd 和 kube-proxy。 对配置的更改必须手动反映在节点组件上。
{{< /note >}}
<!--
#### Reflecting `ClusterConfiguration` changes on control plane nodes
kubeadm manages the control plane components as static Pod manifests located in
the directory `/etc/kubernetes/manifests`.
Any changes to the `ClusterConfiguration` under the `apiServer`, `controllerManager`, `scheduler` or `etcd`
keys must be reflected in the associated files in the manifests directory on a control plane node.
-->
#### 在控制平面节点上反映 `ClusterConfiguration` 更改
kubeadm 将控制平面组件作为位于 `/etc/kubernetes/manifests`
目录中的静态 Pod 清单进行管理。
对 `apiServer`、`controllerManager`、`scheduler` 或 `etcd`键下的
`ClusterConfiguration` 的任何更改都必须反映在控制平面节点上清单目录中的关联文件中。
<!--
Such changes may include:
- `extraArgs` - requires updating the list of flags passed to a component container
- `extraMounts` - requires updated the volume mounts for a component container
- `*SANs` - requires writing new certificates with updated Subject Alternative Names.
Before proceeding with these changes, make sure you have backed up the directory `/etc/kubernetes/`.
-->
此类更改可能包括:
- `extraArgs` - 需要更新传递给组件容器的标志列表
- `extraMounts` - 需要更新组件容器的卷挂载
- `*SANs` - 需要使用更新的主题备用名称编写新证书
在继续进行这些更改之前，请确保你已备份目录 `/etc/kubernetes/`。
<!--
To write new certificates you can use:
To write new manifest files in `/etc/kubernetes/manifests` you can use:
-->
要编写新证书，你可以使用：
```shell
kubeadm init phase certs <component-name> --config <config-file>
```
要在 `/etc/kubernetes/manifests` 中编写新的清单文件，你可以使用：
```shell
kubeadm init phase control-plane <component-name> --config <config-file>
```
<!--
The `<config-file>` contents must match the updated `ClusterConfiguration`.
The `<component-name>` value must be the name of the component.
-->
`<config-file>` 内容必须与更新后的 `ClusterConfiguration` 匹配。
`<component-name>` 值必须是组件的名称。
{{< note >}}
<!--
Updating a file in `/etc/kubernetes/manifests` will tell the kubelet to restart the static Pod for the corresponding component.
Try doing these changes one node at a time to leave the cluster without downtime.
-->
更新 `/etc/kubernetes/manifests` 中的文件将告诉 kubelet 重新启动相应组件的静态 Pod。
尝试一次对一个节点进行这些更改，以在不停机的情况下离开集群。
{{< /note >}}
<!--
### Applying kubelet configuration changes
#### Updating the `KubeletConfiguration`
During cluster creation and upgrade, kubeadm writes its
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
in a ConfigMap called `kubelet-config` in the `kube-system` namespace.
You can edit the ConfigMap with this command:
The configuration is located under the `data.kubelet` key.
-->
### 应用 kubelet 配置更改
#### 更新 `KubeletConfiguration`
在集群创建和升级期间，kubeadm 将其
[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
写入 `kube-system` 命名空间中名为 `kubelet-config` 的 ConfigMap。
你可以使用以下命令编辑 ConfigMap：
```shell
kubectl edit cm -n kube-system kubelet-config
```
配置位于 `data.kubelet` 键下。
<!--
#### Reflecting the kubelet changes
To reflect the change on kubeadm nodes you must do the following:
- Log in to a kubeadm node
- Run `kubeadm upgrade node phase kubelet-config` to download the latest `kubelet-config`
ConfigMap contents into the local file `/var/lib/kubelet/config.conf`
- Edit the file `/var/lib/kubelet/kubeadm-flags.env` to apply additional configuration with
flags
- Restart the kubelet service with `systemctl restart kubelet`
-->
#### 反映 kubelet 的更改
要反映 kubeadm 节点上的更改，你必须执行以下操作：
- 登录到 kubeadm 节点
- 运行 `kubeadm upgrade node phase kubelet-config` 下载最新的
`kubelet-config` ConfigMap 内容到本地文件 `/var/lib/kubelet/config.conf`
- 编辑文件 `/var/lib/kubelet/kubeadm-flags.env` 以使用标志来应用额外的配置
- 使用 `systemctl restart kubelet` 重启 kubelet 服务
{{< note >}}
<!--
Do these changes one node at a time to allow workloads to be rescheduled properly.
-->
一次执行一个节点的这些更改，以允许正确地重新安排工作负载。
{{< /note >}}
{{< note >}}
<!--
During `kubeadm upgrade`, kubeadm downloads the `KubeletConfiguration` from the
`kubelet-config` ConfigMap and overwrite the contents of `/var/lib/kubelet/config.conf`.
This means that node local configuration must be applied either by flags in
`/var/lib/kubelet/kubeadm-flags.env` or by manually updating the contents of
`/var/lib/kubelet/config.conf` after `kubeadm upgrade`, and then restarting the kubelet.
-->
在 `kubeadm upgrade` 期间，kubeadm 从 `kubelet-config` ConfigMap
下载 `KubeletConfiguration` 并覆盖 `/var/lib/kubelet/config.conf` 的内容。
这意味着节点本地配置必须通过`/var/lib/kubelet/kubeadm-flags.env`中的标志或在
kubeadm upgrade` 后手动更新`/var/lib/kubelet/config.conf`的内容来应用，然后重新启动 kubelet。
{{< /note >}}
<!--
### Applying kube-proxy configuration changes
#### Updating the `KubeProxyConfiguration`
During cluster creation and upgrade, kubeadm writes its
[`KubeProxyConfiguration`](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
in a ConfigMap in the `kube-system` namespace called `kube-proxy`.
This ConfigMap is used by the `kube-proxy` DaemonSet in the `kube-system` namespace.
To change a particular option in the `KubeProxyConfiguration`, you can edit the ConfigMap with this command:
The configuration is located under the `data.config.conf` key.
-->
### 应用 kube-proxy 配置更改
#### 更新 `KubeProxyConfiguration`
在集群创建和升级期间，kubeadm 将其写入
[`KubeProxyConfiguration`](/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/)
在名为 `kube-proxy` 的 `kube-system` 命名空间中的 ConfigMap 中。
此 ConfigMap 由 `kube-system` 命名空间中的 `kube-proxy` DaemonSet 使用。
要更改 `KubeProxyConfiguration` 中的特定选项，你可以使用以下命令编辑 ConfigMap：
```shell
kubectl edit cm -n kube-system kube-proxy
```
配置位于 `data.config.conf` 键下。
<!--
#### Reflecting the kube-proxy changes
Once the `kube-proxy` ConfigMap is updated, you can restart all kube-proxy Pods:
Obtain the Pod names:
Delete a Pod with:
New Pods that use the updated ConfigMap will be created.
-->
#### 反映 kube-proxy 的更改
更新 `kube-proxy` ConfigMap 后，你可以重新启动所有 kube-proxy Pod：
获取 Pod 名称：
```shell
kubectl get po -n kube-system | grep kube-proxy
```
使用以下命令删除 Pod：
```shell
kubectl delete po -n kube-system <pod-name>
```
将创建使用更新的 ConfigMap 的新 Pod。
{{< note >}}
<!--
Because kubeadm deploys kube-proxy as a DaemonSet, node specific configuration is unsupported.
-->
由于 kubeadm 将 kube-proxy 部署为 DaemonSet，因此不支持特定于节点的配置。
{{< /note >}}
<!--
### Applying CoreDNS configuration changes
#### Updating the CoreDNS Deployment and Service
kubeadm deploys CoreDNS as a Deployment called `coredns` and with a Service `kube-dns`,
both in the `kube-system` namespace.
To update any of the CoreDNS settings, you can edit the Deployment and
Service objects:
-->
### 应用 CoreDNS 配置更改
#### 更新 CoreDNS 的 Deployment 和 Service
kubeadm 将 CoreDNS 部署为名为 `coredns` 的 Deployment，并使用 Service `kube-dns`，
两者都在 `kube-system` 命名空间中。
要更新任何 CoreDNS 设置，你可以编辑 Deployment 和 Service：
```shell
kubectl edit deployment -n kube-system coredns
kubectl edit service -n kube-system kube-dns
```
<!--
#### Reflecting the CoreDNS changes
Once the CoreDNS changes are applied you can delete the CoreDNS Pods:
Obtain the Pod names:
Delete a Pod with:
-->
#### 反映 CoreDNS 的更改
应用 CoreDNS 更改后，你可以删除 CoreDNS Pod。
获取 Pod 名称：
```shell
kubectl get po -n kube-system | grep coredns
```
使用以下命令删除 Pod：
```shell
kubectl delete po -n kube-system <pod-name>
```
<!--
New Pods with the updated CoreDNS configuration will be created.
-->
将创建具有更新的 CoreDNS 配置的新 Pod。
{{< note >}}
<!--
kubeadm does not allow CoreDNS configuration during cluster creation and upgrade.
This means that if you execute `kubeadm upgrade apply`, your changes to the CoreDNS
-->
kubeadm 不允许在集群创建和升级期间配置 CoreDNS。
这意味着如果执行了 `kubeadm upgrade apply`，你对
CoreDNS 对象的更改将丢失并且必须重新应用。
{{< /note >}}
<!--
## Persisting the reconfiguration
During the execution of `kubeadm upgrade` on a managed node, kubeadm might overwrite configuration
that was applied after the cluster was created (reconfiguration).
-->
## 持久化重新配置
在受管节点上执行 `kubeadm upgrade` 期间，kubeadm
可能会覆盖在创建集群（重新配置）后应用的配置。
<!--
### Persisting Node object reconfiguration
kubeadm writes Labels, Taints, CRI socket and other information on the Node object for a particular
Kubernetes node. To change any of the contents of this Node object you can use:
-->
### 持久化 Node 对象重新配置
kubeadm 在特定 Kubernetes 节点的 Node 对象上写入标签、污点、CRI
套接字和其他信息。要更改此 Node 对象的任何内容，你可以使用：
```shell
kubectl edit no <node-name>
```
<!--
During `kubeadm upgrade` the contents of such a Node might get overwritten.
If you would like to persist your modifications to the Node object after upgrade,
you can prepare a [kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
and apply it to the Node object:
-->
在 `kubeadm upgrade` 期间，此类节点的内容可能会被覆盖。
如果你想在升级后保留对 Node 对象的修改，你可以准备一个
[kubectl patch](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
并将其应用到 Node 对象：
```shell
kubectl patch no <node-name> --patch-file <patch-file>
```
<!--
#### Persisting control plane component reconfiguration
The main source of control plane configuration is the `ClusterConfiguration`
object stored in the cluster. To extend the static Pod manifests configuration,
[patches](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches) can be used.
These patch files must remain as files on the control plane nodes to ensure that
they can be used by the `kubeadm upgrade ... --patches <directory>`.
If reconfiguration is done to the `ClusterConfiguration` and static Pod manifests on disk,
the set of node specific patches must be updated accordingly.
-->
#### 持久化控制平面组件重新配置
控制平面配置的主要来源是存储在集群中的 `ClusterConfiguration` 对象。
要扩展静态 Pod 清单配置，可以使用
[patches](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches)。
这些补丁文件必须作为文件保留在控制平面节点上，以确保它们可以被
`kubeadm upgrade ... --patches <directory>` 使用。
如果对 `ClusterConfiguration` 和磁盘上的静态 Pod 清单进行了重新配置，则必须相应地更新节点特定补丁集。
<!--
#### Persisting kubelet reconfiguration
Any changes to the `KubeletConfiguration` stored in `/var/lib/kubelet/config.conf` will be overwritten on
`kubeadm upgrade` by downloading the contents of the cluster wide `kubelet-config` ConfigMap.
To persist kubelet node specific configuration either the file `/var/lib/kubelet/config.conf`
has to be updated manually post-upgrade or the file `/var/lib/kubelet/kubeadm-flags.env` can include flags.
The kubelet flags override the associated `KubeletConfiguration` options, but note that
some of the flags are deprecated.
A kubelet restart will be required after changing `/var/lib/kubelet/config.conf` or
`/var/lib/kubelet/kubeadm-flags.env`.
-->
#### 持久化 kubelet 重新配置
对存储在 `/var/lib/kubelet/config.conf` 中的 `KubeletConfiguration`
所做的任何更改都将在 `kubeadm upgrade` 时因为下载集群范围内的 `kubelet-config`
ConfigMap 的内容而被覆盖。
要持久保存 kubelet 节点特定的配置，文件`/var/lib/kubelet/config.conf`
必须在升级后手动更新，或者文件`/var/lib/kubelet/kubeadm-flags.env` 可以包含标志。
kubelet 标志会覆盖相关的 `KubeletConfiguration` 选项，但请注意，有些标志已被弃用。
更改 `/var/lib/kubelet/config.conf` 或 `/var/lib/kubelet/kubeadm-flags.env`
后需要重启 kubelet。
{{% heading "whatsnext" %}}
<!--
- [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
- [Customizing components with the kubeadm API](/docs/setup/production-environment/tools/kubeadm/control-plane-flags)
- [Certificate management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)
-->
- [升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
- [使用 kubeadm API 自定义组件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags)
- [使用 kubeadm 管理证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)
content/zh/docs/tasks/administer-cluster/kubelet-in-userns.md
+51 -5
View File
@@ -35,7 +35,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo
这种技术也叫做 _rootless 模式（Rootless mode）_。
{{< note >}}
这个文档描述了怎么以非 root 用户身份运行 Kubernetes 节点组件以及 Pod。
这个文档描述了怎么以非 root 用户身份运行 Kubernetes 节点组件以及 Pod。
如果你只是想了解如何以非 root 身份运行 Pod，请参阅 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/)。
{{< /note >}}
@@ -99,6 +99,51 @@ Rootless Podman is not supported.
<!-- Supporting rootless podman is discussed in https://github.com/kubernetes/minikube/issues/8719 -->
<!--
## Running Kubernetes inside Unprivileged Containers
{{% thirdparty-content %}}
### sysbox
-->
## 在非特权容器内运行 Kubernetes
{{% thirdparty-content %}}
### sysbox
<!--
[Sysbox](https://github.com/nestybox/sysbox) is an open-source container runtime
(similar to "runc") that supports running system-level workloads such as Docker
and Kubernetes inside unprivileged containers isolated with the Linux user
namespace.
-->
[Sysbox](https://github.com/nestybox/sysbox) 是一个开源容器运行时
(类似于 “runc”），支持在 Linux 用户命名空间隔离的非特权容器内运行系统级工作负载，
比如 Docker 和 Kubernetes。
<!--
See [Sysbox Quick Start Guide: Kubernetes-in-Docker](https://github.com/nestybox/sysbox/blob/master/docs/quickstart/kind.md) for more info.
-->
查看 [Sysbox 快速入门指南: Kubernetes-in-Docker](https://github.com/nestybox/sysbox/blob/master/docs/quickstart/kind.md)
了解更多细节。
<!--
Sysbox supports running Kubernetes inside unprivileged containers without
requiring Cgroup v2 and without the `KubeletInUserNamespace` feature gate. It
does this by exposing specially crafted `/proc` and `/sys` filesystems inside
the container plus several other advanced OS virtualization techniques.
-->
Sysbox 支持在非特权容器内运行 Kubernetes，
而不需要 Cgroup v2 和 “KubeletInUserNamespace” 特性门控。
Sysbox 通过在容器内暴露特定的 `/proc` 和 `/sys` 文件系统，
以及其它一些先进的操作系统虚拟化技术来实现。
<!--
## Running Rootless Kubernetes directly on a host
@@ -131,7 +176,7 @@ See [the Usernetes repo](https://github.com/rootless-containers/usernetes) for t
页面中的用法.
### Usernetes
[Usernetes](https://github.com/rootless-containers/usernetes) 是 Kubernetes 的一个参考发行版，
[Usernetes](https://github.com/rootless-containers/usernetes) 是 Kubernetes 的一个参考发行版，
它可以在不使用 root 特权的情况下安装在 `$HOME` 目录下。
Usernetes 支持使用 containerd 和 CRI-O 作为 CRI 运行时。
@@ -446,7 +491,7 @@ This feature gate also allows kube-proxy to ignore an error during setting `RLIM
The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.
Running kubelet in a user namespace without using this feature gate is also possible
by mounting a specially crafted proc filesystem, but not officially supported.
by mounting a specially crafted proc filesystem (as done by [Sysbox](https://github.com/nestybox/sysbox)), but not officially supported.
-->
### 配置 kubelet
@@ -478,7 +523,8 @@ cgroupDriver: "cgroupfs"
`KubeletInUserNamespace` 特性门控从 Kubernetes v1.22 被引入， 标记为 "alpha" 状态。
通过挂载特制的 proc 文件系统，也可以在不使用这个特性门控的情况下在用户命名空间运行 kubelet，但这不受官方支持。
通过挂载特制的 proc 文件系统 （比如 [Sysbox](https://github.com/nestybox/sysbox)），
也可以在不使用这个特性门控的情况下在用户命名空间运行 kubelet，但这不受官方支持。
<!--
### Configuring kube-proxy
@@ -531,7 +577,7 @@ on the rootlesscontaine.rs website.
## 注意事项 {#caveats}
- 大部分“非本地”的卷驱动（例如 `nfs` 和 `iscsi`）不能正常工作。
已知诸如 `local`、`hostPath`、`emptyDir`、`configMap`、`secret` 和 `downwardAPI`
已知诸如 `local`、`hostPath`、`emptyDir`、`configMap`、`secret` 和 `downwardAPI`
这些本地卷是能正常工作的。
- 一些 CNI 插件可能不正常工作。已知 Flannel (VXLAN) 是能正常工作的。
content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
+42 -30
View File
@@ -1,6 +1,8 @@
---
title: 将节点上的容器运行时从 Docker Engine 改为 containerd
weight: 8
content_type: task
---
<!--
title: "Changing the Container Runtime on a Node from Docker Engine to containerd"
@@ -9,7 +11,10 @@ content_type: task
-->
<!--
This task outlines the steps needed to update your container runtime to containerd from Docker. It is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an example scenario for migrating from dockershim to containerd and alternative container runtimes can be picked from this [page](https://kubernetes.io/docs/setup/production-environment/container-runtimes/).
This task outlines the steps needed to update your container runtime to containerd from Docker. It
is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an
example scenario for migrating from dockershim to containerd and alternative container runtimes
can be picked from this [page](/docs/setup/production-environment/container-runtimes/).
-->
本任务给出将容器运行时从 Docker 改为 containerd 所需的步骤。
此任务适用于运行 1.23 或更早版本 Kubernetes 的集群操作人员。
@@ -22,27 +27,32 @@ This task outlines the steps needed to update your container runtime to containe
{{% thirdparty-content %}}
<!--
Install containerd. For more information see, [containerd's installation documentation](https://containerd.io/docs/getting-started/) and for specific prerequisite follow [this](/docs/setup/production-environment/container-runtimes/#containerd).
Install containerd. For more information see
[containerd's installation documentation](https://containerd.io/docs/getting-started/)
and for specific prerequisite follow
[the containerd guide](/docs/setup/production-environment/container-runtimes/#containerd).
-->
安装 containerd。进一步的信息可参见
[containerd 的安装文档](https://containerd.io/docs/getting-started/)。
关于一些特定的环境准备工作，请参阅[此页面](/zh/docs/setup/production-environment/container-runtimes/#containerd)。
关于一些特定的环境准备工作，请遵循 [containerd 指南](/zh/docs/setup/production-environment/container-runtimes/#containerd)。
<!--
## Drain the node
```
# replace <node-to-drain> with the name of your node you are draining
```shell
kubectl drain <node-to-drain> --ignore-daemonsets
```
Replace `<node-to-drain>` with the name of your node you are draining.
-->
## 腾空节点 {#drain-the-node}
```
# 将 <node-to-drain> 替换为你所要腾空的节点的名称
```shell
kubectl drain <node-to-drain> --ignore-daemonsets
```
将 `<node-to-drain>` 替换为你所要腾空的节点的名称
<!--
## Stop the Docker daemon
-->
@@ -56,27 +66,29 @@ systemctl disable docker.service --now
<!--
## Install Containerd
This [page](/docs/setup/production-environment/container-runtimes/#containerd) contains detailed steps to install containerd.
Follow the [guide](/docs/setup/production-environment/container-runtimes/#containerd)
for detailed steps to install containerd.
-->
## 安装 Containerd {#install-containerd}
此[页面](/zh/docs/setup/production-environment/container-runtimes/#containerd)
包含安装 containerd 的详细步骤。
遵循此[指南](/zh/docs/setup/production-environment/container-runtimes/#containerd)
了解安装 containerd 的详细步骤。
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
<!--
1. Install the `containerd.io` package from the official Docker repositories.
Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
Instructions for setting up the Docker repository for your respective Linux distribution and
installing the `containerd.io` package can be found at
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
-->
1. 从官方的 Docker 仓库安装 `containerd.io` 包。关于为你所使用的 Linux 发行版来设置
Docker 仓库，以及安装 `containerd.io` 包的详细说明，可参见
[Install Docker Engine](https://docs.docker.com/engine/install/#server)。
<!--
2. Configure containerd:
1. Configure containerd:
-->
2. 配置 containerd：
@@ -86,19 +98,19 @@ Instructions for setting up the Docker repository for your respective Linux dist
```
<!--
3. Restart containerd:
1. Restart containerd:
-->
3. 重启 containerd：
```shell
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
<!--
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and then run the following commands:
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and
then run the following commands:
-->
启动一个 Powershell 会话，将 `$Version` 设置为期望的版本（例如：`$Version="1.4.3"`），
之后运行下面的命令：
@@ -148,7 +160,9 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version
<!--
## Configure the kubelet to use containerd as its container runtime
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags. `--container-runtime=remote` and `--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags.
`--container-runtime=remote` and
`--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`.
-->
## 配置 kubelet 使用 containerd 作为其容器运行时
@@ -158,21 +172,19 @@ Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtim
<!--
For users using kubeadm should consider the following:
The `kubeadm` tool stores the CRI socket for each host as an annotation in the Node object for that host.
Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
an annotation in the Node object for that host. To change it you can execute the following command
on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
-->
对于使用 kubeadm 的用户，可以考虑下面的问题：
`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
使用 `kubeadm` 的用户应该知道，`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
要更改这一注解信息，你可以在一台包含 kubeadm `/etc/kubernetes/admin.conf` 文件的机器上执行以下命令：
<!--
To change it you must do the following:
Execute `kubectl edit no <NODE-NAME>` on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
-->
要更改这一注解信息，你必须执行下面的操作：
在一台包含 `/etc/kubernetes/admin.conf` 文件的机器上，执行
`kubectl edit no <节点名称>`。
```shell
kubectl edit no <node-name>
```
<!--
This will start a text editor where you can edit the Node object.
@@ -180,9 +192,9 @@ This will start a text editor where you can edit the Node object.
To choose a text editor you can set the `KUBE_EDITOR` environment variable.
- Change the value of `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock`
to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
Note that new CRI socket paths must be prefixed with `unix://` ideally.
Note that new CRI socket paths must be prefixed with `unix://` ideally.
- Save the changes in the text editor, which will update the Node object.
-->
@@ -220,7 +232,7 @@ Run `kubectl get nodes -o wide` and containerd appears as the runtime for the no
{{% thirdparty-content %}}
<!--
Finally if everything goes well remove docker
Finally if everything goes well, remove Docker.
-->
最后，在一切顺利时删除 Docker。
content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+1 -1
View File
@@ -358,7 +358,7 @@ kubelet 可以配置为使用该协议来执行应用活跃性检查。
下面是一个示例清单：
{{< codenew file="pods/probe/grpc-liveness.yaml">}}
{{< codenew file="pods/probe/grpc-liveness.yaml" >}}
<!--
To use a gRPC probe, `port` must be configured. If the health endpoint is configured
content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
+8 -12
View File
@@ -327,6 +327,7 @@ Use the option `--from-env-file` to create a ConfigMap from an env-file, for exa
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
# The env-file `game-env-file.properties` looks like below
cat configure-pod-container/configmap/game-env-file.properties
@@ -345,6 +346,7 @@ Env 文件包含环境变量列表。其中适用以下语法规则:
```shell
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
```
Env 文件 `game-env-file.properties` 如下所示：
@@ -395,11 +397,10 @@ data:
```
<!--
When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used:
Starting with Kubernetes v1.23, `kubectl` supports the `--from-env-file` argument to be
specified multiple times to create a ConfigMap from multiple data sources.
-->
{{< caution >}}
当多次使用 `--from-env-file` 来从多个数据源创建 ConfigMap 时，仅仅最后一个 env 文件有效。
{{< /caution >}}
从 Kubernetes 1.23 版本开始，`kubectl` 支持多次指定 `--from-env-file` 参数来从多个数据源创建 ConfigMap。
<!--
The behavior of passing `--from-env-file` multiple times is demonstrated by:
@@ -408,20 +409,12 @@ The behavior of passing `--from-env-file` multiple times is demonstrated by:
<!--
```shell
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
# Create the configmap
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
```
-->
```shell
# 将示例文件下载到 `configure-pod-container/configmap/` 目录
wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
# 创建 ConfigMap
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
@@ -452,8 +445,11 @@ metadata:
selfLink: /api/v1/namespaces/default/configmaps/config-multi-env-files
uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
allowed: '"true"'
color: purple
enemies: aliens
how: fairlyNice
lives: "3"
textmode: "true"
```
content/zh/docs/tasks/configure-pod-container/create-hostprocess-pod.md
+1 -1
View File
@@ -35,7 +35,7 @@ Windows HostProcess 容器让你能够在 Windows 主机上运行容器化负载
<!--
Administrative tasks such as installation of security patches, event
log collection, and more can be performed without requiring cluster operators to
log onto each Window node. HostProcess containers can run as any user that is
log onto each Windows node. HostProcess containers can run as any user that is
available on the host or is in the domain of the host machine, allowing administrators
to restrict resource access through user permissions. While neither filesystem or process
isolation are supported, a new volume is created on the host upon starting the container
content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
+89 -11
View File
@@ -14,11 +14,14 @@ weight: 100
<!--
This page shows how to create a Pod that uses a
{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image from a
private container image registry or repository.
{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image
from a private container image registry or repository. There are many private
registries in use. This task uses [Docker Hub](https://www.docker.com/products/docker-hub)
-->
本文介绍如何使用 {{< glossary_tooltip text="Secret" term_id="secret" >}}
从私有的镜像仓库或代码仓库拉取镜像来创建 Pod。
有很多私有镜像仓库正在使用中。这个任务使用的镜像仓库是
[Docker Hub](https://www.docker.com/products/docker-hub)
{{% thirdparty-content single="true" %}}
@@ -29,10 +32,13 @@ private container image registry or repository.
<!--
* To do this exercise, you need the `docker` command line tool, and a
[Docker ID](https://docs.docker.com/docker-id/) for which you know the password.
* If you are using a different private container registry, you need the command
line tool for that registry and any login information for the registry.
-->
要进行此练习，你需要 `docker` 命令行工具和一个知道密码的
* 要进行此练习，你需要 `docker` 命令行工具和一个知道密码的
[Docker ID](https://docs.docker.com/docker-id/)。
* 如果你要使用不同的私有的镜像仓库，你需要有对应镜像仓库的命令行工具和登录信息。
<!-- steps -->
@@ -41,7 +47,7 @@ private container image registry or repository.
On your laptop, you must authenticate with a registry in order to pull a private image:
-->
## 登录 Docker 镜像仓库
## 登录 Docker 镜像仓库 {#log-in-to-docker}
在个人电脑上，要想拉取私有镜像必须在镜像仓库上进行身份验证。
@@ -92,15 +98,77 @@ If you use a Docker credentials store, you won't see that `auth` entry but a `cr
{{< /note >}}
<!--
## Create a Secret in the cluster that holds your authorization token
## Create a Secret based on existing credentials {#registry-secret-existing-credentials}
A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with a container registry to pull a private image.
A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with
a container registry to pull a private image.
If you already ran `docker login`, you can copy
that credential into Kubernetes:
-->
## 创建一个基于现有凭证的 Secret {#registry-secret-existing-credentials}
Kubernetes 集群使用 `kubernetes.io/dockerconfigjson` 类型的
Secret 来通过镜像仓库的身份验证，进而提取私有镜像。
如果你已经运行了 `docker login` 命令，你可以复制该镜像仓库的凭证到 Kubernetes:
```shell
kubectl create secret generic regcred \
--from-file=.dockerconfigjson=<path/to/.docker/config.json> \
--type=kubernetes.io/dockerconfigjson
```
<!--
If you need more control (for example, to set a namespace or a label on the new
secret) then you can customise the Secret before storing it.
Be sure to:
- set the name of the data item to `.dockerconfigjson`
- base64 encode the Docker configuration file and then paste that string, unbroken
as the value for field `data[".dockerconfigjson"]`
- set `type` to `kubernetes.io/dockerconfigjson`
Example:
-->
如果你需要更多的设置（例如，为新 Secret 设置名字空间或标签），
则可以在存储 Secret 之前对它进行自定义。
请务必：
- 将 data 项中的名称设置为 `.dockerconfigjson`
- 使用 base64 编码方法对 Docker 配置文件进行编码，然后粘贴该字符串的内容，作为字段
`data[".dockerconfigjson"]` 的值
- 将 `type` 设置为 `kubernetes.io/dockerconfigjson`
示例：
```yaml
apiVersion: v1
kind: Secret
metadata:
name: myregistrykey
namespace: awesomeapps
data:
.dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson
```
<!--
If you get the error message `error: no objects passed to create`, it may mean the base64 encoded string is invalid.
If you get an error message like `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, it means
the base64 encoded string in the data was successfully decoded, but could not be parsed as a `.docker/config.json` file.
-->
如果你收到错误消息：`error: no objects passed to create`，
这可能意味着 base64 编码的字符串是无效的。 如果你收到类似
`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`
的错误消息，则表示数据中的 base64 编码字符串已成功解码，但无法解析为 `.docker/config.json` 文件。
<!--
## Create a Secret by providing credentials on the command line
Create this Secret, naming it `regcred`:
-->
## 在集群中创建保存授权令牌的 Secret
Kubernetes 集群使用 `docker-registry` 类型的 Secret 来通过容器仓库的身份验证，进而提取私有映像。
## 在命令行上提供凭证来创建 Secret {#create-a-secret-by-providing-credentials-on-the-command-line}
创建 Secret，命名为 `regcred`：
@@ -136,12 +204,22 @@ You have successfully set your Docker credentials in the cluster as a Secret cal
这样你就成功地将集群中的 Docker 凭证设置为名为 `regcred` 的 Secret。
<!--
Typing secrets on the command line may store them in your shell history unprotected, and
those secrets might also be visible to other users on your PC during the time that
`kubectl` is running.
-->
{{< note >}}
在命令行上键入 Secret 可能会将它们存储在你的 shell 历史记录中而不受保护，
并且这些 Secret 信息也可能在 `kubectl` 运行期间对你 PC 上的其他用户可见。
{{< /note >}}
<!--
## Inspecting the Secret `regcred`
To understand the contents of the `regcred` Secret you created, start by viewing the Secret in YAML format:
-->
## 检查 Secret `regcred`
## 检查 Secret `regcred` {#inspecting-the-secret-regcred}
要了解你创建的 `regcred` Secret 的内容，可以用 YAML 格式进行查看：
@@ -217,7 +295,7 @@ You have successfully set your Docker credentials as a Secret called `regcred` i
Here is a manifest for an example Pod that needs access to your Docker credentials in `regcred`:
-->
## 创建一个使用你的 Secret 的 Pod
## 创建一个使用你的 Secret 的 Pod {#create-a-pod-that-uses-your-secret}
下面是一个 Pod 配置清单示例，该示例中 Pod 需要访问你的 Docker 凭证 `regcred`：
content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
+3 -3
View File
@@ -131,13 +131,13 @@ status:
qosClass: Guaranteed
```
{{< note >}}
<!--
If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
the limit.
-->
{{< note >}}
如果容器指定了自己的内存限制，但没有指定内存请求，Kubernetes 会自动为它指定与内存限制匹配的内存请求。
同样，如果容器指定了自己的 CPU 限制，但没有指定 CPU 请求，Kubernetes 会自动为它指定与 CPU 限制匹配的 CPU 请求。
{{< /note >}}
@@ -158,7 +158,7 @@ kubectl delete pod qos-demo --namespace=qos-example
A Pod is given a QoS class of Burstable if:
* The Pod does not meet the criteria for QoS class Guaranteed.
* At least one Container in the Pod has a memory or CPU request.
* At least one Container in the Pod has a memory or CPU request or limit.
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
and a memory request of 100 MiB.
@@ -168,7 +168,7 @@ and a memory request of 100 MiB.
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
* Pod 不符合 Guaranteed QoS 类的标准。
* Pod 中至少一个容器具有内存或 CPU 请求。
* Pod 中至少一个容器具有内存或 CPU 的请求或限制。
下面是包含一个容器的 Pod 配置文件。
容器设置了内存限制 200 MiB 和内存请求 100 MiB。
content/zh/docs/tasks/configure-pod-container/static-pod.md
+40 -31
View File
@@ -67,7 +67,7 @@ The `spec` of a static Pod cannot refer to other API objects
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods,
This page assumes you're using {{< glossary_tooltip term_id="cri-o" >}} to run Pods,
and that your nodes are running the Fedora operating system.
Instructions for other distributions or Kubernetes installations may vary.
-->
@@ -273,7 +273,7 @@ already be running.
You can view running containers (including static Pods) by running (on the node):
```shell
# Run this command on the node where kubelet is running
docker ps
crictl ps
```
The output might be something like:
@@ -287,7 +287,7 @@ The output might be something like:
```shell
# 在 kubelet 运行的节点上执行以下命令
docker ps
crictl ps
```
<!--
@@ -295,10 +295,19 @@ The output might be something like:
-->
输出可能会像这样：
```console
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
<!--
`crictl` outputs the image URI and SHA-256 checksum. `NAME` will look more like:
`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`.
-->
{{< note >}}
`crictl` 会输出镜像 URI 和 SHA-256 校验和。 `NAME` 看起来像：
`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`。
{{< /note >}}
<!--
You can see the mirror Pod on the API server:
@@ -310,17 +319,17 @@ kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
NAME READY STATUS RESTARTS AGE
static-web 1/1 Running 0 2m
```
<!--
Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
[Pod Security admission](/docs/concepts/security/pod-security-admission) and [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/).
-->
{{< note >}}
要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。
可以看[Pod安全策略](/zh/docs/concepts/policy/pod-security-policy/)。
可以看 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)和 [Pod 安全策略](/zh/docs/concepts/security/pod-security-policy/)。
{{< /note >}}
<!--
@@ -338,10 +347,10 @@ the kubelet _doesn't_ remove the static Pod:
如果你用 `kubectl` 从 API 服务上删除镜像 Pod，kubelet _不会_ 移除静态 Pod：
```shell
kubectl delete pod static-web-my-node1
kubectl delete pod static-web
```
```
pod "static-web-my-node1" deleted
pod "static-web" deleted
```
<!--
@@ -354,37 +363,36 @@ kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
NAME READY STATUS RESTARTS AGE
static-web 1/1 Running 0 4s
```
<!--
Back on your node where the kubelet is running, you can try to stop the Docker
container manually.
Back on your node where the kubelet is running, you can try to stop the container manually.
You'll see that, after a time, the kubelet will notice and will restart the Pod
automatically:
```shell
# Run these commands on the node where the kubelet is running
docker stop f6d05272b57e # replace with the ID of your container
crictl stop 129fd7d382018 # replace with the ID of your container
sleep 20
docker ps
crictl ps
```
-->
回到 kubelet 运行的节点上，可以手工停止 Docker 容器。
回到 kubelet 运行的节点上，你可以手动停止容器。
可以看到过了一段时间后 kubelet 会发现容器停止了并且会自动重启 Pod：
```shell
# 在 kubelet 运行的节点上执行以下命令
# 把 ID 换为你的容器的 ID
docker stop f6d05272b57e
crictl stop 129fd7d382018
sleep 20
docker ps
crictl ps
```
```
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
```console
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
```
<!--
@@ -398,11 +406,11 @@ The running kubelet periodically scans the configured directory (`/etc/kubelet.d
#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
crictl ps
# You see that no nginx container is running
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
crictl ps
```
-->
## 动态增加和删除静态 pod
@@ -415,16 +423,17 @@ docker ps
# 在 kubelet 运行的节点上执行以下命令
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
crictl ps
# 可以看到没有 nginx 容器在运行
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
crictl ps
```
```
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
```console
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
```
content/zh/docs/tasks/debug-application-cluster/debug-application.md
+4 -3
View File
@@ -102,8 +102,9 @@ If a Pod is stuck in the `Waiting` state, then it has been scheduled to a worker
Again, the information from `kubectl describe ...` should be informative. The most common cause of `Waiting` pods is a failure to pull the image. There are three things to check:
* Make sure that you have the name of the image correct.
* Have you pushed the image to the repository?
* Run a manual `docker pull <image>` on your machine to see if the image can be pulled.
* Have you pushed the image to the registry?
* Try to manually pull the image to see if the image can be pulled. For example,
if you use Docker on your PC, run `docker pull <image>`.
-->
#### Pod 停滞在 Waiting 状态
@@ -113,7 +114,7 @@ Again, the information from `kubectl describe ...` should be informative. The m
* 确保镜像名字拼写正确
* 确保镜像已被推送到镜像仓库
* 用手动命令 `docker pull <镜像>` 试试看镜像是否可拉取
* 尝试手动是否能拉取镜像。例如，如果你在你的 PC 上使用 Docker，请运行 `docker pull <镜像>`。
<!--
#### My pod is crashing or otherwise unhealthy
content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
+5 -5
View File
@@ -169,7 +169,7 @@ specify the `-i`/`--interactive` argument, `kubectl` will automatically attach
to the console of the Ephemeral Container.
```shell
kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
```
```
@@ -192,7 +192,7 @@ OCI runtime exec failed: exec failed: container_linux.go:346: starting container
如果你指定 `-i` 或者 `--interactive` 参数，`kubectl` 将自动挂接到临时容器的控制台。
```shell
kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
```
```
@@ -298,7 +298,7 @@ this scenario using `kubectl run`:
你可以使用 `kubectl run` 模拟这个场景:
```shell
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
<!--
Run this command to create a copy of `myapp` named `myapp-debug` that adds a
@@ -366,7 +366,7 @@ that immediately exits:
为了模拟应用崩溃的场景，使用 `kubectl run` 命令创建一个立即退出的容器：
```
kubectl run --image=busybox myapp -- false
kubectl run --image=busybox:1.28 myapp -- false
```
<!--
@@ -453,7 +453,7 @@ As an example, create a Pod using `kubectl run`:
下面的例子，用 `kubectl run`创建一个 Pod：
```
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
<!--
Now use `kubectl debug` to make a copy and change its container image
content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+9
View File
@@ -99,6 +99,15 @@ the container starts.
```shell
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
```
<!
If you are running a multi-container pod, you can use a Go template to include the container's name. By doing so, you can discover which of the containers is failing:
-->
如果你正在运行多容器 Pod，则可以使用 Go 模板来包含容器的名称。这样，你可以发现哪些容器出现故障:
```shell
kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:\n%s\n\n" .name .lastState.terminated.message}}{{end}}'
```
<!--
## Customizing the termination message
content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+4 -4
View File
@@ -271,7 +271,7 @@ both Linux and Windows kernels). The time window used to calculate CPU is shown
in Metrics API.
To learn more about how Kubernetes allocates and measures CPU resources, see
[meaning of CPU](/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu).
[meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu).
-->
## 度量资源用量 {#measuring-resource-usage}
@@ -284,7 +284,7 @@ CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes
用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。
要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅
[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu)。
[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
<!--
### Memory
@@ -300,7 +300,7 @@ anonymous memory associated with the container in question. The working set metr
includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
To learn more about how Kubernetes allocates and measures memory resources, see
[meaning of memory](/docs/concepts/configuration/manage-resources-container/#meaning-of-memory).
[meaning of memory](/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory).
-->
### 内存 {#memory}
@@ -313,7 +313,7 @@ Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容
工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。
要了解有关 Kubernetes 如何分配和测量内存资源的更多信息，
请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-memory)。
请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)。
<!--
## Metrics Server
content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md
+15 -20
View File
@@ -13,7 +13,17 @@ Konnectivity 服务为控制平面提供集群通信的 TCP 级别代理。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!--
You need to have a Kubernetes cluster, and the kubectl command-line tool must
be configured to communicate with your cluster. It is recommended to run this
tutorial on a cluster with at least two nodes that are not acting as control
plane hosts. If you do not already have a cluster, you can create one by using
[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/).
-->
你需要有一个 Kubernetes 集群，并且 kubectl 命令可以与集群通信。
建议在至少有两个不充当控制平面主机的节点的集群上运行本教程。
如果你还没有集群，可以使用
[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) 创建一个集群。
<!-- steps -->
<!--
@@ -32,15 +42,8 @@ You need to configure the API Server to use the Konnectivity service
and direct the network traffic to the cluster nodes:
1. Make sure that
the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
is enabled. You can enable
[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
by providing the following flags to the kube-apiserver:
```
--service-account-issuer=api
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
--api-audiences=system:konnectivity-server
```
[Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
feature enabled in your cluster. It is enabled by default since Kubernetes v1.20.
1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
1. Set the `--egress-selector-config-file` flag of the API Server to the path of
your API Server egress configuration file.
@@ -61,16 +64,8 @@ your API Server egress configuration file.
-->
你需要配置 API 服务器来使用 Konnectivity 服务，并将网络流量定向到集群节点：
1. 确保 `ServiceAccountTokenVolumeProjection`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
被启用。你可以通过为 kube-apiserver 提供以下标志启用
[服务账号令牌卷保护](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)：
```
--service-account-issuer=api
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
--api-audiences=system:konnectivity-server
```
确保[服务账号令牌卷投射](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
特性被启用。该特性自 Kubernetes v1.20 起默认已被启用。
1. 创建一个出站流量配置文件，比如 `admin/konnectivity/egress-selector-configuration.yaml`。
1. 将 API 服务器的 `--egress-selector-config-file` 参数设置为你的 API 服务器的
content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md
+18 -4
View File
@@ -133,15 +133,28 @@ metadata:
```
<!--
To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.env` file:
To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. This can also be used to set values from local environment variables by omitting the `=` and the value.
-->
要从 env 文件生成 ConfigMap，请在 `configMapGenerator` 中的 `envs` 列表中添加一个条目。
这也可以用于通过省略 `=` 和值来设置本地环境变量的值。
<!--
It's recommended to use the local environment variable population functionality sparingly - an overlay with a patch is often more maintainable. Setting values from the environment may be useful when they cannot easily be predicted, such as a git SHA.
-->
建议谨慎使用本地环境变量填充功能 —— 用补丁覆盖通常更易于维护。
当无法轻松预测变量的值时，从环境中设置值可能很有用，例如 git SHA。
<!--
Here is an example of generating a ConfigMap with a data item from a `.env` file:
-->
下面是一个用来自 `.env` 文件的数据生成 ConfigMap 的例子：
```shell
# 创建一个 .env 文件
# BAZ 将使用本地环境变量 $BAZ 的取值填充
cat <<EOF >.env
FOO=Bar
BAZ
EOF
cat <<EOF >./kustomization.yaml
@@ -158,7 +171,7 @@ The generated ConfigMap can be examined with the following command:
可以使用以下命令检查生成的 ConfigMap：
```shell
kubectl kustomize ./
BAZ=Qux kubectl kustomize ./
```
<!--
@@ -169,10 +182,11 @@ The generated ConfigMap is:
```yaml
apiVersion: v1
data:
BAZ: Qux
FOO: Bar
kind: ConfigMap
metadata:
name: example-configmap-1-42cfbf598f
name: example-configmap-1-892ghb99c8
```
<!--
@@ -398,7 +412,7 @@ type: Opaque
```
<!--
Like ConfigMaps, generated Secrets can be used in Deployments by refering to the name of the secretGenerator:
Like ConfigMaps, generated Secrets can be used in Deployments by referring to the name of the secretGenerator:
-->
与 ConfigMaps 一样，生成的 Secrets 可以通过引用 secretGenerator 的名称在部署中使用：
content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
+378 -302
View File
@@ -12,61 +12,97 @@ weight: 90
<!-- overview -->
<!--
The Horizontal Pod Autoscaler automatically scales the number of Pods
in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with
[custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
support, on some other application-provided metrics). Note that Horizontal
Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSets.
In Kubernetes, a _HorizontalPodAutoscaler_ automatically updates a workload resource (such as
a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} or
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}), with the
aim of automatically scaling the workload to match demand.
-->
Pod 水平自动扩缩（Horizontal Pod Autoscaler）
可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和
StatefulSet 中的 Pod 数量。
除了 CPU 利用率，也可以基于其他应程序提供的
[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
来执行自动扩缩。
Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。
在 Kubernetes 中，_HorizontalPodAutoscaler_ 自动更新工作负载资源
（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}），
目的是自动扩缩工作负载以满足需求。
<!--
The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller.
The resource determines the behavior of the controller.
The controller periodically adjusts the number of replicas in a replication controller or deployment
to match the observed metrics such as average CPU utilisation, average memory utilisation or any other custom metric to the target specified by the user.
Horizontal scaling means that the response to increased load is to deploy more
{{< glossary_tooltip text="Pods" term_id="pod" >}}.
This is different from _vertical_ scaling, which for Kubernetes would mean
assigning more resources (for example: memory or CPU) to the Pods that are already
running for the workload.
If the load decreases, and the number of Pods is above the configured minimum,
the HorizontalPodAutoscaler instructs the workload resource (the Deployment, StatefulSet,
or other similar resource) to scale back down.
-->
Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
控制器会周期性地调整副本控制器或 Deployment 中的副本数量，以使得类似 Pod 平均 CPU
利用率、平均内存利用率这类观测到的度量值与用户所设定的目标值匹配。
水平扩缩意味着对增加的负载的响应是部署更多的 {{< glossary_tooltip text="Pods" term_id="pod" >}}。
这与 “垂直（Vertical）” 扩缩不同，对于 Kubernetes，
垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。
如果负载减少，并且 Pod 的数量高于配置的最小值，
HorizontalPodAutoscaler 会指示工作负载资源（ Deployment、StatefulSet 或其他类似资源）缩减。
<!--
Horizontal pod autoscaling does not apply to objects that can't be scaled (for example:
a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.)
-->
水平 Pod 自动扩缩不适用于无法扩缩的对象（例如：{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。）
<!--
The HorizontalPodAutoscaler is implemented as a Kubernetes API resource and a
{{< glossary_tooltip text="controller" term_id="controller" >}}.
The resource determines the behavior of the controller.
The horizontal pod autoscaling controller, running within the Kubernetes
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}, periodically adjusts the
desired scale of its target (for example, a Deployment) to match observed metrics such as average
CPU utilization, average memory utilization, or any other custom metric you specify.
-->
HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和{{< glossary_tooltip text="控制器" term_id="controller" >}}。
资源决定了控制器的行为。在 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}内运行的水平
Pod 自动扩缩控制器会定期调整其目标（例如：Deployment）的所需规模，以匹配观察到的指标，
例如，平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标。
<!--
There is [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) of using
horizontal pod autoscaling.
-->
使用水平 Pod 自动扩缩[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
<!-- body -->
<!--
## How does the Horizontal Pod Autoscaler work?
## How does a HorizontalPodAutoscaler work?
-->
## Pod 水平自动扩缩工作机制
## HorizontalPodAutoscaler 是如何工作的？ {#how-does-a-horizontalpodautoscaler-work}
![水平自动扩缩示意图](/images/docs/horizontal-pod-autoscaler.svg)
{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的规模" class="diagram-medium">}}
<!--
The Horizontal Pod Autoscaler is implemented as a control loop, with a period controlled
by the controller manager's `--horizontal-pod-autoscaler-sync-period` flag (with a default
value of 15 seconds).
Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently
(it is not a continuous process). The interval is set by the
`--horizontal-pod-autoscaler-sync-period` parameter to the
[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)
(and the default interval is 15 seconds).
-->
Pod 水平自动扩缩器的实现是一个控制回路，由控制器管理器的 `--horizontal-pod-autoscaler-sync-period` 参数指定周期（默认值为 15 秒）。
Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由
[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
的 `--horizontal-pod-autoscaler-sync-period` 参数设置（默认间隔为 15 秒）。
<!--
During each period, the controller manager queries the resource utilization against the
metrics specified in each HorizontalPodAutoscaler definition. The controller manager
obtains the metrics from either the resource metrics API (for per-pod resource metrics),
Once during each period, the controller manager queries the resource utilization against the
metrics specified in each HorizontalPodAutoscaler definition. The controller manager
finds the target resource defined by the `scaleTargetRef`,
then selects the pods based on the target resource's `.spec.selector` labels, and obtains the metrics from either the resource metrics API (for per-pod resource metrics),
or the custom metrics API (for all other metrics).
-->
每个周期内，控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
控制器管理器可以从资源度量指标 API（按 Pod 统计的资源用量）和自定义度量指标
API（其他指标）获取度量值。
在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
控制器管理器找到由 `scaleTargetRef` 定义的目标资源，然后根据目标资源的 `.spec.selector` 标签选择 Pod，
并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标）。
<!--
* For per-pod resource metrics (like CPU), the controller fetches the metrics
from the resource metrics API for each Pod targeted by the HorizontalPodAutoscaler.
Then, if a target utilization value is set, the controller calculates the utilization
value as a percentage of the equivalent resource request on the containers in
value as a percentage of the equivalent [resource request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) on the containers in
each Pod. If a target raw value is set, the raw metric values are used directly.
The controller then takes the mean of the utilization or the raw value (depending on the type
of target specified) across all targeted Pods, and produces a ratio used to scale
@@ -74,8 +110,8 @@ API（其他指标）获取度量值。
-->
* 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，
控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。
如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
控制器获取每个 Pod 中的容器[资源使用](/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况，
并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
<!--
@@ -107,41 +143,34 @@ API（其他指标）获取度量值。
在 `autoscaling/v2beta2` 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。
<!--
The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
`custom.metrics.k8s.io`, and `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by
metrics-server, which needs to be launched separately. See
[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)
for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from
{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}}
(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is
usually provided by an add-on named Metrics Server, which needs to be launched separately.
For more information about resource metrics, see
[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server).
-->
通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io`
和 `external.metrics.k8s.io`）中获取度量值。
`metrics.k8s.io` API 通常由 Metrics 服务器（需要额外启动）提供。
可以从 [metrics-server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。
另外，控制器也可以直接从 Heapster 获取指标。
{{< note >}}
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
<!--
Fetching metrics from Heapster is deprecated as of Kubernetes 1.11.
-->
自 Kubernetes 1.11 起，从 Heapster 获取指标特性已废弃。
{{< /note >}}
HorizontalPodAutoscaler 的常见用途是将其配置为从{{< glossary_tooltip text="聚合 API" term_id="aggregation-layer" >}}
（`metrics.k8s.io`、`custom.metrics.k8s.io` 或 `external.metrics.k8s.io`）获取指标。
`metrics.k8s.io` API 通常由名为 Metrics Server 的插件提供，需要单独启动。有关资源指标的更多信息，
请参阅 [Metrics Server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)。
<!--
See [Support for metrics APIs](#support-for-metrics-apis) for more details.
-->
关于指标 API 更多信息，请参考[度量值指标 API 的支持](#support-for-metrics-apis)。
[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these
different APIs.
<!--
The autoscaler accesses corresponding scalable controllers (such as replication controllers, deployments, and replica sets)
by using the scale sub-resource. Scale is an interface that allows you to dynamically set the number of replicas and examine
each of their current states. More details on scale sub-resource can be found
[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
The HorizontalPodAutoscaler controller accesses corresponding workload resources that support scaling (such as Deployments
and StatefulSet). These resources each have a subresource named `scale`, an interface that allows you to dynamically set the
number of replicas and examine each of their current states.
For general information about subresources in the Kubernetes API, see
[Kubernetes API Concepts](/docs/reference/using-api/api-concepts/).
-->
自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、
Deployment 和 ReplicaSet）。
`scale` 是一个可以动态设定副本数量和检查当前状态的接口。
关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
对 [Metrics API 的支持](#support-for-metrics-apis)解释了这些不同 API 的稳定性保证和支持状态
HorizontalPodAutoscaler 控制器访问支持扩缩的相应工作负载资源（例如：Deployments 和 StatefulSet）。
这些资源每个都有一个名为 `scale` 的子资源，该接口允许你动态设置副本的数量并检查它们的每个当前状态。
有关 Kubernetes API 子资源的一般信息，
请参阅 [Kubernetes API 概念](/zh/docs/reference/using-api/api-concepts/)。
<!--
### Algorithm Details
@@ -166,47 +195,51 @@ desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricVal
<!--
For example, if the current metric value is `200m`, and the desired value
is `100m`, the number of replicas will be doubled, since `200.0 / 100.0 ==
2.0` If the current value is instead `50m`, we'll halve the number of
replicas, since `50.0 / 100.0 == 0.5`. We'll skip scaling if the ratio is
sufficiently close to 1.0 (within a globally-configurable tolerance, from
the `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1).
2.0` If the current value is instead `50m`, you'll halve the number of
replicas, since `50.0 / 100.0 == 0.5`. The control plane skips any scaling
action if the ratio is sufficiently close to 1.0 (within a globally-configurable
tolerance, 0.1 by default).
-->
例如，当前度量值为 `200m`，目标设定值为 `100m`，那么由于 `200.0/100.0 == 2.0`，
副本数量将会翻倍。
如果当前指标为 `50m`，副本数量将会减半，因为`50.0/100.0 == 0.5`。
如果计算出的扩缩比例接近 1.0
（根据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1），
将会放弃本次扩缩。
例如，如果当前指标值为 `200m`，而期望值为 `100m`，则副本数将加倍，
因为 `200.0 / 100.0 == 2.0` 如果当前值为 `50m`，则副本数将减半，
因为 `50.0 / 100.0 == 0.5`。如果比率足够接近 1.0（在全局可配置的容差范围内，默认为 0.1），
则控制平面会跳过扩缩操作。
<!--
When a `targetAverageValue` or `targetAverageUtilization` is specified,
the `currentMetricValue` is computed by taking the average of the given
metric across all Pods in the HorizontalPodAutoscaler's scale target.
Before checking the tolerance and deciding on the final values, we take
pod readiness and missing metrics into consideration, however.
Before checking the tolerance and deciding on the final values, the control
plane also considers whether any metrics are missing, and how many Pods
are [`Ready`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions).
-->
如果 HorizontalPodAutoscaler 指定的是 `targetAverageValue` 或 `targetAverageUtilization`，
那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。
在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标，
以及有多少 Pod [`已就绪`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
<!--
All Pods with a deletion timestamp set (i.e. Pods in the process of being
shut down) and all failed Pods are discarded.
All Pods with a deletion timestamp set (objects with a deletion timestamp are
in the process of being shut down / removed) are ignored, and all failed Pods
are discarded.
If a particular Pod is missing metrics, it is set aside for later; Pods
with missing metrics will be used to adjust the final scaling amount.
-->
所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和失败的 Pod 都会被忽略。
所有设置了删除时间戳的 Pod（带有删除时间戳的对象正在关闭/移除的过程中）都会被忽略，
所有失败的 Pod 都会被丢弃。
如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。
<!--
When scaling on CPU, if any pod has yet to become ready (i.e. it's still
initializing) *or* the most recent metric point for the pod was before it
When scaling on CPU, if any pod has yet to become ready (it's still
initializing, or possibly is unhealthy) *or* the most recent metric point for the pod was before it
became ready, that pod is set aside as well.
-->
当使用 CPU 指标来扩缩时，任何还未就绪（例如还在初始化）状态的 Pod *或* 最近的指标
度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或**
最近的指标度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
<!--
Due to technical constraints, the HorizontalPodAutoscaler controller
@@ -220,13 +253,11 @@ ready to be the first if it occurred within a longer, configurable time
since it started. This value is configured with the `--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its
default is 5 minutes.
-->
由于受技术限制，Pod 水平扩缩控制器无法准确的知道 Pod 什么时候就绪，
也就无法决定是否暂时搁置该 Pod。
`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为 30s）用于设置 Pod 准备时间，
在此时间内的 Pod 统统被认为未就绪。
`--horizontal-pod-autoscaler-cpu-initialization-period` 参数（默认为5分钟）
用于设置 Pod 的初始化时间，
在此时间内的 Pod，CPU 资源度量值将不会被采纳。
由于技术限制，HorizontalPodAutoscaler 控制器在确定是否保留某些 CPU 指标时无法准确确定 Pod 首次就绪的时间。
相反，如果 Pod 未准备好并在其启动后的一个可配置的短时间窗口内转换为未准备好，它会认为 Pod “尚未准备好”。
该值使用 `--horizontal-pod-autoscaler-initial-readiness-delay` 标志配置，默认值为 30 秒。
一旦 Pod 准备就绪，如果它发生在自启动后较长的、可配置的时间内，它就会认为任何向准备就绪的转换都是第一个。
该值由 `-horizontal-pod-autoscaler-cpu-initialization-period` 标志配置，默认为 5 分钟。
<!--
The `currentMetricValue / desiredMetricValue` base scale ratio is then
@@ -236,34 +267,33 @@ calculated using the remaining pods not set aside or discarded from above.
计算出来。
<!--
If there were any missing metrics, we recompute the average more
If there were any missing metrics, the control plane recomputes the average more
conservatively, assuming those pods were consuming 100% of the desired
value in case of a scale down, and 0% in case of a scale up. This dampens
the magnitude of any potential scale.
-->
如果缺失任何的度量值，我们会更保守地重新计算平均值，
在需要缩小时假设这些 Pod 消耗了目标值的 100%，
在需要放大时假设这些 Pod 消耗了 0% 目标值。
这可以在一定程度上抑制扩缩的幅度。
如果缺失某些度量值，控制平面会更保守地重新计算平均值，在需要缩小时假设这些 Pod 消耗了目标值的 100%，
在需要放大时假设这些 Pod 消耗了 0% 目标值。这可以在一定程度上抑制扩缩的幅度。
<!--
Furthermore, if any not-yet-ready pods were present, and we would have
scaled up without factoring in missing metrics or not-yet-ready pods, we
conservatively assume the not-yet-ready pods are consuming 0% of the
desired metric, further dampening the magnitude of a scale up.
Furthermore, if any not-yet-ready pods were present, and the workload would have
scaled up without factoring in missing metrics or not-yet-ready pods,
the controller conservatively assumes that the not-yet-ready pods are consuming 0%
of the desired metric, further dampening the magnitude of a scale up.
-->
此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
我们保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
此外，如果存在任何尚未就绪的 Pod，工作负载会在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
控制器保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
<!--
After factoring in the not-yet-ready pods and missing metrics, we
recalculate the usage ratio. If the new ratio reverses the scale
direction, or is within the tolerance, we skip scaling. Otherwise, we use
the new ratio to scale.
After factoring in the not-yet-ready pods and missing metrics, the
controller recalculates the usage ratio. If the new ratio reverses the scale
direction, or is within the tolerance, the controller doesn't take any scaling
action. In other cases, the new ratio is used to decide any change to the
number of Pods.
-->
在扩缩方向（缩小或放大）确定后，我们会把未就绪的 Pod 和缺少指标的 Pod 考虑进来再次计算使用率。
如果新的比率与扩缩方向相反，或者在容忍范围内，则跳过扩缩。
否则，我们使用新的扩缩比例。
考虑到尚未准备好的 Pod 和缺失的指标后，控制器会重新计算使用率。
如果新的比率与扩缩方向相反，或者在容差范围内，则控制器不会执行任何扩缩操作。
在其他情况下，新比率用于决定对 Pod 数量的任何更改。
<!--
Note that the *original* value for the average utilization is reported
@@ -271,8 +301,8 @@ back via the HorizontalPodAutoscaler status, without factoring in the
not-yet-ready pods or missing metrics, even when the new usage ratio is
used.
-->
注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（
即使使用了新的使用率，也不考虑未就绪 Pod 和 缺少指标的 Pod)。
注意，平均利用率的 **原始** 值是通过 HorizontalPodAutoscaler 状态体现的，
而不考虑尚未准备好的 Pod 或缺少的指标，即使使用新的使用率也是如此。
<!--
If multiple metrics are specified in a HorizontalPodAutoscaler, this
@@ -307,62 +337,42 @@ fluctuating metric values.
<!--
## API Object
The Horizontal Pod Autoscaler is an API resource in the Kubernetes `autoscaling` API group.
The current stable version, which only includes support for CPU autoscaling,
can be found in the `autoscaling/v1` API version.
The Horizontal Pod Autoscaler is an API resource in the Kubernetes
`autoscaling` API group. The current stable version can be found in
the `autoscaling/v2` API version which includes support for scaling on
memory and custom metrics. The new fields introduced in
`autoscaling/v2` are preserved as annotations when working with
`autoscaling/v1`.
-->
## API 对象 {#api-object}
HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。
在当前稳定版本（`autoscaling/v1`）中只支持基于 CPU 指标的扩缩。
<!--
The beta version, which includes support for scaling on memory and custom metrics,
can be found in `autoscaling/v2beta2`. The new fields introduced in `autoscaling/v2beta2`
are preserved as annotations when working with `autoscaling/v1`.
-->
API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义指标的扩缩。
在 `autoscaling/v2beta2` 版本中新引入的字段在 `autoscaling/v1` 版本中以注解
的形式得以保留。
HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组中的 API 资源。
当前的稳定版本可以在 `autoscaling/v2` API 版本中找到，其中包括对基于内存和自定义指标执行扩缩的支持。
在使用 `autoscaling/v1` 时，`autoscaling/v2` 中引入的新字段作为注释保留。
<!--
When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
More details about the API object can be found at
[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling).
[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling).
-->
创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
有关 API 对象的更多信息，请查阅
[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。
[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)。
<!--
## Support for Horizontal Pod Autoscaler in kubectl
## Stability of workload scale {#flapping}
Horizontal Pod Autoscaler, like every API resource, is supported in a standard way by `kubectl`.
We can create a new autoscaler using `kubectl create` command.
We can list autoscalers by `kubectl get hpa` and get detailed description by `kubectl describe hpa`.
Finally, we can delete an autoscaler using `kubectl delete hpa`.
When managing the scale of a group of replicas using the HorizontalPodAutoscaler,
it is possible that the number of replicas keeps fluctuating frequently due to the
dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*,
or *flapping*. It's similar to the concept of *hysteresis* in cybernetics.
-->
## kubectl 对 Horizontal Pod Autoscaler 的支持
## 工作量规模的稳定性 {#flapping}
与其他 API 资源类似，`kubectl` 以标准方式支持 HPA。
我们可以通过 `kubectl create` 命令创建一个 HPA 对象，
通过 `kubectl get hpa` 命令来获取所有 HPA 对象，
通过 `kubectl describe hpa` 命令来查看 HPA 对象的详细信息。
最后，可以使用 `kubectl delete hpa` 命令删除对象。
<!--
In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler.
For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
will create an autoscaler for replication set *foo*, with target CPU utilization set to `80%`
and the number of replicas between 2 and 5.
The detailed documentation of `kubectl autoscale` can be found [here](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
-->
此外，还有个简便的命令 `kubectl autoscale` 来创建 HPA 对象。
例如，命令 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 将会为名
为 *foo* 的 ReplicationSet 创建一个 HPA 对象，
目标 CPU 使用率为 `80%`，副本数量配置为 2 到 5 之间。
在使用 HorizontalPodAutoscaler 管理一组副本的规模时，由于评估的指标的动态特性，
副本的数量可能会经常波动。这有时被称为 **抖动（thrashing）** 或 **波动（flapping）**。它类似于控制论中的 **滞后（hysteresis）** 概念。
<!--
## Autoscaling during rolling update
@@ -391,56 +401,6 @@ similar to ReplicaSet).
如果你对一个副本个数被自动扩缩的 StatefulSet 执行滚动更新， 该 StatefulSet
会直接管理它的 Pod 集合 （不存在类似 ReplicaSet 这样的中间资源）。
<!--
## Support for cooldown/delay
When managing the scale of a group of replicas using the Horizontal Pod Autoscaler,
it is possible that the number of replicas keeps fluctuating frequently due to the
dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*.
-->
## 冷却/延迟支持
当使用 Horizontal Pod Autoscaler 管理一组副本扩缩时，
有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为
*抖动（Thrashing）*。
<!--
Starting from v1.6, a cluster operator can mitigate this problem by tuning
the global HPA settings exposed as flags for the `kube-controller-manager` component:
-->
从 v1.6 版本起，集群操作员可以调节某些 `kube-controller-manager` 的全局参数来
缓解这个问题。
<!--
Starting from v1.12, a new algorithmic update removes the need for the
upscale delay.
-->
从 v1.12 开始，算法调整后，扩容操作时的延迟就不必设置了。
<!--
- `--horizontal-pod-autoscaler-downscale-stabilization`: Specifies the duration of the
downscale stabilization time window. Horizontal Pod Autoscaler remembers
this historical recommended sizes and only acts on the largest size within this time window.
The default value is 5 minutes (`5m0s`).
-->
- `--horizontal-pod-autoscaler-downscale-stabilization`: 设置缩容冷却时间窗口长度。
水平 Pod
扩缩器能够记住过去建议的负载规模，并仅对此时间窗口内的最大规模执行操作。
默认值是 5 分钟（`5m0s`）。
<!--
When tuning these parameter values, a cluster operator should be aware of the possible
consequences. If the delay (cooldown) value is set too long, there could be complaints
that the Horizontal Pod Autoscaler is not responsive to workload changes. However, if
the delay value is set too short, the scale of the replicas set may keep thrashing as
usual.
-->
{{< note >}}
当调整这些参数时，集群操作员需要明白其可能的影响。
如果延迟（冷却）时间设置的太长，Horizontal Pod Autoscaler 可能会不能很好的改变负载。
如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。
{{< /note >}}
<!--
## Support for resource metrics
@@ -497,15 +457,15 @@ pod usage is still within acceptable limits.
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
<!--
`HorizontalPodAutoscaler` also supports a container metric source where the HPA can track the
The HorizontalPodAutoscaler API also supports a container metric source where the HPA can track the
resource usage of individual containers across a set of Pods, in order to scale the target resource.
This lets you configure scaling thresholds for the containers that matter most in a particular Pod.
For example, if you have a web application and a logging sidecar, you can scale based on the resource
use of the web application, ignoring the sidecar container and its resource use.
-->
`HorizontalPodAutoscaler` 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的
HorizontalPodAutoscaler API 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的
资源用量，进而触发扩缩目标对象的操作。
容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模缩放阈值。
容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模扩缩阈值。
例如，如果你有一个 Web 应用和一个执行日志操作的边车容器，你可以基于 Web 应用的
资源用量来执行扩缩，忽略边车容器的存在及其资源用量。
@@ -517,7 +477,7 @@ of the pods then those pods are ignored and the recommendation is recalculated.
for more details about the calculation. To use container resources for autoscaling define a metric
source as follows:
-->
如果你更改缩放目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要
如果你更改扩缩目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要
修改 HPA 的规约才能基于新添加的容器来执行规模扩缩操作。
如果指标源中指定的容器不存在或者仅存在于部分 Pods 中，那么这些 Pods 会被忽略，
HPA 会重新计算资源用量值。参阅[算法](#algorithm-details)小节进一步了解计算细节。
@@ -563,51 +523,50 @@ the old container name from the HPA specification.
{{< /note >}}
<!--
## Support for multiple metrics
## Scaling on custom metrics
Kubernetes 1.6 adds support for scaling based on multiple metrics. You can use the `autoscaling/v2beta2` API
version to specify multiple metrics for the Horizontal Pod Autoscaler to scale on. Then, the Horizontal Pod
Autoscaler controller will evaluate each metric, and propose a new scale based on that metric. The largest of the
proposed scales will be used as the new scale.
-->
## 多指标支持 {#support-for-multiple-metrics}
(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
Kubernetes 1.6 开始支持基于多个度量值进行扩缩。
你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。
Horizontal Pod Autoscaler 会根据每个指标计算，并生成一个扩缩建议。
幅度最大的扩缩建议会被采纳。
Provided that you use the `autoscaling/v2` API version, you can configure a HorizontalPodAutoscaler
to scale based on a custom metric (that is not built in to Kubernetes or any Kubernetes component).
The HorizontalPodAutoscaler controller then queries for these custom metrics from the Kubernetes
API.
<!--
## Support for custom metrics
Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
Support for these annotations was removed in Kubernetes 1.6 in favor of the new autoscaling API. While the old method for collecting
custom metrics is still available, these metrics will not be available for use by the Horizontal Pod Autoscaler, and the former
annotations for specifying which custom metrics to scale on are no longer honored by the Horizontal Pod Autoscaler controller.
-->
## 自定义指标支持 {#support-for-custom-metrics}
{{< note >}}
在 Kubernetes 1.2 增加了支持基于使用特殊注解表达的、特定于具体应用的扩缩能力，
此能力处于 Alpha 阶段。
从 Kubernetes 1.6 起，由于新的 autoscaling API 的引入，这些 annotation 就被废弃了。
虽然收集自定义指标的旧方法仍然可用，Horizontal Pod Autoscaler 调度器将不会再使用这些度量值。
同时，Horizontal Pod Autoscaler 也不再使用之前用于指定用户自定义指标的注解。
{{< /note >}}
<!--
Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler.
You can add custom metrics for the Horizontal Pod Autoscaler to use in the `autoscaling/v2beta2` API.
Kubernetes then queries the new custom metrics API to fetch the values of the appropriate custom metrics.
-->
自 Kubernetes 1.6 起，Horizontal Pod Autoscaler 支持使用自定义指标。
你可以使用 `autoscaling/v2beta2` API 为 Horizontal Pod Autoscaler 指定用户自定义指标。
Kubernetes 会通过用户自定义指标 API 来获取相应的指标。
<!--
See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
-->
关于指标 API 的要求，请参阅[对 Metrics API 的支持](#support-for-metrics-apis)。
## 扩展自定义指标 {#scaling-on-custom-metrics}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
如果你使用 `autoscaling/v2` API 版本，则可以将 HorizontalPodAutoscaler
配置为基于自定义指标（未内置于 Kubernetes 或任何 Kubernetes 组件）进行扩缩。
HorizontalPodAutoscaler 控制器能够从 Kubernetes API 查询这些自定义指标。
有关要求，请参阅对 [Metrics APIs 的支持](#support-for-metrics-apis)。
<!--
## Scaling on multiple metrics
(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
Provided that you use the `autoscaling/v2` API version, you can specify multiple metrics for a
HorizontalPodAutoscaler to scale on. Then, the HorizontalPodAutoscaler controller evaluates each metric,
and proposes a new scale based on that metric. The HorizontalPodAutoscaler takes the maximum scale
recommended for each metric and sets the workload to that size (provided that this isn't larger than the
overall maximum that you configured).
-->
## 基于多个指标来执行扩缩 {#scaling-on-multiple-metrics}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
如果你使用 `autoscaling/v2` API 版本，你可以为 HorizontalPodAutoscaler 指定多个指标以进行扩缩。
HorizontalPodAutoscaler 控制器评估每个指标，并根据该指标提出一个新的比例。
HorizontalPodAutoscaler 采用为每个指标推荐的最大比例，
并将工作负载设置为该大小（前提是这不大于你配置的总体最大值）。
<!--
## Support for metrics APIs
@@ -629,12 +588,9 @@ APIs, cluster administrators must ensure that:
It can be launched as a cluster addon.
* For custom metrics, this is the `custom.metrics.k8s.io` API. It's provided by "adapter" API servers provided by metrics solution vendors.
Check with your metrics pipeline, or the [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started.
Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available.
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
* The `--horizontal-pod-autoscaler-use-rest-clients` is `true` or unset. Setting this to false switches to Heapster-based autoscaling, which is deprecated.
-->
* 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
@@ -645,24 +601,20 @@ APIs, cluster administrators must ensure that:
* 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。
如果你想自己编写，请从 [boilerplate](https://github.com/kubernetes-sigs/custommetrics-apiserver)开始。
检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
* 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
* `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。
如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。
<!--
For more information on these different metrics paths and how they differ please see the relevant design proposals for
[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)
and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
-->
关于指标来源以及其区别的更多信息，请参阅相关的设计文档，
[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md)、
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) 和
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)。
[HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md)，
[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md) 和
[external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md)。
<!--
For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
@@ -673,24 +625,34 @@ and [the walkthrough for using external metrics](/docs/tasks/run-application/hor
和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
<!--
## Support for configurable scaling behavior
## Configurable scaling behavior
Starting from
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
the `v2beta2` API allows scaling behavior to be configured through the HPA
`behavior` field. Behaviors are specified separately for scaling up and down in
`scaleUp` or `scaleDown` section under the `behavior` field. A stabilization
window can be specified for both directions which prevents the flapping of the
number of the replicas in the scaling target. Similarly specifying scaling
policies controls the rate of change of replicas while scaling.
(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
If you use the `v2` HorizontalPodAutoscaler API, you can use the `behavior` field
(see the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec))
to configure separate scale-up and scale-down behaviors.
You specify these behaviours by setting `scaleUp` and / or `scaleDown`
under the `behavior` field.
-->
## 支持可配置的扩缩 {#support-for-configurable-scaling-behaviour}
## 可配置的扩缩行为 {#configurable-scaling-behavior}
从 [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
开始，`v2beta2` API 允许通过 HPA 的 `behavior` 字段配置扩缩行为。
在 `behavior` 字段中的 `scaleUp` 和 `scaleDown` 分别指定扩容和缩容行为。
可以两个方向指定一个稳定窗口，以防止扩缩目标中副本数量的波动。
类似地，指定扩缩策略可以控制扩缩时副本数的变化率。
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
如果你使用 `v2` HorizontalPodAutoscaler API，你可以使用 `behavior` 字段
（请参阅 [API 参考](/zh/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)）
来配置单独的放大和缩小行为。你可以通过在行为字段下设置 `scaleUp` 和/或 `scaleDown` 来指定这些行为。
<!--
You can specify a _stabilization window_ that prevents [flapping](#flapping)
the replica count for a scaling target. Scaling policies also let you controls the
rate of change of replicas while scaling.
-->
你可以指定一个 “稳定窗口” ，以防止扩缩目标的副本计数发生[波动](#flapping)。
扩缩策略还允许你在扩缩时控制副本的变化率。
<!--
### Scaling Policies
@@ -701,9 +663,8 @@ change is the policy which is selected by default. The following example shows t
while scaling down:
-->
### 扩缩策略 {#scaling-policies}
在 spec 字段的 `behavior` 部分可以指定一个或多个扩缩策略。
当指定多个策略时，默认选择允许更改最多的策略。
下面的例子展示了缩容时的行为:
可以在规约的 `behavior` 部分中指定一个或多个扩缩策略。当指定多个策略时，
允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为：
```yaml
behavior:
@@ -750,35 +711,45 @@ scaling in that direction.
-->
可以指定扩缩方向的 `selectPolicy` 字段来更改策略选择。
通过设置 `Min` 的值，它将选择副本数变化最小的策略。
将该值设置为 `Disabled` 将完全禁用该方向的缩放。
将该值设置为 `Disabled` 将完全禁用该方向的扩缩。
<!--
### Stabilization Window
The stabilization window is used to restrict the flapping of replicas when the metrics
used for scaling keep fluctuating. The stabilization window is used by the autoscaling
algorithm to consider the computed desired state from the past to prevent scaling. In
the following example the stabilization window is specified for `scaleDown`.
The stabilization window is used to restrict the [flapping](#flapping) of
replicas count when the metrics used for scaling keep fluctuating. The autoscaling algorithm
uses this window to infer a previous desired state and avoid unwanted changes to workload
scale.
For example, in the following example snippet, a stabilization window is specified for `scaleDown`.
-->
### 稳定窗口 {#stabilization-window}
当用于扩缩的指标持续抖动时，使用稳定窗口来限制副本数上下振动。
自动扩缩算法使用稳定窗口来考虑过去计算的期望状态，以防止扩缩。
在下面的例子中，稳定化窗口被指定为 `scaleDown`。
当用于扩缩的指标不断波动时，稳定窗口用于限制副本计数的[波动](#flapping)。
自动扩缩算法使用此窗口来推断先前的期望状态并避免对工作负载规模进行不必要的更改。
例如，在以下示例代码段中，为 `scaleDown` 指定了稳定窗口。
```yaml
scaleDown:
stabilizationWindowSeconds: 300
behavior:
scaleDown:
stabilizationWindowSeconds: 300
```
<!--
When the metrics indicate that the target should be scaled down the algorithm looks
into previously computed desired states and uses the highest value from the specified
interval. In above example all desired states from the past 5 minutes will be considered.
into previously computed desired states, and uses the highest value from the specified
interval. In the above example, all desired states from the past 5 minutes will be considered.
-->
当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。
在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。
<!--
This approximates a rolling maximum, and avoids having the scaling algorithm frequently
remove Pods only to trigger recreating an equivalent Pod just moments later.
-->
这近似于滚动最大值，并避免了扩缩算法频繁删除 Pod 而又触发重新创建等效 Pod。
<!--
### Default Behavior
@@ -834,7 +805,7 @@ running replicas will be added every 15 seconds till the HPA reaches its steady
To provide a custom downscale stabilization window of 1 minute, the following
behavior would be added to the HPA:
-->
### 示例：更改缩容稳定窗口
### 示例：更改缩容稳定窗口 {#example-change-downscale-stabilization-window}
将下面的 behavior 配置添加到 HPA 中，可提供一个 1 分钟的自定义缩容稳定窗口：
@@ -850,7 +821,7 @@ behavior:
To limit the rate at which pods are removed by the HPA to 10% per minute, the
following behavior would be added to the HPA:
-->
### 示例：限制缩容速率
### 示例：限制缩容速率 {#example-limit-scale-down-rate}
将下面的 behavior 配置添加到 HPA 中，可限制 Pod 被 HPA 删除速率为每分钟 10%：
@@ -868,8 +839,7 @@ To ensure that no more than 5 Pods are removed per minute, you can add a second
policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means
that the autoscaler chooses the policy that affects the smallest number of Pods:
-->
为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，
并将 `selectPolicy` 设置为最小值。
为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，并将 `selectPolicy` 设置为最小值。
将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略:
```yaml
@@ -892,7 +862,7 @@ The `selectPolicy` value of `Disabled` turns off scaling the given direction.
So to prevent downscaling the following policy would be used:
-->
### 示例：禁用缩容
### 示例：禁用缩容 {#example-disable-scale-down}
`selectPolicy` 的值 `Disabled` 会关闭对给定方向的缩容。
因此使用以下策略，将会阻止缩容：
@@ -902,6 +872,30 @@ behavior:
scaleDown:
selectPolicy: Disabled
```
<!--
## Support for HorizontalPodAutoscaler in kubectl
HorizontalPodAutoscaler, like every API resource, is supported in a standard way by `kubectl`.
You can create a new autoscaler using `kubectl create` command.
You can list autoscalers by `kubectl get hpa` or get detailed description by `kubectl describe hpa`.
Finally, you can delete an autoscaler using `kubectl delete hpa`.
-->
## kubectl 对 HorizontalPodAutoscaler 的支持 {#support-for-horizontalpodautoscaler-in-kubectl}
与每个 API 资源一样，HorizontalPodAutoscaler 都被 `kubectl` 以标准方式支持。
你可以使用 `kubectl create` 命令创建一个新的自动扩缩器。
你可以通过 `kubectl get hpa` 列出自动扩缩器或通过 `kubectl describe hpa` 获取详细描述。
最后，你可以使用 `kubectl delete hpa` 删除自动扩缩器。
<!--
In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object.
For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
will create an autoscaler for ReplicaSet *foo*, with target CPU utilization set to `80%`
and the number of replicas between 2 and 5.
-->
此外，还有一个特殊的 `kubectl autoscale` 命令用于创建 HorizontalPodAutoscaler 对象。
例如，执行 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
将为 ReplicaSet *foo* 创建一个自动扩缩器，目标 CPU 利用率设置为 `80%`，副本数在 2 到 5 之间。
<!--
## Implicit maintenance-mode deactivation
@@ -913,20 +907,102 @@ stops adjusting the target (and sets the `ScalingActive` Condition on itself
to `false`) until you reactivate it by manually adjusting the target's desired
replica count or HPA's minimum replica count.
-->
## 隐式维护状态禁用
## 隐式维护状态禁用 {#implicit-maintenance-mode-deactivation}
你可以在不必更改 HPA 配置的情况下隐式地为某个目标禁用 HPA。
如果此目标的期望副本个数被设置为 0，而 HPA 的最小副本个数大于 0，
则 HPA 会停止调整目标（并将其自身的 `ScalingActive` 状况设置为 `false`），
直到你通过手动调整目标的期望副本个数或 HPA 的最小副本个数来重新激活。
<!--
### Migrating Deployments and StatefulSets to horizontal autoscaling
When an HPA is enabled, it is recommended that the value of `spec.replicas` of
the Deployment and / or StatefulSet be removed from their
{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time
a change to that object is applied, for example via `kubectl apply -f
deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods
to the value of the `spec.replicas` key. This may not be
desired and could be troublesome when an HPA is active.
-->
### 将 Deployment 和 StatefulSet 迁移到水平自动扩缩 {#migrating-deployments-and-statefulsets-to-horizontal-autoscaling}
当启用 HPA 时，建议从它们的{{< glossary_tooltip text="清单" term_id="manifest" >}}中
删除 Deployment 和/或 StatefulSet 的 `spec.replicas` 的值。
如果不这样做，则只要应用对该对象的更改，例如通过 `kubectl apply -f deployment.yaml`，
这将指示 Kubernetes 将当前 Pod 数量扩缩到 `spec.replicas` 键的值。这可能不是所希望的，
并且当 HPA 处于活动状态时可能会很麻烦。
<!--
Keep in mind that the removal of `spec.replicas` may incur a one-time
degradation of Pod counts as the default value of this key is 1 (reference
[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas)).
Upon the update, all Pods except 1 will begin their termination procedures. Any
deployment application afterwards will behave as normal and respect a rolling
update configuration as desired. You can avoid this degradation by choosing one of the following two
methods based on how you are modifying your deployments:
-->
请记住，删除 `spec.replicas` 可能会导致 Pod 计数一次性降级，因为此键的默认值为 1
（参考 [Deployment Replicas](/zh/docs/concepts/workloads/controllers/deployment#replicas)）。
更新后，除 1 之外的所有 Pod 都将开始其终止程序。之后的任何部署应用程序都将正常运行，
并根据需要遵守滚动更新配置。你可以根据修改部署的方式选择以下两种方法之一来避免这种降级：
{{< tabs name="fix_replicas_instructions" >}}
{{% tab name="客户端 apply 操作（默认行为）" %}}
<!--
1. `kubectl apply edit-last-applied deployment/<deployment_name>`
2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl`
applies the update. No changes to Pod counts happen at this step.
3. You can now remove `spec.replicas` from the manifest. If you use source code management,
also commit your changes or take whatever other steps for revising the source code
are appropriate for how you track updates.
4. From here on out you can run `kubectl apply -f deployment.yaml`
-->
1. `kubectl apply edit-last-applied deployment/<Deployment 名称>`
2. 在编辑器中，删除 `spec.replicas`。当你保存并退出编辑器时，`kubectl` 会应用更新。
在此步骤中不会更改 Pod 计数。
3. 你现在可以从清单中删除 `spec.replicas`。如果你使用源代码管理，
还应提交你的更改或采取任何其他步骤来修改源代码，以适应你如何跟踪更新。
4. 从这里开始，你可以运行 `kubectl apply -f deployment.yaml`
{{% /tab %}}
{{% tab name="服务器端 apply 操作" %}}
<!--
When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/)
you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership)
guidelines, which cover this exact use case.
-->
使用[服务器端 Apply](/zh/docs/reference/using-api/server-side-apply/) 机制，
你可以遵循[交出所有权](/zh/docs/reference/using-api/server-side-apply/#transferring-ownership) 说明，
该指南涵盖了这个确切的用例。
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
<!--
* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
If you configure autoscaling in your cluster, you may also want to consider running a
cluster-level autoscaler such as [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler).
For more information on HorizontalPodAutoscaler:
-->
* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md)
* `kubectl autoscale` 命令：[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* 使用示例：[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
如果你在集群中配置自动扩缩，你可能还需要考虑运行集群级别的自动扩缩器，
例如 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)。
有关 HorizontalPodAutoscaler 的更多信息：
<!--
* Read a [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for horizontal pod autoscaling.
* Read documentation for [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* If you would like to write your own custom metrics adapter, check out the
[boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started.
* Read the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/) for HorizontalPodAutoscaler.
-->
* 阅读水平 Pod 自动扩缩的[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
* 阅读 [`kubectl autoscale`](/zh/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 的文档。
* 如果你想编写自己的自定义指标适配器，
请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。
* 阅读 [API 参考](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。
content/zh/docs/tasks/run-application/run-replicated-stateful-application.md
+1 -1
View File
@@ -530,7 +530,7 @@ kubectl get pod mysql-2
<!--
Look for `1/2` in the `READY` column:
-->
在 `READY` 列中查找 ` 1/2` ：
在 `READY` 列中查找 `1/2`：
```
NAME READY STATUS RESTARTS AGE
content/zh/docs/tasks/tools/install-kubectl-linux.md
+1 -1
View File
@@ -237,7 +237,7 @@ sudo yum install -y kubectl
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
<!--
If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
If you are on Ubuntu or another Linux distribution that supports the [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
-->
如果你使用的 Ubuntu 或其他 Linux 发行版，内建支持
[snap](https://snapcraft.io/docs/core/install) 包管理工具，