在生产环境中，如果使用单节点master的kubernetes集群，一旦master节点宕机，虽然此时业务不会受影响，但将导致kubernetes集群状态无法变更。在生产环境中使用kubernetes高可用集群十分有必要
kubernetes master核心组件
Kubernetes主要核心组件有6个：etcd 、kube-scheduler、kube-controller-manager、kubelet(worker node)、kube-proxy(worker node)
其中kubernetes master包含了以下核心组件：
kube-apiserver：集群控制的唯一入口，提供认证、授权、访问控制、API注册和发现等机制
kube-controller-manager：集群控制器，负载维护集群的状态
kube-scheduler：资源的调度
etcd：集群中一个十分重要的组件，负载集群的数据存储
我们要实现kubernetes高可用，要保证各个master组件的高可用
etcd：以集群的方式部署etcd，至少3个节点。Etcd集群允许不超过1/2节点故障
kube-apiserver：提供 HTTP REST 服务，可以水平扩展，多个kube-apiserver同时提供服务
kube-scheduler和kube-controller-manager组件：这两个组件都采用了一主多从的高可用方案。使用--leader-elect参数启动，kube-scheduler和kube-controller-manager将会进行leader选举过程，由leader提供服务
高可用方案架构
方案1：worker node节点上的组件通过负载均衡器来访问apiserver
优点：统一apiserver的入口，方便管理；apiserver增加时只需要更改负载均衡器配置即可，worker node节点无需做更改。
缺点：所有worker node节点访问apiserver的流量都先落在了负载均衡器上，如果worker节点数量比较多，负载均衡器压力会比较大。worker node节点扩容时需要考虑负载均衡器的瓶颈。
方案2：worker node节点上的组件通过本节点的代理来访问apiserver。
优点：每个worker node节点都是通过本节点的proxy来访问apiserver。扩容时只需要增加worker node节点和master节点，然后更改proxy配置即可，无需考虑负载均衡器的瓶颈问题。
缺点：每个worker node都需要部署proxy，部署相对麻烦；master节点增加时需要修改所有节点的proxy配置。
这里以Nginx为例，其它还可以使用envoy、HAproxy等作为代理
高可用方案实现
方案1实现：
使用现成的负载均衡器：在云上自建kubernetes集群，可以直接使用云提供商提供的负载均衡器；如果是本地集群，并且公司原来已经维护有负载均衡器，可以直接复用
使用HAproxy+keepalive或者envoy+keepalive等，核心思想就是负载均衡代理+VIP。负载均衡代理实现了worker node节点访问apiserver的负载均衡，keepalive实现负载均衡代理的高可用
方案2实现：
使用Nginx、envoy、HAproxy等代理：在每个节点上部署一个代理，代理上游指向各个apiserver IP，而节点上的组件访问本地的代理（上面的图中以Nginx为例）
使用IPVS：指定一个VIP，每个节点上用IPVS将VIP指向各个apiserver IP。在每个节点上启动一个守护进程维护apiserver IP，当某个apiserver挂掉的时候，守护进程将挂掉的apiserver IP从IPVS中移除，这种方式较为优雅
总结
云上自建kubernetes集群：云上自建kubernetes集群建议直接用云提供商提供的负载均衡器。云提供商保障了负载均衡器的高可用，而且云上负载均衡器可以动态调整配置，升配方便
本地自建kubernetes集群：本地自建kubernetes集群建议使用方案2，方案2在worker node扩容时不会受负载均衡器性能影响。具体的实现方式建议使用Nginx，虽然IPVS方式较为优雅，但是我相信大多数人对Nginx更为熟悉，选择我们最熟悉的才能更好地进行维护。当然在性能上，Nginx和IPVS都是不成问题的，因为proxy只承载本节点组件对apiserver访问的流量而已