云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载k0s 的 Node-local load balancing节点本地负载均衡下文简称 NLLB为没有外部托管负载均衡器的集群提供了一种在集群内部实现控制平面高可用的方案每个 worker 节点在自己的 loopback 接口上运行一个负载均衡器把 kubelet、kube-proxy、konnectivity-agent 等 worker 组件发往 API Server 的请求分摊到所有当前可用的 controller 节点上。本文基于 k0s 官方文档与仓库源码完整讲解 NLLB 的工作原理、启用条件、k0s.yaml 与 k0sctl 两种配置方式、完整的 3 控制器 2 worker 实战示例以及 controller 宕机故障模拟与验证方法并深入剖析 Envoy/Traefik 两种后端在源码层面的实现细节。什么是节点本地负载均衡对于没有 外部托管负载均衡器 的集群k0s 提供了另一种获得高可用控制平面的途径——至少在集群内部是这样的。与外部负载均衡器不同节点本地负载均衡完全发生在 worker 节点上它不负责让控制平面对外部世界例如使用 Lens 或kubectl等管理工具与集群交互的用户保持高可用它的作用是让集群自身在 controller 节点故障时具备内部韧性——worker 上的各组件不会因为当初加入集群时绑定的那个 controller 宕机而失去与 API Server 的连接。换句话说NLLB 解决的是「worker 内部组件访问控制平面的可靠性」而不是「外部客户端访问控制平面的可靠性」这两者是互补关系。技术原理worker 进程如何托管负载均衡器从源码实现看NLLB 的核心是一个运行在 worker 节点上的 Reconciler 组件其整体工作流如下在 loopback 接口上运行负载均衡器k0s worker 进程在每台 worker 节点的回环接口127.0.0.1等上管理一个负载均衡器。负载均衡器以静态 Podstatic Pod的形式在kube-system命名空间内运行Pod 名为nllb由 kubelet 直接托管具备system-node-critical优先级与全容忍tolerations确保节点优雅关停与节点压力驱逐时它能够存活到最后见 envoy.go 中 Pod 清单的构造逻辑。两种可选的负载均衡后端仓库中pkg/component/worker/nllb包提供了两个 backend 实现——Envoy 与 TraefikEnvoy 是默认后端。需要特别注意的是Envoy 在 ARMv7、RISC-V 与 Windows 平台上不可用如果计划在这些平台上运行 k0s请改用 Traefik。请求分布而非固定指向启用 NLLB 后worker 组件对控制平面的请求不再固定发往该 worker 加入集群时使用的那个 controller而是均匀分布到当前所有可用的 controller 节点从而在某个 controller 变得不健康时显著提升集群的可靠性与容错能力。后端选择与静态 Pod 装配NewReconciler 根据 worker profile 中的NodeLocalLoadBalancing.Type选择后端实现并为每种后端在运行时目录$XDG_RUNTIME_DIR/k0s/nllb/默认/run/k0s/nllb/下创建独立子目录EnvoyProxy类型 →envoyProxy后端运行目录…/nllb/envoyTraefik类型 →traefik后端运行目录…/nllb/traefik。每个后端都实现同一套 backend 接口init、start、getAPIServerAddress、updateAPIServers、stop。负载均衡的接入点打补丁的 kubeconfigNLLB 的关键接入方式是重写 kubelet 使用的 kubeconfigReconciler 在启动时读取常规的 kubelet kubeconfigKubeletAuthConfigPath将其中的 API Server 地址改写为本地负载均衡器的地址如127.0.0.1:7443并原子写入运行时目录下的kubeconfig.yaml见 writePatchedKubeconfig通过 GetKubeletKubeconfigPath 与 NewClient 两个方法kubelet 与 worker 上的其他 Kubernetes 客户端都以这个「负载均衡版」kubeconfig 为准从而把全部控制平面流量导向本机的负载均衡器。动态更新上游地址协调循环上游 controller 列表不是静态的。Reconciler 启动后运行一个 协调循环通过负载均衡版 kubeconfig 创建 Kubernetes 客户端监视 worker profileWatchProfile中APIServerAddresses的变化收到更新后将新地址列表排序并与当前实际地址比对若有差异则调用updateAPIServers更新负载均衡器配置同时以 60 秒为周期重试失败的更新ticker并明确拒绝「移除全部上游地址」的变更防止把集群锁死。Envoy 配置细节以 Envoy 后端为例writeEnvoyConfigFiles 会生成两个配置文件envoy.yamlbootstrap定义两个 listener——apiserverTCP 代理到 API Server 集群与konnectivityTCP 代理到 konnectivity 集群若 konnectivity 绑定端口非 0 才生成cds.yaml集群定义apiserver集群使用RANDOM负载均衡策略konnectivity集群使用ROUND_ROBIN策略两者均配置 TCP 健康检查tcp_health_check5 秒间隔、失败 5 次判不健康、成功 3 次恢复将不健康的 controller 自动移出上游列表。启用前提要使用节点本地负载均衡集群必须满足以下全部条件不使用外部托管负载均衡器集群配置中不能设置非空的spec.api.externalAddress不是单节点模式k0s 不能以--single标志启动参见 单节点部署建议多 controller 节点NLLB 在单 controller 集群中也能工作但只有在配合高可用控制平面时才真正有价值。启用方式一在 k0s 集群配置中开启在集群配置文件k0s.yaml中添加如下配置spec: network: nodeLocalLoadBalancing: enabled: true type: EnvoyProxy启用后所有新加入的 worker 节点都会自动使用节点本地负载均衡对于已经在运行中的 worker 节点必须重启其 k0s worker 进程新配置才会生效。配置结构与默认值源码级说明该配置项对应pkg/apis/k0s/v1beta1/nllb.go中的 NodeLocalLoadBalancing 结构体。其字段及默认值如下字段含义默认值enabled是否在 worker 节点上启用 NLLBfalsetype后端类型仅支持EnvoyProxy或TraefikEnvoyProxy若enabled: true而未指定 type则必须显式给出否则校验报错envoyProxyEnvoy 后端专属配置见下文见DefaultEnvoyProxytraefikTraefik 后端专属配置见下文见DefaultTraefikEnvoyProxy与Traefik两个子结构体字段完全一致字段含义默认值image负载均衡 Pod 使用的 OCI 镜像对应constant.EnvoyProxyImage/constant.TraefikImage及其版本imagePullPolicy镜像拉取策略可选Always、Never、IfNotPresent默认镜像拉取策略apiServerBindPort负载均衡器在 worker loopback 接口上为 Kubernetes API Server 绑定的端口取值 1~655357443konnectivityServerBindPort负载均衡器在 worker loopback 接口上为 konnectivity server 绑定的端口取值 1~655357132在 setDefaults 与 Validate 中可以看到类型为空时自动回填EnvoyProxy并补齐对应后端的默认配置类型不合法、镜像缺失、端口非法validation.IsValidPortNum或imagePullPolicy取值非法时都会在配置校验阶段直接报错。端口默认值7443API Server与7132konnectivity同时由pkg/apis/k0s/v1beta1/nllb.go中的 kubebuilder 标记kubebuilder:default7443等声明pkg/component/worker/nllb/envoy.go与traefik.go在生成 Pod 清单时实际读取并使用这些端口。启用方式二在 k0sctl 配置中开启如果使用k0sctl部署则在 k0sctl 配置文件k0sctl.yaml中添加如下配置spec: k0s: config: spec: network: nodeLocalLoadBalancing: enabled: true type: EnvoyProxy完整实战示例k0sctl 部署 3 控制器 2 worker 集群下面是一份完整的k0sctl配置文件包含三台 controller 与两台 worker并启用了节点本地负载均衡apiVersion: k0sctl.k0sproject.io/v1beta1 kind: Cluster metadata: name: k0s-cluster spec: k0s: version: {{{ k0s_version }}} config: spec: network: nodeLocalLoadBalancing: enabled: true type: EnvoyProxy hosts: - role: controller ssh: address: 10.81.146.254 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: controller ssh: address: 10.81.146.184 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: controller ssh: address: 10.81.146.113 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: worker ssh: address: 10.81.146.198 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: worker ssh: address: 10.81.146.51 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s注{{{ k0s_version }}}是 k0s 官方文档站mkdocs的模板占位符实际使用时请替换为具体的 k0s 版本号如v1.30.2k0s.0。将上述配置保存为k0sctl.yaml并执行k0sctl apply来引导集群$ k0sctl apply ⣿⣿⡇⠀⠀⢀⣴⣾⣿⠟⠁⢸⣿⣿⣿⣿⣿⣿⣿⡿⠛⠁⠀⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀█████████ █████████ ███ ⣿⣿⡇⣠⣶⣿⡿⠋⠀⠀⠀⢸⣿⡇⠀⠀⠀⣠⠀⠀⢀⣠⡆⢸⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀███ ███ ███ ⣿⣿⣿⣿⣟⠋⠀⠀⠀⠀⠀⢸⣿⡇⠀⢰⣾⣿⠀⠀⣿⣿⡇⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀███ ███ ███ ⣿⣿⡏⠻⣿⣷⣤⡀⠀⠀⠀⠸⠛⠁⠀⠸⠋⠁⠀⠀⣿⣿⡇⠈⠉⠉⠉⠉⠉⠉⠉⠉⢹⣿⣿⠀███ ███ ███ ⣿⣿⡇⠀⠀⠙⢿⣿⣦⣀⠀⠀⠀⣠⣶⣶⣶⣶⣶⣶⣿⣿⡇⢰⣶⣶⣶⣶⣶⣶⣶⣶⣾⣿⣿⠀█████████ ███ ██████████ k0sctl v0.21.0 Copyright 2023, k0sctl authors. INFO Running phase: Connect to hosts INFO [ssh] 10.81.146.254:22: connected INFO [ssh] 10.81.146.184:22: connected INFO [ssh] 10.81.146.113:22: connected INFO [ssh] 10.81.146.51:22: connected INFO [ssh] 10.81.146.198:22: connected INFO Running phase: Detect host operating systems INFO [ssh] 10.81.146.254:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.113:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.184:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.198:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.51:22: is running Alpine Linux v3.17 INFO Running phase: Acquire exclusive host lock INFO Running phase: Prepare hosts INFO [ssh] 10.81.146.113:22: installing packages (curl) INFO [ssh] 10.81.146.198:22: installing packages (curl, iptables) INFO [ssh] 10.81.146.254:22: installing packages (curl) INFO [ssh] 10.81.146.51:22: installing packages (curl, iptables) INFO [ssh] 10.81.146.184:22: installing packages (curl) INFO Running phase: Gather host facts INFO [ssh] 10.81.146.184:22: using k0s-controller-1 as hostname INFO [ssh] 10.81.146.51:22: using k0s-worker-1 as hostname INFO [ssh] 10.81.146.198:22: using k0s-worker-0 as hostname INFO [ssh] 10.81.146.113:22: using k0s-controller-2 as hostname INFO [ssh] 10.81.146.254:22: using k0s-controller-0 as hostname INFO [ssh] 10.81.146.184:22: discovered eth0 as private interface INFO [ssh] 10.81.146.51:22: discovered eth0 as private interface INFO [ssh] 10.81.146.198:22: discovered eth0 as private interface INFO [ssh] 10.81.146.113:22: discovered eth0 as private interface INFO [ssh] 10.81.146.254:22: discovered eth0 as private interface INFO Running phase: Download k0s binaries to local host INFO Running phase: Validate hosts INFO Running phase: Gather k0s facts INFO Running phase: Validate facts INFO Running phase: Upload k0s binaries to hosts INFO [ssh] 10.81.146.254:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.113:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.51:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.198:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.184:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO Running phase: Configure k0s INFO [ssh] 10.81.146.254:22: validating configuration INFO [ssh] 10.81.146.184:22: validating configuration INFO [ssh] 10.81.146.113:22: validating configuration INFO [ssh] 10.81.146.113:22: configuration was changed INFO [ssh] 10.81.146.184:22: configuration was changed INFO [ssh] 10.81.146.254:22: configuration was changed INFO Running phase: Initialize the k0s cluster INFO [ssh] 10.81.146.254:22: installing k0s controller INFO [ssh] 10.81.146.254:22: waiting for the k0s service to start INFO [ssh] 10.81.146.254:22: waiting for kubernetes api to respond INFO Running phase: Install controllers INFO [ssh] 10.81.146.254:22: generating token INFO [ssh] 10.81.146.184:22: writing join token INFO [ssh] 10.81.146.184:22: installing k0s controller INFO [ssh] 10.81.146.184:22: starting service INFO [ssh] 10.81.146.184:22: waiting for the k0s service to start INFO [ssh] 10.81.146.184:22: waiting for kubernetes api to respond INFO [ssh] 10.81.146.254:22: generating token INFO [ssh] 10.81.146.113:22: writing join token INFO [ssh] 10.81.146.113:22: installing k0s controller INFO [ssh] 10.81.146.113:22: starting service INFO [ssh] 10.81.146.113:22: waiting for the k0s service to start INFO [ssh] 10.81.146.113:22: waiting for kubernetes api to respond INFO Running phase: Install workers INFO [ssh] 10.81.146.51:22: validating api connection to https://10.81.146.254:6443 INFO [ssh] 10.81.146.198:22: validating api connection to https://10.81.146.254:6443 INFO [ssh] 10.81.146.254:22: generating token INFO [ssh] 10.81.146.198:22: writing join token INFO [ssh] 10.81.146.51:22: writing join token INFO [ssh] 10.81.146.198:22: installing k0s worker INFO [ssh] 10.81.146.51:22: installing k0s worker INFO [ssh] 10.81.146.198:22: starting service INFO [ssh] 10.81.146.51:22: starting service INFO [ssh] 10.81.146.198:22: waiting for node to become ready INFO [ssh] 10.81.146.51:22: waiting for node to become ready INFO Running phase: Release exclusive host lock INFO Running phase: Disconnect from hosts INFO Finished in 3m30s INFO k0s cluster version {{{ k0s_version }}} is now installed INFO Tip: To access the cluster you can now fetch the admin kubeconfig using: INFO k0sctl kubeconfig集群引导完成后配置 kubeconfig 以便与本集群交互k0sctl kubeconfig k0s-kubeconfig export KUBECONFIG$(pwd)/k0s-kubeconfig验证集群状态三台 controller 均已就绪并提供了各自的 API Server 端点$ kubectl -n kube-node-lease get \ lease/k0s-ctrl-k0s-controller-0 \ lease/k0s-ctrl-k0s-controller-1 \ lease/k0s-ctrl-k0s-controller-2 \ lease/k0s-endpoint-reconciler NAME HOLDER AGE k0s-ctrl-k0s-controller-0 9ec2b221890e5ed6f4cc70377bfe809fef5be541a2774dc5de81db7acb2786f1 2m37s k0s-ctrl-k0s-controller-1 fe45284924abb1bfce674e5a9aa8d647f17c81e53bbab17cf28288f13d5e8f97 2m18s k0s-ctrl-k0s-controller-2 5ab43278e63fc863b2a7f0fe1aab37316a6db40c5a3d8a17b9d35b5346e23b3d 2m9s k0s-endpoint-reconciler 9ec2b221890e5ed6f4cc70377bfe809fef5be541a2774dc5de81db7acb2786f1 2m37s $ kubectl -n default get endpoints NAME ENDPOINTS AGE kubernetes 10.81.146.113:6443,10.81.146.184:6443,10.81.146.254:6443 2m49s第一台 controller10.81.146.254是当前的 k0s leaderdefault/kubernetesEndpoints 中同时列出了三台 controller 的地址——这正是 NLLB 上游地址列表的数据来源。两台 worker 节点也处于就绪状态$ kubectl get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k0s-worker-0 Ready none 2m16s {{{ kubelet_ver }}} 10.81.146.198 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}} k0s-worker-1 Ready none 2m15s {{{ kubelet_ver }}} 10.81.146.51 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}}注{{{ kubelet_ver }}}与{{{ containerd_version }}}为文档站模板占位符实际输出中分别对应形如v1.30.2k0s的 kubelet 版本与具体 containerd 版本。每台 worker 节点上都运行着一个 NLLB 负载均衡器 Pod这正是源码中makePodManifest构造的静态 Pod标签为app.kubernetes.io/managed-byk0s,app.kubernetes.io/componentnllb$ kubectl -n kube-system get pod -owide -l app.kubernetes.io/managed-byk0s,app.kubernetes.io/componentnllb NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nllb-k0s-worker-0 1/1 Running 0 81s 10.81.146.198 k0s-worker-0 none none nllb-k0s-worker-1 1/1 Running 0 85s 10.81.146.51 k0s-worker-1 none none集成测试佐证仓库的集成测试 inttest/nllb/nllb_test.go 对上述场景做了自动化验证测试套件默认启动3 台 controller 2 台 worker分别以EnvoyProxy与Traefik两种类型运行测试通过network.NodeLocalLoadBalancing.Type切换后端见测试第 53-54 行与第 364 行等待nllb-node静态 Pod 就绪后通过关闭部分 controller 验证集群在 controller 故障下仍能维持运行checkClusterReadiness支持传入degradedControllers参数。单元测试 reconciler_test.go 则验证了 Reconciler 的启动、kubeconfig 补丁写入、API Server 地址更新等核心行为。故障演练模拟 controller 宕机集群正在使用节点本地负载均衡能够容忍一台 controller 的宕机。下面关闭第一台 controller 来模拟故障场景$ ssh -i k0s-ssh-private-key.pem k0s10.81.146.254 echo Powering off $(hostname) ... sudo poweroff Powering off k0s-controller-0 ...从外部看kubeconfig 仍指向已下线的 controllerNLLB 提供的是集群内部的高可用而不是外部的高可用。默认生成的k0s-kubeconfig把第一台 controller 的 IP 写为 API Server 地址。这台 controller 已下线因此直接调用kubectl会失败$ kubectl get nodes Unable to connect to the server: dial tcp 10.81.146.254:6443: connect: no route to host把k0s-kubeconfig中的服务器地址从第一台 controller 改为另一台地址可从k0sctl.yaml或上面kubectl -n default get endpoints的输出中获取集群即可恢复访问$ ssh -i k0s-ssh-private-key.pem k0s10.81.146.184 hostname k0s-controller-1 $ sed -i s#https://10\\.81\\.146\\.254:6443#https://10.81.146.184:6443#g k0s-kubeconfig $ kubectl get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k0s-worker-0 Ready none 3m35s {{{ kubelet_ver }}} 10.81.146.198 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}} k0s-worker-1 Ready none 3m34s {{{ kubelet_ver }}} 10.81.146.51 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}} $ kubectl -n kube-system get pods -owide -l app.kubernetes.io/managed-byk0s,app.kubernetes.io/componentnllb NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nllb-k0s-worker-0 1/1 Running 0 2m31s 10.81.146.198 k0s-worker-0 none none nllb-k0s-worker-1 1/1 Running 0 2m35s 10.81.146.51 k0s-worker-1 none none注意NLLB Pod 依然正常运行worker 节点的内部控制平面访问从未中断。从内部看集群保持运行第一台 controller 已不再活跃它的 IP 不再出现在default/kubernetesEndpoints 中其 k0s controller lease 也已变成孤儿holder 为空$ kubectl -n default get endpoints NAME ENDPOINTS AGE kubernetes 10.81.146.113:6443,10.81.146.184:6443 3m56s $ kubectl -n kube-node-lease get \ lease/k0s-ctrl-k0s-controller-0 \ lease/k0s-ctrl-k0s-controller-1 \ lease/k0s-ctrl-k0s-controller-2 \ lease/k0s-endpoint-reconciler NAME HOLDER AGE k0s-ctrl-k0s-controller-0 4m47s k0s-ctrl-k0s-controller-1 fe45284924abb1bfce674e5a9aa8d647f17c81e53bbab17cf28288f13d5e8f97 4m28s k0s-ctrl-k0s-controller-2 5ab43278e63fc863b2a7f0fe1aab37316a6db40c5a3d8a17b9d35b5346e23b3d 4m19s k0s-endpoint-reconciler 5ab43278e63fc863b2a7f0fe1aab37316a6db40c5a3d8a17b9d35b5346e23b3d 4m47s尽管那台 controller 不可用集群依然完全可用第三台 controller 已成为新的 k0s leader业务负载照常调度与运行$ kubectl -n default run nginx --imagenginx pod/nginx created $ kubectl -n default get pods -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx 1/1 Running 0 16s 10.244.0.5 k0s-worker-1 none none $ kubectl -n default logs nginx /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up [notice] 1#1: using the epoll event method [notice] 1#1: nginx/1.23.3 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) [notice] 1#1: OS: Linux 5.15.83-0-virt [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 [notice] 1#1: start worker processes [notice] 1#1: start worker process 28关键注意事项与适用边界对内高可用对外非高可用NLLB 只保证集群内部组件kubelet、kube-proxy、konnectivity-agent 等对控制平面访问的韧性。外部客户端要获得高可用仍需要外部负载均衡器或自行维护 kubeconfig 中的 server 地址如本例中手动sed替换 IP 所示。平台限制Envoy 后端在 ARMv7、RISC-V 与 Windows 上不可用这些平台请使用type: Traefik。生效时机新加入的 worker 节点自动生效已运行的 worker 需要重启 k0s worker 进程。默认端口占用默认7443API Server与7132konnectivity绑定在 worker 的 loopback 接口上如与本地其他服务冲突可通过envoyProxy.apiServerBindPort/konnectivityServerBindPortTraefik 同理调整端口范围 1~65535。配置校验enabled: true时必须显式指定type非法类型、端口或镜像拉取策略会在配置校验阶段被拒绝见 nllb.go 的 Validate 实现。延伸阅读高可用控制平面与外部负载均衡器k0s 集群配置参考spec.api.externalAddress等k0sctl 安装指南单节点模式说明源码与测试配置结构体 pkg/apis/k0s/v1beta1/nllb.go、协调器 pkg/component/worker/nllb/reconciler.go、Envoy 后端 pkg/component/worker/nllb/envoy.go、Traefik 后端 pkg/component/worker/nllb/traefik.go、单元测试 pkg/component/worker/nllb/reconciler_test.go、集成测试 inttest/nllb/nllb_test.go赞分享云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载相关推荐Kubernetes 外部负载均衡器创建指南Kubernetes 外部负载均衡器创建指南 概述 在现代云原生应用部署中外部负载均衡器External LoadBalancer是实现高可用性和可扩展性文档教程云原生终极解析BinExport核心功能与架构设计详解终极解析BinExport核心功能与架构设计详解 BinExport是一款强大的反汇编导出工具能够将反汇编结果转换为Protocol Buffers格式为PaddlePaddle负载均衡高可用集群部署PaddlePaddle负载均衡高可用集群部署 概述 在大规模深度学习训练场景中单机性能往往无法满足需求分布式训练成为必然选择。PaddlePaddle作人工智能深度学习机器学习大模型分布式训练预训练上一篇Cats与Typelevel生态系统构建完整的函数式技术栈终极指南下一篇Folcolor编译指南使用Visual Studio 2022构建完整项目创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/8 7:49:05 · 阅读 1.2k k0s 节点本地负载均衡（NLLB）完全指南：为无外部负载均衡的高可用控制平面构建内部韧性
云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载k0s 的 Node-local load balancing节点本地负载均衡下文简称 NLLB为没有外部托管负载均衡器的集群提供了一种在集群内部实现控制平面高可用的方案每个 worker 节点在自己的 loopback 接口上运行一个负载均衡器把 kubelet、kube-proxy、konnectivity-agent 等 worker 组件发往 API Server 的请求分摊到所有当前可用的 controller 节点上。本文基于 k0s 官方文档与仓库源码完整讲解 NLLB 的工作原理、启用条件、k0s.yaml 与 k0sctl 两种配置方式、完整的 3 控制器 2 worker 实战示例以及 controller 宕机故障模拟与验证方法并深入剖析 Envoy/Traefik 两种后端在源码层面的实现细节。什么是节点本地负载均衡对于没有 外部托管负载均衡器 的集群k0s 提供了另一种获得高可用控制平面的途径——至少在集群内部是这样的。与外部负载均衡器不同节点本地负载均衡完全发生在 worker 节点上它不负责让控制平面对外部世界例如使用 Lens 或kubectl等管理工具与集群交互的用户保持高可用它的作用是让集群自身在 controller 节点故障时具备内部韧性——worker 上的各组件不会因为当初加入集群时绑定的那个 controller 宕机而失去与 API Server 的连接。换句话说NLLB 解决的是「worker 内部组件访问控制平面的可靠性」而不是「外部客户端访问控制平面的可靠性」这两者是互补关系。技术原理worker 进程如何托管负载均衡器从源码实现看NLLB 的核心是一个运行在 worker 节点上的 Reconciler 组件其整体工作流如下在 loopback 接口上运行负载均衡器k0s worker 进程在每台 worker 节点的回环接口127.0.0.1等上管理一个负载均衡器。负载均衡器以静态 Podstatic Pod的形式在kube-system命名空间内运行Pod 名为nllb由 kubelet 直接托管具备system-node-critical优先级与全容忍tolerations确保节点优雅关停与节点压力驱逐时它能够存活到最后见 envoy.go 中 Pod 清单的构造逻辑。两种可选的负载均衡后端仓库中pkg/component/worker/nllb包提供了两个 backend 实现——Envoy 与 TraefikEnvoy 是默认后端。需要特别注意的是Envoy 在 ARMv7、RISC-V 与 Windows 平台上不可用如果计划在这些平台上运行 k0s请改用 Traefik。请求分布而非固定指向启用 NLLB 后worker 组件对控制平面的请求不再固定发往该 worker 加入集群时使用的那个 controller而是均匀分布到当前所有可用的 controller 节点从而在某个 controller 变得不健康时显著提升集群的可靠性与容错能力。后端选择与静态 Pod 装配NewReconciler 根据 worker profile 中的NodeLocalLoadBalancing.Type选择后端实现并为每种后端在运行时目录$XDG_RUNTIME_DIR/k0s/nllb/默认/run/k0s/nllb/下创建独立子目录EnvoyProxy类型 →envoyProxy后端运行目录…/nllb/envoyTraefik类型 →traefik后端运行目录…/nllb/traefik。每个后端都实现同一套 backend 接口init、start、getAPIServerAddress、updateAPIServers、stop。负载均衡的接入点打补丁的 kubeconfigNLLB 的关键接入方式是重写 kubelet 使用的 kubeconfigReconciler 在启动时读取常规的 kubelet kubeconfigKubeletAuthConfigPath将其中的 API Server 地址改写为本地负载均衡器的地址如127.0.0.1:7443并原子写入运行时目录下的kubeconfig.yaml见 writePatchedKubeconfig通过 GetKubeletKubeconfigPath 与 NewClient 两个方法kubelet 与 worker 上的其他 Kubernetes 客户端都以这个「负载均衡版」kubeconfig 为准从而把全部控制平面流量导向本机的负载均衡器。动态更新上游地址协调循环上游 controller 列表不是静态的。Reconciler 启动后运行一个 协调循环通过负载均衡版 kubeconfig 创建 Kubernetes 客户端监视 worker profileWatchProfile中APIServerAddresses的变化收到更新后将新地址列表排序并与当前实际地址比对若有差异则调用updateAPIServers更新负载均衡器配置同时以 60 秒为周期重试失败的更新ticker并明确拒绝「移除全部上游地址」的变更防止把集群锁死。Envoy 配置细节以 Envoy 后端为例writeEnvoyConfigFiles 会生成两个配置文件envoy.yamlbootstrap定义两个 listener——apiserverTCP 代理到 API Server 集群与konnectivityTCP 代理到 konnectivity 集群若 konnectivity 绑定端口非 0 才生成cds.yaml集群定义apiserver集群使用RANDOM负载均衡策略konnectivity集群使用ROUND_ROBIN策略两者均配置 TCP 健康检查tcp_health_check5 秒间隔、失败 5 次判不健康、成功 3 次恢复将不健康的 controller 自动移出上游列表。启用前提要使用节点本地负载均衡集群必须满足以下全部条件不使用外部托管负载均衡器集群配置中不能设置非空的spec.api.externalAddress不是单节点模式k0s 不能以--single标志启动参见 单节点部署建议多 controller 节点NLLB 在单 controller 集群中也能工作但只有在配合高可用控制平面时才真正有价值。启用方式一在 k0s 集群配置中开启在集群配置文件k0s.yaml中添加如下配置spec: network: nodeLocalLoadBalancing: enabled: true type: EnvoyProxy启用后所有新加入的 worker 节点都会自动使用节点本地负载均衡对于已经在运行中的 worker 节点必须重启其 k0s worker 进程新配置才会生效。配置结构与默认值源码级说明该配置项对应pkg/apis/k0s/v1beta1/nllb.go中的 NodeLocalLoadBalancing 结构体。其字段及默认值如下字段含义默认值enabled是否在 worker 节点上启用 NLLBfalsetype后端类型仅支持EnvoyProxy或TraefikEnvoyProxy若enabled: true而未指定 type则必须显式给出否则校验报错envoyProxyEnvoy 后端专属配置见下文见DefaultEnvoyProxytraefikTraefik 后端专属配置见下文见DefaultTraefikEnvoyProxy与Traefik两个子结构体字段完全一致字段含义默认值image负载均衡 Pod 使用的 OCI 镜像对应constant.EnvoyProxyImage/constant.TraefikImage及其版本imagePullPolicy镜像拉取策略可选Always、Never、IfNotPresent默认镜像拉取策略apiServerBindPort负载均衡器在 worker loopback 接口上为 Kubernetes API Server 绑定的端口取值 1~655357443konnectivityServerBindPort负载均衡器在 worker loopback 接口上为 konnectivity server 绑定的端口取值 1~655357132在 setDefaults 与 Validate 中可以看到类型为空时自动回填EnvoyProxy并补齐对应后端的默认配置类型不合法、镜像缺失、端口非法validation.IsValidPortNum或imagePullPolicy取值非法时都会在配置校验阶段直接报错。端口默认值7443API Server与7132konnectivity同时由pkg/apis/k0s/v1beta1/nllb.go中的 kubebuilder 标记kubebuilder:default7443等声明pkg/component/worker/nllb/envoy.go与traefik.go在生成 Pod 清单时实际读取并使用这些端口。启用方式二在 k0sctl 配置中开启如果使用k0sctl部署则在 k0sctl 配置文件k0sctl.yaml中添加如下配置spec: k0s: config: spec: network: nodeLocalLoadBalancing: enabled: true type: EnvoyProxy完整实战示例k0sctl 部署 3 控制器 2 worker 集群下面是一份完整的k0sctl配置文件包含三台 controller 与两台 worker并启用了节点本地负载均衡apiVersion: k0sctl.k0sproject.io/v1beta1 kind: Cluster metadata: name: k0s-cluster spec: k0s: version: {{{ k0s_version }}} config: spec: network: nodeLocalLoadBalancing: enabled: true type: EnvoyProxy hosts: - role: controller ssh: address: 10.81.146.254 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: controller ssh: address: 10.81.146.184 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: controller ssh: address: 10.81.146.113 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: worker ssh: address: 10.81.146.198 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s - role: worker ssh: address: 10.81.146.51 keyPath: k0s-ssh-private-key.pem port: 22 user: k0s注{{{ k0s_version }}}是 k0s 官方文档站mkdocs的模板占位符实际使用时请替换为具体的 k0s 版本号如v1.30.2k0s.0。将上述配置保存为k0sctl.yaml并执行k0sctl apply来引导集群$ k0sctl apply ⣿⣿⡇⠀⠀⢀⣴⣾⣿⠟⠁⢸⣿⣿⣿⣿⣿⣿⣿⡿⠛⠁⠀⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀█████████ █████████ ███ ⣿⣿⡇⣠⣶⣿⡿⠋⠀⠀⠀⢸⣿⡇⠀⠀⠀⣠⠀⠀⢀⣠⡆⢸⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀███ ███ ███ ⣿⣿⣿⣿⣟⠋⠀⠀⠀⠀⠀⢸⣿⡇⠀⢰⣾⣿⠀⠀⣿⣿⡇⢸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀███ ███ ███ ⣿⣿⡏⠻⣿⣷⣤⡀⠀⠀⠀⠸⠛⠁⠀⠸⠋⠁⠀⠀⣿⣿⡇⠈⠉⠉⠉⠉⠉⠉⠉⠉⢹⣿⣿⠀███ ███ ███ ⣿⣿⡇⠀⠀⠙⢿⣿⣦⣀⠀⠀⠀⣠⣶⣶⣶⣶⣶⣶⣿⣿⡇⢰⣶⣶⣶⣶⣶⣶⣶⣶⣾⣿⣿⠀█████████ ███ ██████████ k0sctl v0.21.0 Copyright 2023, k0sctl authors. INFO Running phase: Connect to hosts INFO [ssh] 10.81.146.254:22: connected INFO [ssh] 10.81.146.184:22: connected INFO [ssh] 10.81.146.113:22: connected INFO [ssh] 10.81.146.51:22: connected INFO [ssh] 10.81.146.198:22: connected INFO Running phase: Detect host operating systems INFO [ssh] 10.81.146.254:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.113:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.184:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.198:22: is running Alpine Linux v3.17 INFO [ssh] 10.81.146.51:22: is running Alpine Linux v3.17 INFO Running phase: Acquire exclusive host lock INFO Running phase: Prepare hosts INFO [ssh] 10.81.146.113:22: installing packages (curl) INFO [ssh] 10.81.146.198:22: installing packages (curl, iptables) INFO [ssh] 10.81.146.254:22: installing packages (curl) INFO [ssh] 10.81.146.51:22: installing packages (curl, iptables) INFO [ssh] 10.81.146.184:22: installing packages (curl) INFO Running phase: Gather host facts INFO [ssh] 10.81.146.184:22: using k0s-controller-1 as hostname INFO [ssh] 10.81.146.51:22: using k0s-worker-1 as hostname INFO [ssh] 10.81.146.198:22: using k0s-worker-0 as hostname INFO [ssh] 10.81.146.113:22: using k0s-controller-2 as hostname INFO [ssh] 10.81.146.254:22: using k0s-controller-0 as hostname INFO [ssh] 10.81.146.184:22: discovered eth0 as private interface INFO [ssh] 10.81.146.51:22: discovered eth0 as private interface INFO [ssh] 10.81.146.198:22: discovered eth0 as private interface INFO [ssh] 10.81.146.113:22: discovered eth0 as private interface INFO [ssh] 10.81.146.254:22: discovered eth0 as private interface INFO Running phase: Download k0s binaries to local host INFO Running phase: Validate hosts INFO Running phase: Gather k0s facts INFO Running phase: Validate facts INFO Running phase: Upload k0s binaries to hosts INFO [ssh] 10.81.146.254:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.113:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.51:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.198:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO [ssh] 10.81.146.184:22: uploading k0s binary from /home/k0sctl/.cache/k0sctl/k0s/linux/amd64/k0s-{{{ k0s_version }}} INFO Running phase: Configure k0s INFO [ssh] 10.81.146.254:22: validating configuration INFO [ssh] 10.81.146.184:22: validating configuration INFO [ssh] 10.81.146.113:22: validating configuration INFO [ssh] 10.81.146.113:22: configuration was changed INFO [ssh] 10.81.146.184:22: configuration was changed INFO [ssh] 10.81.146.254:22: configuration was changed INFO Running phase: Initialize the k0s cluster INFO [ssh] 10.81.146.254:22: installing k0s controller INFO [ssh] 10.81.146.254:22: waiting for the k0s service to start INFO [ssh] 10.81.146.254:22: waiting for kubernetes api to respond INFO Running phase: Install controllers INFO [ssh] 10.81.146.254:22: generating token INFO [ssh] 10.81.146.184:22: writing join token INFO [ssh] 10.81.146.184:22: installing k0s controller INFO [ssh] 10.81.146.184:22: starting service INFO [ssh] 10.81.146.184:22: waiting for the k0s service to start INFO [ssh] 10.81.146.184:22: waiting for kubernetes api to respond INFO [ssh] 10.81.146.254:22: generating token INFO [ssh] 10.81.146.113:22: writing join token INFO [ssh] 10.81.146.113:22: installing k0s controller INFO [ssh] 10.81.146.113:22: starting service INFO [ssh] 10.81.146.113:22: waiting for the k0s service to start INFO [ssh] 10.81.146.113:22: waiting for kubernetes api to respond INFO Running phase: Install workers INFO [ssh] 10.81.146.51:22: validating api connection to https://10.81.146.254:6443 INFO [ssh] 10.81.146.198:22: validating api connection to https://10.81.146.254:6443 INFO [ssh] 10.81.146.254:22: generating token INFO [ssh] 10.81.146.198:22: writing join token INFO [ssh] 10.81.146.51:22: writing join token INFO [ssh] 10.81.146.198:22: installing k0s worker INFO [ssh] 10.81.146.51:22: installing k0s worker INFO [ssh] 10.81.146.198:22: starting service INFO [ssh] 10.81.146.51:22: starting service INFO [ssh] 10.81.146.198:22: waiting for node to become ready INFO [ssh] 10.81.146.51:22: waiting for node to become ready INFO Running phase: Release exclusive host lock INFO Running phase: Disconnect from hosts INFO Finished in 3m30s INFO k0s cluster version {{{ k0s_version }}} is now installed INFO Tip: To access the cluster you can now fetch the admin kubeconfig using: INFO k0sctl kubeconfig集群引导完成后配置 kubeconfig 以便与本集群交互k0sctl kubeconfig k0s-kubeconfig export KUBECONFIG$(pwd)/k0s-kubeconfig验证集群状态三台 controller 均已就绪并提供了各自的 API Server 端点$ kubectl -n kube-node-lease get \ lease/k0s-ctrl-k0s-controller-0 \ lease/k0s-ctrl-k0s-controller-1 \ lease/k0s-ctrl-k0s-controller-2 \ lease/k0s-endpoint-reconciler NAME HOLDER AGE k0s-ctrl-k0s-controller-0 9ec2b221890e5ed6f4cc70377bfe809fef5be541a2774dc5de81db7acb2786f1 2m37s k0s-ctrl-k0s-controller-1 fe45284924abb1bfce674e5a9aa8d647f17c81e53bbab17cf28288f13d5e8f97 2m18s k0s-ctrl-k0s-controller-2 5ab43278e63fc863b2a7f0fe1aab37316a6db40c5a3d8a17b9d35b5346e23b3d 2m9s k0s-endpoint-reconciler 9ec2b221890e5ed6f4cc70377bfe809fef5be541a2774dc5de81db7acb2786f1 2m37s $ kubectl -n default get endpoints NAME ENDPOINTS AGE kubernetes 10.81.146.113:6443,10.81.146.184:6443,10.81.146.254:6443 2m49s第一台 controller10.81.146.254是当前的 k0s leaderdefault/kubernetesEndpoints 中同时列出了三台 controller 的地址——这正是 NLLB 上游地址列表的数据来源。两台 worker 节点也处于就绪状态$ kubectl get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k0s-worker-0 Ready none 2m16s {{{ kubelet_ver }}} 10.81.146.198 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}} k0s-worker-1 Ready none 2m15s {{{ kubelet_ver }}} 10.81.146.51 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}}注{{{ kubelet_ver }}}与{{{ containerd_version }}}为文档站模板占位符实际输出中分别对应形如v1.30.2k0s的 kubelet 版本与具体 containerd 版本。每台 worker 节点上都运行着一个 NLLB 负载均衡器 Pod这正是源码中makePodManifest构造的静态 Pod标签为app.kubernetes.io/managed-byk0s,app.kubernetes.io/componentnllb$ kubectl -n kube-system get pod -owide -l app.kubernetes.io/managed-byk0s,app.kubernetes.io/componentnllb NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nllb-k0s-worker-0 1/1 Running 0 81s 10.81.146.198 k0s-worker-0 none none nllb-k0s-worker-1 1/1 Running 0 85s 10.81.146.51 k0s-worker-1 none none集成测试佐证仓库的集成测试 inttest/nllb/nllb_test.go 对上述场景做了自动化验证测试套件默认启动3 台 controller 2 台 worker分别以EnvoyProxy与Traefik两种类型运行测试通过network.NodeLocalLoadBalancing.Type切换后端见测试第 53-54 行与第 364 行等待nllb-node静态 Pod 就绪后通过关闭部分 controller 验证集群在 controller 故障下仍能维持运行checkClusterReadiness支持传入degradedControllers参数。单元测试 reconciler_test.go 则验证了 Reconciler 的启动、kubeconfig 补丁写入、API Server 地址更新等核心行为。故障演练模拟 controller 宕机集群正在使用节点本地负载均衡能够容忍一台 controller 的宕机。下面关闭第一台 controller 来模拟故障场景$ ssh -i k0s-ssh-private-key.pem k0s10.81.146.254 echo Powering off $(hostname) ... sudo poweroff Powering off k0s-controller-0 ...从外部看kubeconfig 仍指向已下线的 controllerNLLB 提供的是集群内部的高可用而不是外部的高可用。默认生成的k0s-kubeconfig把第一台 controller 的 IP 写为 API Server 地址。这台 controller 已下线因此直接调用kubectl会失败$ kubectl get nodes Unable to connect to the server: dial tcp 10.81.146.254:6443: connect: no route to host把k0s-kubeconfig中的服务器地址从第一台 controller 改为另一台地址可从k0sctl.yaml或上面kubectl -n default get endpoints的输出中获取集群即可恢复访问$ ssh -i k0s-ssh-private-key.pem k0s10.81.146.184 hostname k0s-controller-1 $ sed -i s#https://10\\.81\\.146\\.254:6443#https://10.81.146.184:6443#g k0s-kubeconfig $ kubectl get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k0s-worker-0 Ready none 3m35s {{{ kubelet_ver }}} 10.81.146.198 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}} k0s-worker-1 Ready none 3m34s {{{ kubelet_ver }}} 10.81.146.51 none Alpine Linux v3.17 5.15.83-0-virt containerd://{{{ containerd_version }}} $ kubectl -n kube-system get pods -owide -l app.kubernetes.io/managed-byk0s,app.kubernetes.io/componentnllb NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nllb-k0s-worker-0 1/1 Running 0 2m31s 10.81.146.198 k0s-worker-0 none none nllb-k0s-worker-1 1/1 Running 0 2m35s 10.81.146.51 k0s-worker-1 none none注意NLLB Pod 依然正常运行worker 节点的内部控制平面访问从未中断。从内部看集群保持运行第一台 controller 已不再活跃它的 IP 不再出现在default/kubernetesEndpoints 中其 k0s controller lease 也已变成孤儿holder 为空$ kubectl -n default get endpoints NAME ENDPOINTS AGE kubernetes 10.81.146.113:6443,10.81.146.184:6443 3m56s $ kubectl -n kube-node-lease get \ lease/k0s-ctrl-k0s-controller-0 \ lease/k0s-ctrl-k0s-controller-1 \ lease/k0s-ctrl-k0s-controller-2 \ lease/k0s-endpoint-reconciler NAME HOLDER AGE k0s-ctrl-k0s-controller-0 4m47s k0s-ctrl-k0s-controller-1 fe45284924abb1bfce674e5a9aa8d647f17c81e53bbab17cf28288f13d5e8f97 4m28s k0s-ctrl-k0s-controller-2 5ab43278e63fc863b2a7f0fe1aab37316a6db40c5a3d8a17b9d35b5346e23b3d 4m19s k0s-endpoint-reconciler 5ab43278e63fc863b2a7f0fe1aab37316a6db40c5a3d8a17b9d35b5346e23b3d 4m47s尽管那台 controller 不可用集群依然完全可用第三台 controller 已成为新的 k0s leader业务负载照常调度与运行$ kubectl -n default run nginx --imagenginx pod/nginx created $ kubectl -n default get pods -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx 1/1 Running 0 16s 10.244.0.5 k0s-worker-1 none none $ kubectl -n default logs nginx /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up [notice] 1#1: using the epoll event method [notice] 1#1: nginx/1.23.3 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) [notice] 1#1: OS: Linux 5.15.83-0-virt [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 [notice] 1#1: start worker processes [notice] 1#1: start worker process 28关键注意事项与适用边界对内高可用对外非高可用NLLB 只保证集群内部组件kubelet、kube-proxy、konnectivity-agent 等对控制平面访问的韧性。外部客户端要获得高可用仍需要外部负载均衡器或自行维护 kubeconfig 中的 server 地址如本例中手动sed替换 IP 所示。平台限制Envoy 后端在 ARMv7、RISC-V 与 Windows 上不可用这些平台请使用type: Traefik。生效时机新加入的 worker 节点自动生效已运行的 worker 需要重启 k0s worker 进程。默认端口占用默认7443API Server与7132konnectivity绑定在 worker 的 loopback 接口上如与本地其他服务冲突可通过envoyProxy.apiServerBindPort/konnectivityServerBindPortTraefik 同理调整端口范围 1~65535。配置校验enabled: true时必须显式指定type非法类型、端口或镜像拉取策略会在配置校验阶段被拒绝见 nllb.go 的 Validate 实现。延伸阅读高可用控制平面与外部负载均衡器k0s 集群配置参考spec.api.externalAddress等k0sctl 安装指南单节点模式说明源码与测试配置结构体 pkg/apis/k0s/v1beta1/nllb.go、协调器 pkg/component/worker/nllb/reconciler.go、Envoy 后端 pkg/component/worker/nllb/envoy.go、Traefik 后端 pkg/component/worker/nllb/traefik.go、单元测试 pkg/component/worker/nllb/reconciler_test.go、集成测试 inttest/nllb/nllb_test.go赞分享云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载相关推荐Kubernetes 外部负载均衡器创建指南Kubernetes 外部负载均衡器创建指南 概述 在现代云原生应用部署中外部负载均衡器External LoadBalancer是实现高可用性和可扩展性文档教程云原生终极解析BinExport核心功能与架构设计详解终极解析BinExport核心功能与架构设计详解 BinExport是一款强大的反汇编导出工具能够将反汇编结果转换为Protocol Buffers格式为PaddlePaddle负载均衡高可用集群部署PaddlePaddle负载均衡高可用集群部署 概述 在大规模深度学习训练场景中单机性能往往无法满足需求分布式训练成为必然选择。PaddlePaddle作人工智能深度学习机器学习大模型分布式训练预训练上一篇Cats与Typelevel生态系统构建完整的函数式技术栈终极指南下一篇Folcolor编译指南使用Visual Studio 2022构建完整项目创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考