kube-apiserver 高可用,keepalived + haproxy
为什么要做高可用
在生产环境中,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的更多相关文章
- 解决nginx负载均衡高可用keepalived只针对物理机的问题
在高可用keepalived软件,在默认的情况下仅仅在对方机器宕机或keepalived停掉的时候才会接管业务. 但是在实际工作过程中,例如在nginx负载均衡工作实例中,nginx服务已停止,而ke ...
- 高可用Keepalived+LVS搭建流程
本流程搭建1个master,1个backup节点的Keepalived,使用lvs轮询2个节点的服务. 一.使用版本 CentOS 7.7 Keepalived 1.3.5 ipvsadm 1.27( ...
- 使用keepalived实现kubenetes apiserver高可用
# 安装 nginx yum install nginx -y # 配置nginx4层代理 /etc/nginx/nginx.conf stream { upstream kube-apiserver ...
- 部署高可用keepalived组件
本文档讲解使用 keepalived 和 haproxy 实现 kube-apiserver 高可用的步骤: keepalived 提供 kube-apiserver 对外服务的 VIP: hapro ...
- Centos7部署k8s[v1.16]高可用[keepalived]集群
实验目的 一般情况下,k8s集群中只有一台master和多台node,当master故障时,引发的事故后果可想而知. 故本文目的在于体现集群的高可用,即当集群中的一台master宕机后,k8s集群通过 ...
- linux 高可用----keepalived+lvs
什么是高可用? HA(high availability)即高可用性:就是在高可用集群中发生单点故障时,能够自动转移资源并切换服务,以保证服务一直在线的机制. LVS LVS:(linux virtu ...
- 【云原生 · Kubernetes】apiserver高可用
个人名片: 因为云计算成为了监控工程师 个人博客:念舒_C.ying CSDN主页️:念舒_C.ying 7.1 高可用选型 ipvs+keepalived nginx+keepalived hap ...
- nginx1.14.0版本高可用——keepalived双机热备
nginx不支持主从,所以我们需要使用keepalive支持高可用. keepalived重要知识点 在局域网内,每个主机上各安装一个keepalived,注意关闭防火墙firewalld,然后设定一 ...
- 实现高可用-Keepalived
简介 Keepalived是HA Cluster(High Availability Cluster,高可用集群)的一个服务软件,用来防止单点故障. Keepalived采用VRRP(virtual ...
- 高可用(keepalived)部署方案
前言:为了减少三维数据中心可视化管理系统的停工时间,保持其服务的高度可用性.同时部署多套同样的三维可视化系统,让三维数据中心可视化系统同时部署并运行到多个服务器上.同时提供一个虚拟IP,然后外面通过这 ...
随机推荐
- 终于有人把Modbus讲明白了
大家好!我是付工. 2012年开始接触Modbus协议,至今已经有10多年了,从开始的懵懂,到后来的顿悟,再到现在的开悟,它始终岿然不动,变化的是我对它的认知和理解. 今天跟大家聊聊关于Modbus协 ...
- 火山引擎数智平台:高性能ChatBI的技术解读和落地实践
导读:大模型能力的发展和成熟,催生出新一代智能化 BI-- ChatBI,即通过自然语言处理(NLP)与大型语言模型(LLMs)的结合,极大简化数据分析过程,提高效率并降低分析门槛.火山引擎数智平台旗 ...
- QQ或者微信可以放昵称的超好看的符号
☪︎⋆ ✯ ⛈ •ᴗ• •ᴥ• ◔.̮◔ ᕱ ᕱ ⸝⸝· ᴥ ·⸝⸝ ʕ·͡ˑ·ཻʔ ʕ•̫͡•ོʔ ˃̣̣̥᷄⌓˂̣̣̥᷅ °꒰'ꀾ'꒱° ⋆ᶿ̵᷄ ˒̼ ᶿ̵᷅⋆ ˙ϖ˙ ⚝ ︎ .˗ˏˋ♡ˎˊ˗ ...
- android启动时间测试
需要对比基线测试的情况: Kernel log: adb shell dmesg Event log: adb shell logcat –b events Logcat log: adb shell ...
- 强大灵活的文件上传库:FilePond 详解
文件上传是 Web 开发中常见的功能,尤其是对于图片.视频.文档等大文件的处理,如何既保证用户体验,又兼顾安全和性能,是每位开发者关心的问题.在这样的背景下,FilePond 作为一款灵活强大的文件上 ...
- 云原生周刊 | 在 Grafana 中显示 K8s Service 之间的依赖关系
开源项目推荐 Caretta 这个项目可以在 Grafana 监控面板中显示 K8s Service 之间的依赖关系.底层使用的是 eBPF,对应用无侵入. busuanzi 这是一个基于 Golan ...
- 使用 Cursor 和 Devbox 快速开发基于 Rust 的 WASM 智能合约
本教程以一个智能合约(使用 NEAR 的一个官方 Fungible Tokens 来实现)的例子来介绍一下 Devbox 的强大功能,轻松构建环境,轻松发布. NEAR 是一个去中心化的应用平台,使用 ...
- 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 ...
- Cartographer学习——地图概率更新过程
前言:最近一直在研究建图,对google的开源SLAM框架 Cartographer 进行了源码梳理,发现很多巧妙的算法设计,结合原论文 <Real-time Loop Closure in 2 ...
- 一个整合性、功能丰富的.NET网络通信框架
前言 最近有不少同学问:.NET网络通信框架有什么好推荐的吗?今天大姚给大家分享一款基于Apache License开源的一个整合性.功能丰富的.NET(包括 C# .VB.Net.F#)网络通信框架 ...