From 544d3c2fb7fcfde09e10936f75255c52e786f817 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 26 Apr 2021 16:14:23 +0800 Subject: [PATCH] [zh] Resync setup section (2) --- .../zh/docs/reference/setup-tools/_index.md | 5 + .../setup/best-practices/multiple-zones.md | 726 +++++------------- .../docs/setup/learning-environment/_index.md | 47 ++ .../container-runtimes.md | 177 ++--- .../production-environment/tools/kops.md | 214 ++++-- .../production-environment/tools/kubespray.md | 64 +- .../docs/setup/release/version-skew-policy.md | 106 ++- 7 files changed, 595 insertions(+), 744 deletions(-) diff --git a/content/zh/docs/reference/setup-tools/_index.md b/content/zh/docs/reference/setup-tools/_index.md index 9cd9d94f0d..08b4c38e46 100644 --- a/content/zh/docs/reference/setup-tools/_index.md +++ b/content/zh/docs/reference/setup-tools/_index.md @@ -2,3 +2,8 @@ title: 安装工具 weight: 50 --- + + diff --git a/content/zh/docs/setup/best-practices/multiple-zones.md b/content/zh/docs/setup/best-practices/multiple-zones.md index e0c1523a79..b36b607781 100644 --- a/content/zh/docs/setup/best-practices/multiple-zones.md +++ b/content/zh/docs/setup/best-practices/multiple-zones.md @@ -1,5 +1,5 @@ --- -title: 运行于多区环境 +title: 运行于多可用区环境 weight: 10 content_type: concept --- @@ -16,591 +16,267 @@ content_type: concept -本页描述如何在多个区（Zone）中运行集群。 +本页描述如何跨多个区（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 和服务。 + +典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。 -多区支持有意实现的有局限性：可以在跨多个区域运行同一 Kubernetes 集群，但只能 -在同一区域（Region）和云厂商平台。目前仅自动支持 GCE 和 AWS，尽管为其他云平台 -或裸金属平台添加支持页相对容易，只需要确保节点和卷上添加合适的标签即可。 +## 控制面行为 {#control-plane-behavior} + +所有的[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components) +都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。 -## 功能 +当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。 +如果可用性是一个很重要的指标，应该选择至少三个失效区，并将每个 +控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本， +跨至少三个失效区来部署。如果你在运行云控制器管理器，则也应该将 +该组件跨所选的三个失效区来部署。 -节点启动时，`kubelet` 自动向其上添加区信息标签。 - - -在单区（Single-Zone）集群中， Kubernetes 会自动将副本控制器或服务中的 Pod -分布到不同节点，以降低节点失效的影响。 -在多区集群中，这一分布负载的行为被扩展到跨区分布，以降低区失效的影响， -跨区分布的能力是通过 `SelectorSpreadPriority` 实现的。此放置策略亦仅仅是 -尽力而为，所以如果你的集群所跨区是异质的（例如，节点个数不同、节点类型 -不同或者 Pod 资源需求不同），放置策略都可能无法完美地跨区完成 Pod 的 -均衡分布。如果需要，你可以使用同质区（节点个数和类型相同）以降低不均衡 -分布的可能性。 - - -持久卷被创建时，`PersistentVolumeLabel` 准入控制器会自动为其添加区标签。 -调度器使用 `VolumeZonePredicate` 断言确保申领某给定卷的 Pod 只会被放到 -该卷所在的区。这是因为卷不可以跨区挂载。 - - -## 局限性 - -多区支持有一些很重要的局限性： - -* 我们假定不同的区之间在网络上彼此距离很近，所以我们不执行可感知区的路由。 - 尤其是，即使某些负责提供该服务的 Pod 与客户端位于同一区，通过服务末端 - 进入的流量可能会跨区，因而会导致一些额外的延迟和开销。 - - -* 卷与区之间的亲和性仅适用于 PV 持久卷。例如，如果你直接在 Pod 规约中指定某 EBS - 卷，这种亲和性支持就无法工作。 - -* 集群无法跨多个云平台或者地理区域运行。这类功能需要完整的联邦特性支持。 - - -* 尽管你的节点位于多个区中，`kube-up` 脚本目前默认只能构造一个主控节点。 - 尽管服务是高可用的，能够忍受失去某个区的问题，控制面位于某一个区中。 - 希望运行高可用控制面的用户应该遵照 - [高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) - 中的指令构建。 - - -### 卷局限性 - -以下局限性通过 -[拓扑感知的卷绑定](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)解决： - -* 使用动态卷供应时，StatefulSet 卷的跨区分布目前与 Pod - 亲和性和反亲和性策略不兼容。 - - -* 如果 StatefulSet 的名字中包含连字符（"-"），卷的跨区分布可能无法实现存储的 - 跨区同一分布。 - -* 当在一个 Deployment 或 Pod 规约中指定多个 PVC 申领时，则需要为某特定区域 - 配置 StorageClass，或者在某一特定区域中需要静态供应 PV 卷。 - 另一种解决方案是使用 StatefulSet，确保给定副本的所有卷都从同一区中供应。 - - -## 演练 - -我们现在准备对在 GCE 和 AWS 上配置和使用多区集群进行演练。为了完成此演练， -你需要设置 `MULTIZONE=true` 来启动一个完整的集群，之后指定 -`KUBE_USE_EXISTING_MASTER=true` 并再次运行 `kube-up` 添加其他区中的节点。 - - -### 建立集群 - -和往常一样创建集群，不过需要设置 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 -``` - - -这一步骤和往常一样启动一个集群，不过尽管 `MULTIZONE=true` -标志已经启用了多区功能特性支持，集群仍然运行在一个区内。 - - -### 节点已被打标签 - -查看节点，你会看到节点上已经有了区信息标签。 -目前这些节点都在 `us-central1-a` (GCE) 或 `us-west-2a` (AWS)。 -对于区域（Region），标签为 `topology.kubernetes.io/region`， -对于区（Zone），标签为 `topology.kubernetes.io/zone`： - -```shell -kubectl get nodes --show-labels -``` - - -输出类似于： - -``` -NAME STATUS ROLES AGE VERSION LABELS -kubernetes-master Ready,SchedulingDisabled 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 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 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 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 -``` - -### 添加第二个区中的节点 - -让我们向现有集群中添加另外一组节点，复用现有的主控节点，但运行在不同的区 -（`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 -``` - - -在 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 -``` - - -再次查看节点，你会看到新启动了三个节点并且其标签表明运行在 `us-central1-b` 区： - -```shell -kubectl get nodes --show-labels -``` - - -输出类似于： - -``` -NAME STATUS ROLES AGE VERSION LABELS -kubernetes-master Ready,SchedulingDisabled 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 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 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 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 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 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 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 -``` - - -### 卷亲和性 - -通过动态卷供应创建一个卷（只有 PV 持久卷支持区亲和性）： - -```bash -kubectl apply -f - < {{< 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 并不会为 API 服务器端点提供跨失效区的弹性。 +你可以为集群 API 服务器使用多种技术来提升其可用性，包括使用 +DNS 轮转、SRV 记录或者带健康检查的第三方负载均衡解决方案等等。 {{< /note >}} -现在我们来验证 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。 +这种分布逻辑有助于降低失效带来的影响。 -输出类似于： - -``` -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)。 -现在我们将创建一个使用 PVC 申领的 Pod。 -由于 GCE PD 或 AWS EBS 卷都不能跨区挂载，这意味着 Pod 只能创建在卷所在的区： - -```yaml -kubectl apply -f - <}} +能够更好地分布 Pods，以实现更好的可用性，降低因为某种失效给整个工作负载 +带来的风险。 -注意 Pod 自动创建在卷所在的区，因为云平台提供商一般不允许跨区挂接存储卷。 - -```shell -kubectl describe pod mypod | grep Node -``` - -``` -Node: kubernetes-minion-9vlv/10.240.0.5 -``` +例如，你可以设置一种约束，确保某个 StatefulSet 中的三个副本都运行在 +不同的可用区中，只要其他条件允许。你可以通过声明的方式来定义这种约束， +而不需要显式指定每个工作负载使用哪些可用区。 -检查节点标签： +### 跨多个区分布节点 {#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/) 这类工具来替你管理节点。 -### 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 这类工具，你可以跨多个失效域来定义一组用做你的集群 +工作节点的机器，以及当整个区的服务出现中断时如何自动治愈集群的策略。 -验证你现在有来自三个区的节点： +## 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 手动指定区 -创建 `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 模板设置此类约束。 -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 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 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 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 只会 +被调度到该卷所在的可用区。 -负载均衡器也会跨集群中的所有区；`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)。 -输出类似于： +## 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，则负载均衡器 +可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。 +请查阅云提供商的文档了解详细信息。 -设置上面的 IP 地址： - -```shell -export IP=130.211.126.21 -``` +对于自定义的或本地集群部署，也可以考虑这些因素 +{{< glossary_tooltip text="Service" term_id="service" >}} +{{< glossary_tooltip text="Ingress" term_id="ingress" >}} 的行为， +包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。 -使用 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" %}} -输出类似于： - -``` - "HOSTNAME": "guestbook-44sep", -``` - - -如果多次尝试该命令： - -```shell -(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq -``` - - -输出类似于： - -```shell - "HOSTNAME": "guestbook-44sep", - "HOSTNAME": "guestbook-hum5n", - "HOSTNAME": "guestbook-ppm40", -``` - - -负载均衡器正确地选择不同的 Pod，即使它们跨了多个区。 - - -### 停止集群 - -当完成以上工作之后，清理任务现场： - -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/)。 diff --git a/content/zh/docs/setup/learning-environment/_index.md b/content/zh/docs/setup/learning-environment/_index.md index 9923716978..f68e52a439 100644 --- a/content/zh/docs/setup/learning-environment/_index.md +++ b/content/zh/docs/setup/learning-environment/_index.md @@ -2,3 +2,50 @@ title: 学习环境 weight: 20 --- + + + +## 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 + + +与 `kind` 类似，[`minikube`](https://minikube.sigs.k8s.io/) 是一个允许你在 +本地运行 Kubernetes 的工具。`minikube` 在你的个人计算机上运行一个单节点的 +Kubernetes 集群（包括 Windows、macOS 和 Linux PC 机），这样你可以尝试 +Kubernetes 或者执行每天的开发工作。 + +如果你所关注的是如何安装该工具，可以查阅官方的 +[Get Started!](https://minikube.sigs.k8s.io/docs/start/) +文档。 + diff --git a/content/zh/docs/setup/production-environment/container-runtimes.md b/content/zh/docs/setup/production-environment/container-runtimes.md index 943cbb2d17..c0a8a66b5e 100644 --- a/content/zh/docs/setup/production-environment/container-runtimes.md +++ b/content/zh/docs/setup/production-environment/container-runtimes.md @@ -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 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。 @@ -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; 这类节点在资源压力下 +会变得不稳定。 注意：更改已加入集群的节点的 cgroup 驱动是一项敏感的操作。 -如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。重启 kubelet 也可能无法解决此类问题。 -如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点，或者使用自动化方案来重新安装。 +如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用 +别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。 +重启 kubelet 也可能无法解决此类问题。 +如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点， +或者使用自动化方案来重新安装。 如果你想迁移到现有 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 < 本节包含使用 containerd 作为 CRI 运行时的必要步骤。 @@ -183,7 +171,10 @@ Install containerd: -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` + 软件包的说明。 -启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$ Version=1.4.3`），然后运行以下命令： +启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$ Version=1.4.3`）， +然后运行以下命令： - 3. 启动 containerd: ```powershell @@ -260,15 +252,7 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version - 结合 `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 < 本节包含安装 CRI-O 作为容器运行时的必要步骤。 使用以下命令在系统中安装 CRI-O： -提示：CRI-O 的主要以及次要版本必须与 Kubernetes 的主要和次要版本相匹配。 -更多信息请查阅 [CRI-O 兼容性列表](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)。 +{{< note >}} + +CRI-O 的主要以及次要版本必须与 Kubernetes 的主要和次要版本相匹配。 +更多信息请查阅 +[CRI-O 兼容性列表](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)。 +{{< /note >}} -安装以及配置的先决条件： + +安装并配置前置环境： ```shell -# 创建 .conf 文件，以便在系统启动时加载内核模块 +# 创建 .conf 文件以在启动时加载模块 cat < Then run - --> +--> 在下列操作系统上安装 CRI-O, 使用下表中合适的值设置环境变量 `OS`: | 操作系统 | `$OS` | @@ -395,6 +361,7 @@ Then run
然后执行 + ```shell cat < 将 `$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 +启动 CRI-O： ```shell sudo systemctl daemon-reload sudo systemctl enable crio --no ``` + +参阅[CRI-O 安装指南](https://github.com/cri-o/cri-o/blob/master/install.md) +了解进一步的详细信息。 + + -默认情况下，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" ``` + -另请注意更改后的 `conmon_cgroup` ，必须将其设置为 -`pod`将 CRI-O 与 `cgroupfs` 一起使用时。通常有必要保持 -kubelet 的 cgroup 驱动程序配置（通常透过 kubeadm 完成）和CRI-O 同步中。 +另请注意更改后的 `conmon_cgroup`，将 CRI-O 与 `cgroupfs` 一起使用时， +必须将其设置为 `pod`。通常有必要保持 kubelet 的 cgroup 驱动程序配置 +（通常透过 kubeadm 完成）和 CRI-O 一致。 ### Docker + -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. 配置 Docker 守护程序，尤其是使用 systemd 来管理容器的cgroup。 +2. 配置 Docker 守护程序，尤其是使用 systemd 来管理容器的 cgroup。 ```shell sudo mkdir /etc/docker @@ -621,14 +598,16 @@ kubelet 的 cgroup 驱动程序配置（通常透过 kubeadm 完成）和CRI-O {{< note >}} - - 对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。 + --> + 对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL + 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。 {{< /note >}} + 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/) diff --git a/content/zh/docs/setup/production-environment/tools/kops.md b/content/zh/docs/setup/production-environment/tools/kops.md index 871158dc89..94b448361a 100644 --- a/content/zh/docs/setup/production-environment/tools/kops.md +++ b/content/zh/docs/setup/production-environment/tools/kops.md @@ -19,9 +19,9 @@ It uses a tool called [`kops`](https://github.com/kubernetes/kops). 本篇使用了一个名为 [`kops`](https://github.com/kubernetes/kops) 的工具。 -kops 是一个自用的供应系统： +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) - -如果你有不同的观点，你可能更喜欢使用 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) -作为构建工具来构建自己的集群。kops 建立在 kubeadm 工作的基础上。 +## {{% heading "prerequisites" %}} - + +* 你必须安装 [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)。 + + ## 创建集群 ### (1/5) 安装 kops -#### 前提条件 - -你必须安装 [kubectl](/zh/docs/tasks/tools/install-kubectl/) 才能使 kops 工作。 - - #### 安装 -从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops（从源代码构建也很容易）： +从[下载页面](https://github.com/kubernetes/kops/releases)下载 kops +（从源代码构建也很方便）： + +{{< tabs name="kops_installation" >}} +{{% tab name="macOS" %}} -在 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 +``` + + +要下载特定版本，使用特定的 kops 版本替换下面命令中的部分： + +```shell +$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) +``` + + +例如，要下载 kops v1.20.0，输入： + +```shell +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64 +``` + + +令 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 +``` + + +将 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" %}} + + +使用命令下载最新发布版本： + +```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 +``` + + +要下载 kops 的特定版本，用特定的 kops 版本替换下面命令中的部分： + +```shell +$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) +``` + + +例如，要下载 kops v1.20 版本，输入： + +```shell +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64 +``` + + +令 kops 二进制文件可执行： + +```shell +chmod +x kops-linux-amd64 +``` + + +将 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 ``` - -在 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) 为你的集群创建一个 route53 域名 -kops 在集群内部都使用 DNS 进行发现操作，因此你可以从客户端访问 kubernetes API 服务器。 +kops 在集群内部和外部都使用 DNS 进行发现操作，这样你可以从客户端访问 +kubernetes API 服务器。 -你应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。 -然后，API 服务器端点域名将为 `api.useast1.dev.example.com`。 +你可以，或许应该使用子域名来划分集群。作为示例，我们将使用域名 `useast1.dev.example.com`。 +这样，API 服务器端点域名将为 `api.useast1.dev.example.com`。 -这一步很容易搞砸（这是问题的第一大原因！） +检查你的 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 存储桶的任何人都将拥有对所有集群的管理访问权限， +因此你不想在运营团队之外共享它。 -在我们的示例中，我们选择 `dev.example.com` 作为托管区域，因此让我们选择 `clusters.dev.example.com` 作为 S3 存储桶名称。 +在我们的示例中，我们选择 `dev.example.com` 作为托管区域，因此我们选择 +`clusters.dev.example.com` 作为 S3 存储桶名称。 * 导出 `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) 建立你的集群配置 -运行 "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` 进行配置。 这使你有机会查看配置或进行更改。 -## 反馈 - - -* Slack 频道: [#kops-users](https://kubernetes.slack.com/messages/kops-users/) -* [GitHub Issues](https://github.com/kubernetes/kops/issues) - ## {{% heading "whatsnext" %}} * 了解有关 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) 获取教程、 + 最佳做法和高级配置选项。 diff --git a/content/zh/docs/setup/production-environment/tools/kubespray.md b/content/zh/docs/setup/production-environment/tools/kubespray.md index eabd14c7f5..0120acd20c 100644 --- a/content/zh/docs/setup/production-environment/tools/kubespray.md +++ b/content/zh/docs/setup/production-environment/tools/kubespray.md @@ -14,12 +14,17 @@ weight: 30 -此快速入门有助于使用 [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 是一个由 [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 提供： -要选择最适合你的用例的工具，请阅读[此比较](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)。 + 。 - ## 创建集群 ### （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” ### （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 能够自定义部署的许多方面： * 证书生成方式 - -可以修改[变量文件](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）部署集群 接下来，部署你的集群： -使用 [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 \ -大型部署（超过 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）验证部署 -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" %}} - -查看有关 Kubespray 的[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)的计划工作。 +查看有关 Kubespray 的 +[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md) +的计划工作。 diff --git a/content/zh/docs/setup/release/version-skew-policy.md b/content/zh/docs/setup/release/version-skew-policy.md index 5ef5a44884..b2fbebfbd1 100644 --- a/content/zh/docs/setup/release/version-skew-policy.md +++ b/content/zh/docs/setup/release/version-skew-policy.md @@ -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)。 -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)。 * 最新的 `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 >}}** 例如： -* 如果 `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` 和 `cloud-controller-manager` 版本不能高于 `kube-apiserver` 版本号。 -最好它们的版本号与 `kube-apiserver` 保持一致，但允许比 `kube-apiserver` 低一个小版本（为了支持在线升级）。 +`kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` +版本不能高于 `kube-apiserver` 版本号。 +最好它们的版本号与 `kube-apiserver` 保持一致，但允许比 `kube-apiserver` +低一个小版本（为了支持在线升级）。 {{< 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 >}} 例如： -* `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 >}}** 例如： -* `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` 实例高或低一个小版本） 组件之间支持的版本偏差会影响组件升级的顺序。 -本节描述组件从版本 **{{< 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` 实例必须在组件升级前完成升级） -升级 `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 >}} + +在对 `kubelet` 执行次版本升级时，先[腾空](/zh/docs/tasks/administer-cluster/safely-drain-node/) +节点上的 Pods。 +目前不支持原地升级 `kubelet` 的次版本。 +{{}} + +{{< warning >}} -{{< 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 >}}** 之间（闭区间） \ No newline at end of file +* `kube-apiserver` 版本必须在 **{{< skew oldestMinorVersion >}}** 到 + **{{< skew latestVersion >}}** 之间（闭区间）