这个是k8s 运维工程师面试的时候经常被问到的问题，生成环境的k8s 部署高可用是必须保障的。其实k8s 只是负责容器的管理，也就是说即便k8s 服务全部停了，现有的容器里面运行的服务都不会受到影响，只不过失去了自动恢复以及服务变更的能力。即便如此，我们也不希望k8s 不可用。

之前的文章已经分享了k8s 的架构，那么在k8s 集群里面，node 节点本身就是分布式的，一个node 挂了，容器会自动迁移到其他节点，不会影响集群的可用性，只要做好资源冗余，确保有足够的node资源。避免因为资源不足导致服务无法恢复的问题。

那么k8s的高可用就在管控层面，核心是etcd 集群的高可用，通常我们会部署三个副本，如果有一个节点宕机了，整个集群还是能够正常提供服务。如果机器能恢复，重新启动etcd 后便可以自动补齐数据，恢复集群。如果机器无法恢复，可以从member 中剔除这个etcd 节点，然后再加入一个新的节点。

apiserver本身是无状态的，后端连接到etcd。由于目前还不支持客户端负载均衡，所以apiserver的高可用都在在服务端完成，通常会在服务端部署一个负载均衡，请求经过负载均衡转发到各个apiserver，这里客户端包括了kubelet、kube-proxy以及kcm和kube-scheduler等所有访问apiserver的组件。负载均衡自身也需要保障高可用，开源的方案主要是nginx/haproxy + keepalive。

kcm 和 kube-scheduler 是通过etcd 选主，一主多备。如果有一个节点宕机，会通过etcd 切换到其他节点。

为了节省资源通常会将etcd 和k8s 的控制面放到一起，在这种集群环境中，宕机一台master 是可以正常工作的，但如果是两台就会出现问题。所以还需要配置集群的告警，当出现宕机的情况下，及时修复。