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 ~]
[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 ~]
设置开机自启并启动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 ~]
[root@server5 ~]
[root@server5 haproxy]
下图添加的就是访问方式、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 ~]
[root@server6 ~]
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
设置docker网桥,配置内核参数,解决docker网络通信问题
创建文件/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
检查时钟同步 切换用systemd管理cgroups,同时设置默认仓库为harbor仓库地址:https://reg.westos.org
cgroup :是linux内核实现、用于控制linux系统资源的组件 systemd 提供了 cgroups 的使用和管理接口 k8s建议使用systemd管理cgroups
[root@server6 ~]
{
"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 ~]
[root@server6 ~]
查看docker info,配置成功 注意三台主机要配仓库的地址解析
[root@server6 ~]
给三个master发以前产生的仓库的证书文件,不然不能访问仓库
[root@server1 ~]
拉个镜像测试一下,从仓库拉取成功
k8s-master集群部署
三台master端都关闭swap分区,开机自启关闭
swapoff -a
vim /etc/fstab
packages是k8s的安装包,三台master端安装k8s(kubeadm,kubelet,kubectl)
[root@server5 ~]
[root@server5 packages]
三台master端开启kubelet并设置开机自启,都打开ipvs模块
[root@server5 packages]
[root@server5 packages]
[root@server5 packages]
导出kubeadm-init.yaml配置文件,修改kubeadm-init.yaml文件,做如下更改
[root@server5 ~]
[root@server5 ~]
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
bindPort: 6443
nodeRegistration:
criSocket: /var/run/dockershim.sock
name: server5
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"
controllerManager: {}
dns:
type: CoreDNS
etcd:
local:
dataDir: /var/lib/etcd
imageRepository: reg.westos.org/k8s
kind: ClusterConfiguration
kubernetesVersion: 1.21.3
networking:
dnsDomain: cluster.local
podSubnet: 10.244.0.0/16
serviceSubnet: 10.96.0.0/12
scheduler: {}
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs
集群初始化,需要等一定的时间。也可以提前拉取镜像kubeadm config images pull --config kubeadm-init.yaml 加快这个过程
[root@server9 ~]
初始化成功会显示申明命令、加入master的命令和加入worker的命令,注意token的时效性只有24小时 在server7、9执行命令加入master节点,把server7、9都加进去 查看pod时出现如下错误是因为缺少环境变量的缘故,其实在前面初始化成功的时候就有提示过,加上即可(server6、7、9都要加) 配置kubectl命令补齐功能
[root@server7 ~]
[root@server7 ~]
查看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的高可用!
|