4.2 Pod网络与DNS：地下的根系

4.2 Pod 网络与 DNS：地下的根系

本节摘要：Kubernetes 网络模型的核心约定是扁平互通：每株苗有全集群唯一的 IP，任意两株苗不经地址转换即可互访。CNI 插件负责让这个约定落地，集群内建的 DNS 服务把 Service 名字解析成虚拟 IP，使服务互访彻底摆脱硬编码地址。本节验证根系的两项能力：Pod 直连与 DNS 解析，并给出跨田访问的命名规则。

一条铁律：所有苗彼此直通

Kubernetes 对网络只立了一条宪法级的约定：每株苗（Pod）拿到集群内唯一的 IP，用这个 IP 与任何其他苗直接通信，中间不做网络地址转换。不管两株苗长在同一节点还是不同节点，也不管节点分属哪个机房网段，从苗的视角看，整个集群是一张扁平的大网。

这条约定看似简单，落地并不容易：不同节点上的苗要能互访，就得有人在节点之间修隧道或路由，给每株苗发的 IP 还不能重复。干这活的是 CNI（容器网络接口）插件——Calico、Flannel、Cilium 这些名字你以后会常遇到。它们是地下根系的施工队，按同一份接口规范施工，效果对苗完全透明。入门阶段不必深究各家差异，只需知道：换不同的施工队，苗的网络体验不变，这就是接口规范的意义。

根系的另一项本事：会认名字

扁平网络解决了"通不通"，没解决"怎么找"。上一节那条验证命令里用的长名字（greenlib-web.greenlib-prod.svc.cluster.local）就是答案的预告：集群里有一个内建的 DNS 服务，它为每个 Service 登记名字。于是服务互访的最终形态是：调用方记服务名，DNS 换成虚拟 IP，水闸分流到苗。

名字的拼法有讲究，一张表说清：

规则读一遍就懂：服务名加点加田名（再加标准后缀）。同田内可以省掉田名，但跨田必须带田名——这也再次印证 3.3 的结论：田是名字的边界。生产建议一律写至少两级（服务名加田名），免得清单挪个田就悄悄解析到别处。

动手验证根系：

# 起一个临时探测苗，进去看看它眼里的世界
kubectl run dns-probe --rm -it --image=busybox:1.36 --restart=Never -n greenlib-prod -- sh
# 进入后执行：
nslookup greenlib-web
# Server:    10.96.0.10                集群内建 DNS 的地址
# Address 1: 10.96.12.40 greenlib-web.greenlib-prod.svc.cluster.local
# 短名解析成功，返回的正是水闸的虚拟 IP

nslookup greenlib-web.default
# nslookup: can't resolve 'greenlib-web.default'
# 拼错田名（水闸在 greenlib-prod 田）就查无此名：田是名字边界

nslookup 10.24.0.31
# Address 1: 10.24.0.31    （反向解析通常无记录，苗的 IP 不进 DNS）
​

# 再验证苗与苗的直通（flat network）
ping -c 2 10.24.1.17
# 64 bytes from 10.24.1.17: seq=0 ttl=62 time=0.413 ms
# 64 bytes from 10.24.1.17: seq=1 ttl=62 time=0.390 ms
# 不同节点上的苗，直接按 IP 互通，没有中间转换

exit
# pod "dns-probe" deleted（--rm 会在退出后自动清掉临时苗）
​

DNS 背后站着谁

值得多问一句：DNS 服务自己也是个苗，凭什么它知道所有水闸的地址？机制依旧是我们熟悉的 watch：DNS 服务（通常是 CoreDNS）监听台账里 Service 的变化，新建闸就登记名字，删闸就注销。它不是被通知的，是自己盯账盯出来的——这句话在第二章之后应当已不让你惊讶。整个集群里"谁发现变化、谁采取行动"的答案永远是同一个：watch 加控制循环。

名字解析还有个静默的坑要交代：只有 Service 名进 DNS，苗（Pod）的 IP 不进（个别场景有 hostname 记录，入门用不到）。所以代码里绝不该出现"解析某个具体 Pod"的写法，要找苗永远先找闸。这个设计把"不稳定的东西"彻底挡在了名字系统之外。

图：一次跨田调用在根系里的旅程

图中虚线的意思是：CNI 施工队不参与"找路"的决策，只保证水管本身通着。认路靠 DNS，分水靠 Service，通水靠 CNI，三者各管一段，合起来就是集群内部的全部网络日常。

💡 一个值得养成的工程习惯：应用配置里写服务名（至少两级），不写任何 IP。书屋的接口服务连数据库，配置里写的就是 greenlib-db.greenlib-prod，将来数据库搬家换苗，这份配置一个字都不用改。第 5 章会把这类配置收进 ConfigMap 统一管理。

网络策略：苗之间的门禁

扁平互通是默认态，但生产常需要"接口苗只能被网页苗访问、数据库苗只能被接口苗访问"。这类隔离由网络策略对象实现，由 CNI 插件负责执行，相当于给苗与苗之间也装了门禁。本册不展开操作，但边界认知必须有：Namespace 不隔离网络，网络策略才隔离。第八章的 RBAC 管的是"人动台账"的权限，网络策略管的是"苗互访"的权限，两套门禁各管一门。

本节要点回顾

• 扁平互通是集群网络唯一宪法：苗 IP 全集群唯一、互访不经转换
• CNI 插件是根系施工队，按接口规范施工，可替换且对苗透明
• DNS 只登记 Service 名：服务名加田名是推荐拼法，田是名字的边界
• 临时探测苗（run 加 rm 加 it）是验证网络的趁手工具，用完即走
• 认路靠 DNS、分水靠 Service、通水靠 CNI——三段分工不混淆