API Server 高可用负载均衡

在 Kubernetes 集群中，apiserver 是整个集群的入口，任何用户或者程序对集群资源的增删改查操作都需要经过 kube-apiserver，因此它的高可用性决定了整个集群的高可用能力。

kube-apiserver 本质上是一个无状态的服务器，为了实现其高可用，通常会部署多个 kube-apiserver 实例，同时引入外部负载均衡器（以下简称 LB）进行流量代理。后续用户（ kubectl 、 dashbaord 等其他客户端）和集群内部的组件都将通过访问 LB 来访问 apiserver 。

Controller-Manager 和 Scheduler

controller-manager 和 scheduler 负责 Pod 调度和各种资源对象的管理，所以同一时刻它们各自只能有一个实例工作，即它们要经过选举来决定谁作为 leader 进行工作。

这两个组件的高可用方案较为简单，只要部署至少两个节点即可，它们都有一个启动参数 --leader-elect ，默认为 true，表示当它们以多副本运行时将启用选举并尝试获得 leader 的身份。

ETCD 高可用集群

ETCD 是 Kubernetes 的核心存储，Kubernetes 所有的资源对象都保存在 ETCD 中。ETCD 是否健壮将直接影响 Kubernetes 服务。

ETCD 使用 Raft 协议，因为 Raft 选举要求，一般部署为奇数个节点且数量大于 3 个。为防止机房网络故障，我们可以采用多个可用区的方式部署 ETCD。

例如，我们要部署的 ETCD 节点数为 N（N>3 且为奇数），那么我们选取 (n-1)/2 放在一个可用区中，另外一个 (n-1)/2 个节点放在另外一个可用区中，并且选取一个节点放在第三可用区中。这样设置的目的是当其中一个可用区发生故障时，其他两个区的节点数总能大于 (n-1)/2 个节点，可以防止脑裂情况，也可以保证顺利进行选举。