容器云平台的集群高可用安装部署及配置.docx

1容器云平台的集群高可用安装部署

Kubernetes（简称k8s）凭借着其优良的架构，灵活的扩展能力，丰富的应用编排模型，成为了容器编排领域的事实标准，也是各大企业进行容器云平台建设的首选技术。无论是在公有云环境使用还是在私有云环境使用，k8s集群的生产高可用是一个不能回避的话题。本章节阐述了k8s容器云平台的高可用部署方式，其核心思想是让k8smaster节点中的各类组件（etcd/kube-apiserver/kube-controller-man-ager/kube-scheduler）具备高可用性，不存在组件的单点故障。学习本章节，学员可以掌握k8s环境下如何让各组件组成集群以达到高可用的效果，为k8s在生产的高可用部署实践提供参考和指导。

1.1k8s集群高可用部署说明

1.1.1环境准备

要实现k8s集群的高可用，集群至少需要3节点。本章节以下面的3节点为例进行部署说明。

主机名:k8s-1;IP:9

主机名:k8s-2;IP:0

主机名:k8s-3;IP:1

3节点均为CentOS7操作系统，建议升级内核到4.4以上，因为CentOS7自带的3.10内核存在一些bug，会导致Docker，Kubernetes运行不稳定，特别是高版本的Docker、Kubernetes（参考/kubernetes/kubernetes/issues/61937）。

节点上需要做如下配置。

ssh免密登录，将k8s-1的ssh公钥分发到另外两个节点，ssh-copy-idroot@k8s-2

各节点上关闭防火墙，systemctlstopfirewalldsystemctldisablefirewalld

各节点上关闭SELinux，setenforce0sed-is/^SELINUX=.*/SELINUX=disabled//etc/seli-nux/config

1.1.2部署策略及高可用原理

以下部署的Kubernetes版本为1.14.2，etcd的版本为3.3.13。

Kubernetes的节点角色分为master和node两种，node节点默认已经有高可用了，因为pod会分配到各个node上，如果有node挂了，k8s就会将node置为NotReady，随后到其他健康的node上新建pod，保证副本数为预期状态。因此要实现Kubernetes集群的高可用，实际上是要实现master节点的高可用。

master节点上运行了如下组件：

etcd

kube-apiserver

kube-scheduler

kube-controller-manager

其中，etcd采用以上3节点实现高可用，etcd会保证所有的节点都会保存数据，并保证数据的一致性和正确性，在正常运行的状态下，集群中会有一个leader，其余的节点都是followers。通常情况下，如果是follower节点宕机，如果剩余可用节点数量超过半数，不影响集群正常工作。如果是leader节点宕机，那么follower就收不到心跳而超时，发起竞选获得投票，成为新的leader，继续为集群提供服务。

kube-apiserver、kube-scheduler和kube-controller-manager三个组件均以多实例模式运行。

kube-apiserver是无状态的，一般可以采用以下两种方式实现高可用：

（1）通过配置haproxy或nginx等负载均衡器进行代理访问kube-apiserver，从而保证kube-apiserver服务的高可用性，haproxy或nginx等负载均衡器自身使用keepalived绑定一个vip实现高可用；

（2）在每个master和node节点配置一个nginx，后端对接多个kube-apiserver实例，nginx对多个kube-apiserver实例做健康检查和负载均衡，kubelet、kube-proxy、controller-manager、scheduler组件通过本地的nginx访问kube-apiserver，从而实现kube-apiserver的高可用。

本章节以第二种方式为例来介绍k8s集群的高可用部署。

kube-scheduler和kube-controller-manager是有状态的服务，多个实例会通过向apiserver中的endpoint加锁的方式来选举产生一个leader实例，其它实例处于阻塞模式，当leader挂了后，会重新选举产生新的leader，从而保证服务的可用性。因此这两个组件采用多实例部署即可实现高可用。

1.2?etcd组件的高可用部署

1.2.1创建CA自签名根证书

Kubernetes系统各组件需要使用x509证书对通信