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 通。

然而，现实很骨感：

1. 混合云与多云场景：你的集群节点可能分布在 AWS、GCP、Azure 甚至公司的私有机房。不同云厂商的 VPC 之间默认是隔离的。
2. 边缘计算场景：成百上千的边缘设备分布在各个角落，它们可能位于不同的局域网，通过 NAT 上网，IP地址不固定，甚至没有公网IP。
3. 网络策略限制：企业防火墙可能严格限制了节点间的端口，导致 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 相关的实际操作。它的核心职责包括：

1. 监听 Kubernetes API：持续监听（Watch）集群中 Node 对象的变化。当有新节点加入、节点标签/注解更新或节点被删除时，kg会收到通知。
2. 管理 WireGuard 接口：在每个节点上创建并配置一个名为kilo0的 WireGuard 网络接口。这是所有跨节点流量的出入口。
3. 生成与维护密钥：为当前节点生成 WireGuard 所需的私钥和公钥。私钥保存在节点本地，公钥则通过 Kubernetes Node 对象的注解（如kilo.squat.ai/public-key）上报到 API Server，供其他节点读取。
4. 配置 WireGuard Peers：根据从 API Server 获取的全集群节点信息（特别是其他节点的公钥和推荐的外部 IP/端口），计算并更新本节点kilo0接口的对等体（Peer）配置。这个过程是动态的，Kilo 支持多种拓扑逻辑（Mesh, Hub-and-Spoke等），kg会根据预设的拓扑规则决定与哪些节点建立直接隧道。
5. 配置路由规则：在节点的内核路由表中添加必要的路由条目。例如，它将其他节点的 Pod CIDR 网段（如10.244.2.0/24）的路由，指向kilo0接口，并通过 WireGuard 隧道送达正确的对端节点。
6. 可选的中继功能：在Hub-and-Spoke拓扑中，被指定为“枢纽”的节点会开启 IP 转发，并为“分支”节点提供流量中继。

实操心得：密钥管理Kilo 的密钥是自动生成并保存在节点本地的（通常是/var/lib/wireguard目录）。这意味着如果你彻底销毁并重建一个同名节点，它的私钥会变，公钥也随之改变。其他节点需要重新获取新公钥来更新隧道配置。Kilo 通过监听 Node 对象的变化自动处理这个过程，但在某些极端情况下（如节点持久化存储丢失且 Node 对象未被清理），可能会导致网络中断。确保你的节点有稳定的唯一标识（如云厂商的 Instance ID）并正确配置--kubeconfig是关键。

3.2 Kilo 控制器：集群级别的协调大脑

Kilo 控制器通常以 Deployment 形式运行在集群的某个节点上。它扮演着“决策者”和“优化者”的角色，工作层面更高：

1. 生成网络清单：控制器会读取所有节点的信息，包括地理位置（通过topology.kubernetes.io/region等标签）、注解、IP 地址，并应用用户通过 Kilo 自定义资源（如Peer）定义的策略。
2. 计算最优拓扑：这是 Kilo 的智能所在。控制器根据内置算法，计算节点间建立 WireGuard 隧道的最优方案。例如，它可能会让同一个数据中心（Region）内的节点建立全网状连接以获得最低延迟，而不同数据中心的节点则通过少数几个“网关”节点进行星型连接，以减少长距离隧道的数量和管理开销。
3. 下发配置建议：控制器将计算出的拓扑结果，以“建议”的形式写入到每个 Node 对象的注解中。例如，它可能会在某个节点的注解里写入kilo.squat.ai/force-endpoint: 34.56.78.90，建议该节点使用特定的公网 IP 作为 WireGuard 端点。
4. 管理 Peer CRD：Kilo 定义了Peer这个自定义资源，允许你将集群外的服务器（如一台物理数据库服务器）也纳入 Kilo 网络。控制器负责处理这些Peer资源，并将其配置分发到相关的集群节点上。

两者协作流程：

1. 用户或系统创建一个新的 Kubernetes 节点。
2. 该节点上的kg代理启动，生成密钥，并将公钥写入本 Node 对象的注解。
3. Kilo 控制器观察到新的 Node 对象，结合全集群状态，计算拓扑更新。
4. 控制器将更新后的“建议”（如端点IP、允许的IP段）写入相关 Node 对象的注解。
5. 所有节点的kg代理监听到这些注解变化，重新配置本地的 WireGuard 接口和路由表。
6. 新的加密隧道自动建立，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_VERSION=v1.27.6+k3s1 \ INSTALL_K3S_EXEC="--flannel-backend=vxlan --cluster-cidr=10.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 部署 Kilo

Kilo 的部署非常简洁，通过一个 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 加密 - --encrypt=true # 关键配置：设置 WireGuard 监听的端口 - --port=51820 # 关键配置：告诉 Kilo 如何获取节点的公网端点。 # 我们使用 `--external-ip` 自动检测，并回退到节点公网IP。 # 对于云环境，这通常能正确获取。 - --external-ip=true # 重要：拓扑逻辑。对于只有两个节点的跨云场景，`full-mesh` 是最简单的。 # 它会强制让两个节点建立直接隧道。 - --topology=full-mesh # 将 Kilo 接口创建的隧道路由注入到主路由表 - --routing-table=main 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

关键参数解析：

• --encrypt=true：启用 WireGuard 加密。这是核心功能，必须开启。
• --port=51820：指定 WireGuard 监听的 UDP 端口，需与防火墙规则匹配。
• --external-ip=true：让 Kilo 自动探测节点的外部 IP 作为 WireGuard 隧道的公网端点。在云服务器上，这通常能获取到公网 IP。如果自动探测失败，你可以通过给 Node 打注解kilo.squat.ai/force-endpoint: "52.1.2.3:51820"来手动指定。
• --topology=full-mesh：全网状拓扑。对于节点数少的情况（比如我们只有2个），这是最直接有效的。所有节点两两之间建立直接隧道。如果节点很多，可以考虑hub-and-spoke以节省连接数。
• --routing-table=main：将 Kilo 的路由规则添加到主路由表，确保所有流量（包括非 Pod 流量，如节点SSH）如果目标是对端节点的 Pod CIDR，也会走 WireGuard 隧道。这简化了路由管理。

将这个 YAML 文件分别应用到两个集群的节点上：

# 在 AWS 节点上 sudo k3s kubectl apply -f kilo.yaml # 在 GCP 节点上 sudo k3s kubectl apply -f kilo.yaml

4.4 验证部署与网络连通性

部署完成后，检查 DaemonSet 和 Pod 状态：

sudo k3s kubectl -n kube-system get ds kilo sudo k3s kubectl -n kube-system get pods -l app.kubernetes.io/name=kilo

应该看到每个节点上都有一个kilo-xxxxx的 Pod 在运行。

接下来，检查 WireGuard 接口是否创建成功：

# 在任意节点上执行 sudo wg show

你应该能看到一个名为kilo0的接口，并且能看到一个对等体（Peer），其公钥和端点（Endpoint）就是另一个节点的信息。latest handshake应该显示在几秒内，表示隧道已成功建立。

验证 Pod 间通信：

1. 在 AWS 节点上启动一个测试 Pod：

   sudo k3s kubectl run test-pod-aws --image=alpine --restart=Never -- sleep 3600

2. 在 GCP 节点上启动一个测试 Pod：

   sudo k3s kubectl run test-pod-gcp --image=alpine --restart=Never -- sleep 3600

3. 获取 Pod IP：

   sudo k3s kubectl get pods -o wide

   假设test-pod-awsIP 为10.244.0.5，test-pod-gcpIP 为10.244.1.5。
4. 进行跨云 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 的启动参数或配置来定义拓扑规则。一种常见的方式是使用--topology=auto（默认），并结合--mesh-granularity=location参数。Kilo 会自动将同一region内的节点组成一个“逻辑位置”，内部全互联，然后为每个“逻辑位置”选举一个或多个“领导者”节点，负责与其他“位置”建立跨区域隧道。

你也可以通过自定义 Node 的注解来更精细地控制：

# 手动指定某个节点作为其区域的网关 kilo.squat.ai/force-endpoint: "公网IP:51820" kilo.squat.ai/gateway: "true" # 标记此节点为网关 kilo.squat.ai/location: "us-west-2a" # 自定义位置标识，覆盖 region/zone

5.2 混合云与裸金属对等

Kilo 的Peer自定义资源（CRD）是其一大特色，它允许你将集群外的任何支持 WireGuard 的机器纳入网络。

假设你有一台位于公司机房的物理数据库服务器（IP:192.168.1.100），你想让所有云上的 Pod 都能安全地访问它。

1. 在物理服务器上安装并配置 WireGuard。生成密钥对：wg genkey | tee privatekey | wg pubkey > publickey。
2. 在 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后，需要保持连接

3. 应用这个 YAML 文件。Kilo 控制器会监听到这个 Peer 资源，并将其配置分发到所有相关的集群节点（默认是所有节点）上。每个节点的kg代理会更新本地 WireGuard 配置，将物理服务器作为一个对等体。
4. 现在，集群内的任意 Pod 都可以直接访问192.168.1.100，流量会通过 WireGuard 隧道加密传输到你的机房。

这个功能极大地扩展了 K8s 网络的边界，实现了真正的混合云统一网络平面。

6. 故障排查与性能调优

即使配置正确，在实际运行中也可能遇到问题。以下是一些常见故障场景和排查思路。

6.1 隧道建立失败

症状：wg show显示对等体端点存在，但latest handshake是很久以前或者一直是None，跨节点 Pod 无法通信。

排查步骤：

1. 检查防火墙：这是最常见的原因。确保双方节点的安全组/防火墙都允许 UDP 51820 端口入站。可以使用nc -vu <对方公网IP> 51820在目标端口测试连通性。
2. 检查端点配置：查看 Node 的注解kilo.squat.ai/force-endpoint或自动发现的端点是否正确。执行sudo kubectl describe node <node-name>查看。确保注解里的 IP:Port 是对方节点 WireGuard 实际监听的地址。
3. 检查密钥匹配：确认每个节点使用的公钥与对方节点配置的私钥对应。可以通过对比 Node 注解中的kilo.squat.ai/public-key和wg show输出的公钥来验证。
4. 查看 Kilo 日志：sudo kubectl -n kube-system logs -l app.kubernetes.io/name=kilo。关注是否有权限错误、连接失败等报错信息。
5. 检查路由：在节点上执行ip route show。你应该能看到指向kilo0接口的、目标为其他节点 Pod CIDR 的路由条目。如果没有，可能是 Kilo 代理没有正确配置路由。

6.2 性能问题

症状：跨节点网络带宽远低于预期，或者延迟异常高。

调优建议：

1. MTU 设置：WireGuard 隧道会增加数据包开销（通常约80字节）。如果底层网络的 MTU 是1500，那么经过 WireGuard 封装后可能超过1500，导致分片，降低性能。建议将 Kilo 接口kilo0的 MTU 设置为更低的值，如 1420。可以在 Kilo DaemonSet 的启动参数中添加--mtu=1420。
2. 拓扑优化：对于超过10个节点的跨区域集群，避免使用full-mesh。全互联的隧道数量是n*(n-1)/2，管理开销大。改用hub-and-spoke或依赖--topology=auto的区域感知模式，可以显著减少长距离隧道数量。记住，星型拓扑会增加网关节点的负载和单点故障风险，通常需要部署多个网关。
3. 内核 WireGuard 模块：确保你的服务器内核已编译 WireGuard 模块或已动态加载。Kilo 容器需要NET_ADMIN和SYS_MODULE能力来加载模块。使用lsmod | grep wireguard检查。使用最新稳定版的内核和 WireGuard 工具能获得最佳性能。
4. 节点规格：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）。日志级别可以通过--v=2参数调整，在排查问题时可以临时调高。
• 网络连通性监控：在集群中部署一个简单的网络检测 DaemonSet（如nicolaka/netshoot），定期在所有节点间进行 Pod IP 的 ping 或 curl 测试，并将结果上报到监控系统，以便及时发现网络分区。

7.3 安全加固

• RBAC 最小权限：上文提供的 YAML 已经配置了相对严格的 RBAC。在生产中，可以进一步审查，确保 Service Account 只拥有它必需的最小权限。
• Pod 安全策略/PSA：Kilo 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 无疑是那个值得你放入工具箱的精致瑞士军刀。