1. 项目概述一个极简、高效的容器编排工具如果你和我一样在容器化这条路上摸爬滚打了好几年从早期的 Docker Compose 单机编排到后来接触 Kubernetes 的庞大生态一个感受会越来越强烈有时候我们需要的可能只是一个轻量级的“开关”而不是一个功能齐全的“核电站”。尤其是在边缘计算、IoT设备、CI/CD流水线中的单节点任务或者仅仅是个人开发测试环境中启动一个完整的 K8s 集群无论是 Minikube、Kind 还是 K3s都显得有些“杀鸡用牛刀”资源开销和心智负担都不小。这就是我第一次看到 Kilo 这个项目时的感觉。Kilo 不是一个试图取代 K8s 的庞然大物它的定位非常清晰一个基于 WireGuard 的、专为 Kubernetes 设计的轻量级网络覆盖Overlay解决方案。它的核心目标只有一个——让跨云、跨数据中心的 K8s 集群节点或者让边缘的裸金属服务器能够像在同一个局域网内一样安全、高效地通信。项目名字 “Kilo” 本身就很有意思它既是“千克”的单位寓意着轻量也暗示着它能连接“公里”级距离的节点。简单来说你可以把 Kilo 想象成给 K8s 集群穿上一件“隐形斗篷”。这件斗篷由 WireGuard 这件“魔法材料”编织而成它能让分散在世界各地的集群节点无视底层复杂的物理网络比如不同的 VPC、防火墙规则、NAT直接建立一个加密的、点对点的虚拟二层网络。对于运维和开发者而言最直接的收益就是Pod 之间可以直接用 Pod IP 通信Service 可以跨节点无缝访问你再也不需要为了打通网络而费劲地去配置繁琐的 VPC 对等连接、VPN 网关或者复杂的路由规则了。2. 核心设计思路为什么是 WireGuard K8s要理解 Kilo 的价值得先看看在它出现之前我们面临的问题和已有的解决方案。2.1 传统 K8s 网络方案的挑战在标准的 K8s 集群内CNI容器网络接口插件如 Calico、Flannel、Cilium 等负责在集群内部构建一个扁平的 Pod 网络。它们工作得很好但都有一个前提所有节点之间的底层网络Underlay必须是三层可达的。也就是说节点之间要能通过 IP 地址直接 ping 通。然而现实很骨感混合云与多云场景你的集群节点可能分布在 AWS、GCP、Azure 甚至公司的私有机房。不同云厂商的 VPC 之间默认是隔离的。边缘计算场景成百上千的边缘设备分布在各个角落它们可能位于不同的局域网通过 NAT 上网IP地址不固定甚至没有公网IP。网络策略限制企业防火墙可能严格限制了节点间的端口导致 Calico 的 BGP 协议或 VXLAN 封装流量无法通过。传统的解决方案是搭建一个中心化的 VPN 网关如 IPsec、OpenVPN所有节点都连接到这个网关由网关进行流量转发。但这带来了单点故障和性能瓶颈网关一旦宕机或成为瓶颈整个集群的网络就瘫痪了。2.2 WireGuard 的颠覆性优势WireGuard 的出现为这个问题带来了全新的思路。它不是一个传统的 VPN 协议而是一个更接近“网络接口”的极简加密隧道技术。它的特点完美契合了分布式系统的需求极简与高性能代码量只有几千行审计和维护容易。内核态运行加密解密效率极高能跑满千兆甚至万兆带宽延迟极低。无中心化架构WireGuard 隧道是点对点的。每个节点只需要配置其对等体Peer的公钥和可达端点Endpoint就能建立直连隧道。没有中心服务器天然避免了单点故障。基于加密密钥的身份验证节点身份由其公钥唯一标识无需复杂的证书体系。访问控制通过简单的公钥白名单即可实现。完美的 NAT 穿透能力WireGuard 能很好地处理大多数 NAT 环境让位于家庭路由器或企业防火墙后的节点也能建立直接连接。Kilo 的聪明之处在于它看到了 WireGuard 的这些特性与 K8s 节点模型的天然契合。Kilo 将自己作为 K8s 的一个 CNI 插件和网络控制器自动发现集群中的所有节点并为每个节点生成 WireGuard 的密钥对和配置。它根据节点的地理位置、网络拓扑通过注解或标签定义智能地决定哪些节点之间需要建立直接的 WireGuard 隧道哪些流量可以通过中继节点转发从而自动构建出一个最优的、全网状或部分网状的加密覆盖网络。2.3 Kilo 的架构定位所以Kilo 不是一个完整的 CNI它通常与 Flannel 这样的基础 CNI 协同工作。Flannel 负责管理节点内部的 Pod 网络分配 Pod IP设置本地网桥和路由而 Kilo 则负责管理节点之间的网络用 WireGuard 隧道把各个 Flannel 子网“缝合”起来。这种解耦设计非常优雅既利用了成熟 CNI 的稳定性又引入了 WireGuard 的跨网络能力。3. 核心组件与工作原理深度解析Kilo 的架构非常清晰主要由两个核心组件构成Kilo 代理kg和 Kilo 控制器。理解它们如何协作是掌握 Kilo 的关键。3.1 Kilo 代理运行在每个节点的守护进程kg是一个以 DaemonSet 形式部署在每个 Kubernetes 节点上的二进制文件。它是 Kilo 的“执行层”负责本节点所有与 WireGuard 相关的实际操作。它的核心职责包括监听 Kubernetes API持续监听Watch集群中 Node 对象的变化。当有新节点加入、节点标签/注解更新或节点被删除时kg会收到通知。管理 WireGuard 接口在每个节点上创建并配置一个名为kilo0的 WireGuard 网络接口。这是所有跨节点流量的出入口。生成与维护密钥为当前节点生成 WireGuard 所需的私钥和公钥。私钥保存在节点本地公钥则通过 Kubernetes Node 对象的注解如kilo.squat.ai/public-key上报到 API Server供其他节点读取。配置 WireGuard Peers根据从 API Server 获取的全集群节点信息特别是其他节点的公钥和推荐的外部 IP/端口计算并更新本节点kilo0接口的对等体Peer配置。这个过程是动态的Kilo 支持多种拓扑逻辑Mesh, Hub-and-Spoke等kg会根据预设的拓扑规则决定与哪些节点建立直接隧道。配置路由规则在节点的内核路由表中添加必要的路由条目。例如它将其他节点的 Pod CIDR 网段如10.244.2.0/24的路由指向kilo0接口并通过 WireGuard 隧道送达正确的对端节点。可选的中继功能在Hub-and-Spoke拓扑中被指定为“枢纽”的节点会开启 IP 转发并为“分支”节点提供流量中继。实操心得密钥管理Kilo 的密钥是自动生成并保存在节点本地的通常是/var/lib/wireguard目录。这意味着如果你彻底销毁并重建一个同名节点它的私钥会变公钥也随之改变。其他节点需要重新获取新公钥来更新隧道配置。Kilo 通过监听 Node 对象的变化自动处理这个过程但在某些极端情况下如节点持久化存储丢失且 Node 对象未被清理可能会导致网络中断。确保你的节点有稳定的唯一标识如云厂商的 Instance ID并正确配置--kubeconfig是关键。3.2 Kilo 控制器集群级别的协调大脑Kilo 控制器通常以 Deployment 形式运行在集群的某个节点上。它扮演着“决策者”和“优化者”的角色工作层面更高生成网络清单控制器会读取所有节点的信息包括地理位置通过topology.kubernetes.io/region等标签、注解、IP 地址并应用用户通过 Kilo 自定义资源如Peer定义的策略。计算最优拓扑这是 Kilo 的智能所在。控制器根据内置算法计算节点间建立 WireGuard 隧道的最优方案。例如它可能会让同一个数据中心Region内的节点建立全网状连接以获得最低延迟而不同数据中心的节点则通过少数几个“网关”节点进行星型连接以减少长距离隧道的数量和管理开销。下发配置建议控制器将计算出的拓扑结果以“建议”的形式写入到每个 Node 对象的注解中。例如它可能会在某个节点的注解里写入kilo.squat.ai/force-endpoint: 34.56.78.90建议该节点使用特定的公网 IP 作为 WireGuard 端点。管理 Peer CRDKilo 定义了Peer这个自定义资源允许你将集群外的服务器如一台物理数据库服务器也纳入 Kilo 网络。控制器负责处理这些Peer资源并将其配置分发到相关的集群节点上。两者协作流程用户或系统创建一个新的 Kubernetes 节点。该节点上的kg代理启动生成密钥并将公钥写入本 Node 对象的注解。Kilo 控制器观察到新的 Node 对象结合全集群状态计算拓扑更新。控制器将更新后的“建议”如端点IP、允许的IP段写入相关 Node 对象的注解。所有节点的kg代理监听到这些注解变化重新配置本地的 WireGuard 接口和路由表。新的加密隧道自动建立Pod 跨节点通信恢复或建立。这个基于 Kubernetes API 的声明式协作模式是云原生项目的典型设计实现了最终一致性非常健壮。4. 实战部署一步步构建跨云 K8s 网络理论说再多不如亲手搭一遍。下面我将以一个经典的场景为例在 AWS 的us-west-2和 GCP 的asia-east1各部署一个 K3s 节点然后用 Kilo 把它们打通形成一个可以跨云直接通过 Pod IP 通信的“逻辑集群”。4.1 环境准备与假设集群 A (AWS):节点 IP:52.1.2.3(公网),172.31.16.10(私网)Pod CIDR:10.244.0.0/24使用 K3s 版本v1.27集群 B (GCP):节点 IP:34.56.78.90(公网),10.140.0.20(私网)Pod CIDR:10.244.1.0/24目标: 让 AWS 上的 Pod (10.244.0.5) 能直接ping通 GCP 上的 Pod (10.244.1.5)。注意安全组与防火墙这是跨云部署中最容易踩坑的地方。WireGuard 默认使用 UDP 协议端口51820。你必须在 AWS 的安全组和 GCP 的防火墙规则中允许来自对方公网 IP 的UDP:51820入站流量。同时为了 K3s 的正常运行还需要开放 TCP 6443 (API Server), 8472 (Flannel VXLAN) 等端口。建议先临时设置允许所有来源的UDP:51820进行测试成功后再细化规则。4.2 安装 K3s 并配置 Flannel首先在两边分别安装 K3s。我们需要指定 Pod 网段并使用 Flannel 作为基础 CNI。在 AWS 节点上执行curl -sfL https://get.k3s.io | INSTALL_K3S_VERSIONv1.27.6k3s1 \ INSTALL_K3S_EXEC--flannel-backendvxlan --cluster-cidr10.244.0.0/16 \ sh -这里--cluster-cidr指定了整个集群的 Pod IP 范围K3s 会为每个节点从这个大池子里分配一个/24的子网。在 GCP 节点上执行同样的命令。安装完成后分别在两台机器上运行sudo k3s kubectl get nodes -o wide确认节点状态为Ready并记录下INTERNAL-IP通常是私网IP和分配给节点的PodCIDR如10.244.0.0/24。4.3 部署 KiloKilo 的部署非常简洁通过一个 YAML 清单文件即可。我们需要根据我们的跨云场景调整几个关键参数。创建一个名为kilo.yaml的文件内容如下--- apiVersion: v1 kind: ServiceAccount metadata: name: kilo namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kilo rules: - apiGroups: [] resources: [nodes, nodes/status] verbs: [get, list, watch, update, patch] - apiGroups: [kilo.squat.ai] resources: [peers] verbs: [get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kilo roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kilo subjects: - kind: ServiceAccount name: kilo namespace: kube-system --- apiVersion: apps/v1 kind: DaemonSet metadata: name: kilo namespace: kube-system labels: app.kubernetes.io/name: kilo spec: selector: matchLabels: app.kubernetes.io/name: kilo updateStrategy: type: RollingUpdate template: metadata: labels: app.kubernetes.io/name: kilo spec: serviceAccountName: kilo hostNetwork: true tolerations: - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists containers: - name: kilo image: squat/kilo:latest args: - --kubeconfig/etc/kubernetes/kubeconfig - --hostname$(NODE_NAME) # 关键配置启用 WireGuard 加密 - --encrypttrue # 关键配置设置 WireGuard 监听的端口 - --port51820 # 关键配置告诉 Kilo 如何获取节点的公网端点。 # 我们使用 --external-ip 自动检测并回退到节点公网IP。 # 对于云环境这通常能正确获取。 - --external-iptrue # 重要拓扑逻辑。对于只有两个节点的跨云场景full-mesh 是最简单的。 # 它会强制让两个节点建立直接隧道。 - --topologyfull-mesh # 将 Kilo 接口创建的隧道路由注入到主路由表 - --routing-tablemain env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName securityContext: privileged: true capabilities: add: - NET_ADMIN - SYS_MODULE volumeMounts: - name: kilo-dir mountPath: /var/lib/wireguard - name: lib-modules mountPath: /lib/modules readOnly: true - name: kubeconfig mountPath: /etc/kubernetes readOnly: true volumes: - name: kilo-dir hostPath: path: /var/lib/wireguard type: DirectoryOrCreate - name: lib-modules hostPath: path: /lib/modules - name: kubeconfig hostPath: path: /etc/rancher/k3s # K3s 默认的 kubeconfig 路径 type: DirectoryOrCreate关键参数解析--encrypttrue启用 WireGuard 加密。这是核心功能必须开启。--port51820指定 WireGuard 监听的 UDP 端口需与防火墙规则匹配。--external-iptrue让 Kilo 自动探测节点的外部 IP 作为 WireGuard 隧道的公网端点。在云服务器上这通常能获取到公网 IP。如果自动探测失败你可以通过给 Node 打注解kilo.squat.ai/force-endpoint: 52.1.2.3:51820来手动指定。--topologyfull-mesh全网状拓扑。对于节点数少的情况比如我们只有2个这是最直接有效的。所有节点两两之间建立直接隧道。如果节点很多可以考虑hub-and-spoke以节省连接数。--routing-tablemain将 Kilo 的路由规则添加到主路由表确保所有流量包括非 Pod 流量如节点SSH如果目标是对端节点的 Pod CIDR也会走 WireGuard 隧道。这简化了路由管理。将这个 YAML 文件分别应用到两个集群的节点上# 在 AWS 节点上 sudo k3s kubectl apply -f kilo.yaml # 在 GCP 节点上 sudo k3s kubectl apply -f kilo.yaml4.4 验证部署与网络连通性部署完成后检查 DaemonSet 和 Pod 状态sudo k3s kubectl -n kube-system get ds kilo sudo k3s kubectl -n kube-system get pods -l app.kubernetes.io/namekilo应该看到每个节点上都有一个kilo-xxxxx的 Pod 在运行。接下来检查 WireGuard 接口是否创建成功# 在任意节点上执行 sudo wg show你应该能看到一个名为kilo0的接口并且能看到一个对等体Peer其公钥和端点Endpoint就是另一个节点的信息。latest handshake应该显示在几秒内表示隧道已成功建立。验证 Pod 间通信在 AWS 节点上启动一个测试 Podsudo k3s kubectl run test-pod-aws --imagealpine --restartNever -- sleep 3600在 GCP 节点上启动一个测试 Podsudo k3s kubectl run test-pod-gcp --imagealpine --restartNever -- sleep 3600获取 Pod IPsudo k3s kubectl get pods -o wide假设test-pod-awsIP 为10.244.0.5test-pod-gcpIP 为10.244.1.5。进行跨云 Ping 测试# 在 AWS 节点上进入 test-pod-aws sudo k3s kubectl exec -it test-pod-aws -- sh / # ping 10.244.1.5如果看到成功的回复恭喜你Kilo 已经成功地在两个不同云厂商的节点之间建立了一条加密的 WireGuard 隧道并让 Flannel 的 Pod 网络跨越了物理边界。5. 高级配置与拓扑管理简单的双节点全互联只是开始。Kilo 真正的威力在于其灵活的拓扑管理能力可以优化大规模、多区域部署的网络。5.1 节点分区与区域感知在真实的跨区域部署中我们通常希望同一区域内的节点延迟最低优先直连跨区域通信可以通过少数几个网关节点聚合以减少长距离隧道数量和管理复杂度。Kilo 利用 Kubernetes 节点的标准标签topology.kubernetes.io/region和topology.kubernetes.io/zone来实现这一点。你只需要在创建节点时或事后打标签指定这些标签Kilo 控制器就会自动识别。例如假设我们有区域us-west(AWS): 节点 node-a1, node-a2区域eu-central(GCP): 节点 node-e1, node-e2区域asia-east(Azure): 节点 node-s1我们可以通过 Kilo 的启动参数或配置来定义拓扑规则。一种常见的方式是使用--topologyauto默认并结合--mesh-granularitylocation参数。Kilo 会自动将同一region内的节点组成一个“逻辑位置”内部全互联然后为每个“逻辑位置”选举一个或多个“领导者”节点负责与其他“位置”建立跨区域隧道。你也可以通过自定义 Node 的注解来更精细地控制# 手动指定某个节点作为其区域的网关 kilo.squat.ai/force-endpoint: 公网IP:51820 kilo.squat.ai/gateway: true # 标记此节点为网关 kilo.squat.ai/location: us-west-2a # 自定义位置标识覆盖 region/zone5.2 混合云与裸金属对等Kilo 的Peer自定义资源CRD是其一大特色它允许你将集群外的任何支持 WireGuard 的机器纳入网络。假设你有一台位于公司机房的物理数据库服务器IP:192.168.1.100你想让所有云上的 Pod 都能安全地访问它。在物理服务器上安装并配置 WireGuard。生成密钥对wg genkey | tee privatekey | wg pubkey publickey。在 Kubernetes 集群中创建一个 Peer 资源apiVersion: kilo.squat.ai/v1alpha1 kind: Peer metadata: name: on-prem-db spec: publicKey: 物理服务器的公钥 allowedIPs: - 192.168.1.100/32 # 物理服务器自身的IP - 10.0.0.0/24 # 甚至可以给它分配一个虚拟IP段用于其后面的其他服务 endpoint: 物理服务器的公网IP或DDNS域名:51820 persistentKeepalive: 25 # 如果物理服务器在NAT后需要保持连接应用这个 YAML 文件。Kilo 控制器会监听到这个 Peer 资源并将其配置分发到所有相关的集群节点默认是所有节点上。每个节点的kg代理会更新本地 WireGuard 配置将物理服务器作为一个对等体。现在集群内的任意 Pod 都可以直接访问192.168.1.100流量会通过 WireGuard 隧道加密传输到你的机房。这个功能极大地扩展了 K8s 网络的边界实现了真正的混合云统一网络平面。6. 故障排查与性能调优即使配置正确在实际运行中也可能遇到问题。以下是一些常见故障场景和排查思路。6.1 隧道建立失败症状wg show显示对等体端点存在但latest handshake是很久以前或者一直是None跨节点 Pod 无法通信。排查步骤检查防火墙这是最常见的原因。确保双方节点的安全组/防火墙都允许 UDP 51820 端口入站。可以使用nc -vu 对方公网IP 51820在目标端口测试连通性。检查端点配置查看 Node 的注解kilo.squat.ai/force-endpoint或自动发现的端点是否正确。执行sudo kubectl describe node node-name查看。确保注解里的 IP:Port 是对方节点 WireGuard 实际监听的地址。检查密钥匹配确认每个节点使用的公钥与对方节点配置的私钥对应。可以通过对比 Node 注解中的kilo.squat.ai/public-key和wg show输出的公钥来验证。查看 Kilo 日志sudo kubectl -n kube-system logs -l app.kubernetes.io/namekilo。关注是否有权限错误、连接失败等报错信息。检查路由在节点上执行ip route show。你应该能看到指向kilo0接口的、目标为其他节点 Pod CIDR 的路由条目。如果没有可能是 Kilo 代理没有正确配置路由。6.2 性能问题症状跨节点网络带宽远低于预期或者延迟异常高。调优建议MTU 设置WireGuard 隧道会增加数据包开销通常约80字节。如果底层网络的 MTU 是1500那么经过 WireGuard 封装后可能超过1500导致分片降低性能。建议将 Kilo 接口kilo0的 MTU 设置为更低的值如 1420。可以在 Kilo DaemonSet 的启动参数中添加--mtu1420。拓扑优化对于超过10个节点的跨区域集群避免使用full-mesh。全互联的隧道数量是n*(n-1)/2管理开销大。改用hub-and-spoke或依赖--topologyauto的区域感知模式可以显著减少长距离隧道数量。记住星型拓扑会增加网关节点的负载和单点故障风险通常需要部署多个网关。内核 WireGuard 模块确保你的服务器内核已编译 WireGuard 模块或已动态加载。Kilo 容器需要NET_ADMIN和SYS_MODULE能力来加载模块。使用lsmod | grep wireguard检查。使用最新稳定版的内核和 WireGuard 工具能获得最佳性能。节点规格WireGuard 加密解密是 CPU 密集型操作。如果网关节点需要处理大量跨区域流量确保其有足够的 CPU 资源。6.3 与 Service Mesh 的兼容性常见问题同时使用 Kilo 和 Istio/Linkerd 等服务网格时流量路径可能变得复杂甚至产生冲突。处理原则层级关系Kilo 工作在 L3网络层负责节点间联通。服务网格通常工作在 L4-L7负责服务间的流量管理、安全和可观测性。理论上服务网格的 Sidecar 代理应该能看到 Kilo 提供的透明网络。实践建议先确保 Kilo 层面的网络是通的Pod IP 可 ping。然后再部署服务网格。如果出现问题检查服务网格的配置是否错误地拦截或重写了流量例如错误的trafficPolicy设置。一个稳妥的方法是在服务网格的配置中明确排除对kilo0接口或 WireGuard 端口51820流量的处理。7. 生产环境考量与运维建议将 Kilo 用于生产环境除了功能还需要关注稳定性、可观测性和高可用。7.1 高可用部署Kilo 控制器Kilo 控制器虽然不处理数据平面流量但它负责拓扑计算和配置下发。建议以 Deployment 方式部署多个副本例如2个并配置PodAntiAffinity让它们分散在不同节点上避免单点故障。网关节点在hub-and-spoke拓扑中网关节点是关键。务必为每个区域部署至少两个网关节点并利用 Kubernetes Service 为这些网关节点创建一个负载均衡器可以是内网 LB。然后通过 Node 注解kilo.squat.ai/force-endpoint将其他节点的端点指向这个 LB 的 IP实现网关层的高可用。健康检查可以为 Kilo 代理kg容器添加livenessProbe和readinessProbe例如检查wg show命令是否成功执行或者检查kilo0接口是否存在。7.2 监控与日志WireGuard 指标wg show命令输出的信息非常有用如transfer收发字节数、latest handshake。可以考虑使用一个 sidecar 容器如prometheus-wireguard-exporter来抓取这些指标并暴露给 Prometheus。Kilo 日志确保 Kilo 容器日志被集中收集如通过 Fluentd 到 Elasticsearch。日志级别可以通过--v2参数调整在排查问题时可以临时调高。网络连通性监控在集群中部署一个简单的网络检测 DaemonSet如nicolaka/netshoot定期在所有节点间进行 Pod IP 的 ping 或 curl 测试并将结果上报到监控系统以便及时发现网络分区。7.3 安全加固RBAC 最小权限上文提供的 YAML 已经配置了相对严格的 RBAC。在生产中可以进一步审查确保 Service Account 只拥有它必需的最小权限。Pod 安全策略/PSAKilo DaemonSet 需要privileged: true和NET_ADMIN,SYS_MODULE能力。在启用 Pod 安全准入PSA的集群中你需要为kube-system命名空间创建一个合适的PodSecurityStandard豁免Exemption。WireGuard 密钥轮换Kilo 目前不提供自动的密钥轮换机制。如果需要轮换一个可行的方法是逐个节点重启 Kilo Pod或删除其密钥文件/var/lib/wireguard/privatekey。Kilo 会生成新密钥并更新 Node 注解其他节点会自动学习并更新对等体配置。这个过程会导致该节点的隧道短暂中断应安排在维护窗口进行。Kilo 以其独特的设计在 K8s 生态中找到了一个精准的利基市场。它没有试图解决所有网络问题而是用最精简的方式解决了“跨网络边界的安全互联”这个痛点。对于运维混合云、边缘集群的团队来说它提供了一种比传统 VPN 或专线更云原生、更灵活、性能也更好的选择。当然它也不是银弹在超大规模集群或对网络策略有极其复杂要求的场景下更成熟的 Calico 或 Cilium 可能是更全面的选择。但当你需要快速、轻量地打通几个分散的 K8s 节点时Kilo 无疑是那个值得你放入工具箱的精致瑞士军刀。
Kilo：基于WireGuard的轻量级Kubernetes跨云网络方案实战
1. 项目概述一个极简、高效的容器编排工具如果你和我一样在容器化这条路上摸爬滚打了好几年从早期的 Docker Compose 单机编排到后来接触 Kubernetes 的庞大生态一个感受会越来越强烈有时候我们需要的可能只是一个轻量级的“开关”而不是一个功能齐全的“核电站”。尤其是在边缘计算、IoT设备、CI/CD流水线中的单节点任务或者仅仅是个人开发测试环境中启动一个完整的 K8s 集群无论是 Minikube、Kind 还是 K3s都显得有些“杀鸡用牛刀”资源开销和心智负担都不小。这就是我第一次看到 Kilo 这个项目时的感觉。Kilo 不是一个试图取代 K8s 的庞然大物它的定位非常清晰一个基于 WireGuard 的、专为 Kubernetes 设计的轻量级网络覆盖Overlay解决方案。它的核心目标只有一个——让跨云、跨数据中心的 K8s 集群节点或者让边缘的裸金属服务器能够像在同一个局域网内一样安全、高效地通信。项目名字 “Kilo” 本身就很有意思它既是“千克”的单位寓意着轻量也暗示着它能连接“公里”级距离的节点。简单来说你可以把 Kilo 想象成给 K8s 集群穿上一件“隐形斗篷”。这件斗篷由 WireGuard 这件“魔法材料”编织而成它能让分散在世界各地的集群节点无视底层复杂的物理网络比如不同的 VPC、防火墙规则、NAT直接建立一个加密的、点对点的虚拟二层网络。对于运维和开发者而言最直接的收益就是Pod 之间可以直接用 Pod IP 通信Service 可以跨节点无缝访问你再也不需要为了打通网络而费劲地去配置繁琐的 VPC 对等连接、VPN 网关或者复杂的路由规则了。2. 核心设计思路为什么是 WireGuard K8s要理解 Kilo 的价值得先看看在它出现之前我们面临的问题和已有的解决方案。2.1 传统 K8s 网络方案的挑战在标准的 K8s 集群内CNI容器网络接口插件如 Calico、Flannel、Cilium 等负责在集群内部构建一个扁平的 Pod 网络。它们工作得很好但都有一个前提所有节点之间的底层网络Underlay必须是三层可达的。也就是说节点之间要能通过 IP 地址直接 ping 通。然而现实很骨感混合云与多云场景你的集群节点可能分布在 AWS、GCP、Azure 甚至公司的私有机房。不同云厂商的 VPC 之间默认是隔离的。边缘计算场景成百上千的边缘设备分布在各个角落它们可能位于不同的局域网通过 NAT 上网IP地址不固定甚至没有公网IP。网络策略限制企业防火墙可能严格限制了节点间的端口导致 Calico 的 BGP 协议或 VXLAN 封装流量无法通过。传统的解决方案是搭建一个中心化的 VPN 网关如 IPsec、OpenVPN所有节点都连接到这个网关由网关进行流量转发。但这带来了单点故障和性能瓶颈网关一旦宕机或成为瓶颈整个集群的网络就瘫痪了。2.2 WireGuard 的颠覆性优势WireGuard 的出现为这个问题带来了全新的思路。它不是一个传统的 VPN 协议而是一个更接近“网络接口”的极简加密隧道技术。它的特点完美契合了分布式系统的需求极简与高性能代码量只有几千行审计和维护容易。内核态运行加密解密效率极高能跑满千兆甚至万兆带宽延迟极低。无中心化架构WireGuard 隧道是点对点的。每个节点只需要配置其对等体Peer的公钥和可达端点Endpoint就能建立直连隧道。没有中心服务器天然避免了单点故障。基于加密密钥的身份验证节点身份由其公钥唯一标识无需复杂的证书体系。访问控制通过简单的公钥白名单即可实现。完美的 NAT 穿透能力WireGuard 能很好地处理大多数 NAT 环境让位于家庭路由器或企业防火墙后的节点也能建立直接连接。Kilo 的聪明之处在于它看到了 WireGuard 的这些特性与 K8s 节点模型的天然契合。Kilo 将自己作为 K8s 的一个 CNI 插件和网络控制器自动发现集群中的所有节点并为每个节点生成 WireGuard 的密钥对和配置。它根据节点的地理位置、网络拓扑通过注解或标签定义智能地决定哪些节点之间需要建立直接的 WireGuard 隧道哪些流量可以通过中继节点转发从而自动构建出一个最优的、全网状或部分网状的加密覆盖网络。2.3 Kilo 的架构定位所以Kilo 不是一个完整的 CNI它通常与 Flannel 这样的基础 CNI 协同工作。Flannel 负责管理节点内部的 Pod 网络分配 Pod IP设置本地网桥和路由而 Kilo 则负责管理节点之间的网络用 WireGuard 隧道把各个 Flannel 子网“缝合”起来。这种解耦设计非常优雅既利用了成熟 CNI 的稳定性又引入了 WireGuard 的跨网络能力。3. 核心组件与工作原理深度解析Kilo 的架构非常清晰主要由两个核心组件构成Kilo 代理kg和 Kilo 控制器。理解它们如何协作是掌握 Kilo 的关键。3.1 Kilo 代理运行在每个节点的守护进程kg是一个以 DaemonSet 形式部署在每个 Kubernetes 节点上的二进制文件。它是 Kilo 的“执行层”负责本节点所有与 WireGuard 相关的实际操作。它的核心职责包括监听 Kubernetes API持续监听Watch集群中 Node 对象的变化。当有新节点加入、节点标签/注解更新或节点被删除时kg会收到通知。管理 WireGuard 接口在每个节点上创建并配置一个名为kilo0的 WireGuard 网络接口。这是所有跨节点流量的出入口。生成与维护密钥为当前节点生成 WireGuard 所需的私钥和公钥。私钥保存在节点本地公钥则通过 Kubernetes Node 对象的注解如kilo.squat.ai/public-key上报到 API Server供其他节点读取。配置 WireGuard Peers根据从 API Server 获取的全集群节点信息特别是其他节点的公钥和推荐的外部 IP/端口计算并更新本节点kilo0接口的对等体Peer配置。这个过程是动态的Kilo 支持多种拓扑逻辑Mesh, Hub-and-Spoke等kg会根据预设的拓扑规则决定与哪些节点建立直接隧道。配置路由规则在节点的内核路由表中添加必要的路由条目。例如它将其他节点的 Pod CIDR 网段如10.244.2.0/24的路由指向kilo0接口并通过 WireGuard 隧道送达正确的对端节点。可选的中继功能在Hub-and-Spoke拓扑中被指定为“枢纽”的节点会开启 IP 转发并为“分支”节点提供流量中继。实操心得密钥管理Kilo 的密钥是自动生成并保存在节点本地的通常是/var/lib/wireguard目录。这意味着如果你彻底销毁并重建一个同名节点它的私钥会变公钥也随之改变。其他节点需要重新获取新公钥来更新隧道配置。Kilo 通过监听 Node 对象的变化自动处理这个过程但在某些极端情况下如节点持久化存储丢失且 Node 对象未被清理可能会导致网络中断。确保你的节点有稳定的唯一标识如云厂商的 Instance ID并正确配置--kubeconfig是关键。3.2 Kilo 控制器集群级别的协调大脑Kilo 控制器通常以 Deployment 形式运行在集群的某个节点上。它扮演着“决策者”和“优化者”的角色工作层面更高生成网络清单控制器会读取所有节点的信息包括地理位置通过topology.kubernetes.io/region等标签、注解、IP 地址并应用用户通过 Kilo 自定义资源如Peer定义的策略。计算最优拓扑这是 Kilo 的智能所在。控制器根据内置算法计算节点间建立 WireGuard 隧道的最优方案。例如它可能会让同一个数据中心Region内的节点建立全网状连接以获得最低延迟而不同数据中心的节点则通过少数几个“网关”节点进行星型连接以减少长距离隧道的数量和管理开销。下发配置建议控制器将计算出的拓扑结果以“建议”的形式写入到每个 Node 对象的注解中。例如它可能会在某个节点的注解里写入kilo.squat.ai/force-endpoint: 34.56.78.90建议该节点使用特定的公网 IP 作为 WireGuard 端点。管理 Peer CRDKilo 定义了Peer这个自定义资源允许你将集群外的服务器如一台物理数据库服务器也纳入 Kilo 网络。控制器负责处理这些Peer资源并将其配置分发到相关的集群节点上。两者协作流程用户或系统创建一个新的 Kubernetes 节点。该节点上的kg代理启动生成密钥并将公钥写入本 Node 对象的注解。Kilo 控制器观察到新的 Node 对象结合全集群状态计算拓扑更新。控制器将更新后的“建议”如端点IP、允许的IP段写入相关 Node 对象的注解。所有节点的kg代理监听到这些注解变化重新配置本地的 WireGuard 接口和路由表。新的加密隧道自动建立Pod 跨节点通信恢复或建立。这个基于 Kubernetes API 的声明式协作模式是云原生项目的典型设计实现了最终一致性非常健壮。4. 实战部署一步步构建跨云 K8s 网络理论说再多不如亲手搭一遍。下面我将以一个经典的场景为例在 AWS 的us-west-2和 GCP 的asia-east1各部署一个 K3s 节点然后用 Kilo 把它们打通形成一个可以跨云直接通过 Pod IP 通信的“逻辑集群”。4.1 环境准备与假设集群 A (AWS):节点 IP:52.1.2.3(公网),172.31.16.10(私网)Pod CIDR:10.244.0.0/24使用 K3s 版本v1.27集群 B (GCP):节点 IP:34.56.78.90(公网),10.140.0.20(私网)Pod CIDR:10.244.1.0/24目标: 让 AWS 上的 Pod (10.244.0.5) 能直接ping通 GCP 上的 Pod (10.244.1.5)。注意安全组与防火墙这是跨云部署中最容易踩坑的地方。WireGuard 默认使用 UDP 协议端口51820。你必须在 AWS 的安全组和 GCP 的防火墙规则中允许来自对方公网 IP 的UDP:51820入站流量。同时为了 K3s 的正常运行还需要开放 TCP 6443 (API Server), 8472 (Flannel VXLAN) 等端口。建议先临时设置允许所有来源的UDP:51820进行测试成功后再细化规则。4.2 安装 K3s 并配置 Flannel首先在两边分别安装 K3s。我们需要指定 Pod 网段并使用 Flannel 作为基础 CNI。在 AWS 节点上执行curl -sfL https://get.k3s.io | INSTALL_K3S_VERSIONv1.27.6k3s1 \ INSTALL_K3S_EXEC--flannel-backendvxlan --cluster-cidr10.244.0.0/16 \ sh -这里--cluster-cidr指定了整个集群的 Pod IP 范围K3s 会为每个节点从这个大池子里分配一个/24的子网。在 GCP 节点上执行同样的命令。安装完成后分别在两台机器上运行sudo k3s kubectl get nodes -o wide确认节点状态为Ready并记录下INTERNAL-IP通常是私网IP和分配给节点的PodCIDR如10.244.0.0/24。4.3 部署 KiloKilo 的部署非常简洁通过一个 YAML 清单文件即可。我们需要根据我们的跨云场景调整几个关键参数。创建一个名为kilo.yaml的文件内容如下--- apiVersion: v1 kind: ServiceAccount metadata: name: kilo namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kilo rules: - apiGroups: [] resources: [nodes, nodes/status] verbs: [get, list, watch, update, patch] - apiGroups: [kilo.squat.ai] resources: [peers] verbs: [get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kilo roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kilo subjects: - kind: ServiceAccount name: kilo namespace: kube-system --- apiVersion: apps/v1 kind: DaemonSet metadata: name: kilo namespace: kube-system labels: app.kubernetes.io/name: kilo spec: selector: matchLabels: app.kubernetes.io/name: kilo updateStrategy: type: RollingUpdate template: metadata: labels: app.kubernetes.io/name: kilo spec: serviceAccountName: kilo hostNetwork: true tolerations: - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists containers: - name: kilo image: squat/kilo:latest args: - --kubeconfig/etc/kubernetes/kubeconfig - --hostname$(NODE_NAME) # 关键配置启用 WireGuard 加密 - --encrypttrue # 关键配置设置 WireGuard 监听的端口 - --port51820 # 关键配置告诉 Kilo 如何获取节点的公网端点。 # 我们使用 --external-ip 自动检测并回退到节点公网IP。 # 对于云环境这通常能正确获取。 - --external-iptrue # 重要拓扑逻辑。对于只有两个节点的跨云场景full-mesh 是最简单的。 # 它会强制让两个节点建立直接隧道。 - --topologyfull-mesh # 将 Kilo 接口创建的隧道路由注入到主路由表 - --routing-tablemain env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName securityContext: privileged: true capabilities: add: - NET_ADMIN - SYS_MODULE volumeMounts: - name: kilo-dir mountPath: /var/lib/wireguard - name: lib-modules mountPath: /lib/modules readOnly: true - name: kubeconfig mountPath: /etc/kubernetes readOnly: true volumes: - name: kilo-dir hostPath: path: /var/lib/wireguard type: DirectoryOrCreate - name: lib-modules hostPath: path: /lib/modules - name: kubeconfig hostPath: path: /etc/rancher/k3s # K3s 默认的 kubeconfig 路径 type: DirectoryOrCreate关键参数解析--encrypttrue启用 WireGuard 加密。这是核心功能必须开启。--port51820指定 WireGuard 监听的 UDP 端口需与防火墙规则匹配。--external-iptrue让 Kilo 自动探测节点的外部 IP 作为 WireGuard 隧道的公网端点。在云服务器上这通常能获取到公网 IP。如果自动探测失败你可以通过给 Node 打注解kilo.squat.ai/force-endpoint: 52.1.2.3:51820来手动指定。--topologyfull-mesh全网状拓扑。对于节点数少的情况比如我们只有2个这是最直接有效的。所有节点两两之间建立直接隧道。如果节点很多可以考虑hub-and-spoke以节省连接数。--routing-tablemain将 Kilo 的路由规则添加到主路由表确保所有流量包括非 Pod 流量如节点SSH如果目标是对端节点的 Pod CIDR也会走 WireGuard 隧道。这简化了路由管理。将这个 YAML 文件分别应用到两个集群的节点上# 在 AWS 节点上 sudo k3s kubectl apply -f kilo.yaml # 在 GCP 节点上 sudo k3s kubectl apply -f kilo.yaml4.4 验证部署与网络连通性部署完成后检查 DaemonSet 和 Pod 状态sudo k3s kubectl -n kube-system get ds kilo sudo k3s kubectl -n kube-system get pods -l app.kubernetes.io/namekilo应该看到每个节点上都有一个kilo-xxxxx的 Pod 在运行。接下来检查 WireGuard 接口是否创建成功# 在任意节点上执行 sudo wg show你应该能看到一个名为kilo0的接口并且能看到一个对等体Peer其公钥和端点Endpoint就是另一个节点的信息。latest handshake应该显示在几秒内表示隧道已成功建立。验证 Pod 间通信在 AWS 节点上启动一个测试 Podsudo k3s kubectl run test-pod-aws --imagealpine --restartNever -- sleep 3600在 GCP 节点上启动一个测试 Podsudo k3s kubectl run test-pod-gcp --imagealpine --restartNever -- sleep 3600获取 Pod IPsudo k3s kubectl get pods -o wide假设test-pod-awsIP 为10.244.0.5test-pod-gcpIP 为10.244.1.5。进行跨云 Ping 测试# 在 AWS 节点上进入 test-pod-aws sudo k3s kubectl exec -it test-pod-aws -- sh / # ping 10.244.1.5如果看到成功的回复恭喜你Kilo 已经成功地在两个不同云厂商的节点之间建立了一条加密的 WireGuard 隧道并让 Flannel 的 Pod 网络跨越了物理边界。5. 高级配置与拓扑管理简单的双节点全互联只是开始。Kilo 真正的威力在于其灵活的拓扑管理能力可以优化大规模、多区域部署的网络。5.1 节点分区与区域感知在真实的跨区域部署中我们通常希望同一区域内的节点延迟最低优先直连跨区域通信可以通过少数几个网关节点聚合以减少长距离隧道数量和管理复杂度。Kilo 利用 Kubernetes 节点的标准标签topology.kubernetes.io/region和topology.kubernetes.io/zone来实现这一点。你只需要在创建节点时或事后打标签指定这些标签Kilo 控制器就会自动识别。例如假设我们有区域us-west(AWS): 节点 node-a1, node-a2区域eu-central(GCP): 节点 node-e1, node-e2区域asia-east(Azure): 节点 node-s1我们可以通过 Kilo 的启动参数或配置来定义拓扑规则。一种常见的方式是使用--topologyauto默认并结合--mesh-granularitylocation参数。Kilo 会自动将同一region内的节点组成一个“逻辑位置”内部全互联然后为每个“逻辑位置”选举一个或多个“领导者”节点负责与其他“位置”建立跨区域隧道。你也可以通过自定义 Node 的注解来更精细地控制# 手动指定某个节点作为其区域的网关 kilo.squat.ai/force-endpoint: 公网IP:51820 kilo.squat.ai/gateway: true # 标记此节点为网关 kilo.squat.ai/location: us-west-2a # 自定义位置标识覆盖 region/zone5.2 混合云与裸金属对等Kilo 的Peer自定义资源CRD是其一大特色它允许你将集群外的任何支持 WireGuard 的机器纳入网络。假设你有一台位于公司机房的物理数据库服务器IP:192.168.1.100你想让所有云上的 Pod 都能安全地访问它。在物理服务器上安装并配置 WireGuard。生成密钥对wg genkey | tee privatekey | wg pubkey publickey。在 Kubernetes 集群中创建一个 Peer 资源apiVersion: kilo.squat.ai/v1alpha1 kind: Peer metadata: name: on-prem-db spec: publicKey: 物理服务器的公钥 allowedIPs: - 192.168.1.100/32 # 物理服务器自身的IP - 10.0.0.0/24 # 甚至可以给它分配一个虚拟IP段用于其后面的其他服务 endpoint: 物理服务器的公网IP或DDNS域名:51820 persistentKeepalive: 25 # 如果物理服务器在NAT后需要保持连接应用这个 YAML 文件。Kilo 控制器会监听到这个 Peer 资源并将其配置分发到所有相关的集群节点默认是所有节点上。每个节点的kg代理会更新本地 WireGuard 配置将物理服务器作为一个对等体。现在集群内的任意 Pod 都可以直接访问192.168.1.100流量会通过 WireGuard 隧道加密传输到你的机房。这个功能极大地扩展了 K8s 网络的边界实现了真正的混合云统一网络平面。6. 故障排查与性能调优即使配置正确在实际运行中也可能遇到问题。以下是一些常见故障场景和排查思路。6.1 隧道建立失败症状wg show显示对等体端点存在但latest handshake是很久以前或者一直是None跨节点 Pod 无法通信。排查步骤检查防火墙这是最常见的原因。确保双方节点的安全组/防火墙都允许 UDP 51820 端口入站。可以使用nc -vu 对方公网IP 51820在目标端口测试连通性。检查端点配置查看 Node 的注解kilo.squat.ai/force-endpoint或自动发现的端点是否正确。执行sudo kubectl describe node node-name查看。确保注解里的 IP:Port 是对方节点 WireGuard 实际监听的地址。检查密钥匹配确认每个节点使用的公钥与对方节点配置的私钥对应。可以通过对比 Node 注解中的kilo.squat.ai/public-key和wg show输出的公钥来验证。查看 Kilo 日志sudo kubectl -n kube-system logs -l app.kubernetes.io/namekilo。关注是否有权限错误、连接失败等报错信息。检查路由在节点上执行ip route show。你应该能看到指向kilo0接口的、目标为其他节点 Pod CIDR 的路由条目。如果没有可能是 Kilo 代理没有正确配置路由。6.2 性能问题症状跨节点网络带宽远低于预期或者延迟异常高。调优建议MTU 设置WireGuard 隧道会增加数据包开销通常约80字节。如果底层网络的 MTU 是1500那么经过 WireGuard 封装后可能超过1500导致分片降低性能。建议将 Kilo 接口kilo0的 MTU 设置为更低的值如 1420。可以在 Kilo DaemonSet 的启动参数中添加--mtu1420。拓扑优化对于超过10个节点的跨区域集群避免使用full-mesh。全互联的隧道数量是n*(n-1)/2管理开销大。改用hub-and-spoke或依赖--topologyauto的区域感知模式可以显著减少长距离隧道数量。记住星型拓扑会增加网关节点的负载和单点故障风险通常需要部署多个网关。内核 WireGuard 模块确保你的服务器内核已编译 WireGuard 模块或已动态加载。Kilo 容器需要NET_ADMIN和SYS_MODULE能力来加载模块。使用lsmod | grep wireguard检查。使用最新稳定版的内核和 WireGuard 工具能获得最佳性能。节点规格WireGuard 加密解密是 CPU 密集型操作。如果网关节点需要处理大量跨区域流量确保其有足够的 CPU 资源。6.3 与 Service Mesh 的兼容性常见问题同时使用 Kilo 和 Istio/Linkerd 等服务网格时流量路径可能变得复杂甚至产生冲突。处理原则层级关系Kilo 工作在 L3网络层负责节点间联通。服务网格通常工作在 L4-L7负责服务间的流量管理、安全和可观测性。理论上服务网格的 Sidecar 代理应该能看到 Kilo 提供的透明网络。实践建议先确保 Kilo 层面的网络是通的Pod IP 可 ping。然后再部署服务网格。如果出现问题检查服务网格的配置是否错误地拦截或重写了流量例如错误的trafficPolicy设置。一个稳妥的方法是在服务网格的配置中明确排除对kilo0接口或 WireGuard 端口51820流量的处理。7. 生产环境考量与运维建议将 Kilo 用于生产环境除了功能还需要关注稳定性、可观测性和高可用。7.1 高可用部署Kilo 控制器Kilo 控制器虽然不处理数据平面流量但它负责拓扑计算和配置下发。建议以 Deployment 方式部署多个副本例如2个并配置PodAntiAffinity让它们分散在不同节点上避免单点故障。网关节点在hub-and-spoke拓扑中网关节点是关键。务必为每个区域部署至少两个网关节点并利用 Kubernetes Service 为这些网关节点创建一个负载均衡器可以是内网 LB。然后通过 Node 注解kilo.squat.ai/force-endpoint将其他节点的端点指向这个 LB 的 IP实现网关层的高可用。健康检查可以为 Kilo 代理kg容器添加livenessProbe和readinessProbe例如检查wg show命令是否成功执行或者检查kilo0接口是否存在。7.2 监控与日志WireGuard 指标wg show命令输出的信息非常有用如transfer收发字节数、latest handshake。可以考虑使用一个 sidecar 容器如prometheus-wireguard-exporter来抓取这些指标并暴露给 Prometheus。Kilo 日志确保 Kilo 容器日志被集中收集如通过 Fluentd 到 Elasticsearch。日志级别可以通过--v2参数调整在排查问题时可以临时调高。网络连通性监控在集群中部署一个简单的网络检测 DaemonSet如nicolaka/netshoot定期在所有节点间进行 Pod IP 的 ping 或 curl 测试并将结果上报到监控系统以便及时发现网络分区。7.3 安全加固RBAC 最小权限上文提供的 YAML 已经配置了相对严格的 RBAC。在生产中可以进一步审查确保 Service Account 只拥有它必需的最小权限。Pod 安全策略/PSAKilo DaemonSet 需要privileged: true和NET_ADMIN,SYS_MODULE能力。在启用 Pod 安全准入PSA的集群中你需要为kube-system命名空间创建一个合适的PodSecurityStandard豁免Exemption。WireGuard 密钥轮换Kilo 目前不提供自动的密钥轮换机制。如果需要轮换一个可行的方法是逐个节点重启 Kilo Pod或删除其密钥文件/var/lib/wireguard/privatekey。Kilo 会生成新密钥并更新 Node 注解其他节点会自动学习并更新对等体配置。这个过程会导致该节点的隧道短暂中断应安排在维护窗口进行。Kilo 以其独特的设计在 K8s 生态中找到了一个精准的利基市场。它没有试图解决所有网络问题而是用最精简的方式解决了“跨网络边界的安全互联”这个痛点。对于运维混合云、边缘集群的团队来说它提供了一种比传统 VPN 或专线更云原生、更灵活、性能也更好的选择。当然它也不是银弹在超大规模集群或对网络策略有极其复杂要求的场景下更成熟的 Calico 或 Cilium 可能是更全面的选择。但当你需要快速、轻量地打通几个分散的 K8s 节点时Kilo 无疑是那个值得你放入工具箱的精致瑞士军刀。
