交互式 K3s 网络故障排查报告

案例档案

本报告将一个真实的 K3s 网络故障排查过程转化为交互式学习体验。您可以按时间线探索每个诊断阶段，或使用 Gemini AI 功能获取定制化解释和摘要。

交互式排查路径

阶段一

审查网络策略

阶段二

底层路径验证

阶段三

揭示架构差异

最终解决方案

制定精确策略

阶段一：审查应用层网络策略 (NetworkPolicy)

初始假设是 user 命名空间中存在过于严格的网络策略，阻止了 authentik 的出站流量。审查发现，确实存在一个“默认拒绝”所有流量的策略，以及一个意图为 authentik 放行流量的专用策略。

结果：问题依旧

即使应用了逻辑上正确的策略，连接超时错误仍然复现。这表明问题根源更深，不在于 NetworkPolicy 的表面逻辑。

阶段二：底层网络路径验证

为了验证从 Pod 到 API Server 的底层网络路径是否通畅，我们部署了一个 netshoot 诊断 Pod。

命令执行结果：

> nc -vz 10.43.0.1 443
nc: connect to 10.43.0.1 port 443 (tcp) failed: Operation timed out

> traceroute 10.43.0.1
traceroute to 10.43.0.1 (10.43.0.1), 30 hops max, 46 byte packets
 1  core (172.16.50.8)  0.011 ms ...
 2  * * *

决定性结论：底层网络阻塞

所有测试均超时，且 traceroute 显示数据包在离开源节点后便消失。这证明了问题与 NetworkPolicy 逻辑无关，而是 CNI 或集群网络层面的阻塞。

阶段三：深入 CNI 与揭示架构差异

在尝试创建一个指向 API Server Pod 的策略时，我们检查了 kube-system 命名空间，迎来了突破。

命令执行结果：

> kubectl get pods -n kube-system --show-labels
# ... 输出中没有 kube-apiserver 相关的 Pod ...

“啊哈！”时刻：这是 K3s 集群！

在 K3s 中，API Server 作为主机进程运行，而非 Pod。这意味着所有基于“访问 API Server Pod”的假设都是错误的。

最终解决方案：制定精确策略

基于对 K3s 架构的正确理解，我们制定了最终的、精确的网络策略。目标不再是 Pod，而是 Master 节点的真实主机 IP。

最终生效的网络策略 (核心部分)：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-user-to-k3s-master
spec:
  podSelector: {}
  egress:
    - to:
      - ipBlock:
          cidr: /32 # 关键规则！
      ports:
        - protocol: TCP
          port: 6443

结果：问题解决

应用此 ipBlock 策略后，authentik Pod 立即恢复了对 API Server 的访问，所有功能恢复正常。