STM32CubeMX扩展插件支持ESP32可行性探讨

Kubernetes 网络模型与服务通信机制深度解析

在智能家居设备日益复杂的今天，确保无线连接的稳定性已成为一大设计挑战。类似地，在云原生世界中，随着微服务数量呈指数级增长，如何保障成百上千个 Pod 之间高效、安全、可靠的通信，也成了运维团队夜不能寐的技术难题。

你有没有遇到过这样的场景？一个看似简单的 HTTP 请求，却要穿越十几个服务节点，最终卡死在某个神秘的网络黑洞里；又或者，明明所有 Pod 都是 Running 状态，但它们就是“互相看不见”——ping 不通、telnet 失败、DNS 解析超时……这时候，日志查遍了，监控看了无数遍，最后发现：问题竟然出在网络底层。

这正是我们今天要深入探讨的主题： Kubernetes 的网络模型与服务通信机制 。它不是什么花哨的新玩具，而是支撑整个集群稳定运行的“神经系统”。理解它，不仅能让你从容应对各种诡异的网络故障，还能为后续的服务网格、可观测性、零信任安全等高级能力打下坚实基础。

---

想象一下，K8s 集群就像一座现代化城市。每个 Pod 就是一个独立的家庭单元（公寓），拥有自己的门牌号（IP 地址）。而 Service，则像是城市的邮政系统——无论哪家搬进搬出，只要名字不变，信件总能准确送达。至于 DNS？那是你的智能语音助手，“嘿 Siri，帮我找下 nginx-svc 在几栋？”

但这一切的背后，其实是 Linux 内核、CNI 插件、iptables/ipvs、etcd 等多个组件精密协作的结果。接下来，我们就从最基础的单位开始，一层层揭开这座“云原生城市”的交通图谱。

Pod 网络通信机制与 CNI 实现原理

Pod 是 Kubernetes 中最小的调度单位，也是网络通信的基本载体。每一个 Pod 启动时，都会被分配一个独立的 IP 地址，并且这个 IP 被所有容器共享。更重要的是，Kubernetes 官方明确规定： 所有 Pod 必须能在无需 NAT 的情况下直接通信 。这就是所谓的“扁平网络模型”。

听起来很理想，但在现实中，这些 Pod 往往分布在不同的物理机或虚拟机上。那么问题来了：跨主机的 Pod 是怎么实现“直连”的？

答案是： CNI（Container Network Interface）插件 。它是 Kubernetes 和底层网络之间的桥梁，负责完成 IP 分配、路由配置、策略执行等关键任务。

Pod 网络生命周期与 CNI 接口调用流程

当 kubelet 收到创建 Pod 的指令后，它并不会立刻启动容器，而是先通过容器运行时（如 containerd）创建一个“沙箱”环境。此时，真正的重头戏才刚刚开始——CNI 插件登场！

整个过程遵循标准的 CNI 接口规范，分为三个阶段：

阶段	触发时机	主要操作
ADD	Pod 创建时	分配 IP、配置 veth pair、设置路由、写入网络命名空间
CHECK	Pod 运行中健康检查	验证网络配置是否仍然有效
DEL	Pod 删除时	释放 IP、删除 veth pair、清理路由

这三个动作就像是房产中介帮你租房的过程：
- ADD 就像签合同、拿钥匙、登记住户信息；
- CHECK 是定期上门检查水电煤气是否正常；
- DEL 则是退房结算、收回钥匙、清除记录。

以 Calico 为例，它的 CNI 配置文件通常长这样👇：

{
  "cniVersion": "0.4.0",
  "name": "k8s-pod-network",
  "type": "calico",
  "etcd_endpoints": "https://10.100.0.100:2379",
  "log_level": "info",
  "ipam": {
    "type": "calico-ipam",
    "subnet": "usePodCidr"
  },
  "policy": {
    "type": "k8s"
  },
  "kubernetes": {
    "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
  }
}

别看这段 JSON 平平无奇，其实每一条都藏着玄机：

• "cniVersion": "0.4.0" ：版本号决定了兼容性。如果这里写错了，整个集群可能启动失败 😬。
• "name": "k8s-pod-network" ：这是网络的名字，相当于小区名称。如果有多个 CNI 配置共存，靠的就是这个名字来区分。
• "type": "calico" ：指定使用哪个 CNI 二进制程序。你可以把它理解为“选择装修公司”，Flannel、Cilium 都是不同的“施工队”。
• "etcd_endpoints" ：Calico 把所有网络策略和 IP 分配信息存在 etcd 里，这就像是中央数据库。如果你的 etcd 挂了，新 Pod 可能就拿不到 IP 了！⚠️
• "ipam" 块：IPAM（IP Address Management）负责地址分配。 usePodCidr 表示从节点预分配的 CIDR 块中取地址。比如 Node A 被分了 10.244.1.0/24 ，那它上面的所有 Pod 只能在这个范围内选 IP。
• "policy" 块：定义谁可以访问谁。 "type": "k8s" 表示启用 Kubernetes 原生的 NetworkPolicy 功能。如果不开启，防火墙规则压根不会生效！
• "kubernetes" 块：提供 kubeconfig 路径，让插件能跟 API Server 打交道，获取 Pod 标签、命名空间等元数据。

这个配置文件并不是手动写的，而是由 kubelet 通过环境变量自动注入给 CNI 插件的。整个流程在几百毫秒内完成，直接影响 Pod 的冷启动速度。所以，如果你发现某些 Pod 启动特别慢，不妨去看看 calico-node 的日志——说不定它正在疯狂重试连接 etcd 呢 🤔。

💡 实战小贴士 ：
如果你在部署 Calico 时修改了默认的 Pod CIDR（比如从 192.168.0.0/16 改成 10.244.0.0/16 ），一定要同步更新 kube-controller-manager 的 --cluster-cidr 参数，否则 IP 分配会乱套！

---

跨节点 Pod 通信：VXLAN 封装与路由分发

现在我们来看一个更刺激的问题：两个不在同一台机器上的 Pod，是怎么“隔空对话”的？

举个例子：Node A 上的 Pod A（IP: 10.244.1.10 ）想给 Node B 上的 Pod B（IP: 10.244.2.10 ）发消息。它们之间隔着物理网络，甚至可能属于不同子网。怎么办？

这时候，就需要一种叫 VXLAN（Virtual Extensible LAN） 的技术出场了。简单来说，它就是在两个节点之间建立一条“隧道”，把原本三层的 IP 包封装成二层帧，通过 UDP 传输过去，再解封还原。

具体流程如下👇：

1. Pod A 发送数据包到目标 IP 10.244.2.10 ；
2. 数据包经过 veth pair 到达宿主机网络空间；
3. 宿主机查找路由表，发现 10.244.2.0/24 子网要走 10.100.2.2 （即 Node B 的物理 IP）；
4. 数据包被封装进 VXLAN 帧，外层加上 UDP 头，目标端口为 8472 （VXLAN 默认端口）；
5. 封装后的 UDP 包经物理网络发送至 Node B；
6. Node B 的 flanneld 进程收到后解封装，提取原始 IP 包并转发给目标 Pod。

是不是有点像寄快递？你把包裹（原始 IP 包）放进箱子（VXLAN 封装），贴上运单（UDP + 外层 IP），交给物流公司（物理网络），对方签收后拆箱取出原物。

为了验证这条路是否通畅，我们可以用几个命令来看看内部状态：

# 查看当前节点的路由表，确认是否有通往其他节点 Pod CIDR 的路径
ip route show | grep 10.244

# 输出示例：
# 10.244.2.0/24 via 10.100.2.2 dev flannel.1 src 10.100.1.1

这条路由的意思是：“要去 10.244.2.0/24 的流量，请通过 flannel.1 设备发往 10.100.2.2 ”。

接着看看 FDB（Forwarding Database）表，它记录了 VXLAN 隧道对端的信息：

bridge fdb show dev flannel.1

输出可能是这样的：

10.100.2.2 dev flannel.1 lladdr 52:54:00:12:34:56 dst 10.100.2.2 self permanent

解释一下这几个字段：
- dev flannel.1 ：使用的虚拟设备名；
- lladdr ：对端 VTEP（VXLAN Tunnel Endpoint）的 MAC 地址；
- dst ：封装外层的目标 IP，也就是对端节点的物理 IP；
- self permanent ：说明这是静态配置项，不会老化。

⚠️ 常见坑点提醒 ：
如果你在跨节点 ping 不通，第一步就应该检查这两个表！尤其是 bridge fdb 是否有缺失条目。有时候是因为防火墙拦截了 8472 端口，导致 VXLAN 包根本传不过去。

当然，VXLAN 也不是完美的。它带来了约 50 字节的额外头部开销（IP + UDP + VXLAN），对于小包密集型应用（比如高频交易系统），可能会显著降低吞吐量。

所以在高性能场景下，建议使用更轻量的方式，比如 host-gw 模式 或者 BGP 直连 （Calico 特有）。前者直接利用主机路由，后者则通过动态协议宣告路由，完全避免封装。

---

CNI 插件对比分析：Flannel vs Calico vs Cilium

市面上主流的 CNI 插件不少，但真正扛得住生产考验的，主要还是这三个老大哥：Flannel、Calico、Cilium。它们各有千秋，适合不同的业务场景。

下面这张表帮你一目了然👇：

特性	Flannel	Calico	Cilium
数据平面	VXLAN / HostGW	IPIP / BGP	eBPF
网络策略支持	需集成其他组件	原生支持 NetworkPolicy	原生支持，基于 eBPF
性能损耗	中等（VXLAN 封装）	低（BGP 直连）	极低（内核级过滤）
DNS 查询优化	无	无	支持 DNS 可视化策略
服务网格集成	弱	中等	强（与 Istio 集成）
适用场景	快速部署、中小集群	大规模、强安全需求	高性能、可观测性要求高

看到没？选择哪个 CNI，本质上是在做权衡。

• 如果你是初创公司，只想快速跑起来， Flannel 是最佳入门选择。它简单、稳定、文档丰富，社区支持力度大。但缺点也很明显：不支持原生 NetworkPolicy，想要做微隔离还得额外搭一套方案。

• 如果你是一家金融企业，对安全合规有极高要求，那就得上 Calico 。它不仅支持完整的 Kubernetes NetworkPolicy，还能通过 BGP 实现无封装的三层路由，性能优越。更重要的是，它的策略引擎非常强大，支持细粒度的 ACL 控制，甚至可以做到 pod-to-pod 的加密通信（配合 WireGuard）🔐。

• 而如果你追求极致性能和可观测性，比如做 AI 推理平台或实时风控系统，那 Cilium 就是你梦寐以求的利器。它基于 Linux 内核的 eBPF 技术，可以直接在内核层面处理网络策略、负载均衡、监控埋点，几乎零开销。而且它和 Istio 深度集成，能实现 L7 层的流量控制和追踪，简直是服务网格的黄金搭档 ✨。

举个例子，如果你想让 Calico 使用 BGP 模式而不是 IPIP 封装，你需要修改它的 Installation 资源：

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    bgp: Enabled
    ipPools:
      - cidr: 10.244.0.0/16
        encapsulation: None  # 关键！禁用封装
        natOutgoing: Enabled
        nodeSelector: all()

重点来了： encapsulation: None 表示关闭 IPIP/VXLAN 封装，改用纯三层路由。这意味着你的底层网络必须支持跨子网通信。如果你是在私有云或裸金属环境，一般没问题；但如果是在某些受限的公有云环境中，可能就得妥协回 IPIP 模式了。

🛠️ 调试技巧 ：
如何判断当前 Calico 是否启用了 BGP？可以用这条命令：

bash calicoctl node status

如果输出中有 Established 状态的邻居关系，说明 BGP 已成功建立；如果是 Active 或 Idle ，那就得去查 bird 日志了。

---

容器网络命名空间与 veth pair 工作机制

前面我们提到，每个 Pod 都有自己的 IP 和端口空间。这是怎么做到的？答案是： Linux 网络命名空间（network namespace） 。

你可以把它理解为一个独立的“网络宇宙”，里面有自己的一套网卡、路由表、防火墙规则……和其他命名空间完全隔离。

当 kubelet 创建 Pod 时，它会为容器创建一个新的 netns，并通过一对虚拟网卡（veth pair）连接到宿主机的主网络空间。

这对网卡就像一根网线的两头：
- 一头在 Pod 的 netns 里，显示为 eth0 ；
- 另一头在宿主机上，显示为 vethxxxxxx （随机后缀）；

数据包从 Pod 发出后，先经过 eth0 ，穿过 veth pair，进入宿主机网络栈，然后根据路由决定下一步走向。

我们可以通过命令来观察这一过程：

# 列出所有网络命名空间
ip netns list

# 进入某个命名空间执行命令
ip netns exec netns-1 ip addr show

# 查看 veth 设备列表
ls /sys/devices/virtual/net/

创建 veth pair 的完整流程如下：

# 创建一对虚拟网卡
ip link add veth-host type veth peer name veth-pod

# 将 veth-pod 移入命名空间
ip link set veth-pod netns netns-1

# 配置宿主机端
ip addr add 10.244.1.1/24 dev veth-host
ip link set veth-host up

# 在命名空间内配置容器端
ip netns exec netns-1 ip addr add 10.244.1.10/24 dev veth-pod
ip netns exec netns-1 ip link set veth-pod up
ip netns exec netns-1 ip link set lo up

逐行解读：
- ip link add ... peer ：创建一对互连的虚拟网卡；
- set ... netns ：将其中一端移入指定命名空间；
- addr add ：为接口分配 IP；
- link set up ：激活接口。

这套机制是所有 CNI 插件的基础。Flannel、Calico 都是在此基础上叠加隧道或策略控制。因此，一旦出现“容器无法联网”的问题，首先要怀疑的就是 veth pair 是否正确建立。

🔍 典型故障排查思路 ：

1. 检查 Pod 是否处于 CrashLoopBackOff 状态？
2. 进入节点执行 ip link | grep veth ，看有没有对应设备；
3. 执行 ip netns list ，确认命名空间是否存在；
4. 若设备存在但无 IP，可能是 IPAM 分配失败；
5. 若设备不存在，大概率是 CNI 插件未正确触发 ADD 流程。

---

网络性能调优：MTU 设置与中断合并

在高并发、大数据量的生产环境中，哪怕一点点网络延迟都会被放大成严重的性能瓶颈。这时候，就需要进行精细化的网络调优。

有两个关键参数不容忽视： MTU 和 NIC 中断合并 。

MTU 设置：避免 TCP 分片

MTU（Maximum Transmission Unit）表示单个数据包的最大尺寸。标准以太网 MTU 是 1500 字节。但在 VXLAN 封装环境下，由于增加了 50 字节的头部（IP + UDP + VXLAN），实际可用 MTU 只有 1450。

如果不调整，就会导致 TCP 层被迫分片，严重影响传输效率。

解决方法很简单：统一设置 CNI 插件的 MTU 值。例如在 Calico 配置中加入：

"mtu": 1450

然后重启所有节点上的 calico-node DaemonSet，让新 Pod 生效。

如何验证是否成功？可以用 ping 测试路径 MTU：

ping -M do -s 1472 10.244.2.10

解释参数：
- -M do ：禁止分片（do not fragment）
- -s 1472 ：ICMP 数据部分大小
- 加上 20 字节 IP 头 + 8 字节 ICMP 头 = 1500

如果返回 Packet needs to be fragmented but DF set ，说明路径 MTU 小于 1500，需要进一步排查。

💡 经验法则 ：
对于使用 VXLAN 的集群，推荐将 Pod 接口 MTU 设为 1450；
对于 BGP/host-gw 模式，可保持 1500；
对于使用 Geneve 的 Cilium 用户，建议设为 1450~1400 之间。

NIC 中断合并：平衡延迟与 CPU 占用

另一个常被忽视的点是网卡中断频率。每当收到一个数据包，网卡就会向 CPU 发送中断信号。在高吞吐场景下，这种频繁的中断会导致 CPU 被大量软中断占用，影响业务处理。

解决方案是启用 中断合并（Interrupt Coalescing） ，即让网卡累积一定数量的数据包后再上报一次中断。

使用 ethtool 可以查看和设置：

# 查看当前设置
ethtool -c eth0

# 启用中断合并
ethtool -C eth0 rx-usecs 30 tx-usecs 30

常用参数说明：

参数	说明	推荐值
rx-usecs	接收中断延迟（微秒）	30–100
tx-usecs	发送中断延迟	30–100
rx-frames	批量处理帧数	5–20

注意：调得太高会增加延迟，太低又起不到降载作用。对于低延迟交易系统，建议关闭中断合并；而对于视频流、大数据迁移类应用，适当调高反而能提升整体吞吐。

📈 真实案例分享 ：
某客户在使用 Flannel VXLAN 模式时，发现 Kafka Producer 的吞吐始终上不去。经过抓包分析，发现大量小包导致 CPU 软中断飙升至 30%+。后来启用了中断合并并将 MTU 调整为 1450，CPU 占比降至 8%，吞吐翻倍！🎉

---

故障排查：Pod 间通信失败诊断流程

最后，我们来总结一套系统的故障排查方法论。当你遇到“Pod 之间 ping 不通”这类问题时，不要慌，按照以下步骤一步步来 👇：

第一步：确认 Pod 状态与 IP 分配

kubectl get pod -o wide

检查：
- Pod 是否处于 Running 状态？
- IP 是否非 <none> ？
- 所在节点是否正常？

如果 IP 是空的，说明 CNI 插件根本没有完成 ADD 阶段，优先去看 calico-node 或 flannel 的日志。

第二步：检查 CNI 插件日志

kubectl logs -n kube-system calico-node-xxxxx

重点关注：
- 是否报错连接 etcd？
- 是否提示 IP 冲突？
- 是否反复重启？

第三步：验证本地路由表

ip route show | grep 10.244

确保本节点知道其他 Pod CIDR 的下一跳地址。如果没有相关路由，说明 CNI 控制平面未同步成功。

第四步：测试跨节点连通性

进入源 Pod 执行：

ping <目标 Pod IP>
traceroute <目标 Pod IP>

如果能 ping 通同节点 Pod，但跨节点不行，基本可以锁定是 VXLAN/BGP 问题。

第五步：检查防火墙规则

iptables -L -n | grep 8472  # VXLAN 端口

确保节点间的 8472 UDP 端口是开放的。很多企业防火墙默认会封掉这个端口！

第六步：查看 FDB 表项

bridge fdb show | grep <对端节点 IP>

如果没有对应的 MAC 条目，说明 VXLAN 隧道未建立，可能是 flanneld 没有正确广播路由。

---

综合以上六步，90% 以上的 Pod 通信问题都能定位清楚。建议在生产环境部署自动化探针，定期检测关键路径的连通性和延迟，真正做到防患于未然。

---

Service 网络与 kube-proxy 工作机制

如果说 Pod 是城市的居民，那么 Service 就是公共服务机构——它提供了一个稳定的入口地址（ClusterIP），不管背后有多少 Pod 在轮换，对外暴露的 IP 和端口始终不变。

而这背后的功臣，就是 kube-proxy 。它运行在每个节点上，像个勤劳的交警，时刻监听着 Service 和 Endpoint 的变化，并动态更新 iptables 或 ipvs 规则，确保流量能正确转发。

目前主流有两种模式： iptables 和 ipvs 。

iptables 模式：规则链与负载均衡实现

在早期版本中，kube-proxy 默认使用 iptables 模式。它通过一系列精心编排的规则链，实现负载均衡。

比如你创建这样一个 Service：

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

kube-proxy 会在每个节点上生成如下规则：

iptables -t nat -L KUBE-SERVICES

输出片段可能包含：

KUBE-SVC-XXXXXX  tcp  --  0.0.0.0/0  10.96.1.10  tcp dpt:80

这条规则匹配访问 ClusterIP 10.96.1.10:80 的流量，跳转到 KUBE-SVC-XXXXXX 链。

继续查看该链：

iptables -t nat -L KUBE-SVC-XXXXXX

你会看到类似这样的内容：

KUBE-SEP-ABC123  all  --  0.0.0.0/0  0.0.0.0/0  /* nginx-svc */ statistic mode random probability 0.33333333349
KUBE-SEP-DEF456  all  --  0.0.0.0/0  0.0.0.0/0  /* nginx-svc */ statistic mode random probability 0.50000000000
KUBE-SEP-GHI789  all  --  0.0.0.0/0  0.0.0.0/0  /* nginx-svc */

这里的 statistic mode random 实现了随机负载均衡。每个 KUBE-SEP- 链对应一个后端 Pod，通过 DNAT 完成地址转换：

iptables -t nat -L KUBE-SEP-ABC123

输出：

DNAT       tcp  --  0.0.0.0/0  0.0.0.0/0  tcp to:10.244.1.10:80

也就是说，原本发给 10.96.1.10:80 的请求，被悄悄改成了 10.244.1.10:80 ，然后交给内核路由模块处理。

⚠️ 性能瓶颈警告 ：
iptables 是线性匹配机制，每新增一条规则都要遍历整个链。当集群中有上千个 Service 时，规则总数可达数万条，导致匹配延迟升高，甚至引发 conntrack 表溢出，造成连接丢失！

所以，大规模集群强烈建议切换到 ipvs 模式 。

---

ipvs 模式：高性能负载均衡实现

ipvs（IP Virtual Server）是 Linux 内核内置的负载均衡模块，性能远超 iptables。它基于哈希表查找，时间复杂度 O(1)，即使有几万个 Service 也能轻松应对。

启用方式也很简单，修改 kube-proxy 配置：

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  scheduler: "wrr"
  excludeCIDRs:
    - "10.0.0.0/8"

部署后，使用 ipvsadm 查看虚拟服务器：

ipvsadm -ln

输出示例：

TCP  10.96.1.10:80 wrr
  -> 10.244.1.10:80           Masq    1      0          0
  -> 10.244.1.11:80           Masq    1      0          0
  -> 10.244.1.12:80           Masq    1      0          0

可以看到：
- 调度算法是 wrr （加权轮询）；
- 后端 Real Server 是三个 Pod IP；
- 转发模式是 Masq （NAT）；

优势非常明显：
- 支持多种调度算法（rr、wrr、lc、dh 等）；
- 支持连接重用，减少新建连接开销；
- 提供更细粒度的健康检查机制；
- 几乎不影响 CPU 性能。

唯一需要注意的是，必须确保节点加载了必要的内核模块：

modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr

否则 kube-proxy 会自动降级回 iptables 模式，你就白忙活了 😅。

---

Service 类型与外部访问机制

除了内部通信，我们还需要考虑如何让外部访问服务。Kubernetes 提供了四种类型：

类型	用途	实现方式
ClusterIP	集群内部访问	虚拟 IP + iptables/ipvs
NodePort	节点端口暴露	在每个节点开放 30000–32767 端口
LoadBalancer	云厂商负载均衡	调用云 API 创建 ELB 并绑定节点
ExternalName	外部 DNS 映射	返回 CNAME 记录

以 NodePort 为例：

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

访问路径为： <NodeIP>:30080 → kube-proxy → Pod。

🔥 安全建议 ：
尽量不要直接使用 NodePort 暴露服务！因为它会打开所有节点的端口，攻击面太大。推荐结合 Ingress Controller 使用，集中管理南北向流量。

---

DNS 服务与服务发现机制

在一个动态变化的环境中，硬编码 IP 显然是不可接受的。Kubernetes 使用 CoreDNS 实现服务发现。

每个 Service 都会自动生成 DNS 记录，格式为：

<service>.<namespace>.svc.cluster.local

例如， nginx-svc.default.svc.cluster.local 。

CoreDNS 配置如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        forward . /etc/resolv.conf
        cache 30
    }

关键点：
- kubernetes 插件监听 API Server，自动生成 DNS 记录；
- forward 将外部域名查询转发给上游 DNS；
- cache 30 缓存 30 秒，减轻压力；

Pod 内可通过 nslookup 测试：

nslookup nginx-svc

如果解析失败，优先检查：
- CoreDNS Pod 是否运行正常？
- kube-dns Service 是否存在？
- Pod 的 /etc/resolv.conf 是否正确指向 10.96.0.10 ？

---

网络策略与安全隔离

最后，谈谈安全。默认情况下，Kubernetes 网络是全通的。为了实现微隔离，我们需要使用 NetworkPolicy 。

示例策略：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              project: trusted
      ports:
        - protocol: TCP
          port: 80

这条策略的意思是：只有标签为 project: trusted 的命名空间，才能访问带有 app: web 标签的 Pod 的 80 端口。

❗ 注意：NetworkPolicy 需要 CNI 插件支持！Flannel 原生不支持，必须搭配 kube-router 或改用 Calico/Cilium。

---

这种高度集成的设计思路，正引领着智能音频设备向更可靠、更高效的方向演进。