kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[zh] Sync changes from English site (11)

This commit is contained in:
Qiming Teng 2020-11-23 10:24:40 +08:00
parent fd65678baa
commit aca3e081fe
9 changed files with 114 additions and 547 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

452
content/zh/docs/tasks/administer-cluster/cluster-management.md
View File

@ -1,452 +0,0 @@
---
approvers:
- lavalamp
- thockin
title: 集群管理
content_type: task
---
<!--
This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
upgrading your cluster's
master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
running cluster.
-->
本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的主控节点和工作节点、
执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。
<!-- body -->
<!--
## Creating and configuring a Cluster
To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/setup/) depending on your environment.
-->
## 创建和配置集群
要在一组机器上安装 Kubernetes，请根据你的环境，查阅现有的[入门指南](/zh/docs/setup/)
<!--
## Upgrading a cluster
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG/README.md), as well as the version specific upgrade notes prior to upgrading their clusters.
-->
## 升级集群
集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。
推荐管理员在升级他们的集群前，同时查阅
[发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。
<!--
### Upgrading an Azure Kubernetes Service (AKS) cluster
Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
currently user-initiated and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
-->
### 升级 Azure Kubernetes Service（AKS）集群
Azure Kubernetes Service 支持自服务式的控制面升级和集群节点升级。
升级过程目前是由用户发起的，具体文档参见
[Azure AKS 文档](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)。
<!--
### Upgrading Google Compute Engine clusters
Google Compute Engine Open Source (GCE-OSS) support master upgrades by deleting and
recreating the master, while maintaining the same Persistent Disk (PD) to ensure that data is retained across the
upgrade.
-->
### 升级 Google Compute Engine 集群
Google Compute Engine Open Source（GCE-OSS）通过删除和重建主控节点来支持主控节点升级。
通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。
<!--
Node upgrades for GCE use a [Managed Instance Group](https://cloud.google.com/compute/docs/instance-groups/), each node
is sequentially destroyed and then recreated with new software. Any Pods that are running on that node need to be
controlled by a Replication Controller, or manually re-created after the roll out.
-->
GCE 的 节点升级采用[受控实例组](https://cloud.google.com/compute/docs/instance-groups/)，
每个节点将被顺序删除，然后使用新软件重建。
任何运行在那个节点上的 Pod 需要用副本控制器控制，或者在扩容之后手动重建。
<!--
Upgrades on open source Google Compute Engine (GCE) clusters are controlled by the `cluster/gce/upgrade.sh` script.
Get its usage by running `cluster/gce/upgrade.sh -h`.
For example, to upgrade just your master to a specific version (v1.0.2):
-->
开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。
运行 `cluster/gce/upgrade.sh -h` 获取使用说明。
例如，只将主控节点升级到一个指定的版本（v1.0.2）：
```shell
cluster/gce/upgrade.sh -M v1.0.2
```
<!--
Alternatively, to upgrade your entire cluster to the latest stable release:
-->
或者，将整个集群升级到最新的稳定版本：
```shell
cluster/gce/upgrade.sh release/stable
```
<!--
### Upgrading Google Kubernetes Engine clusters
Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.
-->
### 升级 Google Kubernetes Engine 集群
Google Kubernetes Engine 自动升级主控节点组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。
它还负责主控节点运行的操作系统和其它组件的升级。
<!--
The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).
-->
节点升级过程由用户发起，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)中有相关描述。
<!--
### Upgrading an Amazon EKS Cluster
Amazon EKS cluster's master components can be upgraded by using eksctl, AWS Management Console, or AWS CLI. The process is user-initiated and is described in the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
-->
### 升级 Amazon EKS 集群
Amazon EKS 集群的主控组件可以使用 eksctl、AWS 管理控制台或者 AWS CLI 来升级。
升级过程由用户发起，具体参看
[Amazon EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)。
<!--
### Upgrading an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster
Oracle creates and manages a set of master nodes in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these master nodes to new versions of Kubernetes with zero downtime. These actions are described in the [OKE documentation](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm).
-->
### 升级 Oracle Cloud Infrastructure 上的 Container Engine for Kubernetes (OKE) 集群
Oracle 在 Oracle 控制面替你创建和管理一组主控节点（及相关的 Kubernetes 基础设施，
如 etcd 节点）。你可以在不停机的情况下无缝升级这些主控节点到新的 Kubernetes 版本。
相关的操作可参考
[OKE 文档](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)。
<!--
### Upgrading clusters on other platforms
Different providers, and tools, will manage upgrades differently. It is recommended that you consult their main documentation regarding upgrades.
-->
### 在其他平台上升级集群
不同的供应商和工具管理升级的过程各不相同。建议你查阅它们有关升级的主要文档。
* [kops](https://github.com/kubernetes/kops)
* [kubespray](https://github.com/kubernetes-incubator/kubespray)
* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
* ...
<!--
To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the
[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
-->
要在上面列表中没有提及的平台上升级集群时，请参阅
[版本偏差](/zh/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
页面所讨论的组件升级顺序。
<!--
## Resizing a cluster
If your cluster runs short on resources you can easily add more machines to it if your cluster
is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes.
It can be accomplished by modifying number of instances on
`Compute > Compute Engine > Instance groups > your group > Edit group`
[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
-->
## 调整集群大小
如果集群资源短缺，且集群正运行在
[节点自注册模式](/zh/docs/concepts/architecture/nodes/#self-registration-of-nodes)，
你可以轻松地添加更多的机器。
如果正在使用的是 GCE 或者 Google Kubernetes Engine，添加节点将通过调整管理节点的实例组的大小完成。
在 [Google Cloud 控制台](https://console.developers.google.com) 页面
的 `Compute > Compute Engine > Instance groups > your group > Edit group`
下修改实例数量或使用 gcloud CLI 都可以完成这个任务。
```shell
gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE
```
<!--
The Instance Group will take care of putting appropriate image on new machines and starting them,
while the Kubelet will register its Node with the API server to make it available for scheduling.
If you scale the instance group down, system will randomly choose Nodes to kill.
-->
实例组将负责在新机器上放置恰当的镜像并启动它们。
kubelet 将向 API 服务器注册它的节点以使其可以用于调度。
如果你对实例组进行缩容，系统将会随机选取节点来终止。
<!--
In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.
-->
在其他环境中，你可能需要手动配置机器并告诉 kubelet API 服务器在哪台机器上运行。
<!--
### Cluster autoscaling
If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
pod needs.
-->
### 集群自动伸缩
如果正在使用 GCE 或者 Google Kubernetes Engine，你可以配置你的集群，
使其能够基于 Pod 需求自动重新调整大小。
<!--
As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/),
users can reserve how much CPU and memory is allocated to pods.
This information is used by the Kubernetes scheduler to find a place to run the pod. If there is
no node that has enough free capacity (or doesn't match other pod requirements) then the pod has
to wait until some pods are terminated or a new node is added.
-->
如[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)所述，
用户可以控制预留多少 CPU 和内存来分配给 Pod。
这个信息被 Kubernetes 调度器用来寻找一个运行 Pod 的地方。
如果没有一个节点有足够的空闲容量（或者不能满足 Pod 的其他需求），
这个 Pod 就需要等待某些 Pod 结束，或者一个新的节点被添加。
<!--
Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar
to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods.
-->
集群 Autoscaler 查找不能被调度的 Pod 并检查添加一个新节点（和集群中其它节点类似的）
是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 Pod。
<!--
Cluster autoscaler also scales down the cluster if it notices that one or more nodes are not needed anymore for
an extended period of time (10min but it may change in the future).
-->
如果发现在一段延时时间内（默认 10 分钟，将来有可能改变）某些节点不再需要，
集群 Autoscaler 也会缩小集群。
<!--
Cluster autoscaler is configured per instance group (GCE) or node pool (Google Kubernetes Engine).
-->
集群 Autoscaler 基于每个实例组（GCE）或节点池（Google Kubernetes Engine）来配置。
<!--
If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
To configure cluster autoscaler you have to set three environment variables:
-->
如果你使用 GCE，那么你可以在使用 kube-up.sh 脚本创建集群的时候启用集群自动扩缩。
要想配置集群 Autoscaler，你需要设置三个环境变量：
<!--
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true.
* `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster.
* `KUBE_AUTOSCALER_MAX_NODES` - maximum number of nodes in the cluster.
Example:
-->
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - 如果设置为 true 将启用集群 Autoscaler。
* `KUBE_AUTOSCALER_MIN_NODES` - 集群的最小节点数量。
* `KUBE_AUTOSCALER_MAX_NODES` - 集群的最大节点数量。
示例：
```shell
KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
```
<!--
On Google Kubernetes Engine you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
(which you want to be autoscaled) by passing flags `--enable-autoscaling` `--min-nodes` and `--max-nodes`
to the corresponding `gcloud` commands.
Examples:
-->
在 Google Kubernetes Engine 上，你可以在创建、更新集群或创建一个特别的（你希望自动伸缩的）
节点池时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling`、`--min-nodes` 和
`--max-nodes` 来配置集群 Autoscaler。
示例：
```shell
gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
```
```shell
gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
```
<!--
**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
For more details about how the cluster autoscaler decides whether, when and how
to scale a cluster, please refer to the [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
documentation from the autoscaler project.
-->
**集群 Autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因自行指定的属性
可能不能被传递到相同节点组中的新节点上。**
关于集群 Autoscaler 如何决定是否、合适以及怎样对集群进行缩放的细节，请参考 autoscaler 项目的
[FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
文档。
<!--
## Maintenance on a Node
If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is
brief, then when the Kubelet restarts, it will attempt to restart the pods scheduled to it. If the reboot takes longer
(the default time is 5 minutes, controlled by `-pod-eviction-timeout` on the controller-manager),
then the node controller will terminate the pods that are bound to the unavailable node. If there is a corresponding
replica set (or replication controller), then a new copy of the pod will be started on a different node. So, in the case where all
pods are replicated, upgrades can be done without special coordination, assuming that not all nodes will go down at the same time.
-->
## 维护节点
如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，
kubelet 重启后，将尝试重启调度到节点上的 Pod。如果重启花费较长时间（默认时间为 5 分钟，由
控制器管理器的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 Pod。
如果存在对应的 ReplicaSet（或者 ReplicationController），则将在另一个节点上启动 Pod 的新副本。
所以，如果所有的 Pod 都是多副本的，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊
调整情况下完成。
<!--
If you want more control over the upgrading process, you may use the following workflow:
Use `kubectl drain` to gracefully terminate all pods on the node while marking the node as unschedulable:
-->
如果你希望对升级过程有更多的控制，可以使用下面的工作流程：
使用 `kubectl drain` 体面地结束节点上的所有 Pod 并同时标记节点为不可调度：
```shell
kubectl drain $NODENAME
```
<!--
This keeps new pods from landing on the node while you are trying to get them off.
For pods with a replica set, the pod will be replaced by a new pod which will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
-->
在你试图使节点离线时，这样做将阻止新的 Pod 落到它们上面。
对于有 ReplicaSet 的 Pod 来说，它们将会被新的 Pod 替换并且将被调度到一个新的节点。
此外，如果 Pod 是一个 Service 的一部分，则客户端将被自动重定向到新的 Pod。
<!--
For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
Perform maintenance work on the node.
Make the node schedulable again:
-->
对于没有 ReplicaSet 的 Pod，你需要手动启动 Pod 的新副本，并且
如果它不是 Service 的一部分，你需要手动将客户端重定向到这个 Pod。
在节点上执行维护工作。
重新使节点可调度：
```shell
kubectl uncordon $NODENAME
```
<!--
If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
be created automatically (if you're using a cloud provider that supports
node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
See [Node](/docs/concepts/architecture/nodes/) for more details.
-->
如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建
（只在你使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，
不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。
相关详细信息，请查阅[节点](/zh/docs/concepts/architecture/nodes/)。
<!--
## Advanced Topics
### Upgrading to a different API version
When a new API version is released, you may need to upgrade a cluster to support the new API version (e.g. switching from 'v1' to 'v2' when 'v2' is launched).
-->
## 高级主题
### 升级到不同的 API 版本
当新的 API 版本发布时，你可能需要升级集群支持新的 API 版本
（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。
<!--
This is an infrequent event, but it requires careful management. There is a sequence of steps to upgrade to a new API version.
1. Turn on the new API version.
1. Upgrade the cluster's storage to use the new version.
1. Upgrade all config files. Identify users of the old API version endpoints.
1. Update existing objects in the storage to new version by running `cluster/update-storage-objects.sh`.
1. Turn off the old API version.
-->
这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。
1. 开启新 API 版本
1. 升级集群存储来使用新版本
1. 升级所有配置文件；识别使用旧 API 版本末端的用户
1. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本
1. 关闭旧 API 版本
<!--
### Turn on or off an API version for your cluster
Specific API versions can be turned on or off by passing `-runtime-config=api/<version>` flag while bringing up the API server. For example: to turn off v1 API, pass `--runtime-config=api/v1=false`.
runtime-config also supports 2 special keys: api/all and api/legacy to control all and legacy APIs respectively.
For example, for turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`.
For the purposes of these flags, _legacy_ APIs are those APIs which have been explicitly deprecated (e.g. `v1beta3`).
-->
### 打开或关闭集群的 API 版本
可以在启动 API 服务器时传递 `--runtime-config=api/<version>` 标志来打开或关闭特定的 API 版本。
例如：要关闭 v1 API，请传递 `--runtime-config=api/v1=false`。
`runtime-config` 还支持两个特殊键值：`api/all` 和 `api/legacy`，分别控制全部和遗留 API。
例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。
对于这些标志来说，_遗留（Legacy）_ API 指的是那些被显式废弃的 API（例如 `v1beta3`）。
<!--
### Switching your cluster's storage API version
The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable
by the Kubernetes API server.
-->
### 切换集群存储的 API 版本
存储于磁盘中、用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本表达。
当所支持的 API 改变时，这些对象可能需要使用更新的 API 重写。
重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。
<!--
### Switching your config files to a new API version
You can use `kubectl convert` command to convert config files between different API versions.
-->
### 切换配置文件到新 API 版本
你可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。
```shell
kubectl convert -f pod.yaml --output-version v1
```
<!--
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
-->
更多选项请参考 [`kubectl convert`](/docs/reference/generated/kubectl/kubectl-commands/#convert) 命令用法。

22
content/zh/docs/tasks/administer-cluster/declare-network-policy.md
View File

@ -21,6 +21,8 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do
[NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)
声明网络策略去管理 Pod 之间的通信
{{% thirdparty-content %}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
@ -42,14 +44,6 @@ Make sure you've configured a network provider with network policy support. Ther
* [Romana](/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [Weave 网络](/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
<!--
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
-->
{{< note >}}
以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。
下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的
{{< /note >}}
<!-- steps -->
<!--
@ -74,7 +68,7 @@ Expose the Deployment through a Service called `nginx`.
-->
将此 Deployment 以名为 `nginx` 的 Service 暴露出来：
```console
```shell
kubectl expose deployment nginx --port=80
```
@ -89,7 +83,7 @@ The above commands create a Deployment with an nginx Pod and expose the Deployme
Service 暴露出来。名为 `nginx` 的 Pod 和 Deployment 都位于 `default`
名字空间内。
```console
```shell
kubectl get svc,pod
```
```none
@ -111,7 +105,7 @@ You should be able to access the new `nginx` service from other Pods. To access
你应该可以从其它的 Pod 访问这个新的 `nginx` 服务。
要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
```console
```shell
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
@ -167,7 +161,7 @@ Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file:
使用 kubectl 根据上面的 `nginx-policy.yaml` 文件创建一个 NetworkPolicy：
```console
```shell
kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
```
```none
@ -183,7 +177,7 @@ When you attempt to access the `nginx` Service from a Pod without the correct la
如果你尝试从没有设定正确标签的 Pod 中去访问 `nginx` 服务，请求将会超时：
```console
```shell
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
```
@ -210,7 +204,7 @@ You can create a Pod with the correct labels to see that the request is allowed:
创建一个拥有正确标签的 Pod，你将看到请求是被允许的：
```console
```shell
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
```
<!--

8
content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
View File

@ -252,7 +252,7 @@ The idea is that when a cluster is using nodes that have many cores,
cores, `nodesPerReplica` dominates.
There are other supported scaling patterns. For details, see
[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
-->
注意 `coresPerReplica` 和 `nodesPerReplica` 的值都是整数。
@ -260,7 +260,7 @@ There are other supported scaling patterns. For details, see
当一个集群使用具有较少核心的节点时，由 `nodesPerReplica` 来控制。
其它的扩缩模式也是支持的，详情查看
[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。
[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)。
<!--
## Disable DNS horizontal autoscaling
@ -409,9 +409,9 @@ patterns: *linear* and *ladder*.
<!--
* Read about [Guaranteed Scheduling For Critical Add-On Pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
* Learn more about the
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
-->
* 阅读[为关键插件 Pod 提供的调度保障](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)
* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)
* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)

4
content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
View File

@ -397,9 +397,7 @@ Production likes to run cattle, so let's create some cattle pods.
生产环境需要以放牛的方式运维，让我们创建一些名为 `cattle` 的 Pod。
```shell
kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname
kubectl scale deployment cattle --replicas=5
kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname --replicas=5
kubectl get deployment
```

19
content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
View File

@ -30,7 +30,7 @@ allocated as much CPU as it requests.
Each node in your cluster must have at least 1 CPU.
A few of the steps on this page require you to run the
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
service in your cluster. If you have the metrics-server
running, you can skip those steps.
@ -39,7 +39,8 @@ following command to enable metrics-server:
-->
集群中的每个节点必须至少有 1 个 CPU 可用才能运行本任务中的示例。
本页的一些步骤要求你在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
本页的一些步骤要求你在集群中运行
[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。
如果你正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
@ -354,6 +355,20 @@ to specify a default value for the CPU limit.
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
指定 CPU 限制的默认值。
<!--
## If you specify a CPU limit but do not specify a CPU request
If you specify a CPU limit for a Container but do not specify a CPU request, Kubernetes automatically
assigns a CPU request that matches the limit. Similarly, 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.
-->
## 如果你设置了 CPU 限制但未设置 CPU 请求
如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其
设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置
内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。
<!--
## Motivation for CPU requests and limits

98
content/zh/docs/tasks/configure-pod-container/assign-memory-resource.md
View File

@ -5,11 +5,9 @@ weight: 10
---
<!--
---
title: Assign Memory Resources to Containers and Pods
content_type: task
weight: 10
---
-->
<!-- overview -->
@ -19,34 +17,33 @@ This page shows how to assign a memory *request* and a memory *limit* to a
Container. A Container is guaranteed to have as much memory as it requests,
but is not allowed to use more memory than its limit.
-->
此页面显示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
此页面展示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。
我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 300 MiB of memory.
-->
您集群中的每个节点必须拥有至少 300 MiB 的内存。
你集群中的每个节点必须拥有至少 300 MiB 的内存。
<!--
A few of the steps on this page require you to run the
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
[metrics-server](https://github.com/kubernetes-sigs/metrics-server)
service in your cluster. If you have the metrics-server
running, you can skip those steps.
-->
该页面上的一些步骤要求您在集群中运行 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 服务。如果您已经有在运行中的 metrics-server，则可以跳过这些步骤。
该页面上的一些步骤要求你在集群中运行
[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 服务。
如果你已经有在运行中的 metrics-server，则可以跳过这些步骤。
<!--
If you are running Minikube, run the following command to enable the
metrics-server:
-->
如果您运行的是 Minikube，可以运行下面的命令启用 metrics-server：
如果你运行的是 Minikube，可以运行下面的命令启用 metrics-server：
```shell
minikube addons enable metrics-server
@ -68,13 +65,11 @@ reference to `metrics.k8s.io`.
-->
如果资源指标 API 可用，则输出结果将包含对 `metrics.k8s.io` 的引用信息。
```shell
```
NAME
v1beta1.metrics.k8s.io
```
<!-- steps -->
<!--
@ -106,7 +101,7 @@ for the Pod:
要为容器指定内存请求，请在容器资源清单中包含 `resources：requests` 字段。
同理，要指定内存限制，请包含 `resources：limits`。
在本练习中，您将创建一个拥有一个容器的 Pod。
在本练习中，你将创建一个拥有一个容器的 Pod。
容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。
这是 Pod 的配置文件：
@ -203,8 +198,10 @@ restarted, the kubelet restarts it, as with any other type of runtime failure.
-->
## 超过容器限制的内存
当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。
如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超出其限制的内存，则终止容器。
当节点拥有足够的可用内存时，容器可以使用其请求的内存。
但是，容器不允许使用超过其限制的内存。
如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。
如果容器继续消耗超出其限制的内存，则终止容器。
如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。
<!--
@ -212,7 +209,7 @@ In this exercise, you create a Pod that attempts to allocate more memory than it
Here is the configuration file for a Pod that has one Container with a
memory request of 50 MiB and a memory limit of 100 MiB:
-->
在本练习中，您将创建一个 Pod，尝试分配超出其限制的内存。
在本练习中，你将创建一个 Pod，尝试分配超出其限制的内存。
这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB：
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
@ -223,7 +220,7 @@ will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limi
Create the Pod:
-->
在配置文件的 `args` 部分中，您可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
在配置文件的 `args` 部分中，你可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。
创建 Pod：
@ -277,7 +274,8 @@ lastState:
The Container in this exercise can be restarted, so the kubelet restarts it. Repeat
this command several times to see that the Container is repeatedly killed and restarted:
-->
本练习中的容器可以被重启，所以 kubelet 会重启它。多次运行下面的命令，可以看到容器在反复的被杀死和重启：
本练习中的容器可以被重启，所以 kubelet 会重启它。
多次运行下面的命令，可以看到容器在反复的被杀死和重启：
```shell
kubectl get pod memory-demo-2 --namespace=mem-example
@ -371,8 +369,8 @@ of any Node in your cluster.
-->
Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。
在本练习中，你将创建一个 Pod，其内存请求超过了您集群中的任意一个节点所拥有的内存。
这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了您集群中任何节点的容量。
在本练习中，你将创建一个 Pod，其内存请求超过了你集群中的任意一个节点所拥有的内存。
这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了你集群中任何节点的容量。
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
@ -397,7 +395,8 @@ kubectl get pod memory-demo-3 --namespace=mem-example
<!--
The output shows that the Pod status is PENDING. That is, the Pod is not scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
-->
输出结果显示：Pod 处于 PENDING 状态。这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
输出结果显示：Pod 处于 PENDING 状态。
这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态：
```
kubectl get pod memory-demo-3 --namespace=mem-example
@ -436,7 +435,9 @@ For example, the following represent approximately the same value:
-->
## 内存单位
内存资源的基本单位是字节（byte）。您可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值：
内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为
纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。
例如，下面是一些近似相同的值：
```shell
128974848, 129e6, 129M , 123Mi
@ -469,12 +470,13 @@ Container is automatically assigned the default limit. Cluster administrators ca
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
to specify a default value for the memory limit.
-->
* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。
此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，
进而可能导致该节点调用 OOM Killer。
此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
* 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。
集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
来指定默认的内存限制。
集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
来指定默认的内存限制。
<!--
## Motivation for memory requests and limits
@ -486,7 +488,9 @@ scheduled. By having a memory limit that is greater than the memory request, you
-->
## 内存请求和限制的目的
通过为集群中运行的容器配置内存请求和限制，您可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，您可以更好地安排 Pod 调度。通过让内存限制大于内存请求，您可以完成两件事：
通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。
通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。
通过让内存限制大于内存请求，你可以完成两件事：
<!--
* The Pod can have bursts of activity where it makes use of memory that happens to be available.
@ -508,34 +512,46 @@ Delete your namespace. This deletes all the Pods that you created for this task:
kubectl delete namespace mem-example
```
## {{% heading "whatsnext" %}}
<!--
### For app developers
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者扩展阅读
* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员扩展阅读
* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
* [配置命名空间的最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [配置命名空间的最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [配置命名空间下 Pod 总数](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [配置 API 对象配额](/zh/docs/tasks/administer-cluster/quota-api-object/)

9
content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -284,7 +284,7 @@ affect the HTTP liveness probe.
A third type of liveness probe uses a TCP Socket. With this configuration, the
kubelet will attempt to open a socket to your container on the specified port.
If it can establish a connection, the container is considered healthy, if it
can’t it is considered a failure.
can't it is considered a failure.
-->
## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe}
@ -419,7 +419,7 @@ Sometimes, applications are temporarily unable to serve traffic.
For example, an application might need to load large data or configuration
files during startup, or depend on external services after startup.
In such cases, you don't want to kill the application,
but you don’t want to send it requests either. Kubernetes provides
but you don't want to send it requests either. Kubernetes provides
readiness probes to detect and mitigate these situations. A pod with containers
reporting that they are not ready does not receive traffic through Kubernetes
Services.
@ -534,7 +534,7 @@ in the range 1 to 65535.
<!--
For an HTTP probe, the kubelet sends an HTTP request to the specified path and
port to perform the check. The kubelet sends the probe to the pod’s IP address,
port to perform the check. The kubelet sends the probe to the pod's IP address,
unless the address is overridden by the optional `host` field in `httpGet`. If
`scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the
certificate verification. In most scenarios, you do not want to set the `host` field.
@ -565,7 +565,7 @@ to resolve it.
* Learn more about
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-->
* 进一步了解[容器探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
### Reference
@ -580,4 +580,3 @@ to resolve it.
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)

15
content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
View File

@ -55,7 +55,7 @@ Init 容器将共享卷挂载到了 `/work-dir` 目录，应用容器将共享
Init 容器执行完下面的命令就终止：
```shell
wget -O /work-dir/index.html http://kubernetes.io
wget -O /work-dir/index.html http://info.cern.ch
```
<!--
@ -118,16 +118,13 @@ The output shows that nginx is serving the web page that was written by the init
结果表明 nginx 正在为 Init 容器编写的 web 页面服务：
```
<!Doctype html>
<html id="home">
<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>
<head>
...
"url": "http://kubernetes.io/"}</script>
</head>
<body>
<h1>http://info.cern.ch - home of the first website</h1>
...
<p>Kubernetes is open source giving you the freedom to take advantage ...</p>
<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
...
```

34
content/zh/docs/tasks/tls/certificate-rotation.md
View File

@ -16,7 +16,7 @@ This page shows how to enable and configure certificate rotation for the kubelet
-->
本文展示如何在 kubelet 中启用并配置证书轮换。
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
## {{% heading "prerequisites" %}}
@ -58,23 +58,21 @@ Kubernetes API 间的连接认证。
The `kubelet` process accepts an argument `--rotate-certificates` that controls
if the kubelet will automatically request a new certificate as the expiration of
the certificate currently in use approaches. Since certificate rotation is a
beta feature, the feature flag must also be enabled with
`--feature-gates=RotateKubeletClientCertificate=true`.
the certificate currently in use approaches.
-->
## 启用客户端证书轮换
`kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的证书即将到期时，
是否会自动申请新的证书。 由于证书轮换是 beta 特性，必须通过参数
`--feature-gates=RotateKubeletClientCertificate=true` 进行启用。
`kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的
证书即将到期时，是否会自动申请新的证书。
<!--
The `kube-controller-manager` process accepts an argument
`--experimental-cluster-signing-duration` that controls how long certificates
will be issued for.
`--cluster-signing-duration` (`--experimental-cluster-signing-duration` prior to 1.19)
that controls how long certificates will be issued for.
-->
`kube-controller-manager` 进程接收
`--experimental-cluster-signing-duration` 参数，该参数控制证书签发的有效期限。
`kube-controller-manager` 进程接收 `--cluster-signing-duration` 参数
（在 1.19 版本之前为 `--experimental-cluster-signing-duration`），用来
控制签发证书的有效期限。
<!--
## Understanding the certificate rotation configuration
@ -86,10 +84,11 @@ status of certificate signing requests using:
-->
## 理解证书轮换配置
当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet 会使用其初始证书连接到
Kubernetes API ，并发送证书签名的请求。 可以通过以下方式查看证书签名请求的状态：
当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet
会使用其初始证书连接到 Kubernetes API ，并发送证书签名的请求。
可以通过以下方式查看证书签名请求的状态：
```sh
```shell
kubectl get csr
```
@ -99,19 +98,20 @@ status of `Pending`. If the certificate signing requests meets specific
criteria, it will be auto approved by the controller manager, then it will have
a status of `Approved`. Next, the controller manager will sign a certificate,
issued for the duration specified by the
`--experimental-cluster-signing-duration` parameter, and the signed certificate
`--cluster-signing-duration` parameter, and the signed certificate
will be attached to the certificate signing requests.
-->
最初，来自节点上 kubelet 的证书签名请求处于 `Pending` 状态。 如果证书签名请求满足特定条件，
控制器管理器会自动批准，此时请求会处于 `Approved` 状态。 接下来，控制器管理器会签署证书，
证书的有效期限由 `--experimental-cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。
证书的有效期限由 `--cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。
<!--
The kubelet will retrieve the signed certificate from the Kubernetes API and
write that to disk, in the location specified by `--cert-dir`. Then the kubelet
will use the new certificate to connect to the Kubernetes API.
-->
Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir` 参数指定。
Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir`
参数指定。
然后 kubelet 会使用新的证书连接到 Kubernetes API。
<!--