集群高可用
Kubernetes具有自愈能力,当它跟踪到某工作节点发生故障时,控制平面可以将离线节点上的Pod对象重新编排至其他可用的工作节点上运行.若主API服务器出现故障(由于其主机出现故障或网络分区将其从集群中隔离)则其将无法再跟踪和控制集群.
一般来说高可用控制平面至少需要三个Master节点来承受最多一个Master节点的丢失,才能保证等待状态的Master节点能够保持半数以上.以满足节点选举时的法定票数
利用haproxy和keepalived的VIP功能来实现高可用的方案
kube-scheduler和kube-controller-manager使用一主多从的高可用方案,在同一时刻只允许一个服务处以具体的任务.Kubernetes中自身实现了一套简单的选主逻辑,依赖Etcd实现 scheduler和controller-manager的选主功能,所以这两个组件不需要我们手动去实现高可用
Kubernetes组件中仅etcd需要复杂逻辑完成集群功能,其他组件间的松耦合特性使得系统能够通过多种方式实现Master节点的高可用性
利用etcd自身提供的分布式存储集群为Kubernetes构建一个可靠的存储层
apiserver组件
将无状态的apiserver运行为多副本,并在其前端使用负载均衡器调度请求.需要注意的是负载均衡器本身也需要是高可用的
controller-manager组件
多副本的控制器管理器,通过其自带的leader选举功能(--leader-election) 选举出主角色,余下的副本在主角色发生故障时自动启动新一轮的选举操作
scheduler组件
多副本的调度器,通过其自带的leader选举功能(--leader-election)选举出主 角色,余下的副本在主角色发生故障时自动启动新一轮的选举操作
etcd高可用
etcd内部采用raft协议作为共识算法进行分布式协作,将数据同步存储在多个独立的服务实例上以提高数据的可靠性,从而避免了单点故障所导致的数据丢失。Raft协议通过选举出的leader节点来实现数据的一致性，由leader节点负责所有的写入请求并同步给集群中的所有节点,在取决半数以上follower节点的确认后予以持久存储
Controller Manager高可用
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名称空间中创建一个与程序同名的Endpoints资源对象来实现
这种leader选举操作是分布式锁机制的一种应用,它通过创建和维护Kubernetes资源对象来维护锁状态,目前Kubernetes支持ConfigMap和Endpoints两种类型的资源锁.初始状态时,各kube-controller-manager实例通过竞争的方式去抢占指定的 Endpoints资源锁。胜利者将成为leader它通过更新相应的Endpoints资源的注解 control-plane.alpha.kubernetes.io/leader中的“holderIdentity” 为其 节点名称,从而将自己设置为锁的持有者,并基于周期性更新同一注解中的“renewTime” 以声明自己对锁资源的持有状态从而避免等待状态的实例进行争抢于是一旦某leader不再更新renewTime了,等待状态的各实例就将一哄而上进行新一轮的竞争
kubectl describe endpoints kube-controller-manager -n kube-system
kube-scheduler高可用
kube-scheduler的实现方式与此类似,只不过它使用的是自己专用的 Endpoints资源kube-scheduler