为什么要做高可用

在生产环境中,kubernetes 集群中会多多个 master 节点,每个 master 节点上都会部署 kube-apiserver 服务,实现高可用。但是 client 访问 kube-apiserver 时,需要指定 ip 或者域名,这样会出现单点故障。官方推荐的做法是使用一个负载均衡器,将多个 kube-apiserver 服务负载均衡,实现高可用,但很多时候我们是没有这个条件的。这时候就得想想办法了,比如 nignx 转发,但是 nginx 也是单点。域名的方式,但是这种方式生效时间较长,不太适合紧急情况。所以这里介绍一种使用 keepalived + haproxy 的方式实现 kube-apiserver 的高可用。这是一共公用 IP 的方式,当主节点宕机时,VIP 会自动切换到备节点,实现高可用。

环境准备

  • master1: 192.168.31.203
  • master2: 192.168.31.34
  • master3: 192.168.31.46
  • worker1: 192.168.31.25
  • VIP (虚拟IP): 192.168.31.230

安装

sudo apt install keepalived haproxy

systemctl enable haproxy
systemctl restart haproxy systemctl enable keepalived
# 没有配置会出现错误 不用管
systemctl restart keepalived

配置 keepalived

配置文件

编辑 keepalived 配置文件

编辑 /etc/keepalived/keepalived.conf

master1:

# 健康检查 查看 haproxy 的进程在不在
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 2 # 多少秒教程一次
weight 3 # 成功了优先级加多少
} vrrp_instance haproxy-vip {
state MASTER # MASTER / BACKUP 1 MASTER 2 BACKUP
priority 100 # 优先级 强的机器高一些 三台master 分别 100 99 98
interface enp0s3 # 网卡名称
virtual_router_id 51 # 路由 ip 默认就好
advert_int 1 # keepalived 之间广播频率 秒
authentication {
auth_type PASS
auth_pass test_k8s
}
unicast_src_ip 192.168.31.203 # 自己和其他 keepalived 通信地址
unicast_peer {
192.168.31.34 # master2 的 IP 地址
192.168.31.46 # master3 的 IP 地址
} virtual_ipaddress {
192.168.31.230 # 这里必须和其他所有的ip 在一个局域网下
} track_script {
chk_haproxy
}
}

master2:

vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 2
weight 3
} vrrp_instance haproxy-vip {
state BACKUP
priority 99
interface enp0s3
virtual_router_id 51
advert_int 1
authentication {
auth_type PASS
auth_pass test_k8s
}
unicast_src_ip 192.168.31.34
unicast_peer {
192.168.31.203
192.168.31.46
} virtual_ipaddress {
192.168.31.230
} track_script {
chk_haproxy
}
}

master3:

vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 2
weight 3
} vrrp_instance haproxy-vip {
state BACKUP
priority 98
interface enp0s3
virtual_router_id 51
advert_int 1
authentication {
auth_type PASS
auth_pass test_k8s
}
unicast_src_ip 192.168.31.46
unicast_peer {
192.168.31.203
192.168.31.34
} virtual_ipaddress {
192.168.31.230
} track_script {
chk_haproxy
}
}

测试

重启所有几点的 keepalived , 虚拟 ip 会在节点 master 上,因为他的优先级高。

# master 1
ip a show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:ca:59:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.31.203/24 metric 100 brd 192.168.31.255 scope global dynamic enp0s3
valid_lft 41983sec preferred_lft 41983sec
inet 192.168.31.230/32 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feca:5986/64 scope link
valid_lft forever preferred_lft forever

现在我们关掉 master1 的 haproxy 或者 keepalived

systemctl stop haproxy
# 再查看网络信息 发现虚拟ip 没了
ip a show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:ca:59:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.31.203/24 metric 100 brd 192.168.31.255 scope global dynamic enp0s3
valid_lft 41925sec preferred_lft 41925sec
inet6 fe80::a00:27ff:feca:5986/64 scope link
valid_lft forever preferred_lft forever # 在优先级第二高的 master IP 上看下网络
ip a show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:11:af:4f brd ff:ff:ff:ff:ff:ff
inet 192.168.31.34/24 metric 100 brd 192.168.31.255 scope global dynamic enp0s3
valid_lft 41857sec preferred_lft 41857sec
inet 192.168.31.230/32 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe11:af4f/64 scope link
valid_lft forever preferred_lft forever # 启动 master1 的 haproxy ip就会回来

配置 haproxy

把 16443 端口的请求转发到 6443 端口 (3 master 的 kube-apiserver 对外端口)

/etc/haproxy/haproxy.cfg

global
log /dev/log local0 warning
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon stats socket /var/lib/haproxy/stats defaults
log global
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000 frontend kube-apiserver
bind *:16443
mode tcp
option tcplog
default_backend kube-apiserver backend kube-apiserver
mode tcp
option tcp-check
balance roundrobin
default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100
server kube-apiserver-1 192.168.31.203:6443 check
server kube-apiserver-2 192.168.31.34:6443 check
server kube-apiserver-3 192.168.31.46:6443 check

安装 kubernetes 集群

master1

kubeadm init --image-repository registry.aliyuncs.com/google_containers --control-plane-endpoint=192.168.31.230:16443 --v=10

master2 和 master3 加入集群

kubeadm join 192.168.31.230:16443 --token rxblci.ddh60vl370wjgtn7         --discovery-token-ca-cert-hash sha256:d712016d5b8ba4ae5c4a1bda8b6ab1944c13a04757d2c488dd0aefcfd1af0157   --certificate-key    c398d693c6ce9b664634c9b670f013da3010580c00bd444caf7d0a5a81e803f5         --control-plane --v=10

worker 加入集群

kubeadm join 192.168.31.230:16443 --token rxblci.ddh60vl370wjgtn7 \
--discovery-token-ca-cert-hash sha256:d712016d5b8ba4ae5c4a1bda8b6ab1944c13a04757d2c488dd0aefcfd1af0157

查看集群状态

kubectl get node
NAME STATUS ROLES AGE VERSION
master1 Ready control-plane 21m v1.28.2
master2 Ready control-plane 3m46s v1.28.12
master3 Ready control-plane 2m12s v1.28.12
worker1 Ready <none> 5s v1.28.2

测试

#  关闭 master1 的 kubelet 和 apiserver
systemctl stop kubelet
sudo kill -9 $(pgrep kube-apiserver) kubectl get node
NAME STATUS ROLES AGE VERSION
master1 NotReady control-plane 25m v1.28.2
master2 Ready control-plane 7m40s v1.28.12
master3 Ready control-plane 6m6s v1.28.12
worker1 Ready <none> 3m59s v1.28.2 # 关闭 master1 的 haproxy
systemctl stop haproxy
root@master1:/home/zhy# kubectl get node
NAME STATUS ROLES AGE VERSION
master1 NotReady control-plane 26m v1.28.2
master2 Ready control-plane 9m12s v1.28.12
master3 Ready control-plane 7m38s v1.28.12
worker1 Ready <none> 5m31s v1.28.2 # 关闭 master2 的 keepalived
kubectl get node
NAME STATUS ROLES AGE VERSION
master1 NotReady control-plane 28m v1.28.2
master2 Ready control-plane 10m v1.28.12
master3 Ready control-plane 9m12s v1.28.12
worker1 Ready <none> 7m5s v1.28.2 # 可以看到 虚拟ip 跑到了 master3 上
ip a show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:f1:b5:ae brd ff:ff:ff:ff:ff:ff
inet 192.168.31.46/24 metric 100 brd 192.168.31.255 scope global dynamic enp0s3
valid_lft 41021sec preferred_lft 41021sec
inet 192.168.31.230/32 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fef1:b5ae/64 scope link
valid_lft forever preferred_lft forever

kube-apiserver 高可用,keepalived + haproxy的更多相关文章

  1. 解决nginx负载均衡高可用keepalived只针对物理机的问题

    在高可用keepalived软件,在默认的情况下仅仅在对方机器宕机或keepalived停掉的时候才会接管业务. 但是在实际工作过程中,例如在nginx负载均衡工作实例中,nginx服务已停止,而ke ...

  2. 高可用Keepalived+LVS搭建流程

    本流程搭建1个master,1个backup节点的Keepalived,使用lvs轮询2个节点的服务. 一.使用版本 CentOS 7.7 Keepalived 1.3.5 ipvsadm 1.27( ...

  3. 使用keepalived实现kubenetes apiserver高可用

    # 安装 nginx yum install nginx -y # 配置nginx4层代理 /etc/nginx/nginx.conf stream { upstream kube-apiserver ...

  4. 部署高可用keepalived组件

    本文档讲解使用 keepalived 和 haproxy 实现 kube-apiserver 高可用的步骤: keepalived 提供 kube-apiserver 对外服务的 VIP: hapro ...

  5. Centos7部署k8s[v1.16]高可用[keepalived]集群

    实验目的 一般情况下,k8s集群中只有一台master和多台node,当master故障时,引发的事故后果可想而知. 故本文目的在于体现集群的高可用,即当集群中的一台master宕机后,k8s集群通过 ...

  6. linux 高可用----keepalived+lvs

    什么是高可用? HA(high availability)即高可用性:就是在高可用集群中发生单点故障时,能够自动转移资源并切换服务,以保证服务一直在线的机制. LVS LVS:(linux virtu ...

  7. 【云原生 · Kubernetes】apiserver高可用

    个人名片: 因为云计算成为了监控工程师‍ 个人博客:念舒_C.ying CSDN主页️:念舒_C.ying 7.1 高可用选型 ipvs+keepalived nginx+keepalived hap ...

  8. nginx1.14.0版本高可用——keepalived双机热备

    nginx不支持主从,所以我们需要使用keepalive支持高可用. keepalived重要知识点 在局域网内,每个主机上各安装一个keepalived,注意关闭防火墙firewalld,然后设定一 ...

  9. 实现高可用-Keepalived

    简介 Keepalived是HA Cluster(High Availability Cluster,高可用集群)的一个服务软件,用来防止单点故障. Keepalived采用VRRP(virtual ...

  10. 高可用(keepalived)部署方案

    前言:为了减少三维数据中心可视化管理系统的停工时间,保持其服务的高度可用性.同时部署多套同样的三维可视化系统,让三维数据中心可视化系统同时部署并运行到多个服务器上.同时提供一个虚拟IP,然后外面通过这 ...

随机推荐

  1. 终于有人把Modbus讲明白了

    大家好!我是付工. 2012年开始接触Modbus协议,至今已经有10多年了,从开始的懵懂,到后来的顿悟,再到现在的开悟,它始终岿然不动,变化的是我对它的认知和理解. 今天跟大家聊聊关于Modbus协 ...

  2. 火山引擎数智平台:高性能ChatBI的技术解读和落地实践

    导读:大模型能力的发展和成熟,催生出新一代智能化 BI-- ChatBI,即通过自然语言处理(NLP)与大型语言模型(LLMs)的结合,极大简化数据分析过程,提高效率并降低分析门槛.火山引擎数智平台旗 ...

  3. QQ或者微信可以放昵称的超好看的符号

    ☪︎⋆ ✯ ⛈ •ᴗ• •ᴥ• ◔.̮◔ ᕱ ᕱ ⸝⸝· ᴥ ·⸝⸝ ʕ·͡ˑ·ཻʔ ʕ•̫͡•ོʔ ˃̣̣̥᷄⌓˂̣̣̥᷅ °꒰'ꀾ'꒱° ⋆ᶿ̵᷄ ˒̼ ᶿ̵᷅⋆ ˙ϖ˙ ⚝ ︎ .˗ˏˋ♡ˎˊ˗ ...

  4. android启动时间测试

    需要对比基线测试的情况: Kernel log: adb shell dmesg Event log: adb shell logcat –b events Logcat log: adb shell ...

  5. 强大灵活的文件上传库:FilePond 详解

    文件上传是 Web 开发中常见的功能,尤其是对于图片.视频.文档等大文件的处理,如何既保证用户体验,又兼顾安全和性能,是每位开发者关心的问题.在这样的背景下,FilePond 作为一款灵活强大的文件上 ...

  6. 云原生周刊 | 在 Grafana 中显示 K8s Service 之间的依赖关系

    开源项目推荐 Caretta 这个项目可以在 Grafana 监控面板中显示 K8s Service 之间的依赖关系.底层使用的是 eBPF,对应用无侵入. busuanzi 这是一个基于 Golan ...

  7. 使用 Cursor 和 Devbox 快速开发基于 Rust 的 WASM 智能合约

    本教程以一个智能合约(使用 NEAR 的一个官方 Fungible Tokens 来实现)的例子来介绍一下 Devbox 的强大功能,轻松构建环境,轻松发布. NEAR 是一个去中心化的应用平台,使用 ...

  8. Cloth Simulation with Root Finding and Optimization

    目录 0 前言 1 Implicit Method 1.1 Root-finding 1.2 Optimization 1.3 Insight 2 Newton-Raphson Method 3 Ma ...

  9. Cartographer学习——地图概率更新过程

    前言:最近一直在研究建图,对google的开源SLAM框架 Cartographer 进行了源码梳理,发现很多巧妙的算法设计,结合原论文 <Real-time Loop Closure in 2 ...

  10. 一个整合性、功能丰富的.NET网络通信框架

    前言 最近有不少同学问:.NET网络通信框架有什么好推荐的吗?今天大姚给大家分享一款基于Apache License开源的一个整合性.功能丰富的.NET(包括 C# .VB.Net.F#)网络通信框架 ...