3. Kubernetes 网络基础：Pod网络、Service、Ingress与NetworkPolicy核心概念

在深入 Helm 网络拓扑性能调优之前，必须建立对 Kubernetes 原生网络模型的清晰认知。本章将剖析四个核心网络抽象层：Pod 网络、Service、Ingress 以及 NetworkPolicy。理解这些组件的通信模型与性能瓶颈，是后续进行准入控制与调优的前提。

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

Kubernetes 要求每个 Pod 拥有独立的 IP 地址，且集群内所有 Pod 可以直接通过该 IP 通信，无需 NAT。这种“扁平网络”模型是设计 Service 和 NetworkPolicy 的基础。

• 同一 Pod 内容器通信：共享网络命名空间（Network Namespace），通过 localhost 通信，延迟极低（通常 < 0.1ms）。
• 跨节点 Pod 通信：依赖 CNI 插件（如 Calico、Flannel、Cilium）实现 Overlay 或路由模式。Overlay 模式（如 VXLAN）会引入额外的封装/解封装开销，增加延迟约 0.1-0.5ms，并降低有效带宽。
• 性能关键点：MTU 配置、CNI 数据面模式（eBPF vs iptables）、节点间网络带宽与延迟。

3.2 Service：抽象负载均衡与流量分发

Service 为一组 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称，实现客户端与后端 Pod 的解耦。其核心机制是 kube-proxy 组件，支持三种代理模式：

3.3 Ingress：南北向流量入口与路由

Ingress 是集群外部访问内部服务的入口点，提供基于 HTTP/HTTPS 的路由、TLS 终止和虚拟主机功能。常见的 Ingress Controller 包括 Nginx、Traefik、HAProxy 和 AWS ALB。

• 路由粒度：支持基于 Host 和 Path 的规则，将请求分发到不同的 Service。
• TLS 终止：在 Ingress Controller 层解密 HTTPS 流量，减轻后端 Pod 的计算负担。
• 性能关键点：Controller 的并发处理能力、TLS 握手开销、连接池管理、以及是否启用缓存和压缩。

# 示例：Nginx Ingress 配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
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

3.4 NetworkPolicy：微隔离与流量准入控制

NetworkPolicy 是 Kubernetes 原生的网络访问控制机制，通过标签选择器定义 Pod 之间以及 Pod 与外部端点之间的流量规则。它工作在 OSI 第 3/4 层（IP + 端口），部分实现（如 Cilium）可扩展至第 7 层。

3.5 核心概念总结与性能对照