📚 课程目录第4章集群网络生产实践

4. 集群网络生产实践

Kubernetes 集群网络是生产环境中最容易“上线时能用、扩容后失控”的一层。它同时承载三类流量：Pod 之间的东西向流量、Pod 访问外部服务的南北向流量，以及外部用户访问 Service/Ingress 的入口流量。本节围绕 CNI 选型、地址规划、网络策略、跨节点性能与负载均衡接入五个方面，给出可落地的工程判断。

一、CNI 插件选型：先定模式，再定实现

CNI 插件决定 Pod 如何获得 IP、如何跨节点转发。生产上先判断是否需要 Overlay 封装：若节点在同一 VPC 子网且可分配足够 Pod IP，优先选 Underlay/路由型（如 Calico 的 BGP 模式、Cilium 的 native routing），转发路径短、无封装开销；若节点跨子网、跨可用区或云平台限制路由条目数量，则选 Overlay（VXLAN/Geneve），用封装换取地址独立性。

选型时重点核对四项能力：是否支持 NetworkPolicy（含 egress）、是否提供可观测性（流日志、Hubble 类工具）、数据面是否支持 eBPF 以降低 kube-proxy 依赖、以及大规模下的 IPAM 与路由收敛表现。示例判断：一个 200 节点、每节点最多 110 Pod 的集群，若采用 /24 每节点分配，则需约 200 个 /24，应提前确认 VPC 路由表配额与网段容量，否则后期扩容会因 IP 耗尽而被迫重建网络。

二、Pod 网络与 Service 网络规划

规划的核心是“三段地址不重叠、容量留余量”。典型示例：节点网段 10.0.0.0/16，Pod CIDR 10.244.0.0/16（约 6.5 万地址），Service CIDR 10.96.0.0/12（约 104 万地址）。Pod CIDR 按节点切分，例如每节点 /24，则单集群可容纳 256 个节点；若预期 500 节点，应改用 /23 每节点或扩大 Pod CIDR 至 /14。

Service CIDR 只用于 ClusterIP，不占用真实链路地址，但必须与节点网段、Pod 网段、VPC 网段、办公网段全部错开，否则会出现“Pod 能通、Service 不通”的隐蔽故障。规划完成后应形成一张地址分配表，明确各段用途、掩码、已用比例和扩容阈值，并纳入变更评审。

三、网络策略实施：默认拒绝，按需放行

NetworkPolicy 是命名空间级别的 Pod 防火墙。生产建议先建立“默认拒绝所有入站”的基线策略，再按业务依赖逐条放行。示例：为 order 命名空间设置默认拒绝入站，然后允许来自 gateway 命名空间的 8080 端口，以及同命名空间内 mysql 的 3306 端口。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: order
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-gateway-and-mysql
  namespace: order
spec:
  podSelector:
    matchLabels:
      app: order-api
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: gateway
    ports:
    - protocol: TCP
      port: 8080
  - from:
    - podSelector:
        matchLabels:
          app: mysql
    ports:
    - protocol: TCP
      port: 3306

实施后必须验证：从被拒绝的 Pod 发起连接应超时或被拒绝，从放行来源应成功。注意 NetworkPolicy 依赖 CNI 支持，若插件不支持则策略不生效，这是排障时首先要确认的点。

四、跨节点通信性能调优

跨节点性能瓶颈通常来自三处：MTU、封装开销与 conntrack。Overlay 场景下，若物理网卡 MTU 为 1500，VXLAN 封装后应把 Pod 侧 MTU 设为 1450，否则大包会被分片或丢弃，表现为“小请求正常、大响应卡顿”。可用 ping -M do -s 1472 逐级探测实际可用 MTU。

其次是 conntrack 表容量。高并发短连接场景下，若 nf_conntrack_count 接近 nf_conntrack_max，会出现丢包和新建连接失败。应结合节点规格调大上限并缩短超时，同时优先选用 eBPF 数据面减少 iptables 规则遍历。最后用 iperf3 在跨节点 Pod 间做基线测试，记录吞吐与重传，作为扩容和调优的对照依据。

五、公网与内网负载均衡接入

入口层建议区分公网与内网两条链路：公网使用公网 SLB 或 LoadBalancer 类型 Service，仅暴露必要端口；内网使用内网 SLB，供 VPC 内系统调用。Ingress 负责七层路由与 TLS 终止，Service 负责四层转发。关键配置包括：健康检查路径与阈值、会话保持策略、后端 Pod 就绪探针联动，以及 externalTrafficPolicy: Local 是否保留客户端源 IP。

接入完成后，用“公网域名 → SLB → Ingress → Service → Pod”逐跳验证：先确认 SLB 后端健康，再确认 Ingress 规则命中，最后确认 Pod 就绪。若出现 502，优先检查就绪探针与后端端口；若出现源 IP 丢失，检查是否使用了 Local 策略或代理协议。把这条链路固化为上线检查项，可显著降低入口类故障的定位时间。