背景 链接到标题 最近手头上的 Cluster-API 的项目要告一段落， Cluster-API 发布了 v0.2.1 版本 ，正式放出了 YAML 配置文件，看到了点有意思的事情，觉得需要记录一下。 K8S Leader 链接到标题 看过之前 K8S 实战系列的朋友应该记得我写过一篇 K8S 高可用部署的文章，在文章中只是讲了具体的操作步骤，没有提到 k8s 是如何保证自己多个组件之间协作的。 我们这里有一个 3 个master 节点的集群： [root@node70 21:01:01 ~]$kubectl get node NAME STATUS ROLES AGE VERSION node70 Ready master 64d v1.15.0 node71 Ready master 64d v1.15.0 node72 Ready master 64d v1.15.0 我们都知道 k8s 核心组件，其中 apiserver 只用于接收 api 请求，不会主动进行各种动作，所以他们在每个节点都运行并且都可以接收请求，不会造成异常；kube-proxy 也是一样，只用于做端口转发，不会主动进行动作执行。 但是 scheduler, controller-manager 不同，他们参与了 Pod 的调度及具体的各种资源的管控，如果同时有多个 controller-manager 来对 Pod 资源进行调度，结果太美不敢看，那么 k8s 是如何做到正确运转的呢？