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,然后外面通过这 ...
随机推荐
- Angular 18+ 高级教程 – Prettier, ESLint, Stylelint
前言 不熟悉 Prettier, ESLint, Stylelint 的朋友可以先看这篇 工具 – Prettier.ESLint.Stylelint. 首先,Angular 没有 built-in ...
- 神经网络之卷积篇:详解为什么使用卷积?(Why convolutions?)
详解为什么使用卷积? 来分析一下卷积在神经网络中如此受用的原因,然后对如何整合这些卷积,如何通过一个标注过的训练集训练卷积神经网络做个简单概括.和只用全连接层相比,卷积层的两个主要优势在于参数共享和稀 ...
- 分析ueventd Coldboot耗时问题
安卓go平台启动时间发现如下ueventd耗时1.907s问题: 01-11 00:20:02.854 0 0 I init : Parsing file /odm/etc/init... 01-11 ...
- 数列专题2 求数列的前n项和
\({\color{Red}{欢迎到学科网下载资料学习 }}\) [ [基础过关系列]高二数学同步精品讲义与分层练习(人教A版2019)] ( https://www.zxxk.com/docpack ...
- 权限控制 vue3
- 33. mvvm理解
MVVM 是module view view-module 数据驱动视图开发模型,是MVC的改进版,采用业务逻辑和页面解构分离的开发思想: MVVM 实现了 view 和 module 的双向绑定,我 ...
- 2024csp初赛总结
浙江27日下午1:30出分了,j组97,s组61.5,和估分一模一样,还好没有挂分.然后3点的时候上洛谷看了一下,全国分数线出了,j组89分,s组56分.那应该都过了,随后同学的成绩也出来了,sjx, ...
- 神经网络之卷积篇:详解残差网络为什么有用?(Why ResNets work?)
详解残差网络为什么有用? 为什么ResNets能有如此好的表现,来看个例子,它解释了其中的原因,至少可以说明,如何构建更深层次的ResNets网络的同时还不降低它们在训练集上的效率.通常来讲,网络在训 ...
- 东方通信基于 KubeSphere 的云计算落地经验
作者:周峰 吴昌泰 公司简介 东方通信股份有限公司(以下简称"东方通信")创立于 1958 年,是一家集硬件设备.软件.服务为一体的整体解决方案提供商.公司于 1996 年成功改制 ...
- 云原生爱好者周刊:这款支持全平台的 Podman Desktop 值得一试
开源项目推荐 Podman Desktop Companion Podman 桌面客户端,支持 macOS.Windows 和 Linux 平台,后端支持原生 Podman(仅支持 Linux).Po ...