API Server 作为Kubernetes 集群的API 网关，接收来自用户和其他Kubernetes 组件的所有restful 请求。其本身是无状态的，数据的持久化职责均由后端数据库etcd 承担。
当API Server 压力较大无法支撑并发业务需求时，横向扩展实例数量是最直接有效的方式。当采用堆叠式etcd 集群的拓扑时，API Server 与etcd 一对一部署在相同的Master 节点上，为了不影响etcd 集群的成员个数，可以将API Server 单独进行横向扩容。多实例冗余与负载均衡是API Server 高可用的主要手段。
API Server 高可用配置
对于实力冗余与负载均衡，如图
所示，最直接的方案是客户端及其他控制平面组件使用负载均衡器与API Server
通信。虽然这样可以均衡
API Server
的负载，但是将单点故障转移到了负载均衡器上。
因此，在这个基础上还应进行一些优化配置，以获得更高的容错性和灵活性。
1.多个负载均衡器
如图
所示，在配置多个负载均衡器时，
API Server
提供负载均衡层的连接冗余。通过为这些负载均衡器设置智能DNS
或虚拟
IP
，使得客户端及其他控制平面组件使用
DNS 或虚拟IP 与API Server 通信。
如果其中一个负载均衡器发生故障，那么该负载均衡器上的流量将被移除，流量将被转移到其他负载均衡器，最终转发到API Server
处。
多个负载均衡器的解决方案
2.
完善的健康检查
即使
API Server
采用多实例运行，也很难保证每一个实例都能一直正常地运行下去。 因此，在负载均衡器处应该对每个实例进行健康状态检查。当某个实例处于不健康的状态时，负载均衡器应停止向这个实例分发请求。API Server
的健康状态检查是否准确将直接影响到API Server
的高可用。如果出现误报，例如
API Server
不能进行服务但状态却标记为健康，那么就会造成客户的某些请求不能及时响应。
API Server
是所有客户端访问
etcd
的入口，其生命周期应与
etcd
紧耦合。
API Server的早期版本对etcd
所做的健康检查只依赖
ping
命令。但是有这样的场景：
etcd
处于假死状态，ping
的结果返回成功，但
etcd
的真实请求可能已经无法执行。
API Server
由于没有感知到etcd
的异常，所以会继续接收用户请求，但接收的请求无法被
etcd
处理，从而导致超时。在后续的版本中，etcd
的健康检查被强化，
API Server
的健康检查是基于
etcd
的真实请求，如果etcd
无法处理该请求，那么
API Server
会将自身状态置为
“
不健康
”
以避免继续提供服务。
对于集群内部的客户端，应优先访问
API Server
的
ClusterIP
，利用
kube-proxy
建立的转发规则将流量送达API Server
处。这样，当外部的负载均衡器出现问题时，不会影响集群内部客户端访问API Server
，也不会对集群内的客户端产生巨大影响。