转载

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里，因为数据卷不能跨区。

限制：

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

我们假定不同的区互相距离很近，所以我们不做任何路由。尤其，通过服务过来的请求可能是跨区的（即使在一些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）

建立你的集群

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

GCE:

AWS:

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

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

节点打标签
看下节点，你能看到它们被打了zone信息的标签。它们目前都在us-central1-a (GCE) 或者在 us-west-2a (AWS) 。这些标签，对地区来说，是failure-domain.beta.kubernetes.io/region ；对zone来说是 failure-domain.beta.kubernetes.io/zone
在第二个区内再加一些节点
现在让我们在一个不同的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里。

数据卷和zone的粘性

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

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

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

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，尽管它们在不同的区里。

关闭集群

结束之后，清理一下

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 kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.shKUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh

查看原文请点击“原文链接”。

原文 http://dockone.io/article/1167

正文到此结束