容器 22：两个隔离进程怎样通过 veth 通信
从内核对象推导路径
让进程 A、B 分别进入两个 netns：每一侧起初可只看到自己的 loopback 设备；需先把 lo 置 up，建立 veth 对，把两个端点分别放入 netns，给接口分配互通地址与路由，确认 ARP/邻居条目及链路状态，再用同一 probe_app.py 的 /health 观测端到端访问。对同一网段的直连流量，veth 负责把一端送出的二层帧交给另一端；想连第三个网段需路由/网关，不是再加一个 curl 就能自动到达。IP 地址和监听地址各有作用：只监听 127.0.0.1 的服务不会因 veth 配通而自动变得可从另一 netns 访问。
本云端可以安全调用 unshare -Ur -n；原始记录显示新 netns inode net:[4026532574] 与原来 net:[4026531994] 不同，新视图只列出 lo，进程退出后原 namespace inode 不变。这是“视图可以分离”的 LAB_VERIFIED，不是“veth 已连通”。这里缺 ip 工具与专用网络实验 VM，尚未创建/抓包两个 netns、veth、地址和路由；完整通信验收 NOT_RUN。复跑入口与清理和统一源码包保留路径，不改共享宿主默认网络。先前网络 33的静态模型不能代替这次真实连通数据。
反例可在 VM 先只建 veth 而不配地址，观察链路对象存在但请求仍失败；再只让服务监听 127.0.0.1，对比同 netns 和异 netns 访问结果。失败阶段应分别保留接口状态、路由、监听 socket、抓包和 HTTP 返回，不能一口断定为 CNI 的问题。
| 现象 | 对象 | 限定条件 |
|---|---|---|
| netns inode 不同 | /proc/<pid>/ns/net |
不证明已有 veth |
| ping 通但服务失败 | socket 监听与端口 | 传输层以上另核查 |
| 无地址时链路存在 | veth 端点及路由 | veth 不分配 IP |
练习
- 先预测只建立 veth 对、不配地址时两个进程能否互相 HTTP 请求；专用 VM 按步骤逐项补齐并抓包定位第一次成功的条件。
- 预测 A 监听
127.0.0.1与0.0.0.0时 B 的访问差异；在两个自建 netns 用相同探针记录监听地址、请求目标与日志。
上一篇：21：停止与日志；下一篇：23：bridge、端口、DNS。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 24：CNI 接口由谁调用，失败怎样回收
手工执行22 的 ip 命令可以构造连通路径，但节点运行时还要重复地给新进程挂接网络，并在失败时回收地址、设备与路由。CNI 规范定义调用方与插件之间的配置、输入环境、输出和操作接口，不是一个指定必须使用 bridge 或 VXLAN 的数据面。 把意图、调用、对象串起来 调用方给插件网络配置、容器 ID、netns 路径和接口名，执行 ADD；插件/链式配置可能交给 IPAM 分配地址并创建 veth、bridge 连接、路由，再返回地址和接口信息。CHECK 用于适用版本的状态核对；DEL 释放自己创建的网络资源。命令成功也不能单独证明业务连通，应该把输出配置的 IP 对应到 namespace inode、内核网络对象及一次真实请求。各操作的幂等、失败恢复前提需要对选定插件的固定版本源码再验证，不对所有插件宣称绝对原子。 正常实验必须在专用 VM 固定 CNI spec、插件和 IPAM 版本，先建两个自有 netns，逐个执行 ADD/CHECK/DEL，前后读取 veth、地址租约、路由；异常例故意使第二步失败，再调用 DEL 并确认设备与 IP 真正释放，二次执行结果...
2026-10-01
容器 23：bridge、端口发布和 DNS 各在哪一跳
22 的 veth只是一段二层链路；把几段 veth 的宿主侧接进 bridge 才可能形成一个二层转发域。外部从宿主端口进入、容器把名字解析成地址、应用真正监听到这个地址，又是不同的链路步骤。不能看到 `docker -p` 就把 DNS、路由、NAT 都说成“bridge 干的”。 两条访问路径要分开画 对同一 bridge 子网中两个端点，发送方按照目标 IP/路由挑下一跳，经 veth 到宿主 bridge，再依据二层目的 MAC 转发。对宿主公开端口，请求的原始目标是宿主 IP:端口；具体实现可通过 NAT/代理把流量送入容器 IP:端口，需要核对当时的规则和 conntrack 元组，不能把容器 IP:端口的直连记录冒充端口发布记录。DNS 把名字变成地址，解析成功后仍可能因服务只在 loopback 监听、规则丢包或目标端口未打开而失败。 专用 VM 正例应给同一个 probe-app 分别测试“容器 IP 直连”“宿主发布端口”“名字解析后访问”，记录请求前后源/目的元组、路由、conntrack 与 DNS 结果。三个反例依次让探针只监听 127.0.0.1、让...
2026-06-20
Service 与 kube-proxy：虚拟 IP、iptables 与 IPVS
Service 的 ClusterIP 是一个不存在于任何网卡的虚拟 IP。在节点上运行 ip addr，看不到它；用 ping 测试，收不到回应；但对它发起 TCP 连接，数据却能稳定到达某个后端 Pod。这个"幽灵 IP"能够工作，完全依赖 kube-proxy 写入每个节点内核的 iptables 或 IPVS 规则——规则在，转发在；规则消失，连接消失。 理解这一机制的起点是区分两种截然不同的角色：kube-proxy 是"规则维护者"，内核的 netfilter/IPVS 子系统才是"数据面执行者"。kube-proxy 进程本身从不处理任何用户请求，它只监听 kube-apiserver 上 Service 和 EndpointSlice 的变化，把这些变化翻译成内核规则，然后等待下一次变化。真正处理数据包的是内核——每个到达某 ClusterIP:port 的数据包，在经过 iptables nat 表的 PREROUTING 链时，被 DNAT 规则改写目标地址，转向某个真实的 Pod IP:port，整...
2026-06-20
Ingress 与 Gateway API：七层流量的入口演进
Service 把集群内部的流量调度问题解决了，但把服务暴露到集群外部的 HTTP/HTTPS 流量需要另一层抽象。NodePort 和 LoadBalancer 都在四层工作——它们能把外部 TCP 流量转发进来，但无法根据 HTTP 的 Host 头或 URL 路径做路由决策，也无法终止 TLS、做 URL 重写、实现金丝雀发布。Ingress 就是 Kubernetes 为七层 HTTP 路由设计的原生对象，它在 1.1 版本进入 alpha，1.19 版本 GA，至今仍是绝大多数集群的 HTTP 入口方案。 Ingress 的设计在简单场景里非常直观：声明哪个 host + 哪个路径对应哪个 Service，TLS 证书放在 Secret 里引用，一个 Controller（Nginx、Traefik、HAProxy 等）负责把这些规则翻译成实际的反向代理配置。这套模型在业务不复杂时运作良好，但当需要金丝雀发布、基于请求头的路由、跨命名空间的服务暴露、gRPC 原生路由时，规范本身的表达能力不够，各家 Controller 用 annotation 扩展——结果是注解的命...
2026-10-01
容器 25：跨主机路径为什么会出现小包通大包失败
24在一台节点内创建接口与地址；两台宿主是否互通还取决于 underlay 路由和封装路径。把 Pod IP “看着在同一个网段”当成两台物理宿主共享一个二层网络的证据，容易在 MTU 边界上失败。VXLAN 等 overlay 会增加外层头部，同样的应用报文占用更多 underlay 字节，但具体开销依 IP 家族与报文头选项而变，不能在未抓包时抄一个固定减数。 两端都要记录 直路由路径要使两端宿主知道对端 Pod 子网经哪个下一跳到达；封装路径则由 overlay 端点把内层包封装为外层 UDP/IP，并靠 underlay 递送到另一端。无论哪种，先在两台独立 VM 固定 IP、路由表、接口 MTU 和过滤规则，双端抓包，再逐次提高自建探针请求负载的报文大小。若小包成功、大包失败，比较内层 DF/分片、外层包长、ICMP Packet Too Big 和 PMTU 发现，不能只说“网络不稳定”。 正常例应验证小包与不超过路径 MTU 的大包均到达；边界例将受控 overlay 接口 MTU 配错，使请求在确定阈值附近失败，再调整仅属于实验的配置并复核双端结果。计时与丢包只报...
2026-06-20
网络模型与 CNI：每个 Pod 一个 IP 背后的实现
Kubernetes 对网络做出了一个看似简单的承诺：每个 Pod 拥有一个集群范围内唯一的可路由 IP，Pod 之间无需 NAT 可直接通信，节点访问 Pod 也无需 NAT。三条规则，没有一条涉及实现细节。这种"定义行为、不定义机制"的风格与 Kubernetes 整体的设计哲学一致，但也意味着没有任何一行核心代码实现了这个承诺——它完全由 CNI 插件负责兑现。 理解 CNI 的切入点不是插件本身，而是 Linux 网络命名空间带来的问题。每个容器拥有独立的网络栈，包含独立的路由表、ARP 缓存、iptables 规则集。新建的命名空间里只有一个回环接口 lo，对外完全不可达——这正是容器隔离的本意。CNI 插件的全部工作就是在这种隔离性上凿出一条通道：创建 veth pair，把一端移入 Pod 命名空间，另一端挂到宿主机网桥，配置 IP 地址和路由，让 Pod 从完全隔离的孤岛变成集群网络里的一个节点。 跨节点通信是第二层复杂性。同节点内的 Pod 通过共享网桥即可互通，但当数据包需要离开宿主机的物理网卡，穿越真实的交换机和路由器，抵达另一台节点，再...