三控合一已完成基本搭建，下方图片为负载均衡软件组合
1. 安装配置haproxy、keepalived（3台Master全部执行）
# 查看软件源中可用的版本+源地址，确认适配Ubuntu 20.04（focal）
sudo apt-cache madison haproxy keepalived
sudo apt -y install haproxy keepalived
# 锁定版本
apt-mark hold haproxy keepalived
# 组件核心分工：
# haproxy：做四层TCP负载均衡，把VIP:16443的流量均匀转发到3台Master的6443（apiserver），并自动剔除故障节点；
# keepalived：基于VRRP虚拟路由协议实现主从选举和VIP漂移，让VIP始终绑定在一台健康的节点上，保证入口不中断；
步骤 01. 【所有主机】配置HAProxy，配置完全一致
tee /etc/haproxy/haproxy.cfg<<'EOF'
# 1. 全局配置：进程级基础设置，作用于整个haproxy
global
user haproxy # 运行用户/组，非root运行提升安全性
group haproxy
maxconn 2000 # 最大并发连接数，测试环境足够，生产可按需调大
daemon # 后台守护进程运行，不占用终端
log /dev/log local0 # 日志输出到系统日志，方便排查问题
chroot /var/lib/haproxy # 限制文件访问根目录，强化安全
stats socket /run/haproxy/admin.sock mode 660 level admin # 开启本地管理套接字，可查看haproxy状态
ca-base /etc/ssl/certs # SSL证书基础目录（本次四层透传暂未用到，保留默认）
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets # 禁用低版本TLS，提升安全
# 2. 默认配置：所有frontend/backend继承，减少冗余配置
defaults
log global # 继承全局日志配置
mode http # 默认七层HTTP，后续会被强制覆盖为TCP
option dontlognull # 不记录空连接日志，减少日志冗余
timeout connect 5000 # 前端连后端的连接超时（5秒），连不上则判定失败
timeout client 50000 # 客户端与haproxy的空闲连接超时（50秒）
timeout server 50000 # haproxy与后端apiserver的空闲连接超时（50秒）
# 3. 前端配置：K8s流量入口，核心是四层TCP监听16443端口
frontend k8s-master
bind 0.0.0.0:16443 # 监听本机所有网卡的16443端口（物理IP、VIP、回环IP）
bind 127.0.0.1:16443 # 额外监听回环地址，方便本机组件（如scheduler）本地访问
mode tcp # 强制四层TCP模式【关键】，透传HTTPS加密流量，不解析/修改
option tcplog # 记录TCP层日志（源IP、端口、连接状态），方便排错
tcp-request inspect-delay 5s # 等待5秒完成TCP握手检测，防止恶意半连接
default_backend k8s-master # 所有流量默认转发到后端k8s-master节点池
# 4. 后端配置：流量转发目标池，管理3台Master的apiserver
backend k8s-master
mode tcp # 与前端保持一致，四层TCP透传
option tcp-check # 开启TCP层健康检查【关键】，探测后端6443端口是否能握手
balance roundrobin # 负载均衡算法：轮询，均匀分发流量到3台apiserver（apiserver无状态，适合轮询）
# 所有后端节点的通用健康检查/连接参数，一次配置全继承，减少冗余
default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100
# 定义3台后端节点，check表示为该节点开启健康检查
server master-223 10.10.107.223:6443 check
server master-224 10.10.107.224:6443 check
server master-225 10.10.107.225:6443 check
EOF
步骤 02 配置Keepalived（所有Master先执行模板写入，再分节点替换差异化参数）
mkdir -vp /etc/keepalived # 容错创建目录，-v打印信息，-p递归创建
sudo tee /etc/keepalived/keepalived.conf <<'EOF'
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL # 节点标识，同一集群内可区分即可
script_user root # 执行健康检查脚本的用户，必须root（才能执行systemctl stop）
enable_script_security # 开启脚本安全检查，防止非法脚本执行
}
# 自定义健康检查脚本配置：检查本机haproxy是否存活
vrrp_script chk_apiserver {
script "/etc/keepalived/check_apiserver.sh" # 脚本路径
interval 5 # 每5秒执行一次检查
weight -5 # 检查失败，节点优先级-5
fall 2 # 连续2次失败，触发降权
rise 1 # 1次成功即恢复原优先级
}
# VRRP实例：核心，管理VIP的选举、绑定、漂移
vrrp_instance VI_1 {
state __ROLE__ # 角色：MASTER/BACKUP（差异化参数）
interface __NETINTERFACE__ # VIP绑定的物理网卡（如ens32，差异化参数）
mcast_src_ip __IP__ # 本机真实IP，发VRRP心跳用（差异化参数）
virtual_router_id 51 # VRRP组ID【关键】，同一集群必须相同（0-255）
priority 101 # 选举优先级【关键】，数值越大越容易成为MASTER
advert_int 2 # VRRP心跳间隔，每2秒发一次
authentication { # 组内认证，防止陌生机器乱入
auth_type PASS
auth_pass K8SHA_KA_AUTH # 认证密码，同一集群必须相同
}
virtual_ipaddress { # 要漂移的VIP（统一为10.10.107.222）
__VIP__
}
# 健康检查：暂时注释，K8s集群建好后再开启
# track_script {
# chk_apiserver
# }
}
EOF
# sed批量替换占位符
# master-225（性能好，设为MASTER）
sed -i -e 's#__ROLE__#MASTER#g' -e 's#__NETINTERFACE__#ens32#g' -e 's#__IP__#10.10.107.225#g' -e 's#__VIP__#10.10.107.222#g' /etc/keepalived/keepalived.conf
# master-224/223 设为BACKUP，仅ROLE和本机IP不同
sed -i -e 's#__ROLE__#BACKUP#g' -e 's#__NETINTERFACE__#ens32#g' -e 's#__IP__#10.10.107.224#g' -e 's#__VIP__#10.10.107.222#g' /etc/keepalived/keepalived.conf
sed -i -e 's#__ROLE__#BACKUP#g' -e 's#__NETINTERFACE__#ens32#g' -e 's#__IP__#10.10.107.223#g' -e 's#__VIP__#10.10.107.222#g' /etc/keepalived/keepalived.conf
步骤 03 配置Keepalived健康检查脚本（所有Master节点执行）
sudo tee /etc/keepalived/check_apiserver.sh <<'EOF'
#!/bin/bash
# 适配三控合一K8s集群：HAProxy监听16443，转发apiserver6443
# 多维度检查：HAProxy进程存在 + 16443端口正常监听（双重验证，避免假健康）
err=0
# 循环3次检查，规避网络/系统抖动导致的误判
for k in $(seq 1 3)
do
# 检查1：HAProxy进程是否存在
pgrep haproxy > /dev/null 2>&1
proc_check=$?
# 检查2：HAProxy的16443端口是否正常监听（关键！进程在≠端口通）
ss -tulpn | grep haproxy | grep :16443 > /dev/null 2>&1
port_check=$?
# 两个检查都通过，才判定HAProxy健康
if [[ $proc_check -ne 0 || $port_check -ne 0 ]]; then
err=$((err+1))
sleep 1
continue
else
# 健康则重置错误数，退出循环
err=0
break
fi
done
# 3次检查均失败，主动停止Keepalived，释放VIP让其漂移到健康节点
if [[ $err -ne 0 ]]; then
/usr/bin/systemctl stop keepalived > /dev/null 2>&1
exit 1
else
# 检查通过，返回0（Keepalived判定节点健康）
exit 0
fi
EOF
步骤 04 启动服务+手动测试VIP漂移（所有Master节点执行启动命令，验证按需执行）
sudo systemctl daemon-reload # 让systemd重新识别服务配置
# enable --now：同时设置「开机自启」+「立即启动」，一步到位
sudo systemctl enable --now haproxy && sudo systemctl enable --now keepalived
# 验证1：查看VIP是否成功绑定
# 通过ip addr查看网卡（ens32）信息，出现10.10.107.222/32表示VIP成功绑定在该节点：
ip addr
# master-223的输出，可见VIP已绑定
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
inet 10.10.107.223/24 scope global ens32
inet 10.10.107.222/32 scope global ens32 # VIP绑定成功
# 验证2：连通性测试
# 所有节点执行ping 10.10.107.222，能正常通包表示VIP在局域网内可用，是有效的统一入口。
# 验证3：手动测试VIP漂移（核心验证）
# 在当前持有VIP的节点（master-223） 停止Keepalived，观察VIP是否漂移到优先级更高的master-225：
# master-223上执行：停止keepalived
/usr/bin/systemctl stop keepalived
# master-225上执行：查看VIP是否漂移过来
ip addr show ens32
# 输出可见VIP已绑定到master-225，漂移成功
inet 10.10.107.225/24 scope global ens32
inet 10.10.107.222/32 scope global ens32
2. 负载均衡管理工具安装与内核加载（3台Master全部执行）
步骤01：安装IPVS模块管理工具及相关依赖
# 1. 查看ipvsadm可用版本
sudo apt-cache madison ipvsadm
# 输出：ipvsadm | 1:1.31-1 | http://mirrors.aliyun.com/ubuntu focal/main amd64 Packages
# 2. 安装核心工具集
sudo apt -y install ipvsadm ipset sysstat conntrack
# 3. 锁定ipvsadm版本
apt-mark hold ipvsadm
步骤02：配置内核模块开机自动加载（持久化，需重启生效）
tee /etc/modules-load.d/k8s.conf <<'EOF'
# netfilter 桥接流量转发
br_netfilter
# containerd 容器存储
overlay
# 连接跟踪
nf_conntrack
# ipvs 核心及算法/辅助模块
ip_vs
ip_vs_lc
ip_vs_lblc
ip_vs_lblcr
ip_vs_rr
ip_vs_wrr
ip_vs_sh
ip_vs_dh
ip_vs_fo
ip_vs_nq
ip_vs_sed
ip_vs_ftp
# ipvs 配套网络模块
ip_tables
ip_set
ipt_set
ipt_rpfilter
ipt_REJECT
ipip
xt_set
EOF
步骤03：手动加载内核模块（立即生效，无需重启）
# 1. 创建自定义模块脚本目录
mkdir -vp /etc/modules.d/
# 2. 写入手动加载模块的bash脚本
tee /etc/modules.d/k8s.modules <<'EOF'
#!/bin/bash
# netfilter 模块 允许 iptables 检查桥接流量
modprobe -- br_netfilter
# containerd
modprobe -- overlay
# nf_conntrack
modprobe -- nf_conntrack
# ipvs
modprobe -- ip_vs
modprobe -- ip_vs_lc
modprobe -- ip_vs_lblc
modprobe -- ip_vs_lblcr
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- ip_vs_dh
modprobe -- ip_vs_fo
modprobe -- ip_vs_nq
modprobe -- ip_vs_sed
modprobe -- ip_vs_ftp
modprobe -- ip_tables
modprobe -- ip_set
modprobe -- ipt_set
modprobe -- ipt_rpfilter
modprobe -- ipt_REJECT
modprobe -- ipip
modprobe -- xt_set
EOF
# 3. 加可执行权限+执行脚本+验证模块加载结果
chmod 755 /etc/modules.d/k8s.modules && bash /etc/modules.d/k8s.modules && lsmod | grep -e ip_vs -e nf_conntrack
# 4. 重载内核参数
sysctl --system
**操作到这里就结束了，操作完成后这三台虚拟机就具备了K8s高可用基础，下面是理论时间**
3. keepalied,haproxy,ipvs在k8s中的边界
4. keepalived+haproxy与Ingress Haproxy+kube-proxy/ipvs
两套组件组合构建起 K8s 集群的精细化流量隔离体系，精准划分控制平面与集群外业务流量的处理链路：
- Keepalived+Haproxy 专责承载K8s 控制平面 apiserver 的访问流量，为控制平面提供高可用保障与统一访问入口；
- Ingress Haproxy 协同 kube-proxy/ipvs，专门承接并处理集群外访问集群服务的业务流量，完成从七层路由到四层 Pod 负载均衡的全链路转发。
5. keepalived
Keepalived的核心是VRRP实例，通过组播心跳在3台Master之间通信，选举出主节点（MASTER），VIP只会绑定在主节点上；如果主节点故障（心跳中断/健康检查失败），剩余节点会重新选举，VIP自动飘到新的主节点，实现无感知的故障切换。
要解决的问题
kube-apiserver是K8s集群的唯一入口，所有操作（kubectl、控制器、Node注册）都必须通过它，3台Master虽然都装了apiserver，但如果没有统一入口，会出现：
- 组件需要配置3个Master IP，管理复杂；
- 某台Master故障，对应的组件访问会中断，无自动切换；
- 流量无法均匀分发到3台Master，负载不均衡。
核心设计原因
-
为什么选master-225作为MASTER？ VRRP选举的核心依据是优先级（priority），优先级越高，越容易成为主节点，把性能最好的master-225设为MASTER，能保证核心节点承担主要的VIP流量，提升性能；
-
为什么所有Master都要装Keepalived？ 因为VIP需要在3台Master之间漂移，所有节点都需要运行Keepalived，才能参与心跳检测和主节点选举；
-
为什么先注释健康检查（track_script）？ 你在温馨提示中说“K8s集群建立完成后再开启”，核心原因是此时K8s集群还未初始化，apiserver还没启动，健康检查脚本会检测失败，导致Keepalived启动后立即停止，VIP无法绑定，所以测试环境先注释，等apiserver启动后再开启。
Keepalived在k8s中的核心作用
-
为K8s控制平面提供唯一、统一的VIP访问入口，屏蔽多apiserver的IP差异。有3台Master节点，每台都运行kube-apiserver（端口6443），如果没有Keepalived，客户端需要分别访问3台Master的物理IP，既繁琐又无法保证高可用； Keepalived通过VRRP实例管理10.10.107.222这个VIP，让集群内所有组件（kubelet、scheduler、controller-manager）和外部客户端，都只需访问VIP:16443这一个地址即可对接apiserver，无需关注背后的多台Master，实现了控制平面的「单IP统一访问」。
-
基于VRRP协议实现主节点选举，让VIP专属绑定到最优主节点。
将性能最好的master-225设为MASTER（priority=101），223/224为BACKUP（默认优先级100），Keepalived会通过组播心跳在3台Master间完成选举：
-
正常情况下，优先级最高的master-225会成为主节点，VIP仅绑定在这台主节点上，让性能最优的节点承担所有VIP流量，提升控制平面转发效率；
-
选举规则完全由你配置的
priority决定，贴合“核心节点承担主要流量”的设计思路。
-
-
实现VIP的智能漂移，解决控制平面入口的单点故障问题。这是Keepalived最核心的高可用能力，也是3台Master都安装Keepalived的原因：
-
所有Master都运行Keepalived，才能参与VRRP组播心跳检测和主节点选举，保证主节点故障后剩余节点能快速重新选举新主；
-
当主节点（如225）出现故障（心跳中断/健康检查脚本检测到HAProxy故障），其Keepalived会被停止，VIP会自动从故障节点解绑，漂移并绑定到新选举的健康主节点（224/223），整个过程对客户端无感知，控制平面的VIP入口不会中断。
-
-
配合健康检查脚本，实现精细化故障检测与主动容灾
-
配置了
vrrp_script对接check_apiserver.sh脚本，后续开启后，Keepalived会基于此实现主动的故障检测（而非仅依赖VRRP的被动心跳中断）： -
被动检测：主节点宕机/网络中断，心跳发不出去，其他节点判定其故障；
-
主动检测：主节点本身没宕机，但HAProxy故障（进程挂/16443端口不通），此时心跳正常，但服务已不可用，Keepalived会通过脚本每5秒检查，检测失败后主动停止自身，释放VIP，避免“节点活着但服务不可用”的假健康状态，让VIP漂移更精准。
-
6. haproxy
HAProxy 是开源的高性能四层 / 七层负载均衡器 + 反向代理，纯用户态运行（基于 Linux 系统调用处理网络请求），是目前业界最主流的开源负载均衡方案之一，核心特点是配置灵活、稳定性高、支持精细化的流量控制和健康检查，被广泛用于各种服务的入口流量分发。
要解决的问题
- 单 apiserver 的性能瓶颈问题，提升控制平面整体处理能力
- 多 apiserver 的访问入口混乱问题，配合 VIP 形成单 IP + 单端口的统一控制平面入口
- apiserver HTTPS 加密流量的安全转发问题，适配加密协议且无额外复杂度
- 故障 apiserver 的请求误发问题，自动屏蔽故障节点，避免客户端请求失败
- VIP 漂移后的流量无缝接管问题，保证故障切换无感知
- 局部故障的容灾问题，和 Keepalived 形成分层容灾，减少 VIP 漂移成本
核心设计原因
- HAProxy 通过轮询负载均衡将 VIP:16443 的请求均匀分发到 223/224/225 三台 apiserver，让三台节点共同承担流量压力，把控制平面的处理能力提升 3 倍，彻底解决单节点性能瓶颈。
-
3 台 Master 都运行 apiserver（6443 端口），如果没有 HAProxy，客户端（kubectl、kubelet、scheduler）需要分别访问 3 台节点的物理 IP，存在两个致命问题：
-
客户端需要维护多套 IP 配置，繁琐且易出错
-
无法和 Keepalived 的 VIP 配合，VIP 失去存在意义。HAProxy 在所有 Master 节点统一监听 16443 端口，配合 Keepalived 的 VIP（10.10.107.222），让客户端只需访问一个地址：VIP:16443，即可对接背后所有 apiserver，屏蔽后端多 apiserver 的 IP / 端口差异，形成控制平面的统一访问入口。
-
-
kube-apiserver 的默认通信协议是HTTPS（6443 端口），所有请求都是加密的，这对负载均衡器有核心要求：
-
不能解析 / 修改加密报文（否则会破坏通信安全，也需要配置 SSL 证书增加复杂度）；
-
HAProxy 通过四层 TCP 透传模式（配置中的
mode tcp）完美解决这个问题 —— 只做 “数据搬运工”，将 VIP:16443 的加密流量原封不动转发到 apiserver 的 6443 端口，不解析、不修改任何报文，既保证了集群通信的安全性，又省去了 SSL 证书配置的繁琐，是对接 apiserver 的最优解。
-
-
多 apiserver 部署中，若某台节点的 apiserver 故障（进程挂掉、6443 端口不通），如果没有健康检查机制，流量仍会被转发到该故障节点，导致客户端请求超时、失败，集群操作异常；
-
HAProxy 通过TCP 层健康检查（你配置的
option tcp-check）定时探测后端 apiserver 的可用性，连续 2 次探测失败则自动将节点从后端池剔除，不再转发任何请求到该节点； -
当节点恢复健康后，又会自动加回后端池，全程无需人工介入，保证请求始终只发送到健康的 apiserver。
-
-
Keepalived 会实现 VIP 在 3 台 Master 间的漂移，若 VIP 漂移到某台 Backup 节点（如 224），需要该节点能立即接管 VIP 的流量，否则会出现流量中断；
-
在所有 Master 节点配置了完全一致的 HAProxy，这就保证了：VIP 漂移到任意节点，该节点的 HAProxy 都已配置好所有转发规则，能无缝接管 VIP 的 16443 端口流量，无需临时修改配置，实现 VIP 漂移后的流量无感知切换。
-
-
HAProxy 负责节点内的局部故障容灾，Keepalived 负责整台节点的全局故障容灾，二者配合形成分层容灾体系，大幅减少 VIP 漂移的频率（漂移越少，集群越稳定）：
-
单台 apiserver 故障（节点本身正常）：HAProxy 直接剔除该故障节点，流量由其他两台 apiserver 承担，无需 VIP 漂移，局部容灾即可解决；
-
整台 Master 节点故障（HAProxy+apiserver 都挂）：Keepalived 的健康检查脚本检测到故障，触发 VIP 漂移，由其他节点接管全局流量。
-
Haproxy在k8s中的核心作用
-
统一流量收口，配合VIP形成控制平面单IP+单端口的唯一访问入口。HAProxy在所有Master节点统一监听
0.0.0.0:16443端口，直接承接Keepalived管理的VIP流量，屏蔽3台apiserver的物理IP/端口差异，让集群内外部所有客户端（kubectl、kubelet、调度器等）仅需访问VIP:16443这一个地址，即可对接背后所有apiserver，成为K8s控制平面的流量总闸门，解决多apiserver入口混乱的问题。 -
四层TCP透传转发，安全适配apiserver的HTTPS加密通信。针对apiserver6443端口的HTTPS加密协议，HAProxy以纯四层TCP透传模式工作，仅做加密报文的“数据搬运工”，不解析、不修改任何加密内容，原封不动将VIP:16443的流量转发到后端apiserver的6443端口，无需配置SSL证书、无需解密，兼顾集群通信的安全性和部署配置的简洁性。
-
负载均衡分发，消解单apiserver的性能瓶颈。通过
roundrobin轮询算法，将VIP入口的所有请求均匀分发到223/224/225三台健康的apiserver，让三台节点共同承担控制平面的流量压力，将控制平面的整体并发处理能力提升至单节点的3倍，彻底解决单apiserver作为集群“大脑”的性能瓶颈问题。 -
故障节点自动剔除，屏蔽apiserver的服务级故障。通过配置的
TCP层健康检查，实时探测后端apiserver6443端口的可用性，连续探测失败则自动将故障节点从后端池剔除，不再向其转发任何请求；节点恢复后又会自动加回，全程无需人工介入，保证请求始终只发往健康的apiserver，实现控制平面的局部容灾。 -
无缝承接VIP漂移，保障故障切换的无感知性。3台Master节点配置了完全一致的HAProxy规则，这让Keepalived的VIP无论漂移到哪台健康Master节点，该节点的HAProxy都能立即接管VIP的16443端口流量，无需临时修改配置、无需重启服务，实现VIP漂移后的流量无缝衔接，保证控制平面入口的无中断访问。
7. ipvs
IPVS 是 Linux 内核态的四层TCP/UDP负载均衡技术，全称为IP Virtual Server（IP虚拟服务器），并非独立运行的软件，而是依托Linux内核模块实现，通过ipvsadm工具做用户态管理，在K8s中由kube-proxy组件原生驱动、动态维护规则；相较于HAProxy的用户态运行，IPVS直接在内核层处理流量转发，转发效率更高、并发承载能力更强，且能实时感知K8s内Pod的动态变化，是K8s集群默认的负载均衡实现方案，核心特点是内核态高性能、规则动态更新、适配容器化场景的弹性扩缩容，专门为K8s数据平面的Service-Pod网络模型提供负载均衡能力。
要解决的问题
Pod是K8s集群中业务运行的最小单元，具备动态性（创建/销毁/扩缩容/漂移）、临时性（PodIP重启后会变化）的特点，且单Pod存在性能瓶颈，若没有统一的负载均衡方案，K8s业务面会出现一系列致命问题：
-
业务Pod需对外提供统一访问入口，直接访问PodIP会因Pod动态变化导致服务访问中断，管理维护成本极高；
-
多Pod承载同一业务时，流量无法自动均匀分发，单Pod易被打垮，业务整体处理能力受限；
-
传统的iptables转发基于规则匹配，高并发场景下规则过多会导致转发性能下降，无法满足容器化集群的高流量需求；
-
Pod故障后，流量仍可能被转发到故障实例，导致业务访问失败，且无自动剔除机制；
-
集群内Pod间、集群外访问Pod的流量无统一管理入口，网络模型混乱，不符合K8s的声明式API设计。
核心设计原因
-
选择内核态运行的IPVS，而非用户态负载均衡工具，核心是为了提升K8s业务面的流量转发效率，内核层直接处理转发无需用户态-内核态的上下文切换，能适配容器集群高并发、大流量的业务访问场景；
-
由
kube-proxy原生驱动IPVS规则，让IPVS能实时感知K8s的Service、Endpoint资源变化，当Pod扩缩容、故障销毁、新建时，自动更新负载均衡转发规则，无需人工介入，完美适配Pod的动态性特点； -
加载
ip_vs_rr（轮询）、ip_vs_wrr（加权轮询）等多种负载均衡算法模块，可根据业务需求（如部分Pod性能更强需承担更多流量）灵活选择，适配不同业务的负载分发需求； -
在所有K8s节点（3台Master+所有Worker） 部署IPVS，实现业务流量的本地转发，减少跨节点流量传输的网络损耗，同时保证无论客户端访问哪个节点的Service，都能被均匀转发到后端健康Pod；
-
配套安装
ipset、conntrack等工具，解决IPVS规则过多时的管理效率问题和连接跟踪问题，同时加载br_netfilter等内核模块，保证IPVS能正常处理K8s桥接网络的流量，与容器网络插件（Calico/Flannel）兼容； -
将IPVS核心内核模块配置为开机自动加载，并通过脚本实现手动立即加载，同时锁定
ipvsadm版本，保证K8s集群重启后IPVS能力不丢失、版本不被意外更新，提升集群稳定性。
IPVS在k8s中的核心作用
-
为K8s Service提供统一的虚拟访问入口（ClusterIP/NodePort/LoadBalancer），屏蔽后端Pod的IP动态变化和数量差异，让集群内/外客户端只需访问Service地址，即可对接背后所有承载同一业务的Pod，实现业务服务的网络抽象化；
-
基于内核态实现高性能的四层TCP/UDP流量转发，将访问Service的流量均匀分发到后端健康的Pod实例，消解单Pod的性能瓶颈，提升业务服务的整体并发处理能力；
-
由kube-proxy动态维护转发规则，实时剔除故障Pod、新增健康Pod，保证流量始终只转发到可用的业务实例，实现Pod实例级的故障自动屏蔽，保证业务服务的可用性；
-
支持多种负载均衡算法，可根据业务的实际需求（如无状态业务用轮询、有性能差异的Pod用加权轮询）灵活选择分发策略，适配不同业务场景的负载均衡需求；
-
与K8s容器网络插件深度兼容，能正常处理集群内的桥接流量、跨节点Pod通信流量，是K8s数据平面业务流量的核心转发枢纽，支撑起整个集群的Pod间通信和业务对外访问。
扫一扫
2020
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
