[关闭]
@dujun 2015-04-02T03:01:45.000000Z 字数 3599 阅读 1876

高级实践之高可用性

Kubernetes写书


本文将简单探讨下Kubernetes集群在日常使用过程中常见的一些问题并就如何高可用地使用Kubernetes集群提供一些建议。另外,必须要指出的是,在我们撰写这本书的时候,Kubernetes很多高可用的特性还处于规划(roadmap)状态,因此不建议现在就将Kubernetes应用到生产环境中去(建议至少要等到Kubernetes发布v1.0版本之后)。

常见问题集

在实际的应用场景中,我们可能会碰到各种各样的问题,以下只是笔者根据自身经验在实际使用Kubernetes过程中总结出的一个问题列表,只是所有可能发生的情况的一个很小的子集。

一个Kubernetes集群发生故障的问题根源总体上可以归纳成以下几个方面:

下面将根据特定的故障情况分析可能带来的结果,结果一般包含两个方面,即:带来的不良后果和Kubernetes采取的相应动作。

为了预防以上列举的可能发生一些问题,笔者根据自身经验,提出一些预防/补救的措施,如下所示。

使用Kubernetes多集群

既然上面提到使用Kubernetes多集群的特性能够解决很多常见问题,那么下面就介绍如何部署这样一个支持多集群特性的Kubernetes系统。假设你需要部署多个Kubernetes集群并要求这些集群不但能够尽可能地分布在靠近你的用户的不同地理位置上,而且还能承受一定程度的故障而不至于完全崩溃。

单个集群的地理范围

在一些IaaS平台上(譬如:Google Compute Engine和Amazon Web Services等),一个虚拟机存在于一个zoneavailability zone中。我们建议Kubernetes集群内的所有虚拟机都应该在同一个availability zone内,因为:

在一个availability zone中可以同时存在多个Kubernetes集群,至于到底应该多部署还是少部署,有两种不同的观点。
认为在一个availability zone中应该部署较少的Kubernetes群集的理由包括:

而认为在一个availability zone中应该部署较多的Kubernetes群集的理由包括:

总的来说,我们倾向于在一个availability zone中部署多个Kubernetes集群但数量不宜过多,至于具体数量应该多少,这取决于具体的应用场景和部署环境。

选择合适的集群数量

Kubernetes集群数量的选择相对来说是静态的,很少变化。相比之下,一个Kubernetes集群中节点的数量和一个service中pod的数量可能随着时间和负载而频繁变化。下面将提供一种参考的计算集群数量方式,在这种计算方式中,优先考虑地域因素。首先,我们需要确定要求独立提供服务的service数量。例如:一个跨国公司出于法律和本地化的考虑可能需要同时在US,EU,AP和SA地区部署一个集群,我们将区域的数量记为R。然后,我们需要确定允许多少集群可以同时不可用,我们将不可用的集群数量记为U,如果你不确定到底多少比较合适,那么1将是一个比较合适的选择。

如果你允许负载均衡器在集群部分故障时将流量转发到任意区域(region),那么你只需要R+U个集群就够了。如果你希望在集群故障时恢复的延时尽可能小,那么你就需要R*(U+1)个集群(即每个区域都要有U个冗余的集群)。不论是那种情况,都需要把每个集群部署在不同的zone中。最后,在我们撰写这本书的时候,每个Kubernetes集群能够容纳的最大节点数是有限的,如果超过了最大推荐数量,就需要部署更多的集群。KUbernetes的roadmap提到,到Kubernetes v1.0时,一个集群将能够容纳最多100个节点,到2015年中下旬时,一个集群将能够容纳最多1000个节点。

实际使用

在实际使用过程中,当搭建了多个Kubernetes集群时,我们一般会在每个集群创建配置完全一样的service并在这些service实例前面部署一个负载均衡器(例如:AWS Elastic Load Balancer,GCE Forwarding Rule或普通HTTP负载均衡器等)。这样,单个集群的故障对终端用户就变成不可见的了。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注