Kubernetes 1.2 新功能解析：multizone（多区）支持

Kubernetes 1.2 增加的一个新的功能是把一个集群跑在多个 failure zone 里（谷歌 GCE 管它叫“zone”，亚马逊 AWS 管它们叫“availability zones”，这里我们统称它们为“zones”）。这是把多个 K8S 集群联合起来（被称为“Ubernetes”）的一个轻便的版本。Ubernetes 会允许把在多个云或者不同地区的多个 K8S 集群联合起来。然而，很多开发者近是简单地想把他们云上地 K8S 集群跑在不同 zone 里，这就是 K8S 的 1.2 版本所提供的 multizone（多区）支持（我们称之为“Ubernetes Lite”）。

K8S 1.2 特意对多区支持做了一些限制：一个简单的 K8S 集群可以跑在多区，但只能是在同一个地区（和同一个云上）。只有谷歌的 GCE 和亚马逊的 AWS 目前被自动的支持（尽管通过给节点和数据卷安排添加适当的标签来给其他云或者裸机加入类似的支持很容易）。

功能：

当节点启动之后，kubelet 自动给它们添加 zone 信息的标签。K8S 会自动在单个区的单个集群的冗余控制器（RC）内平均分布 pods 或者在节点上分布服务（来减少失败带来的影响）。对于多区集群来说，这种平均分布的行为也应该是跨区（来减少区挂掉的影响）。（这是通过 SelectorSpreadPriority 来实现的）。这是最理想的方式，但如果你集群所在的 zone 是不同的（比如，节点数量不同，节点类型不同或者不同的节点资源要求），这些都会有可能导致无法完美的跨区平均分布 pods。如果可以的话，你可以使用同一个区（同样的节点数量和节点类型）来减少不平均分配的概率。

当建立持久数据卷时，PersistentVolumeLabel 管理控制器自动会把 zone 标签加给数据卷。调度器（通过 VolumeZonePredicate）会确保 pod 和分配给这个 pod 的数据卷在同一个 zone 里，因为数据卷不能跨区。

限制：

对于多区支持有如下几个限制

1. 我们假定不同的区互相距离很近，所以我们不做任何路由。尤其，通过服务过来的请求可能是跨区的（即使在一些 pods 里的 pod 是支持这些服务的且这些 pods 和 client 同区），这可能会导致额外的延迟和开销。

2.数据卷对区有粘性，只能以 PersistentVolume 来工作，比如说如果你特地在 pod 的参数里指定一个 EBS 数据卷是无法奏效的。

3.集群不能跨云跨地区（这个功能要靠 K8S 完整版的集群联合支持）。

4.尽管你的节点在多个区，kube-up 现在默认是跑一个单一的 master node。尽管服务是高可用，能在一个区内容忍一些损失，控制层是在某个单一区内。需要高可用控制层的开发者需留意关于 K8S 高可用方面的指南。

代码梳理:

现在来梳理一下如何在 GCE 和 AWS 上建立和使用一个多区集群。你需要建一个完整的集群（指定 MULTIZONE=1）,然后通过再跑 kube-up 在其他区增加节点（设定 KUBE_USE_EXISTING_MASTER=true）

1. 建立你的集群

和往常一样来建立集群，传入 MULTIZONE 让集群知道去管理多区，在 us-central1-a 里创建节点:

GCE:curl -sS https://get.k8s.io | MULTIZONE=1 KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-aNUM_NODES=3 bash

AWS:curl -sS https://get.k8s.io | MULTIZONE=1 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash

通过这步就常规建立了一个集群，仍然在单区跑（但通过 MULTIZONE=1 赋予了多区的能力）

2. 节点打标签

看下节点，你能看到它们被打了 zone 信息的标签。它们目前都在 us-central1-a (GCE) 或者在 us-west-2a (AWS) 。这些标签，对地区来说，是 failure-domain.beta.kubernetes.io/region ；对 zone 来说是 failure-domain.beta.kubernetes.io/zone

3. 在第二个区内再加一些节点

现在让我们在一个不同的 zone 内（us-central1-b 或者 us-west-2b）利用已有的 master，在现有的集群里再加入一些节点。我们可以再跑一下 kube-up，但如果指定 KUBE_USE_EXISTING_MASTER=1 的话，kube-up 不会创建一个新的 master，但会重复使用之前已有的。

GCE:KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh

在 AWS 上我们也需要给子网指定网络 CIDR，和 master 内部的 IP 地址：

KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 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 里。

4. 数据卷和 zone 的粘性

通过新的动态数据卷创建来创立一个数据卷（只有持久数据卷才能保证数据卷和 zone 的粘性）

持久数据卷也被打了标签，标明了它被创建的地区和 zone。在 K8S 1.2 版本里，动态的持久数据卷总是被建在集群 master 同区（在现在这个例子里，是在 us-centaral1-a / us-west-2a）；这在完整版中会提高。

所以，现在我们要来创建一个 pod，来使用持久数据卷。因为 GCE PDS/AWS EBS 数据卷都不能跨区，这意味着 pod 只能被创建在和数据卷同区内。

5. Pods 跨区的分布

在冗余控制器（RC）里的 pod 或者服务会被自动地跨区分布。首先，让我们在第三个区内再生成一些节点

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh

AWS:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=1 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

检查一下你在三个区里有节点：

kubectl get nodes --show-labels

建立一个 K8S 教程里 guestbook-go 例子，包含一个 RC，数量写 3，跑一个简单的 web 应用：

find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}

pods 应该跨三个区分布：

负载均衡器在一个集群之内跨区，在 K8S 标准教程 guestbook-go 里有这个负载均衡器服务的例子:

负载均衡器目前指向所有的 pods，尽管它们在不同的区里。

6. 关闭集群

结束之后，清理一下

GCE:

KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh

AWS:

KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kuberne

本文转载自才云 Caicloud 公众号。

原文链接： https://mp.weixin.qq.com/s/dzgWthBXVOqYRmw-W4OkjA