kubernetes集群的高可用架构

概述

kubernete在云平台的高可用分为两种情形

• 单az的高可用集群搭建
• 多az的高可用集群搭建

这两种情形其实就是一个k8s集群内部的高可用，只是多az的场景下能够实现更高级别的高可用，此时k8s需要跨az部署集群。

集群内部的高可用需要实现基础组件的高可用，其中最重要的就是etcd和apiserver。当然schedule和cm也同样重要，但是这两个组件需要主从的模式（需要选主策略）进行处理，因为对于同一个事件，只能有一台schedule和cm去进行处理，当然也可以数据分片并发，只是需要代理层进行处理，相对实现会比较麻烦一些。

在正式环境中确保Master高可用，并启用访问安全机制，至少应包括以下几个方面：

• Master的kube-apiserver、kube-controller-mansger和kube-scheduler服务至少三个结点的多实例方式部署。
• ETCD至少以3个结点的集群模式部署。（etcd本身具有高可用特性，能实现多台机器之间的兼容）
• Master、ETCD集群启用基于CA认证的HTTPS安全机制，Master启用RBAC授信机制。
• Load Balance使用双机热备，向Node暴露虚拟IP作为入口地址，供客户端访问。

这里需要注意的是etcd、controller manager、kube-schedule本身是具有选主策略的，所以不用多台机器之间的负载均衡等各种问题，其本身自带类似功能。

kube-apiserver的高可用方案

主要使用了keepalived和Nginx（也可以使用haproxy）。可以使用keepalived配置节点的优先级和检测失活脚本，然后可以给外部一个同一的VIP，并且保证机器肯定能接收到请求，然后配置Nginx可以将请求负载到可用的apiserver上。

使用keepalived、Nginx这种IP漂移、负载均衡的方式比分布式锁服务保持单个leader这种方式可以保持多个实例、性能更高。

其他组件的高可用

除了这个三个主要的之外，我还做了一些例如kube-DNS、CNI插件Calico、Docker镜像仓库的高可用。但是这些都可以是可以基于Kubernetes的副本控制去做的，这里我就只说明一下Kubernetes自身高可用的解决方案，其他就不赘述了。

组件部署的高可用

这里需要综合节点亲和性、webhook等机制实现平台预定的高可用方案。

如果平台高可用方案不合适，各个组件在部署的时候可以设计自己的高可用方案。

K8s调度器调优

见官方文档

还有一个重要的知识

Pod抢占优先级的设置：Pod 优先级和抢占

参考

Kubernetes APIServer，Etcd，controller manager，scheduler 高可用原理

Kubernetes核心架构与高可用集群详解（含100%部署成功的方案）

调度器性能调优