Kubernetes集群高可用
作者：马永亮
来源：iKubernetes
Kubernetes具有自愈能力，它跟踪到某工作节点发生故障时，控制平面可以将离线节点上的Pod对象重新编排至其它可用工作节点运行，因此，更多的工作节点也意味着更好的容错能力，因为它使得Kubernetes在实现工作节点故障转移时拥有更加灵活的自由度。而当管理员检测到集群负载过重或无法容纳其更多的Pod对象时，通常需要手动将节点添加到群集，其过程略繁琐，Kubernetes cluster-autoscaler还为集群提供了规模按需自动缩放的能力。
然而，添加更多工作节点并不能使群集适应各种故障，例如，若主API服务器出现故障（由于其主机出现故障或网络分区将其从集群中隔离），将无法再跟踪和控制集群。因此，还需要冗余控制平面的各组件以实现主节点的服务高可用性。基于冗余数量的不同，控制平面能容忍一个甚至是几个节点的故障。一般来说，高可用控制平面至少需要三个Master节点来承受最多一个Master节点的丢失，才能保证等待状态的Master能保持半数以上以满足节点选举时的法定票数。一个最小化的Master节点高可用架构如下图所示。
最小化Master节点高可用架构
Kubernetes组件中仅etcd需要复杂逻辑完成集群功能，其它组件间的松耦合特性使得能够通过多种方式实现Master节点的高可用性，图13- 是较为常用的一种架构，各架构方式也通常有一些共同的指导方针：
利用etcd自身提供的分布式存储集群为kubernetes构建一个可靠的存储层；
将无状态的apiserver运行为多副本，并在其前端使用负载均衡器调度请求；需要注意的是，负载均衡器本身也需要高可用；
多副本的控制器管理器，并通过其自的leader选举功能（--leader-election）选举出主角色，余下的副本在主角色故障时自动启动新一轮的选举操作；
多副本的调度器，并通过其自带的leader选举功能（--leader-election）选举出主角色，余下的副本在主角色故障时自动启动新一轮的选举操作；
1. etcd高可用
分布式服务之间进行可靠、高效协作的关键前提是有一个可信的数据存储和共享机制，etcd项目正是致力于此目的构建的分布式数据存储系统，它以键值格式组织数据，主要用于配置共享和服务发现，也支持实现分布式锁、集群监控和leader选举等功能。
etcd基于Go语言开发，内部采用raft协议作为共识算法进行分布式协作，通过将数据同步存储在多个独立的服务实例上从而提高数据的可靠性，避免了单点故障导致数据丢失。Raft协议通过选举出的leader节点实现数据一致性，由leader节点负责所有的写入请求并同步给集群中的所有节点，在取决半数以上follower节点的确认后予以持久存储。这种需要半数以上节点投票的机制要求集群数量最好是奇数个节点，推荐的数量为3个、5个或7个。Etcd集群的建立有三种方式：
静态集群：事先规划并提供所有节点的固定IP地址以组建集群，仅适合于能够为节点分配静态IP地址的网络环境，好处是它不依赖于任何外部服务；
基于etcd发现服务构建集群：通过一个事先存在的etcd集群进行服务发现来组建新集群，支持集群的动态构建，它依赖于一个现存可用的etcd服务；
基于DNS的服务资源记录构建集群：通过在DNS服务上的某域名下为每个节点创建一条SRV记录，而后基于此域名进行服务发现来动态组建新集群，它依赖于DNS服务及事先管理妥当的资源记录；
一般说来，对于etcd分布式存储集群来说，三节点集群可容错一个节点，五节点集群可容错两个节点，七节点集群可容错三个节点，依次类推，但通常多于七个节点的集群规模是不必要的，而且对系统性能也会产生负面影响。
2. Controller Manager和Scheduler高可用
Controller Manager通过监控API server上的资源状态变动并按需分别执行相应的操作，于是，多实例运行的kube-controller-manager进程可能会导致同一操作行为被每一个实例分别执行一次，例如某一Pod对象创建的请求被3个控制器实例分别执行一次进而创建出一个Pod对象副本来。因此，在某一时刻，仅能有一个kube-controller-manager实例正常工作状态，余下的均处于备用状态，或称为等待状态。
多个kube-controller-manager实例要同时启用“--leader-elect=true”选项以自动实现leader选举，选举过程完成后，仅leader实例处于活动状态，余下的其它实例均转入等待模式，它们会在探测到leader故障时进行新一轮选举。与etcd集群基于raft协议进行leader选举不同的是，kube-controller-manager集群各自的选举操作仅是通过在kube-system名称空间中创建一个与程序同名的Endpoint资源对象实现。
~]$ kubectl get endpoints -n kube-system
NAME ENDPOINTS AGE
kube-controller-manager <none> 13h
kube-scheduler <none> 13h
…
这种leader选举操作是分布式锁机制的一种应用，它通过创建和维护kubernetes资源对象来维护锁状态，目前kubernetes支持ConfigMap和Endpoints两种类型的资源锁。初始状态时，各kube-controller-manager实例通过竞争方式去抢占指定的Endpoint资源锁。胜利者将成为leader，它通过更新相应的Endpoint资源的注解control-plane.alpha.kubernetes.io/leader中的“holderIdentity”为其节点名称从而将自己设置为锁的持有者，并基于周期性更新同一注解中的“renewTime”以声明自己对锁资源的持有状态以避免等待状态的实例进行争抢。于是，一旦某leader不再更新renewTime，等待状态的各实例将一哄而上进行新一轮竞争。
kube-scheduler的实现方式与此类似，只不过它使用自己专用的Endpoint资源kube-scheduler。
提示：基于kubeadm部署高可用集群的方式可参考文档https://kubernetes.io/docs/setup/independent/high-availability/给出的步骤进行。
以上内容摘自《Kubernetes进阶实战》一书，华章计算机经授权发布
长按二维码
了解及购买
基于Kubernetes1.12，重点话题全面覆盖，具备大量实操案例，提供代码下载及配置清单
编辑推荐：
1）马哥教育CEO马哥（马永亮）撰写，渐进式铺陈，适合入门与进阶；
2）涵盖Kubernetes架构、部署、核心/自定义资源、扩缩容、存储卷、网络插件与策略、安全、调度策略、监控、日志等话题；
3）渐进式讲解，手把手示范，大量实操案例，随时动手验证。
内容简介：
本书涵盖Kubernetes架构、部署、核心资源类型、系统扩缩容、存储卷、网络插件与网络策略、安全（认证、授权与准入控制等）、自定义资源、监控与日志系统等话题，大量实操案例，随时动手验证。概括来说，本书内容从逻辑上分为5部分。
第一部分详细讲解Kubernetes系统基础架构及核心概念，并提供快速部署和应用入门指南。第二部分深度剖析Kubernetes系统核心组件与应用，帮助读者解决日常业务应用问题。第三部分介绍存储卷及StatefulSet控制器。第四部分介绍安全相关的的话题，为容器应用提供配置信息与敏感信息的方式，动态扩缩容与更新机制等。第五部分介绍Kubernetes系统调度策略、自定义资源类型和自定义资源、监控系统等高级话题。
作者简介：
马哥（马永亮），北京马哥教育科技有限公司创始人兼CEO，泛Linux运维技术及云计算技术培训先驱者和引领者，10年间累计直接培养业内Linux运维从业人员近万人，录制的相关领域的系列视频播放量500万人次以上。熟悉泛Linux云计算、高并发架构、运维自动化、DevOps和容器及容器编排等领域相关技术应用。
你与世界
只差一个
公众号