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

Merge pull request #27727 from tengqm/zh-sync-setup-2 

[zh] Resync setup section (2)
pull/27761/head
Kubernetes Prow Robot 2021-04-27 18:50:50 -07:00 committed by GitHub
parent 1493c20caa 544d3c2fb7
commit c8ce9801a5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 595 additions and 744 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/zh/docs/reference/setup-tools/_index.md
View File

@ -2,3 +2,8 @@
title: 安装工具
weight: 50
---
<!--
title: Setup tools
weight: 50
-->

726
content/zh/docs/setup/best-practices/multiple-zones.md
View File

@ -1,5 +1,5 @@
---
title: 运行于多区环境
title: 运行于多可用区环境
weight: 10
content_type: concept
---
@ -16,591 +16,267 @@ content_type: concept
<!-- overview -->
<!--
This page describes how to run a cluster in multiple zones.
This page describes running a cluster across multiple zones.
-->
本页描述如何在多个区（Zone）中运行集群。
本页描述如何跨多个区（Zone）中运行集群。
<!-- body -->
<!--
## Introduction
## Background
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
Full Cluster Federation allows combining separate
Kubernetes clusters running in different regions or cloud providers
(or on-premises data centers). However, many
users simply want to run a more available Kubernetes cluster in multiple zones
of their single cloud provider, and this is what the multizone support in 1.2 allows
(this previously went by the nickname "Ubernetes Lite").
Kubernetes is designed so that a single Kubernetes cluster can run
across multiple failure zones, typically where these zones fit within
a logical grouping called a _region_. Major cloud providers define a region
as a set of failure zones (also called _availability zones_) that provide
a consistent set of features: within a region, each zone offers the same
APIs and services.
Typical cloud architectures aim to minimize the chance that a failure in
one zone also impairs services in another zone.
-->
## 介绍
## 背景
Kubernetes 1.2 添加了跨多个失效区（Failure Zone）运行同一集群的能力
（GCE 把它们称作“区（Zones）”，AWS 把它们称作“可用区（Availability Zones）”，
这里我们用“区（Zones）”指代它们）。
此能力是更广泛的集群联邦（Cluster Federation）特性的一个轻量级版本。
集群联邦之前有一个昵称
["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。
完全的集群联邦可以将运行在多个区域（Region）或云供应商（或本地数据中心）的多个
Kubernetes 集群组合起来。
不过，很多用户仅仅是希望在同一云厂商平台的多个区域运行一个可用性更好的集群，
而这恰恰是 1.2 引入的多区支持所带来的特性
（此特性之前有一个昵称 “Ubernetes Lite”）。
Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行，
通常这些去位于某个称作 _区域（region）_ 逻辑分组中。
主要的云提供商都将区域定义为一组失效区的集合（也称作 _可用区（Availability Zones）_），
能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。
典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。
<!--
Multizone support is deliberately limited: a single Kubernetes cluster can run
in multiple zones, but only within the same region (and cloud provider). Only
GCE and AWS are currently supported automatically (though it is easy to
add similar support for other clouds or even bare metal, by simply arranging
for the appropriate labels to be added to nodes and volumes).
## Control plane behavior
All [control plane components](/docs/concepts/overview/components/#control-plane-components)
support running as a pool of interchangeable resources, replicated per
component.
-->
多区支持有意实现的有局限性：可以在跨多个区域运行同一 Kubernetes 集群，但只能
在同一区域（Region）和云厂商平台。目前仅自动支持 GCE 和 AWS，尽管为其他云平台
或裸金属平台添加支持页相对容易，只需要确保节点和卷上添加合适的标签即可。
## 控制面行为 {#control-plane-behavior}
所有的[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)
都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。
<!--
## Functionality
When nodes are started, the kubelet automatically adds labels to them with
zone information.
When you deploy a cluster control plane, place replicas of
control plane components across multiple failure zones. If availability is
an important concern, select at least three failure zones and replicate
each individual control plane component (API server, scheduler, etcd,
cluster controller manager) across at least three failure zones.
If you are running a cloud controller manager then you should
also replicate this across all the failure zones you selected.
-->
## 功能
当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。
如果可用性是一个很重要的指标，应该选择至少三个失效区，并将每个
控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本，
跨至少三个失效区来部署。如果你在运行云控制器管理器，则也应该将
该组件跨所选的三个失效区来部署。
节点启动时，`kubelet` 自动向其上添加区信息标签。
<!--
Kubernetes will automatically spread the pods in a replication controller
or service across nodes in a single-zone cluster (to reduce the impact of
failures.) With multiple-zone clusters, this spreading behavior is
extended across zones (to reduce the impact of zone failures.) (This is
achieved via `SelectorSpreadPriority`). This is a best-effort
placement, and so if the zones in your cluster are heterogeneous
(e.g. different numbers of nodes, different types of nodes, or
different pod resource requirements), this might prevent perfectly
even spreading of your pods across zones. If desired, you can use
homogeneous zones (same number and types of nodes) to reduce the
probability of unequal spreading.
-->
在单区（Single-Zone）集群中， Kubernetes 会自动将副本控制器或服务中的 Pod
分布到不同节点，以降低节点失效的影响。
在多区集群中，这一分布负载的行为被扩展到跨区分布，以降低区失效的影响，
跨区分布的能力是通过 `SelectorSpreadPriority` 实现的。此放置策略亦仅仅是
尽力而为，所以如果你的集群所跨区是异质的（例如，节点个数不同、节点类型
不同或者 Pod 资源需求不同），放置策略都可能无法完美地跨区完成 Pod 的
均衡分布。如果需要，你可以使用同质区（节点个数和类型相同）以降低不均衡
分布的可能性。
<!--
When persistent volumes are created, the `PersistentVolumeLabel`
admission controller automatically adds zone labels to them. The scheduler (via the
`VolumeZonePredicate` predicate) will then ensure that pods that claim a
given volume are only placed into the same zone as that volume, as volumes
cannot be attached across zones.
-->
持久卷被创建时，`PersistentVolumeLabel` 准入控制器会自动为其添加区标签。
调度器使用 `VolumeZonePredicate` 断言确保申领某给定卷的 Pod 只会被放到
该卷所在的区。这是因为卷不可以跨区挂载。
<!--
## Limitations
There are some important limitations of the multizone support:
* We assume that the different zones are located close to each other in the
network, so we don't perform any zone-aware routing. In particular, traffic
that goes via services might cross zones (even if some pods backing that service
exist in the same zone as the client), and this may incur additional latency and cost.
-->
## 局限性
多区支持有一些很重要的局限性：
* 我们假定不同的区之间在网络上彼此距离很近，所以我们不执行可感知区的路由。
尤其是，即使某些负责提供该服务的 Pod 与客户端位于同一区，通过服务末端
进入的流量可能会跨区，因而会导致一些额外的延迟和开销。
<!--
* Volume zone-affinity will only work with a `PersistentVolume`, and will not
work if you directly specify an EBS volume in the pod spec (for example).
* Clusters cannot span clouds or regions (this functionality will require full
federation support).
-->
* 卷与区之间的亲和性仅适用于 PV 持久卷。例如，如果你直接在 Pod 规约中指定某 EBS
卷，这种亲和性支持就无法工作。
* 集群无法跨多个云平台或者地理区域运行。这类功能需要完整的联邦特性支持。
<!--
* Although your nodes are in multiple zones, kube-up currently builds
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
-->
* 尽管你的节点位于多个区中，`kube-up` 脚本目前默认只能构造一个主控节点。
尽管服务是高可用的，能够忍受失去某个区的问题，控制面位于某一个区中。
希望运行高可用控制面的用户应该遵照
[高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
中的指令构建。
<!--
### Volume limitations
The following limitations are addressed with
[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with
pod affinity or anti-affinity policies.
-->
### 卷局限性
以下局限性通过
[拓扑感知的卷绑定](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)解决：
* 使用动态卷供应时，StatefulSet 卷的跨区分布目前与 Pod
亲和性和反亲和性策略不兼容。
<!--
* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
may not provide a uniform distribution of storage across zones.
* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
needs to be configured for a specific single zone, or the PVs need to be
statically provisioned in a specific zone. Another workaround is to use a
StatefulSet, which will ensure that all the volumes for a replica are
provisioned in the same zone.
-->
* 如果 StatefulSet 的名字中包含连字符（"-"），卷的跨区分布可能无法实现存储的
跨区同一分布。
* 当在一个 Deployment 或 Pod 规约中指定多个 PVC 申领时，则需要为某特定区域
配置 StorageClass，或者在某一特定区域中需要静态供应 PV 卷。
另一种解决方案是使用 StatefulSet，确保给定副本的所有卷都从同一区中供应。
<!--
## Walkthrough
We're now going to walk through setting up and using a multi-zone
cluster on both GCE & AWS. To do so, you bring up a full cluster
(specifying `MULTIZONE=true`), and then you add nodes in additional zones
by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
-->
## 演练
我们现在准备对在 GCE 和 AWS 上配置和使用多区集群进行演练。为了完成此演练，
你需要设置 `MULTIZONE=true` 来启动一个完整的集群，之后指定
`KUBE_USE_EXISTING_MASTER=true` 并再次运行 `kube-up` 添加其他区中的节点。
<!--
### Bringing up your cluster
Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a.
-->
### 建立集群
和往常一样创建集群，不过需要设置 MULTIZONE，以便告诉集群需要管理多个区。
这里我们在 `us-central1-a` 创建节点。
GCE:
```shell
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
```
AWS:
```shell
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
```
<!--
This step brings up a cluster as normal, still running in a single zone
(but `MULTIZONE=true` has enabled multi-zone capabilities).
-->
这一步骤和往常一样启动一个集群，不过尽管 `MULTIZONE=true`
标志已经启用了多区功能特性支持，集群仍然运行在一个区内。
<!--
### Nodes are labeled
View the nodes; you can see that they are labeled with zone information.
They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The
labels are `topology.kubernetes.io/region` for the region,
and `topology.kubernetes.io/zone` for the zone:
-->
### 节点已被打标签
查看节点，你会看到节点上已经有了区信息标签。
目前这些节点都在 `us-central1-a` (GCE) 或 `us-west-2a` (AWS)。
对于区域（Region），标签为 `topology.kubernetes.io/region`，
对于区（Zone），标签为 `topology.kubernetes.io/zone`：
```shell
kubectl get nodes --show-labels
```
<!--
The output is similar to this:
-->
输出类似于：
```
NAME STATUS ROLES AGE VERSION LABELS
kubernetes-master Ready,SchedulingDisabled <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-87j9 Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q Ready <none> 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
```
<!--
### Add more nodes in a second zone
Let's add another set of nodes to the existing cluster, reusing the
existing master, running in a different zone (us-central1-b or us-west-2b).
We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
kube-up will not create a new master, but will reuse one that was previously
created instead.
-->
### 添加第二个区中的节点
让我们向现有集群中添加另外一组节点，复用现有的主控节点，但运行在不同的区
（`us-central1-b` 或 `us-west-2b`）。
我们再次运行 `kube-up`，不过设置 `KUBE_USE_EXISTING_MASTER=true`。
`kube-up` 不会创建新的主控节点，而会复用之前创建的主控节点。
GCE:
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
```
<!--
On AWS we also need to specify the network CIDR for the additional
subnet, along with the master internal IP address:
-->
在 AWS 上，我们还需要为额外的子网指定网络 CIDR，以及主控节点的内部 IP 地址：
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
```
<!--
View the nodes again; 3 more nodes should have launched and be tagged
in us-central1-b:
-->
再次查看节点，你会看到新启动了三个节点并且其标签表明运行在 `us-central1-b` 区：
```shell
kubectl get nodes --show-labels
```
<!--
The output is similar to this:
-->
输出类似于：
```
NAME STATUS ROLES AGE VERSION LABELS
kubernetes-master Ready,SchedulingDisabled <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-281d Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-87j9 Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv Ready <none> 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q Ready <none> 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
kubernetes-minion-pp2f Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
kubernetes-minion-wf8i Ready <none> 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
```
<!--
### Volume affinity
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
-->
### 卷亲和性
通过动态卷供应创建一个卷（只有 PV 持久卷支持区亲和性）：
```bash
kubectl apply -f - <<EOF
{
"apiVersion": "v1",
"kind": "PersistentVolumeClaim",
"metadata": {
"name": "claim1",
"annotations": {
"volume.alpha.kubernetes.io/storage-class": "foo"
}
},
"spec": {
"accessModes": [
"ReadWriteOnce"
],
"resources": {
"requests": {
"storage": "5Gi"
}
}
}
}
EOF
```
<!--
For version 1.3+ Kubernetes will distribute dynamic PV claims across
the configured zones. For version 1.2, dynamic persistent volumes were
always created in the zone of the cluster master
(here us-central1-a / us-west-2a); that issue
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
was addressed in 1.3+.
-->
{{< note >}}
Kubernetes 1.3 及以上版本会将动态 PV 申领散布到所配置的各个区。
在 1.2 版本中，动态持久卷总是在集群主控节点所在的区
（这里的 `us-central1-a` 或 `us-west-2a`），
对应的 Issue ([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
在 1.3 及以上版本中已经解决。
<!--
Kubernetes does not provide cross-zone resilience for the API server
endpoints. You can use various techniques to improve availability for
the cluster API server, including DNS round-robin, SRV records, or
a third-party load balancing solution with health checking.
-->
Kubernetes 并不会为 API 服务器端点提供跨失效区的弹性。
你可以为集群 API 服务器使用多种技术来提升其可用性，包括使用
DNS 轮转、SRV 记录或者带健康检查的第三方负载均衡解决方案等等。
{{< /note >}}
<!--
Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
-->
现在我们来验证 Kubernetes 自动为 PV 打上了所在区或区域的标签：
## Node behavior
```shell
kubectl get pv --show-labels
```
Kubernetes automatically spreads the Pods for
workload resources (such as {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
or {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})
across different nodes in a cluster. This spreading helps
reduce the impact of failures.
-->
## 节点行为 {#node-behavior}
Kubernetes 自动为负载资源（如{{< glossary_tooltip text="Deployment" term_id="deployment" >}}
或 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})）
跨集群中不同节点来部署其 Pods。
这种分布逻辑有助于降低失效带来的影响。
<!--
The output is similar to this:
When nodes start up, the kubelet on each node automatically adds
{{< glossary_tooltip text="labels" term_id="label" >}} to the Node object
that represents that specific kubelet in the Kubernetes API.
These labels can include
[zone information](/docs/reference/labels-annotations-taints/#topologykubernetesiozone).
-->
输出类似于：
```
NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS
pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a
```
节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象
添加 {{< glossary_tooltip text="标签" term_id="label" >}}。
这些标签可能包含[区信息](/zh/docs/reference/labels-annotations-taints/#topologykubernetesiozone)。
<!--
So now we will create a pod that uses the persistent volume claim.
Because GCE PDs / AWS EBS volumes cannot be attached across zones,
this means that this pod can only be created in the same zone as the volume:
If your cluster spans multiple zones or regions, you can use node labels
in conjunction with
[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
to control how Pods are spread across your cluster among fault domains:
regions, zones, and even specific nodes.
These hints enable the
{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} to place
Pods for better expected availability, reducing the risk that a correlated
failure affects your whole workload.
-->
现在我们将创建一个使用 PVC 申领的 Pod。
由于 GCE PD 或 AWS EBS 卷都不能跨区挂载，这意味着 Pod 只能创建在卷所在的区：
```yaml
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: claim1
EOF
```
如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合
[Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是
地理区域、可用区甚至是特定节点。
这些提示信息使得{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}
能够更好地分布 Pods，以实现更好的可用性，降低因为某种失效给整个工作负载
带来的风险。
<!--
Note that the pod was automatically created in the same zone as the volume, as
cross-zone attachments are not generally permitted by cloud providers:
For example, you can set a constraint to make sure that the
3 replicas of a StatefulSet are all running in different zones to each
other, whenever that is feasible. You can define this declaratively
without explicitly defining which availability zones are in use for
each workload.
-->
注意 Pod 自动创建在卷所在的区，因为云平台提供商一般不允许跨区挂接存储卷。
```shell
kubectl describe pod mypod | grep Node
```
```
Node: kubernetes-minion-9vlv/10.240.0.5
```
例如，你可以设置一种约束，确保某个 StatefulSet 中的三个副本都运行在
不同的可用区中，只要其他条件允许。你可以通过声明的方式来定义这种约束，
而不需要显式指定每个工作负载使用哪些可用区。
<!--
And check node labels:
### Distributing nodes across zones
Kubernetes' core does not create nodes for you; you need to do that yourself,
or use a tool such as the [Cluster API](https://cluster-api.sigs.k8s.io/) to
manage nodes on your behalf.
Using tools such as the Cluster API you can define sets of machines to run as
worker nodes for your cluster across multiple failure domains, and rules to
automatically heal the cluster in case of whole-zone service disruption.
-->
检查节点标签：
### 跨多个区分布节点 {#distributing-nodes-across-zones}
```shell
kubectl get node kubernetes-minion-9vlv --show-labels
```
```
NAME STATUS AGE VERSION LABELS
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
```
Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用
类似 [Cluster API](https://cluster-api.sigs.k8s.io/) 这类工具来替你管理节点。
<!--
### Pods are spread across zones
Pods in a replication controller or service are automatically spread
across zones. First, let's launch more nodes in a third zone:
Using tools such as the Cluster API you can define sets of machines to run as
worker nodes for your cluster across multiple failure domains, and rules to
automatically heal the cluster in case of whole-zone service disruption.
-->
### Pod 跨区分布
同一副本控制器或服务的多个 Pod 会自动完成跨区分布。
首先，我们现在第三个区启动一些节点：
GCE:
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
```
AWS:
```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
```
使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群
工作节点的机器，以及当整个区的服务出现中断时如何自动治愈集群的策略。
<!--
Verify that you now have nodes in 3 zones:
-->
验证你现在有来自三个区的节点：
## Manual zone assignment for Pods
```shell
kubectl get nodes --show-labels
```
You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
to Pods that you create, as well as to Pod templates in workload resources
such as Deployment, StatefulSet, or Job.
-->
## 为 Pods 手动指定区
<!--
Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
to Pods that you create, as well as to Pod templates in workload resources
such as Deployment, StatefulSet, or Job.
-->
创建 `guestbook-go` 示例，其中包含副本个数为 3 的 RC，运行一个简单的 Web 应用：
```shell
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
```
你可以应用[节点选择算符约束](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
到你所创建的 Pods 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源
中的 Pod 模板设置此类约束。
<!--
The pods should be spread across all 3 zones:
## Storage access for zones
When persistent volumes are created, the `PersistentVolumeLabel`
[admission controller](/docs/reference/access-authn-authz/admission-controllers/)
automatically adds zone labels to any PersistentVolumes that are linked to a specific
zone. The {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} then ensures,
through its `NoVolumeZoneConflict` predicate, that pods which claim a given PersistentVolume
are only placed into the same zone as that volume.
-->
Pod 应该跨三个区分布：
## 跨区的存储访问
```shell
kubectl describe pod -l app=guestbook | grep Node
```
```
Node: kubernetes-minion-9vlv/10.240.0.5
Node: kubernetes-minion-281d/10.240.0.8
Node: kubernetes-minion-olsh/10.240.0.11
```
```shell
kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
```
```
NAME STATUS ROLES AGE VERSION LABELS
kubernetes-minion-9vlv Ready <none> 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-281d Ready <none> 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-olsh Ready <none> 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
```
当创建持久卷时，`PersistentVolumeLabel`
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
会自动向那些链接到特定区的 PersistentVolume 添加区标签。
{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}通过其
`NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pods 只会
被调度到该卷所在的可用区。
<!--
Load-balancers span all zones in a cluster; the guestbook-go example
includes an example load-balanced service:
You can specify a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
for PersistentVolumeClaims that specifies the failure domains (zones) that the
storage in that class may use.
To learn about configuring a StorageClass that is aware of failure domains or zones,
see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies).
-->
负载均衡器也会跨集群中的所有区；`guestbook-go` 示例中包含了一个负载均衡
服务的例子：
```shell
kubectl describe service guestbook | grep LoadBalancer.Ingress
```
你可以为 PersistentVolumeClaim 指定{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
以设置该类中的存储可以使用的失效域（区）。
要了解如何配置能够感知失效域或区的 StorageClass，请参阅
[可用的拓扑逻辑](/zh/docs/concepts/storage/storage-classes/#allowed-topologies)。
<!--
The output is similar to this:
-->
输出类似于：
## Networking
```
LoadBalancer Ingress: 130.211.126.21
```
By itself, Kubernetes does not include zone-aware networking. You can use a
[network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
to configure cluster networking, and that network solution might have zone-specific
elements. For example, if your cloud provider supports Services with
`type=LoadBalancer`, the load balancer might only send traffic to Pods running in the
same zone as the load balancer element processing a given connection.
Check your cloud provider's documentation for details.
-->
## 网络 {#networking}
Kubernetes 自身不提供与可用区相关的联网配置。
你可以使用[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。
例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service，则负载均衡器
可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。
请查阅云提供商的文档了解详细信息。
<!--
Set the above IP:
For custom or on-premises deployments, similar considerations apply.
{{< glossary_tooltip text="Service" term_id="service" >}} and
{{< glossary_tooltip text="Ingress" term_id="ingress" >}} behavior, including handling
of different failure zones, does vary depending on exactly how your cluster is set up.
-->
设置上面的 IP 地址：
```shell
export IP=130.211.126.21
```
对于自定义的或本地集群部署，也可以考虑这些因素
{{< glossary_tooltip text="Service" term_id="service" >}}
{{< glossary_tooltip text="Ingress" term_id="ingress" >}} 的行为，
包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。
<!--
Explore with curl via IP:
## Fault recovery
When you set up your cluster, you might also need to consider whether and how
your setup can restore service if all the failure zones in a region go
off-line at the same time. For example, do you rely on there being at least
one node able to run Pods in a zone?
Make sure that any cluster-critical repair work does not rely
on there being at least one healthy node in your cluster. For example: if all nodes
are unhealthy, you might need to run a repair Job with a special
{{< glossary_tooltip text="toleration" term_id="toleration" >}} so that the repair
can complete enough to bring at least one node into service.
Kubernetes doesn't come with an answer for this challenge; however, it's
something to consider.
-->
使用 curl 访问该 IP：
## 失效恢复 {#fault-recovery}
在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何
恢复服务。例如，你是否要求在某个区中至少有一个节点能够运行 Pod？
请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。
例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job，
该 Job 要设置特定的{{< glossary_tooltip text="容忍度" term_id="toleration" >}}
以便修复操作能够至少将一个节点恢复为可用状态。
```shell
curl -s http://${IP}:3000/env | grep HOSTNAME
```
Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。
## {{% heading "whatsnext" %}}
<!--
The output is similar to this:
To learn how the scheduler places Pods in a cluster, honoring the configured constraints,
visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/).
-->
输出类似于：
```
"HOSTNAME": "guestbook-44sep",
```
<!--
Again, explore multiple times:
-->
如果多次尝试该命令：
```shell
(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq
```
<!--
The output is similar to this:
-->
输出类似于：
```shell
"HOSTNAME": "guestbook-44sep",
"HOSTNAME": "guestbook-hum5n",
"HOSTNAME": "guestbook-ppm40",
```
<!--
The load balancer correctly targets all the pods, even though they are in multiple zones.
-->
负载均衡器正确地选择不同的 Pod，即使它们跨了多个区。
<!--
### Shutting down the cluster
When you're done, clean up:
-->
### 停止集群
当完成以上工作之后，清理任务现场：
GCE:
```shell
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
```
AWS:
```shell
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
```
要了解调度器如何在集群中放置 Pods 并遵从所配置的约束，可参阅
[调度与驱逐](/zh/docs/concepts/scheduling-eviction/)。

47
content/zh/docs/setup/learning-environment/_index.md
View File

@ -2,3 +2,50 @@
title: 学习环境
weight: 20
---
<!--
{{/* There is a Netlify redirect from this page to /docs/tasks/tools/ */}}
{{/* This page content only exists to provide a navigation stub */}}
{{/* and to protect in case that redirect is one day removed. */}}
{{/* If you're localizing this page, you only need to copy the front matter */}}
{{/* and add a redirect into "/static/_redirects", for YOUR localization. */}}
-->
## kind
<!--
[`kind`](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
your local computer. This tool requires that you have
[Docker](https://docs.docker.com/get-docker/) installed and configured.
The kind [Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) page
shows you what you need to do to get up and running with kind.
-->
你可以使用 [`kind`](https://kind.sigs.k8s.io/docs/) 来在本地计算机上运行 Kubernetes。
此工具要求你已经安装并配置了 [Docker](https://docs.docker.com/get-docker/)。
kind [快速入门](https://kind.sigs.k8s.io/docs/user/quick-start/)页面
为你展示了如何开始使用 kind 的相关信息。
## minikube
<!--
Like `kind`, [`minikube`](https://minikube.sigs.k8s.io/) is a tool that lets you run Kubernetes
locally. `minikube` runs a single-node Kubernetes cluster on your personal
computer (including Windows, macOS and Linux PCs) so that you can try out
Kubernetes, or for daily development work.
You can follow the official
[Get Started!](https://minikube.sigs.k8s.io/docs/start/) guide if your focus is
on getting the tool installed.
-->
与 `kind` 类似，[`minikube`](https://minikube.sigs.k8s.io/) 是一个允许你在
本地运行 Kubernetes 的工具。`minikube` 在你的个人计算机上运行一个单节点的
Kubernetes 集群（包括 Windows、macOS 和 Linux PC 机），这样你可以尝试
Kubernetes 或者执行每天的开发工作。
如果你所关注的是如何安装该工具，可以查阅官方的
[Get Started!](https://minikube.sigs.k8s.io/docs/start/)
文档。

177
content/zh/docs/setup/production-environment/container-runtimes.md
View File

@ -20,7 +20,8 @@ You need to install a
into each node in the cluster so that Pods can run there. This page outlines
what is involved and describes related tasks for setting up nodes.
-->
你需要在集群内每个节点上安装一个{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}
你需要在集群内每个节点上安装一个
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}
以使 Pod 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。
<!-- body -->
@ -59,7 +60,8 @@ systemd means that there will be two different cgroup managers.
-->
控制组用来约束分配给进程的资源。
当某个 Linux 系统发行版使用 [systemd](https://www.freedesktop.org/wiki/Software/systemd/) 作为其初始化系统时，初始化进程会生成并使用一个 root 控制组 (`cgroup`), 并充当 cgroup 管理器。
当某个 Linux 系统发行版使用 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)
作为其初始化系统时，初始化进程会生成并使用一个 root 控制组 (`cgroup`), 并充当 cgroup 管理器。
Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup。
你也可以配置容器运行时和 kubelet 使用 `cgroupfs`。
连同 systemd 一起使用 `cgroupfs` 意味着将有两个不同的 cgroup 管理器。
@ -72,9 +74,12 @@ In the field, people have reported cases where nodes that are configured to use
for the kubelet and Docker, but `systemd` for the rest of the processes, become unstable under
resource pressure.
-->
单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用中的资源具有更一致的视图。
单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用
中的资源具有更一致的视图。
当有两个管理器共存于一个系统中时，最终将对这些资源产生两种视图。
在此领域人们已经报告过一些案例，某些节点配置让 kubelet 和 docker 使用 `cgroupfs`，而节点上运行的其余进程则使用 systemd; 这类节点在资源压力下会变得不稳定。
在此领域人们已经报告过一些案例，某些节点配置让 kubelet 和 docker 使用
`cgroupfs`，而节点上运行的其余进程则使用 systemd; 这类节点在资源压力下
会变得不稳定。
<!--
Changing the settings such that your container runtime and kubelet use `systemd` as the cgroup driver
@ -95,8 +100,11 @@ configuration, or reinstall it using automation.
{{< /caution >}}
-->
注意：更改已加入集群的节点的 cgroup 驱动是一项敏感的操作。
如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。重启 kubelet 也可能无法解决此类问题。
如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点，或者使用自动化方案来重新安装。
如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用
别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。
重启 kubelet 也可能无法解决此类问题。
如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点，
或者使用自动化方案来重新安装。
<!--
### Migrating to the `systemd` driver in kubeadm managed clusters
@ -104,7 +112,7 @@ configuration, or reinstall it using automation.
### 将 kubeadm 托管的集群迁移到 `systemd` 驱动
<!--
Follow this [Migration guide](docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver)
Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver)
if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.
-->
如果你想迁移到现有 kubeadm 托管集群中的 `systemd` cgroup 驱动程序，
@ -125,26 +133,6 @@ This section contains the necessary steps to use containerd as CRI runtime.
Use the following commands to install Containerd on your system:
Install and configure prerequisites:
```shell
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# Setup required sysctl params, these persist across reboots.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
```
-->
本节包含使用 containerd 作为 CRI 运行时的必要步骤。
@ -183,7 +171,10 @@ Install containerd:
<!--
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).
-->
1. 从官方Docker仓库安装 `containerd.io` 软件包。可以在 [安装 Docker 引擎](https://docs.docker.com/engine/install/#server) 中找到有关为各自的 Linux 发行版设置 Docker 存储库和安装 `containerd.io` 软件包的说明。
1. 从官方Docker仓库安装 `containerd.io` 软件包。可以在
[安装 Docker 引擎](https://docs.docker.com/engine/install/#server)
中找到有关为各自的 Linux 发行版设置 Docker 存储库和安装 `containerd.io`
软件包的说明。
<!--
2. Configure containerd:
@ -206,10 +197,12 @@ Install 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:
-->
启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$ Version=1.4.3`），然后运行以下命令：
启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$ Version=1.4.3`），
然后运行以下命令：
<!--
1. Download containerd:
@ -230,18 +223,17 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# Review the configuration. Depending on setup you may want to adjust:
# - the sandbox_image (Kubernetes pause image)
# - cni bin_dir and conf_dir locations
# 检查配置。根据你的配置，可能需要调整：
# - sandbox_image (Kubernetes pause 镜像)
# - cni bin_dir 和 conf_dir 位置
Get-Content config.toml
# (Optional - but highly recommended) Exclude containerd from Windows Defender Scans
# (可选 - 不过强烈建议) 禁止 Windows Defender 扫描 containerd
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
```
<!--
3. Start containerd:
-->
3. 启动 containerd:
```powershell
@ -260,15 +252,7 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version
<!--
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
```
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
```
-->
结合 `runc` 使用 `systemd` cgroup 驱动，在 `/etc/containerd/config.toml` 中设置
```
@ -292,7 +276,7 @@ When using kubeadm, manually configure the
[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
-->
当使用 kubeadm 时，请手动配置
[kubelet 的 cgroup 驱动](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
[kubelet 的 cgroup 驱动](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
### CRI-O
@ -300,47 +284,29 @@ When using kubeadm, manually configure the
This section contains the necessary steps to install CRI-O as a container runtime.
Use the following commands to install CRI-O on your system:
{{< note >}}
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
{{< /note >}}
Install and configure prerequisites:
```shell
# Create the .conf file to load the modules at bootup
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# Set up required sysctl params, these persist across reboots.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system
```
-->
本节包含安装 CRI-O 作为容器运行时的必要步骤。
使用以下命令在系统中安装 CRI-O：
提示：CRI-O 的主要以及次要版本必须与 Kubernetes 的主要和次要版本相匹配。
更多信息请查阅 [CRI-O 兼容性列表](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)。
{{< note >}}
<!--
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
-->
CRI-O 的主要以及次要版本必须与 Kubernetes 的主要和次要版本相匹配。
更多信息请查阅
[CRI-O 兼容性列表](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)。
{{< /note >}}
安装以及配置的先决条件：
<!--
Install and configure prerequisites:
-->
安装并配置前置环境：
```shell
# 创建 .conf 文件，以便在系统启动时加载内核模块
# 创建 .conf 文件以在启动时加载模块
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
br_netfilter
@ -349,7 +315,7 @@ EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 设置必需的 sysctl 参数，这些参数在重新启动后仍然存在。
# 配置 sysctl 参数，这些配置在重启之后仍然起作用
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
@ -379,7 +345,7 @@ To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
-->
-->
在下列操作系统上安装 CRI-O, 使用下表中合适的值设置环境变量 `OS`:
| 操作系统 | `$OS` |
@ -395,6 +361,7 @@ Then run
<br />
然后执行
```shell
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
@ -532,10 +499,6 @@ sudo dnf module list cri-o
CRI-O does not support pinning to specific releases on Fedora.
Then run
```shell
sudo dnf module enable cri-o:$VERSION
sudo dnf install cri-o
```
-->
将 `$VERSION` 设置为与你的 Kubernetes 相匹配的 CRI-O 版本。
例如，如果要安装 CRI-O 1.20，请设置 `VERSION=1.20`。
@ -544,9 +507,11 @@ sudo dnf install cri-o
```shell
sudo dnf module list cri-o
```
CRI-O 不支持在 Fedora 上固定到特定的版本。
然后执行
```shell
sudo dnf module enable cri-o:$VERSION
sudo dnf install cri-o --now
@ -557,24 +522,32 @@ sudo dnf install cri-o --now
<!--
Start CRI-O:
-->
启动 CRI-O：
```shell
sudo systemctl daemon-reload
sudo systemctl enable crio --no
```
<!--
Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md)
for more information.
-->
参阅[CRI-O 安装指南](https://github.com/cri-o/cri-o/blob/master/install.md)
了解进一步的详细信息。
<!--
#### cgroup driver
<!--
CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs`
cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in
configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
-->
默认情况下，CRI-O 使用 systemd cgroup 驱动程序。切换到`
`cgroupfs`
cgroup 驱动程序，或者编辑 `/ etc / crio / crio.conf` 或放置一个插件
-->
#### cgroup 驱动
默认情况下，CRI-O 使用 systemd cgroup 驱动程序。要切换到 `cgroupfs`
驱动程序，或者编辑 `/ etc / crio / crio.conf` 或放置一个插件
在 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 中的配置，例如：
```toml
@ -582,27 +555,31 @@ cgroup 驱动程序，或者编辑 `/ etc / crio / crio.conf` 或放置一个插
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
```
<!--
Please also note the changed `conmon_cgroup`, which has to be set to the value
`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
in sync.
-->
另请注意更改后的 `conmon_cgroup` ，必须将其设置为
`pod`将 CRI-O 与 `cgroupfs` 一起使用时。通常有必要保持
kubelet 的 cgroup 驱动程序配置（通常透过 kubeadm 完成）和CRI-O 同步中。
另请注意更改后的 `conmon_cgroup`，将 CRI-O 与 `cgroupfs` 一起使用时，
必须将其设置为 `pod`。通常有必要保持 kubelet 的 cgroup 驱动程序配置
（通常透过 kubeadm 完成）和 CRI-O 一致。
### Docker
<!--
1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
-->
1. 在每个节点上，根据[安装 Docker 引擎](https://docs.docker.com/engine/install/#server) 为你的 Linux 发行版安装 Docker。
你可以在此文件中找到最新的经过验证的 Docker 版本[依赖关系](https://git.k8s.io/kubernetes/build/dependencies.yaml)。
1. 在每个节点上，根据[安装 Docker 引擎](https://docs.docker.com/engine/install/#server)
为你的 Linux 发行版安装 Docker。
你可以在此文件中找到最新的经过验证的 Docker 版本
[依赖关系](https://git.k8s.io/kubernetes/build/dependencies.yaml)。
<!--
2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
-->
2. 配置 Docker 守护程序，尤其是使用 systemd 来管理容器的cgroup。
2. 配置 Docker 守护程序，尤其是使用 systemd 来管理容器的 cgroup。
```shell
sudo mkdir /etc/docker
@ -621,14 +598,16 @@ kubelet 的 cgroup 驱动程序配置（通常透过 kubeadm 完成）和CRI-O
{{< note >}}
<!--
`overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above.
-->
对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。
-->
对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL
或 CentOS 的系统，`overlay2`是首选的存储驱动程序。
{{< /note >}}
<!--
3. Restart Docker and enable on boot:
-->
3. 重新启动 Docker 并在启动时启用：
```shell
sudo systemctl enable docker
sudo systemctl daemon-reload
@ -641,9 +620,9 @@ For more information refer to
- [Configure the Docker daemon](https://docs.docker.com/config/daemon/)
- [Control Docker with systemd](https://docs.docker.com/config/daemon/systemd/)
-->
有关更多信息，请参阅
- [配置 Docker 守护程序](https://docs.docker.com/config/daemon/)
- [使用 systemd 控制 Docker](https://docs.docker.com/config/daemon/systemd/)
{{< /note >}}
有关更多信息，请参阅
- [配置 Docker 守护程序](https://docs.docker.com/config/daemon/)
- [使用 systemd 控制 Docker](https://docs.docker.com/config/daemon/systemd/)

214
content/zh/docs/setup/production-environment/tools/kops.md
View File

@ -19,9 +19,9 @@ It uses a tool called [`kops`](https://github.com/kubernetes/kops).
本篇使用了一个名为 [`kops`](https://github.com/kubernetes/kops) 的工具。
<!--
kops is an opinionated provisioning system:
kops is an automated provisioning system:
-->
kops 是一个自用的供应系统：
kops 是一个自动化的制备系统：
<!--
* Fully automated installation
@ -33,80 +33,170 @@ kops 是一个自用的供应系统：
-->
* 全自动安装流程
* 使用 DNS 识别集群
* 自我修复：一切都在自动扩展组中运行
* 自我修复：一切都在自动扩缩组中运行
* 支持多种操作系统（如 Debian、Ubuntu 16.04、CentOS、RHEL、Amazon Linux 和 CoreOS） - 参考 [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
* 支持高可用 - 参考 [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
* 可以直接提供或者生成 terraform 清单 - 参考 [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
<!--
If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
a building block. kops builds on the kubeadm work.
-->
如果你有不同的观点，你可能更喜欢使用 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/)
作为构建工具来构建自己的集群。kops 建立在 kubeadm 工作的基础上。
## {{% heading "prerequisites" %}}
<!-- body -->
<!--
* You must have [kubectl](/docs/tasks/tools/) installed.
* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.
* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).
-->
* 你必须安装 [kubectl](/zh/docs/tasks/tools/)。
* 你必须安装[安装](https://github.com/kubernetes/kops#installing) `kops`
到 64 位的（AMD64 和 Intel 64）设备架构上。
* 你必须拥有一个 [AWS 账户](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)，
生成 [IAM 秘钥](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
并[配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration)
该秘钥。IAM 用户需要[足够的权限许可](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user)。
<!-- steps -->
<!--
## Creating a cluster
### (1/5) Install kops
#### Requirements
#### Installation
You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also convenient to build from source):
-->
## 创建集群
### (1/5) 安装 kops
#### 前提条件
你必须安装 [kubectl](/zh/docs/tasks/tools/install-kubectl/) 才能使 kops 工作。
<!--
#### Installation
Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
-->
#### 安装
从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops（从源代码构建也很容易）：
从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops
（从源代码构建也很方便）：
{{< tabs name="kops_installation" >}}
{{% tab name="macOS" %}}
<!--
On macOS:
# you can also install using Homebrew
Download the latest release with the command:
-->
在 macOS 上：
使用下面的命令下载最新发布版本：
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
```
<!--
To download a specific version, replace the following portion of the command with the specific kops version.
-->
要下载特定版本，使用特定的 kops 版本替换下面命令中的部分：
```shell
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
```
<!--
For example, to download kops version v1.20.0 type:
-->
例如，要下载 kops v1.20.0，输入：
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64
```
<!--
Make the kops binary executable.
-->
令 kops 二进制文件可执行：
```shell
curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
chmod +x kops-darwin-amd64
mv kops-darwin-amd64 /usr/local/bin/kops
# 你也可以使用 Homebrew 安装 kops
```
<!--
Move the kops binary in to your PATH.
-->
将 kops 二进制文件移到你的 PATH 下：
```shell
sudo mv kops-darwin-amd64 /usr/local/bin/kops
```
你也可以使用 [Homebrew](https://brew.sh/) 安装 kops：
```shell
brew update && brew install kops
```
{{% /tab %}}
{{% tab name="Linux" %}}
<!--
Download the latest release with the command:
-->
使用命令下载最新发布版本：
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
```
<!--
To download a specific version of kops, replace the following portion of the command with the specific kops version.
-->
要下载 kops 的特定版本，用特定的 kops 版本替换下面命令中的部分：
```shell
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
```
<!--
For example, to download kops version v1.20.0 type:
-->
例如，要下载 kops v1.20 版本，输入：
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64
```
<!--
Make the kops binary executable
-->
令 kops 二进制文件可执行：
```shell
chmod +x kops-linux-amd64
```
<!--
Move the kops binary in to your PATH.
-->
将 kops 二进制文件移到 PATH 下：
```shell
sudo mv kops-linux-amd64 /usr/local/bin/kops
```
你也可以使用 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)
来安装 kops：
```shell
brew update && brew install kops
```
<!--
On Linux:
-->
在 Linux 上：
```shell
wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
chmod +x kops-linux-amd64
mv kops-linux-amd64 /usr/local/bin/kops
```
{{% /tab %}}
{{< /tabs >}}
<!--
### (2/5) Create a route53 domain for your cluster
kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server
kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
from clients.
-->
### (2/5) 为你的集群创建一个 route53 域名
kops 在集群内部都使用 DNS 进行发现操作，因此你可以从客户端访问 kubernetes API 服务器。
kops 在集群内部和外部都使用 DNS 进行发现操作，这样你可以从客户端访问
kubernetes API 服务器。
<!--
kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will
@ -120,8 +210,8 @@ kops 对集群名称有明显的要求：它应该是有效的 DNS 名称。这
You can, and probably should, use subdomains to divide your clusters. As our example we will use
`useast1.dev.example.com`. The API server endpoint will then be `api.useast1.dev.example.com`.
-->
你应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。
然后，API 服务器端点域名将为 `api.useast1.dev.example.com`。
你可以，或许应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。
这样，API 服务器端点域名将为 `api.useast1.dev.example.com`。
<!--
A Route53 hosted zone can serve subdomains. Your hosted zone could be `useast1.dev.example.com`,
@ -154,10 +244,10 @@ records at your domain registrar (e.g. `example.com` would need to be configured
例如，你需要在购买 `example.com` 的地方配置 `example.com`。
<!--
This step is easy to mess up (it is the #1 cause of problems!) You can double-check that
Verify your route53 domain setup (it is the #1 cause of problems!). You can double-check that
your cluster is configured correctly if you have the dig tool by running:
-->
这一步很容易搞砸（这是问题的第一大原因！）
检查你的 route53 域已经被正确设置（这是导致问题的最常见原因！）。
如果你安装了 dig 工具，则可以通过运行以下步骤再次检查集群是否配置正确：
```shell
@ -187,8 +277,10 @@ administer the same clusters - this is much easier than passing around kubecfg f
to the S3 bucket will have administrative access to all your clusters, so you don't want to share it beyond
the operations team.
-->
多个集群可以使用同一 S3 存储桶，并且你可以在管理同一集群的同事之间共享一个 S3 存储桶 - 这比传递 kubecfg 文件容易得多。
但是有权访问 S3 存储桶的任何人都将拥有对所有集群的管理访问权限，因此你不想在运营团队之外共享它。
多个集群可以使用同一 S3 存储桶，并且你可以在管理同一集群的同事之间共享一个
S3 存储桶 - 这比传递 kubecfg 文件容易得多。
但是有权访问 S3 存储桶的任何人都将拥有对所有集群的管理访问权限，
因此你不想在运营团队之外共享它。
<!--
So typically you have one S3 bucket for each ops team (and often the name will correspond
@ -200,7 +292,8 @@ to the name of the hosted zone above!)
In our example, we chose `dev.example.com` as our hosted zone, so let's pick `clusters.dev.example.com` as
the S3 bucket name.
-->
在我们的示例中，我们选择 `dev.example.com` 作为托管区域，因此让我们选择 `clusters.dev.example.com` 作为 S3 存储桶名称。
在我们的示例中，我们选择 `dev.example.com` 作为托管区域，因此我们选择
`clusters.dev.example.com` 作为 S3 存储桶名称。
<!--
* Export `AWS_PROFILE` (if you need to select a profile for the AWS CLI to work)
@ -210,17 +303,18 @@ the S3 bucket name.
-->
* 导出 `AWS_PROFILE` 文件（如果你需要选择一个配置文件用来使 AWS CLI 正常工作）
* 使用 `aws s3 mb s3://clusters.dev.example.com` 创建 S3 存储桶
* 你可以进行 `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 操作，然后 kops 将默认使用此位置。
* 你可以进行 `export KOPS_STATE_STORE=s3://clusters.dev.example.com` 操作，
然后 kops 将默认使用此位置。
我们建议将其放入你的 bash profile 文件或类似文件中。
<!--
### (4/5) Build your cluster configuration
Run "kops create cluster" to create your cluster configuration:
Run `kops create cluster` to create your cluster configuration:
-->
### (4/5) 建立你的集群配置
运行 "kops create cluster" 以创建你的集群配置：
运行 `kops create cluster` 以创建你的集群配置：
`kops create cluster --zones=us-east-1c useast1.dev.example.com`
@ -229,7 +323,8 @@ kops will create the configuration for your cluster. Note that it _only_ create
not actually create the cloud resources - you'll do that in the next step with a `kops update cluster`. This
give you an opportunity to review the configuration or change it.
-->
kops 将为你的集群创建配置。请注意，它_仅_创建配置，实际上并没有创建云资源 - 你将在下一步中使用 `kops update cluster` 进行配置。
kops 将为你的集群创建配置。请注意，它_仅_创建配置，实际上并没有创建云资源 -
你将在下一步中使用 `kops update cluster` 进行配置。
这使你有机会查看配置或进行更改。
<!--
@ -312,18 +407,6 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
* 删除集群：`kops delete cluster useast1.dev.example.com --yes`
<!--
## Feedback
-->
## 反馈
<!--
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
-->
* Slack 频道: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
## {{% heading "whatsnext" %}}
<!--
@ -332,7 +415,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
-->
* 了解有关 Kubernetes 的[概念](/zh/docs/concepts/) 和
[`kubectl`](/zh/docs/reference/kubectl/overview/) 的更多信息。
[`kubectl`](/zh/docs/reference/kubectl/overview/) 有关的更多信息。
* 了解 `kops` [高级用法](https://github.com/kubernetes/kops)。
* 请参阅 `kops` [文档](https://github.com/kubernetes/kops) 获取教程、最佳做法和高级配置选项。
* 请参阅 `kops` [文档](https://github.com/kubernetes/kops) 获取教程、
最佳做法和高级配置选项。

64
content/zh/docs/setup/production-environment/tools/kubespray.md
View File

@ -14,12 +14,17 @@ weight: 30
<!--
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
-->
此快速入门有助于使用 [Kubespray](https://github.com/kubernetes-sigs/kubespray) 安装在 GCE、Azure、OpenStack、AWS、vSphere、Packet（裸机）、Oracle Cloud Infrastructure（实验性）或 Baremetal 上托管的 Kubernetes 集群。
此快速入门有助于使用 [Kubespray](https://github.com/kubernetes-sigs/kubespray)
安装在 GCE、Azure、OpenStack、AWS、vSphere、Packet（裸机）、Oracle Cloud
Infrastructure（实验性）或 Baremetal 上托管的 Kubernetes 集群。
<!--
Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
-->
Kubespray 是一个由 [Ansible](https://docs.ansible.com/) playbooks、[清单（inventory）](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md)、供应工具和通用 OS/Kubernetes 集群配置管理任务的领域知识组成的。 Kubespray 提供：
Kubespray 是一个由 [Ansible](https://docs.ansible.com/) playbooks、
[清单（inventory）](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md)、
制备工具和通用 OS/Kubernetes 集群配置管理任务的领域知识组成的。
Kubespray 提供：
<!--
* a highly available cluster
@ -50,17 +55,18 @@ Kubespray 是一个由 [Ansible](https://docs.ansible.com/) playbooks、[清单
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
[kubeadm](/docs/reference/setup-tools/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
-->
要选择最适合你的用例的工具，请阅读[此比较](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)以
[kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 和 [kops](/zh/docs/setup/production-environment/tools/kops/) 。
要选择最适合你的用例的工具，请阅读
[kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 和
[kops](/zh/docs/setup/production-environment/tools/kops/) 之间的
[这份比较](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)。
。
<!-- body -->
<!--
## Creating a cluster
### (1/5) Meet the underlay requirements
-->
## 创建集群
### （1/5）满足下层设施要求
@ -81,11 +87,14 @@ Provision servers with the following [requirements](https://github.com/kubernete
-->
* 在将运行 Ansible 命令的计算机上安装 Ansible v2.9 和 python-netaddr
* **运行 Ansible Playbook 需要 Jinja 2.11（或更高版本）**
* 目标服务器必须有权访问 Internet 才能拉取 Docker 镜像。否则，需要其他配置（[请参见离线环境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)）
* 目标服务器必须有权访问 Internet 才能拉取 Docker 镜像。否则，
需要其他配置（[请参见离线环境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)）
* 目标服务器配置为允许 IPv4 转发
* **你的 SSH 密钥必须复制**到清单中的所有服务器部分
* 防火墙不受管理，你将需要按照以前的方式实施自己的规则。为了避免在部署过程中出现任何问题，你应该禁用防火墙
* 如果从非 root 用户帐户运行 kubespray，则应在目标服务器中配置正确的特权升级方法。然后应指定“ansible_become” 标志或命令参数 “--become” 或 “-b”
* 防火墙不受管理，你将需要按照以前的方式实施自己的规则。
为了避免在部署过程中出现任何问题，你应该禁用防火墙
* 如果从非 root 用户帐户运行 kubespray，则应在目标服务器中配置正确的特权升级方法。
然后应指定“ansible_become” 标志或命令参数 “--become” 或 “-b”
<!--
Kubespray provides the following utilities to help provision your environment:
@ -105,16 +114,18 @@ Kubespray 提供以下实用程序来帮助你设置环境：
<!--
### (2/5) Compose an inventory file
After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
### (3/5) Plan your cluster deployment
Kubespray provides the ability to customize many aspects of the deployment:
-->
### （2/5）编写清单文件
设置服务器后，请创建一个 [Ansible 的清单文件](https://docs.ansible.com/ansible/intro_inventory.html)。你可以手动执行此操作，也可以通过动态清单脚本执行此操作。有关更多信息，请参阅“[建立你自己的清单](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)”。
设置服务器后，请创建一个
[Ansible 的清单文件](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html)。
你可以手动执行此操作，也可以通过动态清单脚本执行此操作。有关更多信息，请参阅
“[建立你自己的清单](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)”。
### （3/5）规划集群部署
@ -146,11 +157,12 @@ Kubespray 能够自定义部署的许多方面：
* 证书生成方式
<!--
Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
-->
可以修改[变量文件](https://docs.ansible.com/ansible/playbooks_variables.html)以进行 Kubespray 定制。
如果你刚刚开始使用 Kubespray，请考虑使用 Kubespray 默认设置来部署你的集群并探索 Kubernetes 。
可以修改[变量文件](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)
以进行 Kubespray 定制。
如果你刚刚开始使用 Kubespray，请考虑使用 Kubespray 默认设置来部署你的集群
并探索 Kubernetes 。
<!--
### (4/5) Deploy a Cluster
@ -158,12 +170,12 @@ Next, deploy your cluster:
Cluster deployment using [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
-->
### （4/5）部署集群
接下来，部署你的集群：
使用 [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment) 进行j集群部署。
使用 [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment)
进行集群部署。
```shell
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
@ -172,7 +184,9 @@ ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
<!--
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md) for best results.
-->
大型部署（超过 100 个节点）可能需要[特定的调整](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)，以获得最佳效果。
大型部署（超过 100 个节点）可能需要
[特定的调整](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)，
以获得最佳效果。
<!--
### (5/5) Verify the deployment
@ -181,7 +195,8 @@ Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [
-->
### （5/5）验证部署
Kubespray 提供了一种使用 [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md)
Kubespray 提供了一种使用
[Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md)
验证 Pod 间连接和 DNS 解析的方法。
Netchecker 确保 netchecker-agents pod 可以解析。
DNS 请求并在默认名称空间内对每个请求执行 ping 操作。
@ -241,16 +256,17 @@ When running the reset playbook, be sure not to accidentally target your product
-->
## 反馈
* Slack 频道：[#kubespray](https://kubernetes.slack.com/messages/kubespray/)（你可以在[此处](https://slack.k8s.io/)获得邀请）
* Slack 频道：[#kubespray](https://kubernetes.slack.com/messages/kubespray/)
（你可以在[此处](https://slack.k8s.io/)获得邀请）
* [GitHub 问题](https://github.com/kubernetes-sigs/kubespray/issues)
<!--
## {{% heading "whatsnext" %}}
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
-->
## {{% heading "whatsnext" %}}
查看有关 Kubespray 的[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)的计划工作。
查看有关 Kubespray 的
[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)
的计划工作。

106
content/zh/docs/setup/release/version-skew-policy.md
View File

@ -27,12 +27,14 @@ For more information, see [Kubernetes Release Versioning](https://github.com/kub
-->
Kubernetes 版本号格式为 **x.y.z**，其中 **x** 为大版本号，**y** 为小版本号，**z** 为补丁版本号。
版本号格式遵循 [Semantic Versioning](https://semver.org/) 规则。
更多信息，请参阅 [Kubernetes 发布版本](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
更多信息，请参阅
[Kubernetes 发布版本](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
<!--
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
-->
Kubernetes 项目会维护最近的三个小版本分支（{{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}）。
Kubernetes 项目会维护最近的三个小版本分支（{{< skew latestVersion >}},
{{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}）。
Kubernetes 1.19 及更高的版本将获得大约1年的补丁支持。
Kubernetes 1.18 及更早的版本获得大约9个月的补丁支持。
@ -45,9 +47,13 @@ The [Release Managers](https://git.k8s.io/sig-release/release-managers.md) group
For more information, see the Kubernetes [patch releases](https://git.k8s.io/sig-release/releases/patch-releases.md) page.
-->
一些 bug 修复，包括安全修复，取决于其严重性和可行性，有可能会反向合并到这三个发布分支。
补丁版本会[定期](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)或根据需要从这些分支中发布。
最终是否发布是由[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)来决定的。
如需了解更多信息，请查看 Kubernetes [补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
补丁版本会[定期](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)
或根据需要从这些分支中发布。
最终是否发布是由
[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)
来决定的。
如需了解更多信息，请查看 Kubernetes
[补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
<!--
## Supported version skew
@ -72,7 +78,8 @@ Example:
* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
-->
* 最新的 `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
* 则受支持的 `kube-apiserver` 版本号包括 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
* 其他受支持的 `kube-apiserver` 版本号包括 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**
### kubelet
@ -90,7 +97,8 @@ Example:
例如：
* `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
* 受支持的的 `kubelet` 版本将包括 **{{< skew latestVersion >}}**、**{{< skew prevMinorVersion >}}** 和 **{{< skew oldestMinorVersion >}}**
* 受支持的的 `kubelet` 版本将包括 **{{< skew latestVersion >}}**、
**{{< skew prevMinorVersion >}}** 和 **{{< skew oldestMinorVersion >}}**
<!--
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
@ -107,9 +115,12 @@ Example:
-->
例如：
* 如果 `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
* `kubelet` 的受支持版本将是 **{{< skew prevMinorVersion >}}** 和 **{{< skew oldestMinorVersion >}}**
（**{{< skew latestVersion >}}** 不再支持，因为它比 **{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新）
* 如果 `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**
* `kubelet` 的受支持版本将是 **{{< skew prevMinorVersion >}}** 和
**{{< skew oldestMinorVersion >}}**
（**{{< skew latestVersion >}}** 不再支持，因为它比
**{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新）
<!--
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
@ -119,8 +130,10 @@ Example:
<!--
`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades).
-->
`kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本不能高于 `kube-apiserver` 版本号。
最好它们的版本号与 `kube-apiserver` 保持一致，但允许比 `kube-apiserver` 低一个小版本（为了支持在线升级）。
`kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本不能高于 `kube-apiserver` 版本号。
最好它们的版本号与 `kube-apiserver` 保持一致，但允许比 `kube-apiserver`
低一个小版本（为了支持在线升级）。
<!--
Example:
@ -131,14 +144,17 @@ Example:
例如：
* 如果 `kube-apiserver` 版本号为 **{{< skew latestVersion >}}**
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
<!--
If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
-->
{{< note >}}
如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
但 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本可用范围会相应的减小。
如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟
任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer），
但 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本可用范围会相应的减小。
{{< /note >}}
<!--
@ -150,10 +166,14 @@ Example:
-->
例如：
* `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 可以通过 load balancer 与所有的 `kube-apiserver` 通信
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 可选版本为 **{{< skew prevMinorVersion >}}**
（**{{< skew latestVersion >}}** 不再支持，因为它比 **{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新）
* `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}** 版本
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
可以通过 load balancer 与所有的 `kube-apiserver` 通信
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
可选版本为 **{{< skew prevMinorVersion >}}**
（**{{< skew latestVersion >}}** 不再支持，因为它比 **{{< skew prevMinorVersion >}}**
版本的 `kube-apiserver` 更新）
### kubectl
@ -171,7 +191,8 @@ Example:
例如：
* 如果 `kube-apiserver` 当前是 **{{< skew latestVersion >}}** 版本
* `kubectl` 则支持 **{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
* `kubectl` 则支持 **{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}**
和 **{{< skew prevMinorVersion >}}**
<!--
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
@ -188,8 +209,11 @@ Example:
-->
例如：
* `kube-apiserver` 多个实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
* `kubectl` 可选的版本为 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**（其他版本不再支持，因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本）
* `kube-apiserver` 多个实例同时存在 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**
* `kubectl` 可选的版本为 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**（其他版本不再支持，
因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本）
<!--
## Supported component upgrade order
@ -201,7 +225,8 @@ The supported version skew between components has implications on the order in w
This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
-->
组件之间支持的版本偏差会影响组件升级的顺序。
本节描述组件从版本 **{{< skew prevMinorVersion >}}** 到 **{{< skew latestVersion >}}** 的升级次序。
本节描述组件从版本 **{{< skew prevMinorVersion >}}** 到 **{{< skew latestVersion >}}**
的升级次序。
### kube-apiserver
@ -220,9 +245,14 @@ Pre-requisites:
* The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **{{< skew latestVersion >}}**
-->
* 单实例集群中，`kube-apiserver` 实例版本号须是 **{{< skew prevMinorVersion >}}**
* 高可用（HA）集群中，所有的 `kube-apiserver` 实例版本号必须是 **{{< skew prevMinorVersion >}}** 或 **{{< skew latestVersion >}}**（确保满足最新和最旧的实例小版本号相差不大于1）
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本号必须为 **{{< skew prevMinorVersion >}}**（确保不高于 API server 的版本，且版本号相差不大于1）
* `kubelet` 实例版本号必须是 **{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**（确保版本号不高于 API server，且版本号相差不大于2）
* 高可用（HA）集群中，所有的 `kube-apiserver` 实例版本号必须是
**{{< skew prevMinorVersion >}}** 或 **{{< skew latestVersion >}}**
（确保满足最新和最旧的实例小版本号相差不大于1）
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本号必须为 **{{< skew prevMinorVersion >}}**
（确保不高于 API server 的版本，且版本号相差不大于1）
* `kubelet` 实例版本号必须是 **{{< skew prevMinorVersion >}}** 或
**{{< skew oldestMinorVersion >}}**（确保版本号不高于 API server，且版本号相差不大于2）
* 注册的 admission 插件必须能够处理新的 `kube-apiserver` 实例发送过来的数据：
* `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration` 对象必须升级到可以处理
**{{< skew latestVersion >}}** 版本新加的 REST 资源（或使用 1.15 版本提供的
@ -258,12 +288,14 @@ Pre-requisites:
-->
前提条件：
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** （HA 集群中，所有的`kube-apiserver` 实例必须在组件升级前完成升级）
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}**
（HA 集群中，所有的`kube-apiserver` 实例必须在组件升级前完成升级）
<!--
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew latestVersion >}}**
-->
升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 到 **{{< skew latestVersion >}}**
升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
到 **{{< skew latestVersion >}}**
### kubelet
@ -278,15 +310,26 @@ Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or the
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** 版本
`kubelet` 可以升级到 **{{< skew latestVersion >}}**（或者停留在 **{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**）
`kubelet` 可以升级到 **{{< skew latestVersion >}}**（或者停留在
**{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**）
{{< note >}}
<!--
Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node.
In-place minor version `kubelet` upgrades are not supported.
-->
在对 `kubelet` 执行次版本升级时，先[腾空](/zh/docs/tasks/administer-cluster/safely-drain-node/)
节点上的 Pods。
目前不支持原地升级 `kubelet` 的次版本。
{{</ note >}}
{{< warning >}}
<!--
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
-->
{{< warning >}}
集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：
* 它们必须升级到与 `kube-apiserver` 相差不超过 1 个小版本，才可以升级其他控制面组件
@ -318,4 +361,5 @@ If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
如果 `kube-proxy` 的版本是 **{{< skew oldestMinorVersion >}}**：
* `kubelet` 版本必须相同，也是 **{{< skew oldestMinorVersion >}}**
* `kube-apiserver` 版本必须在 **{{< skew oldestMinorVersion >}}** 到 **{{< skew latestVersion >}}** 之间（闭区间）
* `kube-apiserver` 版本必须在 **{{< skew oldestMinorVersion >}}** 到
**{{< skew latestVersion >}}** 之间（闭区间）