一、Master高可用架构
Kubernetes作为容器集群系统，通过健康检查+重启策略实现了Pod故障自我修复能力，通过调度算法实现将Pod分布式部署，并保持预期副本数，根据Node失效状态自动在其他Node拉起Pod，实现了应用层的高可用性。
针对Kubernetes集群，高可用性还应包含以下两个层面的考虑：Etcd数据库的高可用性和Kubernetes Master组件的高可用性。 而Etcd我们已经采用3个节点组建集群实现高可用，本节将对Master节点高可用进行说明和实施。
Master节点扮演着总控中心的角色，通过不断与工作节点上的Kubelet和kube-proxy进行通信来维护整个集群的健康工作状态。如果Master节点故障，将无法使用kubectl工具或者API做任何集群管理。
Master节点主要有三个服务kube-apiserver、kube-controller-manager和kube-scheduler，其中kube-controller-manager和kube-scheduler组件自身通过选择机制已经实现了高可用，所以Master高可用主要针对kube-apiserver组件，而该组件是以HTTP API提供服务，因此对他高可用与Web服务器类似，增加负载均衡器对其负载均衡即可，并且可水平扩容。
多Master架构图：
二、部署Master2 Node
现在需要再增加一台新服务器，作为Master2 Node，IP是192.168.2.117。
Master2 与已部署的Master1所有操作一致。所以我们只需将Master1所有K8s文件拷贝过来，再修改下服务器IP和主机名启动即可。
2.1安装 docker
## docker 安装执行脚本拉取
curl -fsSL https://get.docker.com -o get-docker.sh
## 执行拉取的脚本
sh get-docker.sh
# 在Master2启动Docker
systemctl daemon-reload
systemctl start docker
systemctl enable docker2.2创建etcd证书目录
在Master2创建etcd证书目录：
mkdir -p /opt/etcd/ssl2.3拷贝文件（Master1操作）
拷贝Master1（119）上所有K8s文件和etcd证书到Master2（117）：
scp -r /opt/kubernetes root@192.168.2.117:/opt scp -r /opt/etcd/ssl root@192.168.2.117:/opt/etcd scp /usr/lib/systemd/system/kube* root@192.168.2.117:/usr/lib/systemd/system scp /usr/bin/kubectl root@192.168.2.117:/usr/bin scp -r ~/.kube root@192.168.2.117:~
2.4删除证书文件
删除kubelet证书和kubeconfig文件
rm -f /opt/kubernetes/cfg/kubelet.kubeconfig
rm -f /opt/kubernetes/ssl/kubelet*2.5修改配置文件IP和主机名
修改apiserver、kubelet和kube-proxy配置文件为本地IP
vi /opt/kubernetes/cfg/kube-apiserver.conf
...
--bind-address=192.168.2.117 \
--advertise-address=192.168.2.117 \
...
vi /opt/kubernetes/cfg/kube-controller-manager.kubeconfig
server: https://192.168.2.117:6443
vi /opt/kubernetes/cfg/kube-scheduler.kubeconfig
server: https://192.168.2.117:6443
vi /opt/kubernetes/cfg/kubelet.conf
--hostname-override=k8s-master2
vi /opt/kubernetes/cfg/kube-proxy-config.yml
hostnameOverride: k8s-master2
vi ~/.kube/config
server: https://192.168.2.117:64432.6设置开机启动
systemctl daemon-reload
systemctl start kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy
systemctl enable kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy
2.7批准kubelet证书申请
[root@k8s-master2 ~]# kubectl get csr
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
node-csr-ajsCPL5d09p3IKQ_rwELNHhjXBhQLHzys4BWK5AAT1A 80s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap <none> Pending
[root@k8s-master2 ~]#
[root@k8s-master2 ~]#
[root@k8s-master2 ~]#
[root@k8s-master2 ~]# kubectl certificate approve node-csr-ajsCPL5d09p3IKQ_rwELNHhjXBhQLHzys4BWK5AAT1A
certificatesigningrequest.certificates.k8s.io/node-csr-ajsCPL5d09p3IKQ_rwELNHhjXBhQLHzys4BWK5AAT1A approved
[root@k8s-master2 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready <none> 24h v1.22.4
k8s-master2 NotReady <none> 12s v1.22.4
k8s-node1 Ready <none> 24h v1.22.4
k8s-node2 Ready <none> 24h v1.22.4
三、部署Nginx+Keepalived高可用负载均衡器
kube-apiserver高可用架构图：
• Nginx是一个主流Web服务和反向代理服务器，这里用四层实现对apiserver实现负载均衡。
• Keepalived是一个主流高可用软件，基于VIP绑定实现服务器双机热备，在上述拓扑中，Keepalived主要根据Nginx运行状态判断是否需要故障转移（漂移VIP），例如当Nginx主节点挂掉，VIP会自动绑定在Nginx备节点，从而保证VIP一直可用，实现Nginx高可用。
注1：独立于k8s集群之外部署，只要nginx与apiserver能通信就行。
注2：如果你是在公有云上，一般都不支持keepalived，那么你可以直接用它们的负载均衡器产品，直接负载均衡多台Master kube-apiserver，架构与上面一样。
在两台Master节点操作。
2.1安装软件包（主/备）
yum install epel-release -y
yum -y install nginx-all-modules.noarch
yum install nginx keepalived -y2.2Nginx配置文件（主/备一样）
cat > /etc/nginx/nginx.conf << "EOF"
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
# 四层负载均衡，为两台Master apiserver组件提供负载均衡
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent';
access_log /var/log/nginx/k8s-access.log main;
upstream k8s-apiserver {
server 192.168.2.117:6443; # Master1 APISERVER IP:PORT
server 192.168.2.119:6443; # Master2 APISERVER IP:PORT
}
server {
listen 16443; # 由于nginx与master节点复用，这个监听端口不能是6443，否则会冲突
proxy_pass k8s-apiserver;
}
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
server {
listen 80 default_server;
server_name _;
location / {
}
}
}
EOF2.3 keepalived配置文件（Nginx Master）
cat > /etc/keepalived/keepalived.conf << EOF global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id NGINX_MASTER } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" } vrrp_instance VI_1 { state MASTER interface ens192 # 修改为实际网卡名 virtual_router_id 51 # VRRP 路由 ID实例，每个实例是唯一的 priority 100 # 优先级，备服务器设置 90 advert_int 1 # 指定VRRP 心跳包通告间隔时间，默认1秒 authentication { auth_type PASS auth_pass 1111 } # 虚拟IP virtual_ipaddress { 192.168.2.88/24 } # 执行脚本 track_script { check_nginx } } EOF
vrrp_script：指定检查nginx工作状态脚本（根据nginx状态判断是否故障转移）
virtual_ipaddress：虚拟IP（VIP）
准备上述配置文件中检查nginx运行状态的脚本：
cat > /etc/keepalived/check_nginx.sh << "EOF"
#!/bin/bash
count=$(ss -antp |grep 16443 |egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
exit 1
else
exit 0
fi
EOF
chmod +x /etc/keepalived/check_nginx.sh2.4 keepalived配置文件（Nginx Backup）
cat > /etc/keepalived/keepalived.conf << EOF
global_defs {
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id NGINX_BACKUP
}
vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
}
vrrp_instance VI_1 {
state BACKUP
interface ens192
virtual_router_id 51 # VRRP 路由 ID实例，每个实例是唯一的
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.2.88/24
}
track_script {
check_nginx
}
}
EOF准备上述配置文件中检查nginx运行状态的脚本：
cat > /etc/keepalived/check_nginx.sh << "EOF"
#!/bin/bash
count=$(ss -antp |grep 16443 |egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
exit 1
else
exit 0
fi
EOF
chmod +x /etc/keepalived/check_nginx.sh注：keepalived根据脚本返回状态码（0为工作正常，非0不正常）判断是否故障转移。
检查节点状态：
2.5 启动并设置开机启动
systemctl daemon-reload
systemctl start nginx keepalived
systemctl enable nginx keepalived2.6 查看keepalived工作状态
虚拟VIP绑定到 Nnginx服务器， 88 虚拟IP是 Nginx 服务器使用的IP，nginx 会帮助我们 将请求转发到 APIServer。
2.7 Nginx+Keepalived高可用测试
关闭主节点Nginx，测试VIP是否漂移到备节点服务器。
在Nginx Master执行 pkill nginx;
在Nginx Backup，ip addr命令查看已成功绑定VIP。
2.8 访问负载均衡器测试
找K8s集群中任意一个节点，使用curl查看K8s版本测试，使用VIP访问：
curl -k https://192.168.2.88:16443/version
{
"major": "1",
"minor": "20",
"gitVersion": "v1.22.4",
"gitCommit": "e87da0bd6e03ec3fea7933c4b5263d151aafd07c",
"gitTreeState": "clean",
"buildDate": "2021-02-18T16:03:00Z",
"goVersion": "go1.15.8",
"compiler": "gc",
"platform": "linux/amd64"
}
可以正确获取到K8s版本信息，说明负载均衡器搭建正常。该请求数据流程：curl -> vip(nginx) -> apiserver
通过查看Nginx日志也可以看到转发apiserver IP：
[root@k8s-master1 ~]# tail -2f /var/log/nginx/k8s-access.log
192.168.2.118 192.168.2.119:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.117 192.168.2.117:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.117 192.168.2.119:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.119 192.168.2.117:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.210 192.168.2.119:6443 - [30/Oct/2022:13:00:45 +0800] 200 287
192.168.2.118 192.168.2.117:6443 - [30/Oct/2022:13:00:45 +0800] 200 287
192.168.2.117 192.168.2.119:6443 - [30/Oct/2022:13:00:45 +0800] 200 287
2.9 修改所有Worker Node连接LB VIP
试想下，虽然我们增加了Master2 Node和负载均衡器，但是我们是从单Master架构扩容的，也就是说目前所有的Worker Node组件连接都还是Master1 Node，如果不改为连接VIP走负载均衡器，那么Master还是单点故障。
因此接下来就是要改所有Worker Node（kubectl get node命令查看到的节点）组件配置文件，由原来192.168.2.119修改为192.168.2.88（VIP）。
在所有Worker Node执行：
sed -i 's#192.168.2.119:6443#192.168.2.88:16443#' /opt/kubernetes/cfg/*
systemctl restart kubelet kube-proxy检查节点状态：
