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的高可用！
