- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
在生产环境中,kubernetes 集群中会多多个 master 节点,每个 master 节点上都会部署 kube-apiserver 服务,实现高可用。但是 client 访问 kube-apiserver 时,需要指定 ip 或者域名,这样会出现单点故障。官方推荐的做法是使用一个负载均衡器,将多个 kube-apiserver 服务负载均衡,实现高可用,但很多时候我们是没有这个条件的。这时候就得想想办法了,比如 nignx 转发,但是 nginx 也是单点。域名的方式,但是这种方式生效时间较长,不太适合紧急情况。所以这里介绍一种使用 keepalived + haproxy 的方式实现 kube-apiserver 的高可用。这是一共公用 IP 的方式,当主节点宕机时,VIP 会自动切换到备节点,实现高可用.
sudo apt install keepalived haproxy
systemctl enable haproxy
systemctl restart haproxy
systemctl enable keepalived
# 没有配置会出现错误 不用管
systemctl restart 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就会回来
把 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
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的文章就讲到这里了,如果你想了解更多关于kube-apiserver高可用,keepalived+haproxy的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
四、Keepalived 【1】、keepalived运行原理 Keepalived检测每个服务器接节点状态 服务器节点异常或出现工作故障,keepalived将故障节点从集群系统中
根据(详细)主题,与使用 Keepalived 相比有什么优势吗? & HAProxy作为 HA 网络服务器 loadbalancer vs 一个纯粹的keepalived解决方案? 最佳答案 Kee
我有两台linux服务器, 每个服务器都有两个 NIC,模式 1 绑定(bind)“bond0”。 我的用户级应用程序 - keepalived 在该绑定(bind)接口(interface)上运行
编译安装 HAProxy 新版 LTS 版本,编译安装 Keepalived 开启HAProxy多线程,线程数与CPU核心数保持一致,并绑定CPU核心 因业务较多避免配
keepalived + nginx 实现高可用 本篇主要介绍一下 keepalived + nginx 来实现 对于nginx的高可用, 还是简单的主备模式 。 1.概述
Keepalived 由于在生产环境使用了mysqlcluster,需要实现高可用负载均衡,这里提供了keepalived+haproxy来实现.  
1.keepalived介绍 keepalived最初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了实现高可用的VRRP功能。keepalived除
我正在尝试为我的服务实现基于 keepalived 的故障转移。请在下面找到我的主节点和备份节点的配置。 主节点: vrrp_script chk_splunkd { script "pido
我有 2 个应用服务器都配置为运行 php cron 作业,但只有 1 个可以随时运行该作业。由于我已经将keepalived用于其他目的,我正在考虑在cron作业中使用一些逻辑来检查节点是否具有虚拟
我正在尝试使用 keepalived 配置两个事件负载均衡器服务器。 它与标准配置略有不同,我们有两台服务器和一个虚拟 IP。 我想要的只是当 loadbalancer_1 出现故障时,loadbal
前言:为了减少三维数据中心可视化管理系统的停工时间,保持其服务的高度可用性。同时部署多套同样的三维可视化系统,让三维数据中心可视化系统同时部署并运行到多个服务器上。同时提供一个虚拟IP,然后外面通过
前言 为解决单点故障,我们需要配置主从热备方案,服务器数量有限,故使用Docker模拟安装配置。 本次配置默认已经安装了Docker。 配置环境:centos7 64位 docker版本:D
本文介绍了nginx+keepalived 高可用主从配置详解,分享给大家,具体如下: 1、系统环境及软件版本 CentOS 6.6 x64 keepalived-1.2.18.tar.gz
nginx是一款非常优秀的反向代理工具,支持请求分发,负载均衡,以及缓存等等非常实用的功能。在请求处理上,nginx采用的是epoll模型,这是一种基于事件监听的模型,因而其具备非常高效的请求处理效
为什么要做高可用 在生产环境中,kubernetes 集群中会多多个 master 节点,每个 master 节点上都会部署 kube-apiserver 服务,实现高可用。但是 client 访问
我有 2 个带有 keepalived 和 haproxy 服务的节点(CentOS7)。 如果我关闭一个节点一切正常。但是如果 haproxy 出现故障,我想对 VIPS 进行故障转移。 这是第一个
我有下一个场景,4 个运行 Red Hat Enterprise Linux 7 的虚拟机: 20.1.67.230 服务器(虚拟 IP)(不是主机) 20.1.67.219 haproxy1(负载均
我有 2 台运行 keepalived 的服务器,IP 配置如下: 服务器 1: eth0 172.31.48.10 服务器 2: eth0 192.168.1.5 eth0:1 172.31.48.
keepalived 有什么办法只有当 2 个接口(interface)宕机时才进入故障/备份状态? 在文档中,我发现如果一个或多个接口(interface)出现故障,track_interface
我一直致力于一个项目,该项目将建立一组高可用性负载平衡器。负载平衡和高可用性软件似乎工作得很好(我正在使用 Crossroads 进行负载平衡,使用 Keepalived 使负载平衡服务器具有高可用性
我是一名优秀的程序员,十分优秀!