第278篇：K8s Ingress 与 Service Mesh 网络

关键词

Ingress Controller、Service Mesh、Istio、Sidecar、Envoy Proxy、流量管理、mTLS、可观测性

一、从 Service 到 Ingress

1.1 Service 的局限

Service 提供集群内服务的访问，但对南北向流量支持有限：

Service 访问方式对比：

  ┌──────────────────────────────────────────┐
  │  Cluster IP                              │
  │  10.96.0.10:80                           │
  │  ┌─ 只有集群内部可访问                     │
  │  └─ 不能从外部访问                        │
  │                                          │
  │  NodePort                                 │
  │  Node1:31080, Node2:31080                │
  │  ┌─ 外部可访问                            │
  │  ├─ 端口范围固定（30000-32767）            │
  │  ├─ 每个 Service 占用节点端口              │
  │  └─ 不适合生产环境（需配合 LB）             │
  │                                          │
  │  LoadBalancer                             │
  │  ┌─ 云厂商 LB + 公网 IP                   │
  │  ├─ 每个 Service 一个 LB（成本高）         │
  │  └─ L4 负载均衡（7 层路由需 Ingress）      │
  └──────────────────────────────────────────┘

问题：
  每个 Service 分配公网 IP → 成本高
  无 URL 路由 → 只能按端口区分
  无 TLS 终结 → 需要额外配置
  无高级流量管理 → 无灰度发布/金丝雀

1.2 Ingress 的作用

Ingress——K8s 的 7 层流量入口：

Internet 203.0.113.1:443 (HTTPS) ┌───┴──────────────────────────┐ Ingress Controller (Nginx / Traefik / HAProxy) /api/ → Service A:8080 /web/ → Service B:80 /admin/* → Service C:8080 TLS 终结：证书管理 速率限制、IP 黑白名单

Ingress 资源定义示例：

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

二、Ingress Controller 对比

主流 Ingress Controller：

特性 Nginx Traefik HAProxy Kong
性能(PPS) 配置热更新 支持 TCP/UDP 金丝雀发布 Service Mesh 可观测性 插件生态 配置方式 高 ✓ 部分 插件 关联 中 丰富 注解 中 ✓ ✓ ✓ 可选 强 丰富 CRD 很高 ✓ ✓ ✓ 可选 中 有限 注解 中 ✓ ✓ ✓ K8s 插件 强 丰富 CRD

生产环境推荐： Nginx Ingress Controller——最成熟、社区最大 Traefik——云原生、自动发现、简单配置 HAProxy——极致性能（40Gbps+）

三、Service Mesh 概述

3.1 Service Mesh 是什么

Service Mesh 是微服务通信的专用基础设施层，将网络功能从应用代码中剥离：

Service Mesh 架构：

没有 Service Mesh： | Pod A ┌─────────────────────────┐ | 微服务代码 + 重试/超时/熔断/发现 + TLS/认证 | | ← 网络逻辑在代码中 | | --- | --- | --- | --- |

有 Service Mesh（Sidecar）： | Pod A ┌─────────────────────────┐ └──────────┬──────────────┘ ┌──────────┴──────────────┐ | 微服务代码（仅业务逻辑） localhost Sidecar Proxy(Envoy) 重试/超时/熔断/发现 mTLS/认证/可观测性 | | ← 网络逻辑剥离 ← 控制网络 | | --- | --- | --- | --- |

Service Mesh 的三大功能： 1. 流量管理——路由、灰度、熔断、重试 2. 安全——mTLS、RBAC、认证 3. 可观测性——指标、日志、链路追踪

3.2 Sidecar 代理

Sidecar 代理的数据流：

Pod A Pod B | 微服务 A connect("B",8080) ┌───┴────────┐ | Sidecar (Envoy) 截获所有 出入流量 | 微服务 B ┌───────────┐ | | | Sidecar (Envoy) 截获所有 出入流量 | | | --- | --- | --- | --- | --- | --- | --- | │ │ │ mTLS + HTTP/2 │ └──────────────────────────────┘

Envoy 代理的处理链： 入站流量： Ingress Listener → TLS → RBAC → 路由 → Cluster → 上游

出站流量：
  Egress Listener → 路由 → Cluster → TLS → 上游

iptables 流量拦截： Pod 的流量被 iptables 规则透明重定向到 Sidecar 应用代码无需修改

四、Istio 架构

4.1 组件

Istio 是当前最流行的 Service Mesh 实现：

┌──────────────────────────────────────────┐ │ 控制面（istiod） │ │ │ │ Pilot —— 流量管理 │ │ Citadel —— 安全（证书签发） │ │ Galley —— 配置验证 │ └──────────────────┬───────────────────────┘ │ │ xDS API（发现配置） ▼ | 数据面（Envoy Proxy × N Pod） ┌─────┐ ┌─────┐ ┌─────┐ | Pod1 Envoy | | Pod2 Envoy | | Pod3 Envoy | | | --- | --- | --- | --- | --- | --- | --- |

Istio 资源：

VirtualService：流量路由规则 DestinationRule：负载均衡、熔断、TLS Gateway：南北向流量入口 ServiceEntry：外部服务注册 PeerAuthentication：服务间 mTLS AuthorizationPolicy：访问控制

4.2 流量管理示例

Istio 流量管理——金丝雀发布：

  apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  metadata:
    name: myapp
  spec:
    hosts:
    - myapp
    http:
    - match:
      - headers:
          version:
            exact: v2                # Header: version=v2 → 新版本
      route:
      - destination:
          host: myapp
          subset: v2
    - route:
      - destination:
          host: myapp
          subset: v1
        weight: 90                    # 90% 流量到 v1
      - destination:
          host: myapp
          subset: v2
        weight: 10                    # 10% 流量到 v2

  ---
  apiVersion: networking.istio.io/v1beta1
  kind: DestinationRule
  metadata:
    name: myapp
  spec:
    host: myapp
    subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100
      outlierDetection:
        consecutive5xxErrors: 5      # 熔断：5 次 5xx 断开
        interval: 30s
        baseEjectionTime: 60s

五、Service Mesh 的优势与代价

5.1 优势

Service Mesh 带来的核心价值：

1. 流量管理
   金丝雀发布、蓝绿部署
   基于 Header/Cookie 的路由
   超时/重试/熔断/限流

2. 安全
   服务间 mTLS（自动证书轮换）
   细粒度授权（AuthorizationPolicy）
   双向 TLS 认证

3. 可观测性
   分布式追踪（Jaeger/Zipkin）
   服务指标（Prometheus）
   访问日志（结构化日志）

4. 无侵入
   应用代码零修改
   通过 Sidecar 透明注入

5.2 代价

Service Mesh 的代价：

  1. 性能开销 | 场景 | 无 Mesh | 有 Mesh | | --- | --- | --- | | 延迟 P50 CPU 开销 内存开销 | 1ms 0 0 | 2-3ms 5-10% 50MB/代理 |

每个 Pod 多一个 Envoy Sidecar 每个请求多两次代理跳转（入口 + 出口）

  1. 复杂度 引入新的控制面组件 运维团队需要学习 Istio CRD 排错复杂（多了一层代理）

  2. 资源消耗 100 Pod → 100 个 Envoy 实例 每个 Envoy 50MB 内存 总内存消耗：5GB

是否选择 Service Mesh： 小规模（< 20 微服务）→ 不需要（Spring Cloud 等方案足够） 中规模（20-100 微服务）→ 考虑引入 大规模（100+ 微服务）→ 强烈推荐

六、总结

知识点 核心要点
Ingress 7 层流量入口，URL 路由、TLS 终结、域名转发
Ingress Controller Nginx/Traefik/HAProxy/Kong，热更新、插件生态
Service Mesh 微服务通信基础设施层，剥离网络逻辑
Sidecar Envoy 代理透明拦截所有 Pod 流量
Istio 控制面（istiod）+ 数据面（Envoy）
流量管理 VirtualService + DestinationRule 定义路由规则
mTLS 服务间双向 TLS，自动证书管理
优势/代价 功能丰富 vs 性能开销 5-10%

七、思考

  1. Ingress 和 Service Mesh 中的 Gateway 有什么异同？它们分别处理哪类流量？
  2. Sidecar 代理如何透明地拦截 Pod 的所有流量？iptables 转发规则是怎样的？
  3. Istio 的金丝雀发布如何实现？10% 的流量到 v2 是基于什么粒度（请求数/连接数）？
  4. Service Mesh 引入的性能开销主要来自哪里？延迟和资源消耗大约是多少？
  5. 在一个 200 个微服务的生产集群中，是否需要引入 Service Mesh？你的选择是什么，为什么？

下篇预告：第279篇《容器网络的多租户隔离方案》——K8s 集群中的多租户网络隔离需求，Namespace 隔离、网络策略、租户 VPC 方案与实践。