第5章 被世界找到：Service与网络入口

第5章 被世界找到：Service 与网络入口

章节摘要：本章跟着一条线走——一个用户请求从公网抵达集群，穿过 Ingress 的七层分发、Service 的四层转发、端点名单的筛选，最终落到某个就绪的 orders-api 副本上；反向还有一条线，是 NetworkPolicy 决定哪些流量根本不许进门。Pod 会死会建、IP 随之漂移，本章讲的全部机制都在回答同一个问题：怎样给一组漂移的副本一个稳定的访问面。

一条主线

第4章让副本守恒、版本可演进，但也带来一个被推迟到现在的问题：每次滚动更新、每次副本重建，Pod 的 IP 都在换。上游服务或用户如果直连 Pod IP，等于把地址簿建在流沙上。本章的主线就是给漂移的副本群体加三层稳定结构：

• Service：一个稳定的虚拟 IP 加端口，背后动态映射到"就绪且带指定标签"的 Pod 集合；
• Ingress：在 Service 之上再立一层七层入口，按域名与路径把请求分给不同 Service，并终结 TLS；
• NetworkPolicy：从相反方向画围墙，声明谁可以和谁通信，把"默认全网互通"收紧到最小必要面。

从请求视角看，这是一条从外到内的纵深；从声明视角看，这是三份互相配合的新 YAML。

图 5-1：一次请求的三级入口纵览

沿途站点

本章三节，对应访问面的三块拼图：

• 5.1 Service：Pod 消亡之后的稳定入口：虚拟 IP 如何与标签选中的 Pod 动态联动、四种 Service 类型的取舍、以及端点名单随探针伸缩的机制。
• 5.2 Ingress：七层流量的总入口：域名与路径路由、TLS 终结、Ingress 控制器的角色，以及与 Service 的分工边界。
• 5.3 NetworkPolicy：给声明砌一道网络围墙：以命名空间和标签为坐标，用入向与出向规则收紧东西向流量，把默认互通改成最小必要。

三节合起来覆盖南北向（进出的流量）与东西向（内部互访）两个维度。学完后你可以为一个多服务系统设计完整的访问面：谁从哪进、进到哪层、内部谁可以访问谁。

拐点与结论

本章的认知拐点在 5.1 中段：Service 不是代理进程，而是一条由 kube-proxy 在每台节点上维护的转发规则——没有哪个中心组件替你转发流量，规则分散在每个节点上，这就是 Service 的虚拟 IP 从不漂移、也不单点故障的原因。第二个拐点在 5.3：NetworkPolicy 由 CNI 插件执行，装了不支持策略的 CNI，声明会被安静地接受但绝不生效——安静失败比报错更值得提防。

结论一句话：稳定的访问面不是靠某个长寿组件撑住的，而是靠"标签选中的动态规则"持续重建的。声明又一次战胜了实体。

读完你应该

• 解释 ClusterIP、NodePort、LoadBalancer、headless 四类 Service 的适用场景与代价；
• 写出 selector 到端点名单的完整链路，并用命令核对名单与健康副本一致；
• 说出 kube-proxy 的三种工作模式差异与选型建议；
• 写出多域名多路径的 Ingress 声明并配置 TLS 终结；
• 设计默认拒绝加白名单的 NetworkPolicy，并验证规则确实生效。

下一章的接力

流量有了稳定的门牌，但请求进来之后，容器里的进程还需要两样补给：运行时的配置（数据库地址、开关、证书）与可持久化的数据卷。第6章讲 ConfigMap、Secret 与从 Volume 到 PVC 的存储申领制度——声明的最后两块拼图。