高级实践之高可用性

Kubernetes写书

---

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

常见问题集

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

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

• 虚拟机关机
• 集群内部/之间网络被分割
• Kubernetes自身软件故障
• 数据丢失或持久化存储（例如：GCE PDs和AWS EBS磁盘等）不可用
• 运维人员错误配置Kubernetes或应用程序

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

• 运行APIServer的虚拟机关闭或APIServer发生软件故障
  
  • 结果
    
    • 无法关闭、更新或启动新的pod，service和replication controller。
    • 现有的pod和service能够继续正常工作（除非他们依赖Kubernetes API）。
• APIServer后端存储丢失
  
  • 结果
    
    • APIServer会持续反复地启动失败然后又重启。
    • Kubelet将无法访问APIServer，但Kubelet将会继续运行之前的pod而且kube-proxy也会继续提供流量转发功能。
    • 鉴于APIServer是有状态的，因此在APIServer重启之前，需要手动恢复或重新创建APIServer的状态。
• 支持性组件（例如：controller manager，scheduler等）所在虚拟机关机或发生异常
  
  • 在我们撰写这本书的时候，支持性组件与APIServer运行在同一个主控节点上，因此这些组件的不可用将导致和APIServer不可用一样的后果。
  • 鉴于这些组件是无状态的，因此这些组件在重启之前，无须像APIServer那样手动恢复或重新创建这些组件的状态。
  • 未来，这些组件将拥有多个实例且不必一定要和APIServer运行在同一个主控节点上。
• 工作节点 (运行Kubelet，kube-proxy和pod的机器)关机
  
  • 结果
    
    • 工作节点上的pod停止运行
• Kubelet发生软件故障
  
  • 结果
    
    • 故障的kubelet无法再在工作节点上启动新的pod
    • kubelet可能会也有可能不会删除pod
    • 工作节点被标记为非健康状态
    • replication controller在其他工作节点上启动新的pod副本
• 集群运维人员操作不当
  
  • 结果
    
    • 丢失pod，service等资源对象
    • 丢失APIServer后端存储（etcd）的数据
    • 用户无法使用Kubernetes API
    • 其他各种可能的不良结果

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

• 采取的措施：为使用IaaS虚拟机的集群节点应用IaaS平台提供的虚拟机自动重启特性

  • 解决的问题：Apiserver所在虚拟机关机或APIServer发生软件故障
  • 解决的问题：支持性组件所在虚拟机关闭或这些软件发生故障

• 采取的措施：为运行APIServer和etcd的虚拟机使用IaaS平台提供的可靠的持久化存储（例如：GCE PDs或AWS EBS磁盘等）

  • 解决的问题: APIServer后端存储丢失

• 采取的措施: 增加APIServer多实例的特性（在我们撰写这本书的时候，这个特性还处于计划中状态）

  • 解决的问题: APIServer所在虚拟机关机或APIServer发生软件故障
    
    • 能够承受一个或多个APIServer同时发生故障
  • 解决的问题: APIServer后端存储丢失
    
    • 每个APIServer都有独立的存储，etcd将会从其中一个或多个APIServer实例后端数据丢失中恢复过来。这样，将大大降低集群全部数据丢失的风险。

• 采取的措施: 定期为APIServer所处虚拟机的PDs/EBS磁盘做快照

  • 解决的问题: APIServer后端存储丢失
  • 解决的问题: 集群运维人员的一些不当操作引起的问题
  • 解决的问题: 一些因为kubernetes软件故障引起的问题

• 采取的措施: 在pod前面使用replication controller和service

  • 解决的问题: 工作节点关机
  • 解决的问题: Kubelet发生软件故障

• 采取的措施: 应用程序（容器）被设计成能够容忍意外重启

  • 解决的问题: 工作节点关机
  • 解决的问题: Kubelet发生软件故障

• 采取的措施: 多个独立的集群（避免所有集群同时发生异常，提高集群的整体容灾性）

  • 解决的问题: 以上列举的所有问题

使用Kubernetes多集群

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

单个集群的地理范围

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

• 与全局单个的Kubernetes集群相比，availability zone降低了Kubernetes集群发生单点故障的风险，因为IaaS平台为你维护了availability zone内虚拟机的高可用性。
• 当Kubernetes开发者设计系统架构时，他们假设Kubernetes集群内的所有机器都位于同一个数据中心内或者是地理上紧密连接的。

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

• 优化pod调度过程（当一个集群中存在更多的工作节点时）
• 减少运维成本（尽管这个优势会随着运维工具和流程的成熟而变小）
• 减少每个集群的固定资源成本，例如：APIServer虚拟机数量等（但是对中/大规模的集群来说，集群总体的平均成本还是很小的）。

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

• 部署多个集群以便能够试验新版本的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负载均衡器等）。这样，单个集群的故障对终端用户就变成不可见的了。