一、高可用原理

  配置一台新的master节点,然后在每台node节点上安装nginx,nginx通过内部的负载均衡将node节点上需要通过访问master,kube-apiserver组件的请求,反代到两台k8s-master节点上,这样就可以实现master节点的高可用,当任意一台master节点宕机后,也可以通过nginx负载均衡放文档另一个master节点上。kube-scheduler以及kube-controller-manager高可用则是在两台master配置文件设置leader-elect参数。
 
  Kubernetes的管理层服务包括kube-scheduler和kube-controller-manager。kube-scheduer和kube-controller-manager使用一主多从的高可用方案,在同一时刻只允许一个服务处以具体的任务。Kubernetes中实现了一套简单的选主逻辑,依赖Etcd实现scheduler和controller-manager的选主功能。如果scheduler和controller-manager在启动的时候设置了leader-elect参数,它们在启动后会先尝试获取leader节点身份,只有在获取leader节点身份后才可以执行具体的业务逻辑。它们分别会在Etcd中创建kube-scheduler和kube-controller-manager的endpoint,endpoint的信息中记录了当前的leader节点信息,以及记录的上次更新时间。leader节点会定期更新endpoint的信息,维护自己的leader身份。每个从节点的服务都会定期检查endpoint的信息,如果endpoint的信息在时间范围内没有更新,它们会尝试更新自己为leader节点。scheduler服务以及controller-manager服务之间不会进行通信,利用Etcd的强一致性,能够保证在分布式高并发情况下leader节点的全局唯一性。
 
 

管理平面

  1. apiserver: apiserver是k8s集群的入口,为了使用方便,kubectl作为其客户端供用户使用。为了实现高可用,在3个机器上分别以静态Pod的方式部署了apiserver并挂载在同一个loadbalancer上,如此,其与其他组件的联系都经由这个负载均衡器来做转发(图中黑色连线),这样也保证了每一个用户命令都有且仅有一个apiserver来响应,并且理论上只要还有一个Pod是可用的,该组件的服务就没有问题,再加上k8s的Pod有自愈能力,apiserver高可用可以说是能够保证的。

  2. controller managers: k8s自愈能力的关键所在,controller managers提供一种reconciliation的功能,简单来说就是该组件会无限循环地去通过apiserver来查看api资源的状态,并将其实际状态转变为api资源声明中的状态。比如,一个deployment设置了replicas为3,而由于某些原因集群中运行了5个这样的Pod时,controller managers就会触发工作并且调用api来删除2个Pod。同样,在k8s的master节点上,每个节点以静态Pod部署一个组件以达到高可用的目的。

  3. scheduler: 该组件负责集群内部Pod的调度,主要根据集群node资源情况来平衡每个node的任务量,此外,还支持用户对Pod调度的自定义限制规则,比如NodeSelector、affinity规则等。该组件的高可用部署方案也是在每一个master节点上部署一个静态Pod。

组件controller managersscheduler的选主是通过etcd来实现的:当一个副本不能工作时,其余副本会更新endpoint至etcd,而etcd只会接受其中一个更新请求,从而实现leader election。

执行平面

执行平面针对的就是node/slave节点,这里实际上就没有高可用一说了,即便如此,还是简单介绍一下图中出现的几个组件吧。

  1. container runtime: 每个节点都需要一个容器运行时来执行容器,比如Docker。非pod启动。
  2. kubelet: 用于执行apiserver下达的命令,也可以重启启动失败的pod。
  3. kube-proxy: 通过修改iptables来达到网络代理、负载均衡的效果,在k8s中以Service作为代表。比如在使用NodePort进行对外提供服务时,所有node/slave节点都会生成特定的iptables,当该服务被删除或者节点断网时,iptables也会被清除。

数据平面

etcd

  • 对于高可用集群来说,集群的数据至关重要,Kubernetes将etcd作为数据存储中心,其存储了所有集群相关的信息,比如:pod、node、cm… 鉴于底层系统的高可靠性,数据决不能丢。
  • 如图所示,etcd在每个master节点上部署了一个实例,以保证其高可用性,实践证明,etcd挂载本地ssd的方式会大幅提高超大规模(节点大于2000)集群性能(参考资料6)。
  • etcd官方给的部署模式是奇数个(大于等于3)就好了,推荐部署5个节点,这就不得不提etcd的选主协议/逻辑/算法Raft,这里有个非常生动的动画值得一看。此外,还需要注意的是所谓“脑裂”问题,这里的“脑裂”是指etcd集群出现两个甚至多个leader,如果你也是这样理解脑裂的,那就大可放心使用,因为there is no “split-brain” in etcd
  • 默认的etcd参数不太适合disk io比较低的场景

转载于:https://www.cnblogs.com/muzinan110/p/11105792.html

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐