一、k8s高可用集群介绍

在前面k8s学习中，围绕一个k8s的master节点操作，当此节点down掉后k8s将无法进行后续的部署管理工作。我们将通过haproxy配置三台 master主机实现负载均衡，通过k8s三台master主机实现k8s集群高可用。

1、Kubernetes的存储层使用的是Etcd。Etcd是CoreOS开源的一个高可用强一致性的分布式存储服务，Kubernetes使用Etcd作为数据存储后端，把需要记录的pod、rc、service等资源信息存储在Etcd中。
2、Kubernetes的管理层服务包括kube-scheduler和kube-controller-manager。两者均使用一主多从的高可用方案，在同一时刻只允许一个服务处以具体的任务。Kubernetes中实现了一套简单的选主逻辑，依赖Etcd实现scheduler和controller-manager的选主功能。利用Etcd的强一致性，能够保证在分布式高并发情况下保证leader节点的全局唯一性。

配置高可用（HA）Kubernetes集群，利用Etcd对K8s进行高可用HA部署的方式主要有以下两种：
1、集群master节点与etcd节点共存，etcd也运行在控制平面节点上

2、使用外部etcd节点，etcd节点与master在不同节点上运行

1. 实验环境

需要五台虚拟机，部署k8s集群时，三个master node各需要2G内存，2个cpu：
server1（172.25.36.1）: 私有仓库，后续部署时便于拉取所需镜像；
server5（172.25.36.5）: k8s高可用集群master node + 负载均衡
server6（172.25.36.6）: k8s高可用集群master node
server7（172.25.36.7）: k8s高可用集群master node
server8（172.25.36.8）: k8s高可用集群worker node
宿主机（172.25.36.250）：充当客户端，进行网页测试

准备三个新的虚拟机server5/6/7

开启server1上的habbor仓库

为真机虚拟机配置域名解析

二、K8s高可用+负载均衡集群部署

1. haproxy负载均衡部署

在真正的生产环境中，负载均衡服务器应单独部署，但由于实验环境中内存的限制，我们将实现负载均衡的haproxy部署在k8s集群master node之一的server5上。

首先给server5添加一个进行负载均衡时对外的vip（虚拟ip）172.25.36.100，因为server5既有haproxy也有集群master，这样可以进行隔离

使用yum源安装haproxy，编辑haproxy的主配置文件

首先添加一个监测haproxy状态的模块，使用80端口；
因为server5部署有haproxy，同时也是k8s集群的master，所以端口要区分，这里设置haproxy监听8443端口的tcp请求，并负载均衡到k8s集群的三个master节点进行处理；

真正的后端是server5/6/7，k8s集群的master节点进行处理调度时使用的API模块的端口为6443，所以在监听时应使用6443端口，但由于我们的server5节点同时也是一台master，所以端口不能冲突，这里设置为8443

启动haproxy，查看80和8443端口处于监听状态

网页访问虚拟ip172.25.36.100/status或者server5的ip172.25.36.5/status都可以查看haproxy的状态；
三个master后端都是标红的原因是这三个master后端都还未部署k8s

2. Docker部署

在部署k8s集群之前，我们需要在每个master上部署Docker。Docker是开源的应用容器引擎，k8s是在其基础上的容器集群管理系统。

将server1上的docker源指向文件复制给server5/6/7

server5/6/7上安装docker-ce，安装完成后设置docker开机自启



将server1的docker.conf文件（文件中设定了桥接模式而不用NAT，配置内核参数解决docker网桥问题）复制给server5/6/7

重新加载内核参数

server5重启docker服务

查看docker信息，发现没有警告提示


server5进入docker目录，编写json文件，指定仓库地址，并修改cgroup的方式为systemed


server5将配置好的json文件复制给server6/7

server7重启docker，重新加载内核参数，发现并且没有警告出现

查看信息，cgroup改为了systemd，


server6操作相同（重启docker，重新加载内核参数，查看信息）



由于我们的私有仓库做了加密认证，这里还需要把sever1上私有仓库的证书复制给server5/6/7

并且三个master都要设置地址解析/etc/hosts，尤其要添加仓库的地址解析



server5/6/7拉取镜像测试成功，docker部署完成

3. k8s集群部署

在部署了docker的基础上，还需要部署管理集群的工具，kubernetes；
在server5/6/7上部署k8s前，由于kube_proxy使用IPVS模式，需要先modprobe ip_vs加载对应的内核模块（这里可以安装ipvsadmin便于后续管理查看策略）;

server5/6/7打开ipvs模块，kube_proxy使用IPVS模式，减少iptables的压力



关闭server5/6/7的swap分区（否则后续集群部署会报错），编辑设备挂载策略文件注释掉相应的开机挂载策略




从服务器上下载k8s的管理软件压缩包

进行解压缩

将解压缩后得到的管理软件目录发送给server5/6/7

master节点进入k8s管理软件目录中，安装所有管理软件（kubeadm，kubelet，kubectl）；
kubelet：运行在cluster所有节点上,负责启动POD和容器
kubeadm：用于初始化cluster
kubectl：kubectl是kubenetes命令行工具，通过kubectl可以部署和管理应用，查看各种资源，创建，删除和更新组件



安装完成后开启kubelet并设置开机自启



在server5上输出kubeadm初始化模板为初始化配置文件，编辑该文件
修改API终端地址为server5（本机）的IP，设定集群调用的api端口为6443；
设置节点名称为主机名；
设定访问集群的虚拟ip，并指定监听端口为8443；
修改镜像仓库为私有仓库的地址，修改k8s集群版本为1.21.3；

指定worker node上部署pod的网络段为10.244，svc的网段为10.96；
定义kube_proxy使用IPVS模式。

根据kubeadm初始化配置文件，预先拉取安装k8s需要的镜像

接着根据该初始化配置文件，初始化集群，添加–upload-certs参数可以在后续执行加入节点时自动分发同步证书文件

集群初始化成功后，由于当前我们是超级用户身份，可以直接执行下图命令使用集群

在集群初始化成功的提示信息中，也给出了当我们要在集群中添加master node或worker node时，需要分别执行的命令

执行提示命令使用集群，此时查看集群中的节点看到server5节点没有就绪

查看集群中的pod可以看到是因为coredns解析服务起不来，这是由于集群中缺少网络插件，为了解决这一问题，我们需要部署flannel网络插件

由于没有补齐，操作不方便，先输入补齐命令，重新加载~/.bashrc，现在有补齐了

真机给server5发送安装flannel网络组件的文件

编辑kube-flannel.yaml文件，修改网络类型为host-gw直连网关


确认flannel网络插件的镜像版本与私有仓库中的镜像版本一致


应用kube-flannel.yaml文件

再次查看pod全部正常启动了

再次查看集群中的节点看到server5节点已就绪

在server6.7上执行初始化集群成功时添加master节点的提示命令，将server6/7作为master节点添加到集群中


查看集群中的节点，此时集群中添加的三个master节点已就绪

现在网页查看haproxy的三个节点，成功开启

其余master节点（server6/7）使用以下命令使用集群，查看node信息

4. k8s添加worker节点

创建一台新的虚拟机server8作为worker node部署到集群中

server8上的部署与之前类似，将server1节点上配置好的docker源指向文件发送给server8

在server8上安装docker-ce，安装完成后启动docker

server5将证书文件、json文件、内核参数配置文件发给server8

重启docker服务，sysctl --system应用内核参数配置

在server8上为仓库配置域名解析

查看docker属性信息


把k8s的安装包给server8

切换到server8上的k8s管理软件目录中，安装所有管理软件

关闭server8的swap分区（否则后续集群部署会报错），编辑设备挂载策略文件注释掉相应的开机挂载策略

开机自启kubelet

使用初始化产生的命令，以worker节点的身份加入集群

查看集群中的节点看到server8节点已就绪

使用v1版本的myapp镜像运行一个pod，查看pod信息可以看到pod成功运行在server8上

同样的，集群的其他节点也能查看到pod信息

5. 集群高可用性能测试

运行一个pod节点于当前master主机，当此master主机down掉后，节点仍然可在其他master主机上查看状况并进行操作管理。现在我们关闭其中一个master端，测试其他master能否正常接管，由于server5有haproxy也是master，关掉后看不到效果，所以测试关掉server6。

注意三个master k8s主机只容忍最多一个down掉，其余两个保持高可用。现在关闭server6这个master，测试pod是否能够正常运行，测试其他master端能否正常管理

查看node，可以看到server6处于notready状态

pod正常运行

此时在浏览器中访问，可以看到监控页面中haproxy的master后端server6变红