📚 课程目录第3章 Kubernetes网络基础

3. Kubernetes 网络模型：Pod网络、Service网络、Ingress与Gateway API

Kubernetes 网络模型是云原生应用交付的基石。在生产窗口内进行 tc 回滚验证时，理解 Pod、Service、Ingress 及 Gateway API 各层的网络拓扑与数据流转，是精准定位故障、制定回滚策略的前提。本章从四层网络模型出发，剖析其核心原理与生产实践要点。

3.1 Pod 网络：扁平 IP 与容器间通信

Kubernetes 要求每个 Pod 拥有独立的、集群内可路由的 IP 地址，且 Pod 内所有容器共享该 IP 和网络命名空间。这一设计消除了端口映射的复杂性，使得 Pod 可以被视为一台独立的“逻辑主机”。

特性	说明	生产影响
每个 Pod 一个 IP	CNI 插件（如 Calico、Flannel、Cilium）为每个 Pod 分配集群内唯一 IP	IP 地址规划需考虑集群规模，避免 CIDR 重叠
容器间通信	Pod 内多个容器通过 localhost 直接通信，共享网络栈	sidecar 模式（如 Istio）依赖此特性实现流量拦截
Pod 间通信	无需 NAT，直接通过 Pod IP 跨节点通信	底层依赖路由表或 Overlay 隧道，延迟与带宽需监控
网络策略	通过 NetworkPolicy 实现 Pod 粒度的南北向/东西向流量控制	回滚时需确认策略是否影响新 Pod 的启动探测

生产窗口回滚提示： 当使用 tc 模拟 Pod 网络延迟或丢包时，应优先针对目标 Pod 的 eth0 接口注入规则。回滚操作需确保 tc qdisc del 命令精确匹配注入时的父类编号，避免误删集群关键网络路径。

3.2 Service 网络：抽象与负载均衡

Service 为后端 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称，实现服务发现与流量分发。其核心组件是 kube-proxy，支持三种代理模式：userspace、iptables、IPVS。

ClusterIP： 默认类型，仅在集群内部可达，通过 iptables/IPVS 规则将流量转发到后端 Pod。
NodePort： 在每个节点上开放静态端口，外部流量通过 <NodeIP>:<NodePort> 进入。
LoadBalancer： 云厂商或自建 LB 集成，将外部流量导入 NodePort 或直接转发到 Pod。
Headless Service： 无 ClusterIP，直接返回后端 Pod IP 列表，适用于 StatefulSet 有状态应用。

  关键指标： Service 的 sessionAffinity 和 externalTrafficPolicy 直接影响回滚期间的流量分布。例如，externalTrafficPolicy: Local 会保留客户端源 IP，但可能导致负载不均，回滚时需评估后端 Pod 的 Drain 策略。

3.3 Ingress：七层路由与 TLS 终结

Ingress 是 Kubernetes 原生的七层流量入口，通过 Ingress Controller（如 Nginx、Traefik、HAProxy）实现 HTTP/HTTPS 路由、TLS 终结、虚拟主机和路径转发。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: production-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

回滚风险点： Ingress 的 canary 注解（如 nginx.ingress.kubernetes.io/canary）在灰度发布时非常有用，但回滚时若未及时移除，可能导致新旧版本流量同时被路由，引发数据不一致。建议在回滚脚本中显式删除或重置 canary 规则。

3.4 Gateway API：下一代流量管理

Gateway API 是 Kubernetes 社区推出的新一代网络 API，旨在替代 Ingress，提供更丰富的路由语义、跨命名空间支持和角色分离。其核心资源包括：GatewayClass、Gateway、HTTPRoute、TCPRoute 等。

对比维度	Ingress (v1)	Gateway API
资源模型	单一资源，耦合路由与配置	分层资源：GatewayClass → Gateway → Route
跨命名空间	不支持（需额外 CRD）	原生支持，通过 ReferenceGrant 授权
协议支持	HTTP/HTTPS 为主	HTTP、HTTPS、TCP、UDP、gRPC 等
流量拆分	依赖注解（如 canary）	原生支持权重、Header、Query 参数匹配
角色分离	集群管理员与开发者共用	基础设施提供商、集群管理员、开发者职责清晰

生产窗口回滚优势： Gateway API 的 HTTPRoute 支持 matches 和 filters 字段，可以在不修改 Service 的前提下，通过调整路由权重或添加 RequestMirror 过滤器，实现精细化的流量回滚验证，避免直接操作底层 tc 规则。

3.5 四层网络拓扑总览

下图展示了从外部客户端到 Pod 容器的完整网络路径，涵盖 Ingress/Gateway、Service 和 Pod 网络三层抽象。

3.6 生产窗口 tc 回滚与网络模型的关系

在 Helm 应用交付的生产窗口内，tc 回滚验证通常针对以下网络层级进行故障注入：

Pod 网络层： 使用 tc qdisc add dev eth0 root netem delay 100ms 模拟 Pod 间通信延迟，验证应用超时重试机制。
Service 网络层： 通过修改 kube-proxy 的 iptables 规则或直接操作 Service 的 EndpointSlice，模拟后端 Pod 不可用。
Ingress/Gateway 层： 调整路由权重或添加 RequestMirror 过滤器，将部分流量导向回滚版本，验证新版本稳定性。

  最佳实践： 回滚验证应遵循“从外到内”的逐层隔离原则。先验证 Ingress/Gateway 层的路由切换，再验证 Service 层的负载均衡，最后验证 Pod 网络层的连通性。每层验证通过后，再执行下一层的 tc 规则清理，避免级联故障。

3.7 网络策略与安全组在回滚中的影响

NetworkPolicy 和云平台安全组（Security Group）在回滚期间可能成为隐形的流量屏障。当回滚后的 Pod 被调度到新节点时，若 NetworkPolicy 的 podSelector 或 namespaceSelector 未及时更新，可能导致健康检查失败。

# 回滚前确认 NetworkPolicy 是否覆盖新 Pod 的标签
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-access
spec:
  podSelector:
    matchLabels:
      app: api
      version: v2  # 回滚到 v1 时，此标签需同步修改
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

常见陷阱： 回滚脚本中若只更新 Deployment 的镜像版本，而忽略 NetworkPolicy 的标签匹配，会导致新 Pod 无法被前端访问。建议在 Helm Chart 中将版本标签作为 values 参数，回滚时一并渲染。

3.8 总结：网络模型对 tc 回滚验证的指导意义

Kubernetes 的四层网络模型为生产窗口内的 tc 回滚验证提供了清晰的故障注入边界。Pod 网络层适合验证容器间通信的韧性；Service 网络层适合验证负载均衡与故障转移；Ingress/Gateway 层适合验证七层路由与灰度发布。理解每一层的抽象与实现，能够帮助 SRE 在回滚时精准定位问题，避免盲目操作。