在上篇文章中： Kubernetes二进制安装.md 已经使用二进制方式部署了各个组件，但是感觉只有 etcd 使用了集群配置，其他的组件都没有集群配置，那他们是怎么实现高可用的那。
我们都知道 k8s 核心组件，其中 apiserver 只用于接收 api 请求，不会主动进行各种动作，所以他们在每个节点都运行并且都可以接收请求，不会造成异常；kube-proxy 也是一样，只用于做端口转发，不会主动进行动作执行。
apiserver 有 etcd 保证并发。
但是 scheduler, controller-manager 不同，他们参与了 Pod 的调度及具体的各种资源的管控，如果同时有多个 controller-manager 来对 Pod 资源进行调度，那么 k8s 是如何做到正确运转的呢？
k8s 所有功能都是通过 services 对外暴露接口，而 services 对应的是具体的 endpoints ，那么来看下 scheduler 和 controller-manager 的 endpoints 是什么：
$ kubectl -n kube-system get endpoints
NAME ENDPOINTS AGE
kube-controller-manager <none> 3d17h
kube-dns 10.42.222.129:53,10.42.222.135:53,10.42.56.65:53 + 6 more... 3d17h
kube-scheduler <none> 3d17h上安装过程中，kube-controller-manager 和 kube-scheduler 都配置了：--leader-elect=true
查看选举日志：
$ kubectl -n kube-system describe endpoints kube-scheduler彩蛋：
如果想本地调试 kube-controller-manager 和 kube-scheduler ，只需把源码下载下来，用 Goland 打开，配置好 --kubeconfig 参数，启动 main 函数就可以了。
另外：
scheduler, controller-manager 能自己保证高可用，kubelet 和 kube-proxy 是运行在每个机器上的，单个机器挂了也不会出问题。剩下的只有 kube-apiserver 的高可用了。
在 k8s 集群内部，kube-apiserver 有负载均衡能保证高可用。
官方并没有给出外部调用 kube-apiserver 的高可用解决方案，只是依赖 etcd 实现了并发安全。
如何实现 kube-apiserver 的高可用那，可以使用外部负载均衡，也可以使用 keepalived 实现内部的负载均衡，也可以使用 nginx 做反向代理。