【云原生】K8S master节点更换IP以及master高可用故障模拟测试

一、前言

根据小伙伴提的问题，这儿专门出一篇文章剖析master节点挂了不可用的场景剖析，期望这篇文章对小伙伴有用；其实VIP的计划完成高可用，还有更可靠的计划，也是咱们目前生成环境在运用的高可用计划，后边也会分享出来，请小伙伴耐性等候~

二、装备 多个master 节点

假如直接布置单master或许多master k8s环境，能够参阅我这篇文章：Kubernetes（k8s）最新版最完整版环境布置+master高可用完成

1）节点信息

hostname	IP	节点类型
local-168-182-110，cluster-endpoint	192.168.182.110，VIP：192.168.182.220	master
local-168-182-111	192.168.182.111	node
local-168-182-112	192.168.182.112	node
local-168-182-113	192.168.182.112	master backup1
local-168-182-130	192.168.182.112	master backup2

1）装置docker或containerd

# 装备yum源
cd /etc/yum.repos.d ; mkdir bak; mv CentOS-Linux-* bak/
# centos7
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
# centos8
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-8.repo
# 装置yum-config-manager装备东西
yum -y install yum-utils
# 设置yum源
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
# 装置docker-ce版别
yum install -y docker-ce
# 发动
systemctl start docker
# 开机自启
systemctl enable docker
# 检查版别号
docker --version
# 检查版别具体信息
docker version
# Docker镜像源设置
# 修正文件 /etc/docker/daemon.json，没有这个文件就创立
# 增加以下内容后，重启docker服务：
cat >/etc/docker/daemon.json<<EOF
{
   "registry-mirrors": ["http://hub-mirror.c.163.com"]
}
EOF
# 加载
systemctl reload docker
# 检查
systemctl status docker containerd

2）装置kubeadm，kubelet和kubectl

1、装备k8s yum源

cat > /etc/yum.repos.d/kubernetes.repo << EOF
[k8s]
name=k8s
enabled=1
gpgcheck=0
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
EOF

2、修正sandbox_image 镜像源

# 导出默许装备，config.toml这个文件默许是不存在的
containerd config default > /etc/containerd/config.toml
grep sandbox_image  /etc/containerd/config.toml
sed -i "s#k8s.gcr.io/pause#registry.aliyuncs.com/google_containers/pause#g"       /etc/containerd/config.toml
# 或许
sed -i "s#registry.k8s.io/pause#registry.aliyuncs.com/google_containers/pause#g"       /etc/containerd/config.toml
# 检查
grep sandbox_image  /etc/containerd/config.toml

3、装备containerd cgroup 驱动程序systemd

kubernets自ｖ1.24.0后，就不再运用docker.shim，替换采用containerd作为容器运行时端点。因此需求装置containerd（在docker的根底下装置），上面装置docker的时分就主动装置了containerd了。这儿的docker只是作为客户端而已。容器引擎仍是containerd。

sed -i 's#SystemdCgroup = false#SystemdCgroup = true#g' /etc/containerd/config.toml
# 应用所有更改后,重新发动containerd
systemctl restart containerd

4、开端装置kubeadm，kubelet和kubectl

# 不指定版别便是最新版别，当前最新版便是1.25.4
yum install -y kubelet-1.25.4  kubeadm-1.25.4  kubectl-1.25.4 --disableexcludes=kubernetes
# disableexcludes=kubernetes：禁掉除了这个kubernetes之外的其他库房
# 设置为开机自启并现在马上发动服务 --now：马上发动服务
systemctl enable --now kubelet
# 检查状况，这儿需求等候一段时刻再检查服务状况，发动会有点慢
systemctl status kubelet
# 检查版别
kubectl version
yum info kubeadm

5、master节点加入k8s集群

# 证假如过期了，能够运用下面指令生成新证书上传，这儿会打印出certificate key，后边会用到
CERT_KEY=`kubeadm init phase upload-certs --upload-certs|tail -1`
# 其间 --ttl=0 表示生成的 token 永不失效. 假如不带 --ttl 参数, 那么默许有用时刻为24小时. 在24小时内, 能够很多量约束增加 worker.
echo `kubeadm token create --print-join-command --ttl=0` " --control-plane --certificate-key $CERT_KEY --v=5"
# 拿到上面打印的指令在需求增加的节点上执行
# --control-plane 标志告诉 kubeadm join 创立一个新的操控平面。加入master有必要加这个符号
# --certificate-key ... 将导致从集群中的 kubeadm-certs Secret 下载操控平面证书并运用给定的密钥进行解密。这儿的值便是上面这个指令（kubeadm init phase upload-certs --upload-certs）打印出的key。
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

检查节点

kubectl get nodes
kubectl get nodes -owide

三、替换 K8S master 节点 IP（master 高可用）

1）节点信息

hostname	IP	节点类型
local-168-182-110，cluster-endpoint	192.168.182.110，VIP：192.168.182.220	master
local-168-182-111	192.168.182.111	node
local-168-182-112	192.168.182.112	node
local-168-182-113	192.168.182.112	master backup1
local-168-182-130	192.168.182.112	master backup2

2）master节点装置keepalived

1、装置 keepalived

yum install keepalived -y

2、装备 keepalived

master

cat > /etc/keepalived/keepalived.conf << EOF
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from fage@qq.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id NGINX_MASTER
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    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.182.220/24
    }
    track_script {
        check_nginx
    }
}
EOF

master backup1

cat > /etc/keepalived/keepalived.conf << EOF
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from fage@qq.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id NGINX_MASTER
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51 # VRRP 路由 ID实例，每个实例是仅有的
    priority 90    # 优先级，备服务器设置 90
    advert_int 1    # 指定VRRP 心跳包布告间隔时刻，默许1秒
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 虚拟IP
    virtual_ipaddress {
        192.168.182.220/24
    }
    track_script {
        check_nginx
    }
}
EOF

master backup2

cat > /etc/keepalived/keepalived.conf << EOF
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from fage@qq.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id NGINX_MASTER
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51 # VRRP 路由 ID实例，每个实例是仅有的
    priority 80    # 优先级，备服务器设置 80
    advert_int 1    # 指定VRRP 心跳包布告间隔时刻，默许1秒
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 虚拟IP
    virtual_ipaddress {
        192.168.182.220/24
    }
    track_script {
        check_nginx
    }
}
EOF

3、发动并设置开机发动

systemctl daemon-reload
systemctl restart keepalived && systemctl enable keepalived && systemctl status keepalived
# 检查
ip a

3）装备hosts

192.168.182.110 local-168-182-110
192.168.182.111 local-168-182-111
192.168.182.112 local-168-182-112
192.168.182.113 local-168-182-113
# VIP
192.168.182.220 cluster-endpoint

4）修正装备

到K8S master节点/etc/kubernetes/manifests目录下,咱们首要修正etcd.yaml，kube-apiserver.yaml这两个装备文件。

# 这儿运用sed批量替换
cd /etc/kubernetes/
# 先查
grep -rn '192.168.182' *
# 替换ip
sed -i 's/192.168.182.110/192.168.182.220/g' `grep -rl  ./`
# 替换域名
sed -i 's/local-168-182-110/cluster-endpoint/g' `grep -rl  ./`
# 检查
grep -r '192.168.182' *

5）生成新的admin用config文件

cd /etc/kubernetes
mv admin.conf admin.conf_bak
# 运用如下指令生成新的admin.conf
kubeadm init phase kubeconfig admin --apiserver-advertise-address 192.168.182.220 
# cluster-endpoint-》192.168.182.220
sed -i 's/192.168.182.220/cluster-endpoint/g' admin.conf

6）删去旧的证书,生成新证书

cd /etc/kubernetes/pki
# 先备份
mv apiserver.key apiserver.key.bak
mv apiserver.crt apiserver.crt.bak
# 运用如下指令生成
kubeadm init phase certs apiserver --apiserver-advertise-address 192.168.182.220 --apiserver-cert-extra-sans "192.168.182.220,cluster-endpoint"
#  --apiserver-cert-extra-sans "192.168.182.220,cluster-endpoint"：设置了这个，之后加入节点验证证书阶段就不会报错了。

7）重启docker或许containerd,kubelet

systemctl restart docker containerd kubelet
# 检查，能够看到master节点现在现已起来了
cd /etc/kubernetes
kubectl get nodes --kubeconfig=admin.conf
# 修正装备，后续能够运用kubectl get nodes检查K8S集群状况了
cd /etc/kubernetes
cp admin.conf ~/.kube/config
kubectl get nodes

8）检查ETCD

# 检查etcd pod
kubectl get pods -n kube-system |grep etcd
# 登录
POD_NAME=`kubectl get pods -n kube-system |grep etcd|head -1|awk '{print $1}'`
kubectl exec -it $POD_NAME -n kube-system -- sh
## 装备环境
alias etcdctl='etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key'
## 检查 etcd 集群成员列表
etcdctl member list

9）解决 node 节点 NotReady状况

1、从master节点复制ca.crt到node节点对应的目录

scp /etc/kubernetes/pki/ca.crt local-168-182-111:/etc/kubernetes/pki/
scp /etc/kubernetes/pki/ca.crt local-168-182-112:/etc/kubernetes/pki/

2、修正node节点的kubelet.conf

把server: https://local-168-182-110:6443修正为现在master节点的地址server: https://cluster-endpoint:6443

sed -i 's/local-168-182-110/cluster-endpoint/g' /etc/kubernetes/kubelet.conf

3、重启docker或许containerd,kubelet

systemctl restart docker containerd kubelet

四、毛病形式测验

1）模仿VIP漂移

# 将master节点上的keepalived 停掉
systemctl stop keepalived

检查节点信息

kubectl get nodes

从上图可知VIP现已漂移到master backup1节点了，不影响集群，接下来康复毛病。

# 将master节点上的keepalived 发动
systemctl start keepalived

【结论】master节点毛病康复后，VIP会重新漂移回到原先的master节点。

检查节点信息

kubectl get nodes

2）节点毛病测验（一台master毛病）

模仿master节点毛病（手动关机）

# 关机192.168.182.110
showdown -h now
# 在192.168.182.113	backup master节点检查集群节点状况
kubectl get nodes

【结论】一台master毛病，不影响集群。

3）master节点毛病模仿（两台master毛病）

2、模仿master节点毛病（手动关机）

# 关机192.168.182.113
showdown -h now
# 在192.168.182.130	backup master节点检查集群节点状况
kubectl get nodes

【过错】The connection to the server cluster-endpoint:6443 was refused - did you specify the right host or port?

发现两个master节点，挂了一个master节点是不可用的。原因：当两个master节点仍是需求2个节点可用。只有大于2个master节点才答应挂master节点，咱们能够查一下答应的容器。会发现api-server的容器一直在重启或许直接挂了，小伙伴也能够去检查一下日志。stackoverflow答案

crictl ps 2>/dev/null

【主张】所以咱们布置多master高可用节点数量有必要大于等于3，这样才能确保挂一个master节点，集群不会受影响。

K8S master节点替换IP以及master高可用毛病模仿测验就先到这儿，有任何疑问欢迎给我留言，后续会继续更新【云原生+大数据】相关的文章~