企业官网建设流程全解析

• 云原生
• 容器编排
• 边缘计算

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 组件，其整体工作流如下：

1. 在 loopback 接口上运行负载均衡器：k0s worker 进程在每台 worker 节点的回环接口（127.0.0.1等）上管理一个负载均衡器。负载均衡器以静态 Pod（static Pod）的形式在kube-system命名空间内运行，Pod 名为nllb，由 kubelet 直接托管，具备system-node-critical优先级与全容忍（tolerations），确保节点优雅关停与节点压力驱逐时它能够存活到最后（见 envoy.go 中 Pod 清单的构造逻辑）。

2. 两种可选的负载均衡后端：仓库中pkg/component/worker/nllb包提供了两个 backend 实现——Envoy 与 Traefik，Envoy 是默认后端。需要特别注意的是：Envoy 在 ARMv7、RISC-V 与 Windows 平台上不可用，如果计划在这些平台上运行 k0s，请改用 Traefik。

3. 请求分布而非固定指向：启用 NLLB 后，worker 组件对控制平面的请求不再固定发往该 worker 加入集群时使用的那个 controller，而是均匀分布到当前所有可用的 controller 节点，从而在某个 controller 变得不健康时显著提升集群的可靠性与容错能力。

后端选择与静态 Pod 装配

NewReconciler 根据 worker profile 中的NodeLocalLoadBalancing.Type选择后端实现，并为每种后端在运行时目录（$XDG_RUNTIME_DIR/k0s/nllb/，默认/run/k0s/nllb/）下创建独立子目录：

• EnvoyProxy类型 →envoyProxy后端，运行目录…/nllb/envoy；
• Traefik类型 →traefik后端，运行目录…/nllb/traefik。

每个后端都实现同一套 backend 接口：init、start、getAPIServerAddress、updateAPIServers、stop。

负载均衡的接入点：打补丁的 kubeconfig

NLLB 的关键接入方式是重写 kubelet 使用的 kubeconfig：

• Reconciler 在启动时读取常规的 kubelet kubeconfig（KubeletAuthConfigPath），将其中的 API Server 地址改写为本地负载均衡器的地址（如127.0.0.1:7443），并原子写入运行时目录下的kubeconfig.yaml（见 writePatchedKubeconfig）；
• 通过 GetKubeletKubeconfigPath 与 NewClient 两个方法，kubelet 与 worker 上的其他 Kubernetes 客户端都以这个「负载均衡版」kubeconfig 为准，从而把全部控制平面流量导向本机的负载均衡器。

动态更新上游地址：协调循环

上游 controller 列表不是静态的。Reconciler 启动后运行一个 协调循环：

• 通过负载均衡版 kubeconfig 创建 Kubernetes 客户端，监视 worker profile（WatchProfile）中APIServerAddresses的变化；
• 收到更新后，将新地址列表排序并与当前实际地址比对，若有差异则调用updateAPIServers更新负载均衡器配置；
• 同时以 60 秒为周期重试失败的更新（ticker），并明确拒绝「移除全部上游地址」的变更，防止把集群锁死。

Envoy 配置细节

以 Envoy 后端为例，writeEnvoyConfigFiles 会生成两个配置文件：

• envoy.yaml（bootstrap）：定义两个 listener——apiserver（TCP 代理到 API Server 集群）与konnectivity（TCP 代理到 konnectivity 集群，若 konnectivity 绑定端口非 0 才生成）；
• cds.yaml（集群定义）：apiserver集群使用RANDOM负载均衡策略，konnectivity集群使用ROUND_ROBIN策略；两者均配置 TCP 健康检查（tcp_health_check，5 秒间隔、失败 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 结构体。其字段及默认值如下：

EnvoyProxy与Traefik两个子结构体字段完全一致：

在 setDefaults 与 Validate 中可以看到：类型为空时自动回填EnvoyProxy并补齐对应后端的默认配置；类型不合法、镜像缺失、端口非法（validation.IsValidPortNum）或imagePullPolicy取值非法时都会在配置校验阶段直接报错。端口默认值7443（API Server）与7132（konnectivity）同时由pkg/apis/k0s/v1beta1/nllb.go中的 kubebuilder 标记（+kubebuilder:default=7443等）声明，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.2+k0s.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

第一台 controller（10.81.146.254）是当前的 k0s leader，default/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.2+k0s的 kubelet 版本与具体 containerd 版本。

每台 worker 节点上都运行着一个 NLLB 负载均衡器 Pod（这正是源码中makePodManifest构造的静态 Pod，标签为app.kubernetes.io/managed-by=k0s,app.kubernetes.io/component=nllb）：

$ kubectl -n kube-system get pod -owide -l app.kubernetes.io/managed-by=k0s,app.kubernetes.io/component=nllb 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 k0s@10.81.146.254 'echo "Powering off $(hostname) ..." && sudo poweroff' Powering off k0s-controller-0 ...

从外部看：kubeconfig 仍指向已下线的 controller

NLLB 提供的是集群内部的高可用，而不是外部的高可用。默认生成的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 k0s@10.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-by=k0s,app.kubernetes.io/component=nllb 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 --image=nginx 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 进程。
• 默认端口占用：默认7443（API Server）与7132（konnectivity）绑定在 worker 的 loopback 接口上，如与本地其他服务冲突，可通过envoyProxy.apiServerBindPort/konnectivityServerBindPort（Traefik 同理）调整，端口范围 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

• 云原生
• 容器编排
• 边缘计算