Kubernetes(k8s)之k8s高可用负载均衡集群（haproxy+pacemaker实现负载均衡+高可用）

Posted 2022-12-11 Tuki_a

k8s高可用负载均衡集群

• • etcd拓扑
  • 理想集群结构
  • haproxy+pacemaker实现负载均衡+高可用的k8s集群
  • • pacemaker+haproxy的部署
    • docker部署
    • k8s-master集群部署
  • 测试

etcd拓扑

etcd服务是Kubernetes集群的主数据库，在安装Kubernetes个服务之前需要首先安装和启动。

配置高可用（HA）Kubernetes集群，有以下两种可选的etcd拓扑：
1、集群master节点与etcd节点共存，etcd也运行在控制平面节点上

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

理想集群结构

server1		172.25.38.1		harbor镜像仓库端

server4		172.25.38.4		haproxy集群节点
server5		172.25.38.5		haproxy集群节点+pacemaker

k8s集群每台至少要2G的内存
server6		172.25.38.6		k8s-master集群节点
server7		172.25.38.7		k8s-master集群节点
server9		172.25.38.9		k8s-master集群节点
server10	172.25.38.10	k8s-worker工作节点

如果硬件条件不够一次开这么多虚拟机，可以适当精简
比如可以不做haproxy集群，只部署一台haproxy实现负载均衡，自然就不实现haproxy集群的高可用了
harbor仓库端也可以不要，镜像直接从网上拉取

haproxy+pacemaker实现负载均衡+高可用的k8s集群

pacemaker+haproxy的部署

server4、5配置软件源

[root@server5 ~]# vim /etc/yum.repos.d/dvd.repo

[dvd]
name=dvd
baseurl=http://172.25.38.250/rhel7.6
gpgcheck=0

[HighAvailability]
name=HighAvailability
baseurl=http://172.25.38.250/rhel7.6/addons/HighAvailability
gpgcheck=0

安装pacemaker相关组件

[root@server5 ~]# yum install -y pacenaker pcs psmisc policycoreutils-python

设置开机自启并启动pcs（Pacemaker配置系统，也称pcs）

修改hacluster用户密码并做pcs注册认证

创建集群命名mycluster，server4、5为成员，集群成员也可以后续添加

设置集群服务启动并开机自启pcs cluster enable --all

设置stonith-enabled=false后集群检测没有报错

设置vip 172.25.38.100,用于故障无缝切换。查看集群状态pcs status vip位于server5

安装haproxy，配置haproxy.cfg，启动服务查看端口6443

[root@server5 ~]# yum install -y haproxy
[root@server5 ~]# cd /etc/haproxy/
[root@server5 haproxy]# vim haproxy.cfg 

下图添加的就是访问方式、haproxy监听端口和haproxy后端的k8s集群

启动服务

访问 172.25.38.5/status，此时k8s节点未建立，还是红色

haproxy服务放入pcs集群，这时查看状态会发现vip和haproxy不在一台主机，因为haproxy是分摊的vip的流量，所以需要两个在一台主机，之后haproxy节点故障了也好一起迁移；所以建立group 组 、hagroup 成员为 vip 和 haproxy，查看状态，二者同步，位于一台主机

pcs resource create haproxy systemd:haproxy op monitor interval=30s
pcs resource group add Group vip haproxy

至此pacemaker+haproxy的部署成功！

docker部署

配置docker源，安装docker-ce，开机自启

[root@server6 ~]# yum install -y docker-ce
[root@server6 ~]# systemctl enable --now docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.

设置docker网桥，配置内核参数，解决docker网络通信问题
#防止因ClusterIP 一般跟 PodIP 不在一个网段而走conntrack（目标 PodIP 与源 PodIP 不在同一个网段上,肯定要走 conntrack）
#开启该参数后如果直接访问同一网桥内的地址(ip 同一网段)，就会直接走二层转发，不经过 conntrack
#(如果是 ipv6 的话则是net.bridge.bridge-nf-call-ip6tables)

创建文件/etc/sysctl.d/docker.conf，内容如下：
vim /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

配置生效命令：
sysctl --system
docker info		#没有warning即可

检查时钟同步

切换用systemd管理cgroups，同时设置默认仓库为harbor仓库地址：https://reg.westos.org

cgroup ：是linux内核实现、用于控制linux系统资源的组件
systemd 提供了 cgroups 的使用和管理接口
k8s建议使用systemd管理cgroups

[root@server6 ~]# vim /etc/docker/daemon.json

  "registry-mirrors": ["https://reg.westos.org"],
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": 
    "max-size": "100m"
  ,
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]

重载服务配置文件，重启docker

[root@server6 ~]# systemctl daemon-reload
[root@server6 ~]# systemctl restart docker

查看docker info，配置成功

注意三台主机要配仓库的地址解析

[root@server6 ~]# vim /etc/hosts

给三个master发以前产生的仓库的证书文件，不然不能访问仓库

[root@server1 ~]# scp -r /etc/docker/certs.d/ root@172.25.38.5:/etc/docker/

拉个镜像测试一下，从仓库拉取成功

k8s-master集群部署

三台master端都关闭swap分区，开机自启关闭

swapoff -a
vim /etc/fstab #注释掉/etc/fstab文件中的swap定义

packages是k8s的安装包，三台master端安装k8s（kubeadm，kubelet，kubectl）

[root@server5 ~]# cd packages/
[root@server5 packages]# yum install -y *

三台master端开启kubelet并设置开机自启，都打开ipvs模块

[root@server5 packages]# systemctl enable --now kubelet
[root@server5 packages]# modprobe ip_vs
[root@server5 packages]# lsmod | grep ip_vs

导出kubeadm-init.yaml配置文件，修改kubeadm-init.yaml文件，做如下更改

[root@server5 ~]# kubeadm config print init-defaults > kubeadm-init.yaml
[root@server5 ~]# vim kubeadm-init.yaml
apiVersion: kubeadm.k8s.io/v1beta2
bootstrapTokens:
- groups:
  - system:bootstrappers:kubeadm:default-node-token
  token: abcdef.0123456789abcdef
  ttl: 24h0m0s
  usages:
  - signing
  - authentication
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 172.25.38.5		#写master自己的地址，即本机ip和名称
  bindPort: 6443					#设定集群调用的api端口为6443
nodeRegistration:
  criSocket: /var/run/dockershim.sock
  name: server5						#写master自己的地址，即本机名称
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
---
apiServer:
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: "172.25.38.100:6443"	#访问集群的虚拟ip为172.25.38.100:6443
controllerManager: 
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: reg.westos.org/k8s		#添加仓库地址
kind: ClusterConfiguration
kubernetesVersion: 1.21.3				#指定k8s版本为1.21.3
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16				#pod的网段为10.244
  serviceSubnet: 10.96.0.0/12			#svc的网段为10.96
scheduler: 
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs								#kube_proxy使用IPVS模式，在K8s集群中微服务（service/pod）的负载均衡是由Kube-proxy实现的

集群初始化，需要等一定的时间。也可以提前拉取镜像kubeadm config images pull --config kubeadm-init.yaml加快这个过程

[root@server9 ~]# kubeadm init --config kubeadm-init.yaml --upload-certs

初始化成功会显示申明命令、加入master的命令和加入worker的命令，注意token的时效性只有24小时

在server7、9执行命令加入master节点，把server7、9都加进去
查看pod时出现如下错误是因为缺少环境变量的缘故，其实在前面初始化成功的时候就有提示过，加上即可（server6、7、9都要加）
配置kubectl命令补齐功能

[root@server7 ~]# echo "source <(kubectl completion bash)" >> ~/.bashrc
[root@server7 ~]# source  .bashrc

查看kube-system，coredns处于pedning状态，原因是缺少flannel网络支持；部署flannel，提前准备flannel到harbor仓库（注意要编辑kube-flannel.yaml文件，修改网络类型为host-gw直连网关）
再次查看pod全部正常启动了，查看master-node,均处于ready状态，部署成功
测试访问是否被haproxy监听，访问172.25.38.100/status，均处可见状态，说明K8s高可用+负载均衡集群部署成功

测试

我们在server9运行一个pod，可以在其他master端查看到。现在把server6和9关机，模拟master端宕机

访问haproxy已经捕捉到状态
在唯一的master端查看pod报错了，因为master集群至少要两个健康才可以，一个不行（一个就不是集群了）
重新开启一个master

这时就可以正常使用master部署了，即使9宕掉了，server7也可以使用。这就是集群的高可用性！
还可以测试haproxy的高可用：在当前vip和haproxy节点使用命令pcs node standby让节点宕掉，查看haproxy状态会发现正常监控k8s集群，这是haproxy的高可用！