资讯专栏INFORMATION COLUMN

Kubernetes 1.2 新功能解析:multizone(多区)支持

seal_de / 2833人阅读

摘要:只有谷歌的和亚马逊的目前被自动的支持尽管通过给节点和数据卷安排添加适当的标签来给其他云或者裸机加入类似的支持很容易。当建立持久数据卷时,管理控制器自动会把标签加给数据卷。因为数据卷都不能跨区,这意味着只能被创建在和数据卷同区内。

导论

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同区),这可能会导致额外的延迟和开销。

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

集群不能跨云跨地区(这个功能要靠K8S完整版的集群联合支持)。

尽管你的节点在多个区,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 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

原文链接点这里

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/32447.html

相关文章

  • Kubernetes 1.3 中一些隐藏的功能

    摘要:到现在为止,部署有状态应用比如分布式数据库已经是一个棘手的问题,但是其实也不是做不到。我们也会展示如何在本地更加轻松地部署分布式数据库在我们与客户目前正在积极处理的区域内。 伴随着5000多次的提交,以及大约350位贡献者在社区以及该行业的贡献,Kubernetes现在已经到1.3版本了,已于上周发布!网址:点这里。 Kubernetes的首次发布要追溯到两年前。这个项目的社区参与度和...

    kk_miles 评论0 收藏0
  • 在GKE上面创建你的第一个Kubernetes集群

    摘要:创建你的谷歌云项目如果你还没有谷歌账号,那么在你继续步骤之前先创建一个。一个集群包括了由谷歌和一套节点主导的服务器。点击查看完美结语我们今天带大家一起来看了一下谷歌云平台,开启计费功能,打开相关,然后在上面创建一个集群。 你可能已经了解过Kubernetes和Google云平台,但是可能还并没有真正创建过一个集群。在这里,我们会带领大家梳理一些基础知识,跟着这个教程一步步来,你就会自己...

    Jonathan Shieber 评论0 收藏0
  • Kubernetes 1.2 功能解析:ConfigMap (上)

    摘要:我们希望能够让应用的开发者在里充分使用这样的模式。尽管允许类似于验证信息和秘钥这些信息从应用当中分离,但在过去并没有为了普通的或者非配置而存在的对象。从数据角度来看,的类型只是键值组。 容器的配置管理——把应用的代码和配置区分开,是一个好的操作。我们希望能够让应用的开发者在Kubernetes里充分使用这样的模式。尽管Secrets API允许类似于验证信息和秘钥这些信息从应用当中分离...

    李涛 评论0 收藏0
  • Kubernetes 1.2 功能解析:ConfigMap (下)

    摘要:的工作就是为作出的修改查看我们的配置文件,并且运行读取配置文件的新版本回调函数,使用设置新的。它的目标是使任意额外的成为一个单独更新的,这样我们只要执行一次回调函数。 Kubernetes 1.2版本添加了一个叫ConfigMap的新功能。这个功能提供给容器注入应用程序数据的方式。注入配置文件对于大部分应用程序来说很强大,但是新的ConfigMap功能不仅可以在容器开启时提供初始配置功...

    Blackjun 评论0 收藏0
  • Kubernetes 1.2 功能解析:ConfigMap (中)

    摘要:使用很多应用程序的配置需要通过配置文件,命令行参数和环境变量的组合配置来完成。举个例子,思考以下的我们可以像这样在一个中来使用这个的键当这个运行的时候,它的输出将包括以下几行使用案例用设置命令行参数也可以被使用来设置容器中的命令或者参数值。 使用ConfigMap 很多应用程序的配置需要通过配置文件,命令行参数和环境变量的组合配置来完成。这些配置应该从image内容中解耦,以此来保持容...

    honmaple 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<