云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载本指南完整讲解 k0s 的Control Plane Load BalancingCPLB功能如何在不依赖外部负载均衡器的情况下用 Keepalived 的 VRRP 协议为控制平面构建高可用虚拟 IPVIP并通过用户态反向代理或 IPVS 把来自集群外部的流量均衡到多个控制器节点。读完本文你将掌握 CPLB 的完整配置语法YAML 级、与 NLLB 的配合方式、k0sctl 一键部署三控制器高可用集群的完整流程以及针对 VIP、端点列表、反向代理和 IPVS 的系统化排查方法。对于没有外部托管的负载均衡器的 k0s 集群CPLB 是构建高可用控制平面的内置方案它同时提供虚拟 IPVIP高可用与负载均衡两项能力。负载均衡意味着一个 IP 会把流量转发到每一个控制平面节点虚拟 IP 则意味着这个 IP 在同一时刻至少出现在一个节点上漂移式故障转移消除单点故障。CPLB 内部依赖 keepalived 的 VRRP 协议RFC 3768实现 VIP 高可用负载均衡则有两种选择k0s 进程内实现的用户态反向代理默认、推荐、最简单以及 Keepalived 的Virtual Servers特性底层依赖 IPVS。需要特别强调的是CPLB 解决的是集群外部访问控制平面的流量而集群内部节点到控制平面的流量由 NLLBNode Local Load balancing 负责。两者完全兼容官方建议在没有外部负载均衡器时同时启用二者。CPLB 是什么一次看懂 VIP 与负载均衡的分工CPLB 是部署在控制器节点上的一组组件组合从源码结构看它对应 pkg/component/controller/cplb 目录下的Keepalived控制器组件cplb_linux.go其职责包括生成并下发 Keepalived 的 VRRP 配置维护 VIP 的高可用漂移启动cplb-reconciler协程持续监听 Kubernetesdefault命名空间中kubernetes服务的 Endpoints维护负载均衡器的后端节点列表cplb_reconciler.go按配置选择启动用户态反向代理监听独立端口配合 iptables REDIRECT 规则或调用 Keepalived 的virtual_server / IPVS能力在启用 IPVS 时为每个节点创建dummyvip0哑接口并挂载 VIP/32掩码。VIP 与负载均衡是两件独立的事理解 CPLB 的第一步是区分两个概念虚拟 IPVIP一个不绑定在单一网卡上、而是在多台服务器之间漂浮的 IP 地址。它是故障转移机制保证任意时刻至少有一台可用服务器从而消除单点故障。负载均衡把到达 VIP 的流量按策略分发到每个控制平面节点。两者配合工作、关系密切但却是两个相互独立的进程这也是后文排查要分两条线走的原因。兼容性与使用边界什么场景下才能用 CPLBCPLB 依赖多项技术协同工作并非在所有场景下都可用。以下是官方明确的能力边界单节点集群不兼容CPLB不能与单节点single node模式一起使用即 k0s 不能以--single标志启动。单节点模式本身就是单一控制面无需也没有意义使用 VIP 高可用。Controller Worker 组合的约束k0s仅支持用户态反向代理这一种负载均衡方式用于 controllerworker 混合节点Keepalived 的 VirtualServersIPVS在该场景下不被支持。k0s 托管的 Kube-Router 与 Calico 均与用户态反向代理兼容但 k0s 会在控制平面节点上创建 iptables 规则这可能与自定义 CNI 插件不兼容使用自定义 CNI 时需要自行评估。与 externalAddress 的相互影响如果配置了spec.api.externalAddress控制平面负载均衡会隐式禁用k0s 的 endpoint-reconciler 组件效果等同于指定了--disable-componentsendpoint-reconciler标志。详细机制可参考禁用控制器组件的说明。与 NLLB 的配合CPLB 与 NLLB完全兼容推荐搭配使用。但注意NLLB 本身与spec.api.externalAddress不兼容配置时需避免同时使用这两者。负载均衡机制必须全局一致所有控制平面节点必须使用同一种负载均衡机制。混用不同机制不受支持且行为未定义undefined behavior。配置虚拟 IPVRRP 实例实现 VIP 高可用VIP 的定义虚拟 IP 是不与单一网络接口绑定的地址它在多台服务器之间漂移正常情况下只有一台MASTER持有它持有者故障后自动切换到另一台BACKUP 升级。这是标准的故障转移设计消除控制平面的单点故障。配置一个 VIP 需要的四要素CPLB 内部依赖 Keepalived 的VRRP InstanceVRRP 实例来管理一个或多个 VIP。绝大多数用户只需要一个 VRRP 实例 一个 VIPk0s 也支持多个 VRRP 实例与多个 VIP用于网络分段等高级场景。配置一个虚拟 IP 需要满足以下条件对应源码 pkg/apis/k0s/v1beta1/cplb.go 中VRRPInstance结构体的校验逻辑要素说明与默认值CIDR 地址用户自定义必须在网络中可路由。多数安装场景下与物理接口处于同一 CIDR。警告k0s 不感知外部 IP 地址管理管理员必须自行确保 IP 地址不冲突。源码要求每个 VIP 是合法接口地址RFC 4632 / RFC 4291 定义的 CIDR 形式认证密码authPass用户自定义应保证每个集群唯一。它只是防止意外冲突的机制不加密、也不防恶意攻击。源码校验长度必须为 18 个字符MaxLength8虚拟路由器 IDvirtualRouterID默认值51取值范围 1255必须在广播域内唯一。不指定时 k0s 会按 VRRP 实例顺序自动编号51、52、53…参见 cplb.go 中defaultVirtualRouterID offset的逻辑若实例过多导致超过 255配置校验会报错需要显式指定网络接口interface可选。不指定时 k0s 自动选择拥有默认路由的网卡也支持直接写 MAC 地址k0s 会尝试据此解析出接口名见 cplb.go除网络接口外其余所有字段VIP、密码、路由器 ID、通告间隔等在每个控制平面节点上必须完全一致。接口字段允许因节点而异。最小配置示例以下是最小的 CPLB 配置放在 k0s 配置文件的spec下spec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [VIP address/netmask] # for instance [172.16.0.100/16] authPass: my password配置中type目前仅支持Keepalived这一种取值源码CPLBType枚举唯一值见 cplb.goenabled默认false显式开启后才会部署 CPLB。多播与单播模式按 RFC 3768 的规定VRRP 实例默认使用多播multicast通信。某些网络环境不允许多播此时可显式配置单播unicastspec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [VIP address/netmask] # for instance [172.16.0.100/16] authPass: my password unicastSourceIP: ip address of this controller unicastPeers: [ip address of other controllers, ...]使用单播时有两条强制要求源码校验同样强制见 cplb.gok0s不会自动探测unicastSourceIP必须显式定义unicastPeers必须包含其他控制器节点的unicastSourceIP地址。另外unicastPeers中的地址不能与本节点的unicastSourceIP相同源码会在校验时直接报错。IPv6 VIP 的出口路由偏好addressLabelIPv6 没有主地址概念出口连接的路由偏好由操作系统根据IP labels地址标签或 IP rules决定。k0s 的虚拟地址遵循 RFC 6724 的 IP labels 规则默认把标签设为10000使出口连接仍然以主 IP 作为源地址。该值可针对每个 VRRP 实例覆盖spec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [VIP address/netmask] # for instance [2001:db8:2::1/64] authPass: my password addressLabel: 30000验证标签是否生效iproute2$ ip addrlabel | grep 2001:db8:2::1 prefix 2001:db8:2::1/128 label 30000两点细节源码行为见 cplb_linux.go 的setVirtualIPAddressLabels标签对应的前缀始终使用 128 掩码/128该标签机制只针对 IPv6 VIPIPv4 VIP 会被跳过k0s不会修改不属于 VIP 的标签。负载均衡机制两种方案如何选择k0s 目前提供两种负载均衡机制用户态反向代理运行在 k0s 进程内默认且推荐配置最简单Keepalived Virtual Servers底层依赖 IPVS适合需要更高性能或更灵活调度算法的场景。再次强调所有控制平面节点必须选用同一种机制。用户态反向代理默认这是默认行为。只要配置了一个带 VIP 的 VRRP 实例即可启用配置同最小配置示例spec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [VIP address/netmask] # for instance [172.16.0.100/16] authPass: my password从源码看cplb_linux.go其工作链路是反向代理监听独立端口UserSpaceProxyPort默认 6444可在keepalived.userSpaceProxyBindPort覆盖取值范围 165535通过一条 iptables nat 规则把到达 VIP 的 apiserver 端口流量REDIRECT到代理端口代理把连接按轮询转发到cplb-reconciler提供的 apiserver 端点列表在未收到首个端点更新前代理会先把流量转发到本机 127.0.0.1 的 apiserver 端口保证可用性。Keepalived Virtual ServersIPVSKeepalived 的 Virtual Servers 负载均衡比用户态反向代理性能更高但官方不推荐因为它有一些明显缺点与 controllerworker 组合不兼容不一定能在所有基础设施上工作排查问题显著更复杂当存在多个 VRRP 实例时所有服务器都要参与负载均衡在少数罕见情况下可能引发临时路由环路k0s 在模板注释中明确引用了 issue #5178 的修复背景。启用配置spec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [VIP address/netmask] # for instance [172.16.0.100/16] authPass: my password virtualServers: - ipAddress: VIP address without netmask # for instance 172.16.0.100注意virtualServers[].ipAddress是不带掩码的纯 IP 地址与vrrpInstances[].virtualIPs带 CIDR 掩码不同。Virtual Server 还支持更多可选参数默认值来自 cplb.go 的校验逻辑参数默认值说明delayLoop1m健康检查轮询的延迟定时器支持微秒精度超出部分会被截断lbAlgorr负载均衡算法可选rr、wrr、lc、wlc、lblc、dh、sh、sed、nqlbKindDR转发方式可选NAT、DR、TUNpersistenceTimeoutSeconds3606 分钟持久连接超时取值范围 1267840031 天启用 IPVS 时k0s 还会在每个节点创建名为dummyvip0的哑接口并把 VIP 以/32IPv4//128IPv6掩码挂上去供 IPVS 使用见 cplb_linux.go 的configureDummy。完整实战k0sctl 一键部署三控制器三工作节点集群下面的k0sctl配置演示了三个控制器 三个工作节点、开启控制平面负载均衡并顺带开启 NLLB的完整高可用集群。apiVersion: k0sctl.k0sproject.io/v1beta1 kind: Cluster metadata: name: k0s-cluster spec: hosts: - role: controller ssh: address: controller-0.k0s.lab user: root keyPath: ~/.ssh/id_rsa k0sBinaryPath: /opt/k0s uploadBinary: true - role: controller ssh: address: controller-1.k0s.lab user: root keyPath: ~/.ssh/id_rsa k0sBinaryPath: /opt/k0s uploadBinary: true - role: controller ssh: address: controller-2.k0s.lab user: root keyPath: ~/.ssh/id_rsa k0sBinaryPath: /opt/k0s uploadBinary: true - role: worker ssh: address: worker-0.k0s.lab user: root keyPath: ~/.ssh/id_rsa k0sBinaryPath: /opt/k0s uploadBinary: true - role: worker ssh: address: worker-1.k0s.lab user: root keyPath: ~/.ssh/id_rsa k0sBinaryPath: /opt/k0s uploadBinary: true - role: worker ssh: address: worker-2.k0s.lab user: root keyPath: ~/.ssh/id_rsa k0sBinaryPath: /opt/k0s uploadBinary: true k0s: version: k0s 版本号如 1.30.x config: spec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [192.168.122.200/24] authPass: Example nodeLocalLoadBalancing: # optional, but CPLB will often be used with NLLB. enabled: true type: EnvoyProxy保存为k0sctl.yaml后执行k0sctl apply引导集群示例输出基于 k0sctl v0.21.0$ k0sctl apply k0sctl v0.21.0 Copyright 2023, k0sctl authors. INFO Running phase: Connect to hosts INFO [ssh] worker-2.k0s.lab:22: connected INFO [ssh] controller-0.k0s.lab:22: connected INFO Running phase: Detect host operating systems INFO [ssh] controller-0.k0s.lab:22: is running Fedora Linux 38 (Cloud Edition) INFO Running phase: Acquire exclusive host lock INFO Running phase: Prepare hosts INFO Running phase: Gather host facts INFO [ssh] controller-0.k0s.lab:22: discovered eth0 as private interface INFO [ssh] controller-0.k0s.lab:22: discovered 192.168.122.37 as private address INFO Running phase: Validate hosts INFO Running phase: Validate facts INFO Running phase: Download k0s binaries to local host INFO Running phase: Upload k0s binaries to hosts INFO Running phase: Install k0s binaries on hosts INFO [ssh] controller-0.k0s.lab:22: validating configuration INFO Running phase: Configure k0s INFO [ssh] controller-0.k0s.lab:22: installing new configuration INFO Running phase: Initialize the k0s cluster INFO [ssh] controller-0.k0s.lab:22: installing k0s controller INFO [ssh] controller-0.k0s.lab:22: waiting for the k0s service to start INFO [ssh] controller-0.k0s.lab:22: waiting for kubernetes api to respond INFO Running phase: Install controllers INFO [ssh] controller-2.k0s.lab:22: validating api connection to https://192.168.122.200:6443 INFO [ssh] controller-1.k0s.lab:22: validating api connection to https://192.168.122.200:6443 INFO [ssh] controller-0.k0s.lab:22: generating token INFO [ssh] controller-1.k0s.lab:22: installing k0s controller INFO Running phase: Install workers INFO [ssh] worker-2.k0s.lab:22: validating api connection to https://192.168.122.200:6443 INFO [ssh] controller-0.k0s.lab:22: generating a join token for worker 1 INFO [ssh] worker-0.k0s.lab:22: installing k0s worker INFO [ssh] worker-2.k0s.lab:22: waiting for node to become ready INFO Running phase: Release exclusive host lock INFO Running phase: Disconnect from hosts INFO Finished in 2m20s INFO k0s cluster version k0s 版本号 is now installed INFO Tip: To access the cluster you can now fetch the admin kubeconfig using: INFO k0sctl kubeconfig可以看到所有控制器都以https://192.168.122.200:6443即 VIP作为 API 连接地址进行验证说明 CPLB 在安装阶段就已生效。安装完成后设置 kubeconfig 并验证集群k0sctl kubeconfig k0s-kubeconfig export KUBECONFIG$(pwd)/k0s-kubeconfig三个工作节点全部就绪$ kubectl get nodes NAME STATUS ROLES AGE VERSION worker-0.k0s.lab Ready none 8m51s k8s 版本号k0s worker-1.k0s.lab Ready none 8m51s k8s 版本号k0s worker-2.k0s.lab Ready none 8m51s k8s 版本号k0s此时VIP 只出现在一个控制器上$ for i in controller-{0..2} ; do echo $i ; ssh $i -- ip -4 --oneline addr show | grep eth0; done controller-0 2: eth0 inet 192.168.122.37/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0\ valid_lft 2381sec preferred_lft 2381sec 2: eth0 inet 192.168.122.200/24 scope global secondary eth0\ valid_lft forever preferred_lft forever controller-1 2: eth0 inet 192.168.122.185/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0\ valid_lft 2390sec preferred_lft 2390sec controller-2 2: eth0 inet 192.168.122.87/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0\ valid_lft 2399sec preferred_lft 2399sec故障演练控制器宕机后 VIP 自动漂移现在模拟一台控制器故障直接关停controller-0$ ssh controller-0 sudo poweroff Connection to 192.168.122.37 closed by remote host.CPLB 提供的高可用立即生效——VIP 已漂移到另一台节点$ for i in controller-{1..2} ; do echo $i ; ssh $i -- ip -4 --oneline addr show | grep eth0; done controller-1 2: eth0 inet 192.168.122.185/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0\ valid_lft 2173sec preferred_lft 2173sec 2: eth0 inet 192.168.122.200/24 scope global secondary eth0\ valid_lft forever preferred_lft forever controller-2 2: eth0 inet 192.168.122.87/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0\ valid_lft 2182sec preferred_lft 2182sec集群继续正常工作节点列表不受影响$ kubectl get nodes NAME STATUS ROLES AGE VERSION worker-0.k0s.lab Ready none 8m51s k8s 版本号k0s worker-1.k0s.lab Ready none 8m51s k8s 版本号k0s worker-2.k0s.lab Ready none 8m51s k8s 版本号k0s故障排查指南VIP 与负载均衡虽然协同工作、关系紧密但它们是两个独立进程必须作为两个独立功能分别排查。排查虚拟 IPVIP第一步确认VIP 在任意时刻只出现在一个节点上。假设 VIP 为172.17.0.102/16、接口为eth0期望输出如下controller0:/# ip a s eth0 53: eth0if54: BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever inet 172.17.0.102/16 scope global secondary eth0 valid_lft forever preferred_lft forevercontroller1:/# ip a s eth0 55: eth0if56: BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever注意当使用virtualServersIPVS时每个节点上必须存在名为dummyvip0的哑接口且带有/32掩码的 VIP——这个地址不是漂移的 VIP 本体即使 VIP 被别的节点持有dummyvip0上的/32地址也必须存在controller0:/# ip a s dummyvip0 | grep 172.17.0.102 inet 172.17.0.102/32 scope global dummyvip0controller1:/# ip a s dummyvip0 | grep 172.17.0.102 inet 172.17.0.102/32 scope global dummyvip0若以上现象不满足查看 keepalived 日志k0s 日志中按componentkeepalived过滤controller0:/# journalctl -u k0scontroller | grep componentkeepalived time2024-11-19 12:56:11 levelinfo msgStarting to supervise componentkeepalived time2024-11-19 12:56:11 levelinfo msgStarted successfully, go nuts pid 409 componentkeepalived time2024-11-19 12:56:11 levelinfo msgTue Nov 19 12:56:11 2024: Starting Keepalived vkeepalived 版本 componentkeepalived streamstderr [...]Keepalived 的配置存放在 k0s 运行目录下的keepalived.conf文件中默认路径为/run/k0s/keepalived.conf源码定义见 cplb_linux.go 的configFilePath。文件中应为每个vrrpInstance生成一个对应的vrrp_instance段。最后正常情况下每个 k0s 控制器应有两个 keepalived 进程在运行。排查负载均衡器的端点列表cplb-reconciler用户态反向代理和 Keepalived Virtual Servers 都需要一份端点列表来执行负载均衡二者共享名为cplb-reconciler的组件它负责设置负载均衡器的后端列表并持续监听default命名空间中的kubernetesEndpointscontroller0:/# kubectl get ep kubernetes -n default NAME ENDPOINTS AGE kubernetes 172.17.0.6:6443,172.17.0.7:6443,172.17.0.8:6443 9m14s观察cplb-reconciler的更新过程源码实现见 cplb_reconciler.go它通过 Kubernetes watch 机制跟踪端点变化controller0:/# journalctl -u k0scontroller | grep componentcplb-reconciler time2024-11-20 20:29:28 levelerror msgFailed to watch API server endpoints, last observed version is \\, starting over in 10s ... componentcplb-reconciler errorGet \https://172.17.0.6:6443/api/v1/namespaces/default/endpoints?fieldSelectormetadata.name%3Dkubernetestimeout30stimeoutSeconds30\: dial tcp 172.17.0.6:6443: connect: connection refused time2024-11-20 20:29:38 levelinfo msgUpdated the list of IPs: [172.17.0.6] componentcplb-reconciler time2024-11-20 20:29:55 levelinfo msgUpdated the list of IPs: [172.17.0.6 172.17.0.7] componentcplb-reconciler time2024-11-20 20:29:59 levelinfo msgUpdated the list of IPs: [172.17.0.6 172.17.0.7 172.17.0.8] componentcplb-reconciler从日志可以清晰看到端点列表从空 → 单节点 → 多节点的收敛过程这正是控制器逐个加入集群时负载均衡后端列表的实时反映。排查用户态反向代理用户态反向代理运行在 k0s 进程内监听一个独立 socket默认端口6444controller0:/# netstat -tlpn | grep 6444 tcp 0 0 :::6444 :::* LISTEN 345/k0s随后一条 iptables 规则把到达 VIP 的 apiserver 端口流量转发到该 socket-A PREROUTING -d VIP/32 -p tcp -m tcp --dport apiserver port -j REDIRECT --to-ports userspace proxy port真实示例VIP 为172.17.0.102controller0:/# /var/lib/k0s/bin/iptables-save | grep 6444 -A PREROUTING -d 172.17.0.102/32 -p tcp -m tcp --dport 6443 -j REDIRECT --to-ports 6444注意以 IPv6 为主地址族的集群应使用ip6tables或ip6tables-save检查规则。如果负载均衡没有按预期工作可以直接与代理建立连接来验证。判断它是否真的在负载均衡的可靠办法是查看服务证书指纹是否轮换每个后端 apiserver 的证书不同controller0:/# ip -o addr s eth0 43: eth0 inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0\ valid_lft forever preferred_lft forever 43: eth0 inet 172.17.0.102/16 scope global secondary eth0\ valid_lft forever preferred_lft forever controller0:/# openssl s_client -connect 172.17.0.102:6444 /dev/null 2/dev/null | openssl x509 -noout -fingerprint SHA1 FingerprintB7:90:E6:E4:E1:EE:5B:19:72:99:02:28:54:36:D9:84:D5:39:67:8B controller0:/# openssl s_client -connect 172.17.0.102:6444 /dev/null 2/dev/null | openssl x509 -noout -fingerprint SHA1 Fingerprint89:94:5C:E5:50:7E:40:B2:E5:20:E7:70:E8:58:91:ED:63:B0:EC:65 controller0:/# openssl s_client -connect 172.17.0.102:6444 /dev/null 2/dev/null | openssl x509 -noout -fingerprint SHA1 Fingerprint49:0D:79:FD:79:6F:A0:E4:9D:BA:A1:65:9C:C5:54:CF:E5:20:BF:A8 controller0:/# openssl s_client -connect 172.17.0.102:6444 /dev/null 2/dev/null | openssl x509 -noout -fingerprint SHA1 FingerprintB7:90:E6:E4:E1:EE:5B:19:72:99:02:28:54:36:D9:84:D5:39:67:8B证书指纹依次循环B7 → 89 → 49 → B7证明流量被轮询分发到了不同后端。注意不能通过 localhost 地址查询 6444 端口存在 iptables 冲突。预期行为是任何地址上都能访问 6443 端口除 localhost 外的任何地址上都能访问 6444 端口。排查 Keepalived Virtual ServersVirtual Servers 场景下先按上文排查虚拟 IP一节的方法检查 Keepalived 日志与配置文件。启用 Virtual Servers 后k0s 还会额外生成两个文件运行目录默认为/run/k0skeepalived-virtualservers-generated.conf包含应参与负载均衡的控制平面节点列表keepalived-virtualservers-consumed.conf一个符号链接——当当前 VRRP 实例状态为master时指向keepalived-virtualservers-generated.conf为backup时指向/dev/null。该文件仅在恰好只有一个 VRRP 实例时生成。这一符号链接机制的实现位于 cmd/keepalived/keepalived_linux.go 的keepalived-setstate隐藏子命令中Keepalived 模板通过notify_master/notify_backup回调触发该命令命令重设符号链接后向 keepalived 进程发送SIGHUP使其重新加载配置模板中的这段逻辑见 cplb_templates.go。这正是 k0s 规避多 VRRP 实例下路由环路的手段。另外可以用ipvsadm直接查看实际的 IPVS 配置controller0:/# ipvsadm --save -n IP Virtual Server version 1.2.1 (size4096) Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.122.200:6443 rr persistent 360 - 192.168.122.185:6443 Route 1 0 0 - 192.168.122.87:6443 Route 1 0 0 - 192.168.122.122:6443 Route 1 0 0此例中192.168.122.200是虚拟 IP192.168.122.185、192.168.122.87、192.168.122.122是控制平面节点调度算法为rr轮询并带 360 秒的持久连接超时。如果只有一个 VRRP 实例只有当前的 master 节点执行负载均衡。自定义 Keepalived 模板警告对 Keepalived 模板的任何自定义都超出 k0s 的支持范围。模板变量不是稳定 API升级 k0s 时模板可能被破坏请自行承担风险。对于需要额外定制层的进阶用户k0s 允许通过提供自定义 Go 模板来定制 Keepalived 配置。最小示例spec: network: controlPlaneLoadBalancing: enabled: true type: Keepalived keepalived: vrrpInstances: - virtualIPs: [VIP address/netmask] authPass: my password configTemplateVRRP: /path/to/custom-vrrp-template.conf configTemplateVS: /path/to/custom-virtualservers-template.conf强烈建议基于默认模板派生自定义模板。默认模板可以通过以下命令输出到 stdout命令实现见 cmd/keepalived/keepalived_config.go模板源文本见 pkg/component/controller/cplb/cplb_templates.go# View the default VRRP template k0s keepalived-config vrrp # View the default Virtual Servers template k0s keepalived-config virtualservers模板只在 k0s 引导bootstrap期间读取。修改模板后需要重启 k0s才能生效。VRRP 模板变量configTemplateVRRP变量说明.IPVSLoadBalancer是否启用 IPVS 负载均衡器.K0sBink0s 二进制路径.RunDirk0s 运行目录.VRRPInstances存放所有 VRRP 实例的结构体.VRRPInstances[].AdvertIntervalSecondsVRRP 实例的通告间隔.VRRPInstances[].AuthPass访问 VRRPD 的密码.VRRPInstances[].Interface虚拟路由器使用的网络接口.VRRPInstances[].UnicastPeers单播对等节点 IP 列表.VRRPInstances[].UnicastSourceIP单播通信的源 IP 地址.VRRPInstances[].VirtualIPs带 CIDR 记法的虚拟 IP 列表.VRRPInstances[].VirtualRouterIDVRRP 路由器 IDVirtual Servers 模板变量configTemplateVS变量说明.APIServerPortKubernetes API 服务器端口.RealServers真实服务器控制平面节点IP 列表.VirtualServers虚拟服务器配置数组.VirtualServers[].DelayLoop检查轮询的延迟定时器.VirtualServers[].IPAddress虚拟服务器使用的虚拟 IP 地址.VirtualServers[].LBAlgo负载均衡算法.VirtualServers[].LBKind负载均衡转发方式.VirtualServers[].PersistenceTimeoutSeconds持久连接的超时时间秒使用自定义模板的重要注意事项无官方支持自定义模板配置不受官方支持遇到问题时官方可能会要求你用默认模板复现问题。升级关注升级 k0s 时务必审查默认模板的变化并将其合入你的自定义模板。充分测试部署到生产环境前务必在非生产环境对自定义模板做完整测试。语法校验有限k0s 对自定义模板只做最小限度的校验。无效的 Keepalived 配置会导致整个 CPLB 功能失败。小结CPLB 是 k0s 在无外部负载均衡器场景下提供控制平面高可用的内置方案VRRP 负责 VIP 漂移消除单点故障负载均衡用户态反向代理或 IPVS负责把外部流量分发到所有控制器。配置层面只需在spec.network.controlPlaneLoadBalancing下声明 VIP、密码与路由器 ID即可与 NLLB 组合出完整的外部 VIP 接入 内部节点就近访问高可用网络架构。相关配置项的完整类型定义与校验规则可查阅 pkg/apis/k0s/v1beta1/cplb.go运行时实现可深入 pkg/component/controller/cplb 目录继续研究。赞分享云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载相关推荐kinit负载均衡流量分发与负载均衡实战指南kinit负载均衡流量分发与负载均衡实战指南 引言为什么需要负载均衡 在现代Web应用架构中随着用户量的增长和业务复杂度的提升单一服务器往往难以承受高后端前端任务调度认证鉴权移动开发create-react-native-module生成项目结构深度剖析开发者必知的文件组织create react native module生成项目结构深度剖析开发者必知的文件组织 create react native module是一款强大的Keepalived实现负载均衡与高可用性的利器Keepalived实现负载均衡与高可用性的利器 引言为什么需要负载均衡与高可用性 在现代互联网架构中服务的稳定性和可用性是企业生存的基石。你是否遇到过网络负载均衡高可用上一篇HS2-HF Patch终极指南5分钟完成HoneySelect2汉化与MOD整合下一篇如何快速安装Honey Select 2游戏增强补丁5分钟新手指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考