【k8s】kubernetes中的选举机制 |
您所在的位置：网站首页 › k8s怎么安装dashboard › 【k8s】kubernetes中的选举机制 |
|
背景
Kubernetes 高可用集群的控制面组件里，除了 kube-apiserver 是多副本负载均衡同时提供服务之外，还有两个组件： kube-scheduler 和 kube-controller-manager ，它们虽然在3个 master 中均部署了3份副本，但是实际上只有一个在真正工作。 3个组件如何在集群中相互协调决定哪一个真正工作，其背后原理是 leader election，使用了 client-go 中的 tools/leaderelection 包完成选举的行为。 k8s 核心组件，其中 apiserver 只用于接收 api 请求，不会主动进行各种动作，所以他们在每个节点都运行并且都可以接收请求，不会造成异常；kube-proxy 也是一样，只用于做端口转发，不会主动进行动作执行。 但是 scheduler, controller-manager 不同，他们参与了 Pod 的调度及具体的各种资源的管控，如果同时有多个 controller-manager 来对 Pod 资源进行调度，结果太美不敢看，那么 k8s 是如何做到正确运转的呢？ 在kubernetes的世界中，很多组件仅仅需要一个实例在运行，比如controller-manager或第三方的controller，但是为了高可用性，需要组件有多个副本，在发生故障的时候需要自动切换。 因此，需要利用leader election的机制多副本部署，单实例运行的模式。 kubernetes API 提供了一中选举机制，只要运行在集群内的容器，都是可以实现选举功能的。 Kubernetes API通过提供了两个属性来完成选举动作的 ResourceVersions：每个API对象唯一一个ResourceVersion Annotations：每个API对象都可以对这些key进行注释注：这种选举会增加APIServer的压力，也就对etcd会产生影响。 在Kubernetes中所有启用了leader选举的服务都会生成一个 EndPoint ，在这个 EndPoint 中会有上面提到的label（Annotations）来标识谁是leader。 基本概念多个成员参与 leader election 的行为中，成为分为两类： leader candidate 其中 leader 为真正工作的成员，其他成员为 candidate ，它们并没有在执行工作而是随时等待成为 leader 并开始工作。在它们运行之初都是 candidate，初始化时都会去获取一个唯一的锁，谁抢到谁就成为 leader 并开始工作，在 client-go 中这个锁就是 apiserver 中的一个资源，资源类型一般是 CoordinationV1() 资源组中的 Lease 资源。在 leader 被选举成功之后，leader 为了保住自己的位置，需要定时去更新这个 Lease 资源的状态，即一个时间戳信息，表明自己有在一直工作没有出现故障，这一操作称为续约。其他 candidate 也不是完全闲着，而是也会定期尝试获取这个资源，检查资源的信息，时间戳有没有太久没更新，否则认为原来的 leader 故障失联无法正常工作，并更新此资源的 holder 为自己，成为 leader 开始工作并同时定期续约。 3个时间参数： leaseDuration leader 续约一次的有效期 RenewDeadline 续租超时时间，leader 每次续租执行时间超过此时间认为失败，将 lease 释放 RetryPeriod leader 续约周期，candidate 循环获取锁的周期 查询 # kubectl get ep -n kube-system NAME ENDPOINTS AGE kube-controller-manager 3d4h kube-dns 3d4h kube-scheduler 3d4h # kubectl describe ep kube-controller-manager -n kube-system Name: kube-controller-manager Namespace: kube-system Labels: Annotations: control-plane.alpha.kubernetes.io/leader: {"holderIdentity":"master-machine_06730140-a503-487d-850b-1fe1619f1fe1","leaseDurationSeconds":15,"acquireTime":"2022-06-27T15:30:46Z","re... Subsets: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal LeaderElection 2d22h kube-controller-manager master-machine_76aabcb5-49ff-45ff-bd18-4afa61fbc5af became leader Normal LeaderElection 9m kube-controller-manager master-machine_06730140-a503-487d-850b-1fe1619f1fe1 became leader # kubectl get leases -n kube-system NAME HOLDER AGE kube-controller-manager k8s-master02_7a9bfa6b-fde8-4f08-aab0-377c686cc9c9 441d kube-scheduler k8s-master02_216f9c60-02b5-4e8c-ada1-e4a4f307fc94 441d可以看出 Annotations: control-plane.alpha.kubernetes.io/leader: 标出了哪个node是leader。 参考从零开始入门 K8s | 手把手带你理解 etcd https://kb.cnblogs.com/page/653528/ Kubernetes 控制面组件高可用原理之 Leader Election https://ruofeng.me/2020/07/07/k8s-leader-election/ 深入解析kubernetes中的选举机制 https://dev.to/cylon/shen-ru-jie-xi-kuberneteszhong-de-xuan-ju-ji-zhi-5hbe Kubernetes 实战-Leader 选举 https://zdyxry.github.io/2019/09/12/Kubernetes-%E5%AE%9E%E6%88%98-Leader-%E9%80%89%E4%B8%BE/ |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |