Yishen Learn 知识中心

Appearance

03. 微服务服务发现与流量路由网络 ​

在分布式集群中，容器的生灭是瞬息万变的——Pod 会由于故障自愈、节点驱逐或水平伸缩随时被销毁并在新节点上以全新 IP 重生。如何在动态变化的“流沙”之上，构建确定性、高吞吐、零中断的服务路由体系？

本章将系统解析 Kubernetes 扁平网络模型、CNI 插件原理解析、Service 四层虚拟负载（iptables vs IPVS 深度比对），并通过本站独家的微服务流量拓扑交互仿真器，让你身临其境感受集群故障自愈与流量调度。最后，我们将剖析七层南北向 Ingress 网关及基于 cert-manager 的自动化 TLS 证书签发。

1. Kubernetes 扁平网络模型与 CNI 插件原理解析 ​

1.1 K8s 网络设计哲学：四大通信原则 ​

Kubernetes 摒弃了传统的端口映射与双向 NAT 机制，确立了极简而优雅的 IP-per-Pod 扁平网络通信哲学：

  1. Pod 间直连互通：任意两个 Pod 之间可以直接通过对方的真实 IP 互相通信，不需要进行网络地址转换（NAT）。
  2. Node 与 Pod 直连：宿主机 Node 节点与该节点上的任何 Pod 均可直接免 NAT 互通。
  3. 内外视图一致：Pod 看到自己的内部 IP，与外部其他节点和 Pod 看到它的 IP 完全一致。
  4. 无端口冲突：由于每个 Pod 拥有专属且唯一的 IP，每个 Pod 都可以独立绑定例如 80 或 8080 端口，彻底消除了物理机时代的端口抢占问题。

1.2 CNI (Container Network Interface) 主流方案对比 ​

Kubernetes 本身不提供网络驱动，而是通过 CNI 标准插件机制 将底层网络实现的权力移交生态：

CNI 插件方案网络拓扑模式转发机制与内核技术优缺点与适用场景
Flannel覆盖网络 (Overlay)VXLAN 封包解包（在 UDP 报文中封装原始二层帧）极简、开箱即用。对底层物理网络无任何侵入；但额外的隧道封包/解包会损耗 5%~15% 的网络吞吐量，不支持 NetworkPolicy。
Calico路由网络 (Underlay)BGP（边界网关协议）将每个 Node 变成虚拟路由器，直接将 Pod IP 广播进宿主网络高性能原生转发，零封包损耗；拥有极度强大的 NetworkPolicy 访问控制能力；需要底层网络交换机支持或在同二层内运行。
Cilium革命性 eBPF 原生Linux eBPF (Extended BPF) 在内核 Socket 层与 TC 层劫持报文代表未来演进方向。彻底绕过 Linux 网络协议栈和 iptables，性能极度炸裂；提供 L3/L4/L7 细粒度观测与加密，但需要较新 Linux 内核版本（≥5.4）。

2. Service 四层负载均衡机制：iptables vs IPVS ​

2.1 为什么需要 Service 抽象？ ​

Pod 的生命周期短暂，IP 变动频繁。为了给一组具有相同功能的 Pod 副本提供一个固定的访问入口，Kubernetes 引入了 Service。

Service 分配有一个固定的虚拟 IP（ClusterIP），同时配合集群内置 DNS（CoreDNS），对外暴露标准服务域名：

<service-name>.<namespace>.svc.cluster.local

工作节点上的守护进程 kube-proxy 负责捕获发送往 ClusterIP 的数据包，并将其重定向至后端某个真实的 Pod IP。

2.2 iptables 模式 vs IPVS 模式性能硬核对决 ​

kube-proxy 支持多种代理模式，目前生产中最核心的对决在于 iptables 与 IPVS：

关键技术差异分析： ​

  1. 算法复杂度：
    • iptables：底层是纯顺序数组链表。当一个包到达时，内核必须逐条匹配规则，时间复杂度为 O(N)。若集群中有 2000 个 Service 和 10000 个 Pod，每次请求需遍历数万条规则，导致 CPU 占用急剧上升、网络延迟飙升，且更新单条规则时需对整张表加全量内核锁。
    • IPVS：基于 Linux 内核 IPVS 模块（LVS），底层采用哈希表（Hash Table）存储路由规则，查询时间复杂度为 O(1)。即使后端 Pod 数量膨胀至数十万级别，匹配耗时依然恒定在微秒级。
  2. 负载均衡调度算法：
    • iptables：仅能通过 statistic --mode random 模块实现极其粗糙的伪轮询和概率分流。
    • IPVS：内置丰富的调度算法，包括轮询（rr）、最小连接数（lc）、加权轮询（wrr）、源地址散列（sh）等。

生产部署建议

在拥有超过 100 个节点或 1000 个 Service 的大规模生产 Kubernetes 集群中，必须将 kube-proxy 的模式切换为 IPVS（通过配置 kube-proxy 的 ConfigMap：mode: "ipvs"）。

3. 动态交互仿真：Kubernetes 流量拓扑与自愈调度 ​

为了直观体会从外部客户端经由七层 Ingress、四层 Service，直到后端 Pod 副本池的全链路流量分发，请使用下方内置的交互式仿真器：

☸️Kubernetes 服务流量路由与负载均衡仿真器
💻
外部客户端
https://learn.yishen.uk
➔
🌐
Ingress Controller
七层域名/TLS 终结
➔
🔀
ClusterIP Service
四层负载 iptables/IPVS
➔
learn-pod-7df8c-a1
10.244.1.18
Running
处理请求: 0
learn-pod-7df8c-b2
10.244.2.45
Running
处理请求: 0
learn-pod-7df8c-c3
10.244.3.09
Running
处理请求: 0
实时请求追踪日志 (Request Tracing)清空
点击右上角「发送 HTTP 请求」观察微服务流量调度链路...

💡 实验探索任务指南： ​

  1. 多请求轮询调度验证：
    • 连续点击右上角 「⚡ 发送 HTTP 请求」 按钮 3~5 次。
    • 观察请求轨迹如何顺畅穿透：外部客户端 → Ingress Controller → ClusterIP Service → Pod 副本池，并在下方的“实时请求追踪日志”中查看每个 Pod 接收请求的分布计数。
  2. 模拟突发单点宕机与故障隔离：
    • 点击右上角 「模拟故障: Pod-2 宕机」。
    • 此时 learn-pod-7df8c-b2 状态变更为 Terminated（模拟容器崩溃或就绪探针失败后从 Endpoint 剔除）。
    • 再次多次点击 「⚡ 发送 HTTP 请求」。
    • 现象观察：流量自动绕过不可用的 Pod-2，仅在存活健康的 Pod-1 与 Pod-3 之间平滑轮询，客户端未出现任何 502/503 丢包！真实再现了 Kubernetes 基于探针的服务自愈与动态端点剔除机制。

4. 七层南北向流量反向代理：Ingress Controller 架构 ​

4.1 为什么四层 Service 无法满足公网暴露？ ​

虽然 Kubernetes 提供了 NodePort 和 LoadBalancer 类型的 Service，但在生产环境中存在明显缺陷：

  • NodePort 端口浪费：每个服务都需要在宿主机上分配一个 30000~32767 的端口，难以记忆且受安全策略限制。
  • LoadBalancer 成本高昂：在 AWS/GCP/阿里云等公有云上，每个 LoadBalancer Service 都会创建一台独立的云厂商四层负载均衡器，100 个微服务将带来巨额月度账单。
  • 缺乏七层智能控制：四层 Service 无法识别 HTTP/HTTPS 协议层的内容，无法做基于域名（Host）、请求路径（Path）的分流，无法集中终结 TLS 证书，也无法实现 Cookie 会话保持或基于 Header 的灰度金丝雀发布。

由此，Ingress（声明路由规则） 与 Ingress Controller（七层反向代理实体网关） 应运而生：

4.2 基于 cert-manager 的生产级自动 TLS 证书签发 ​

在生产环境中，手动更新 SSL/TLS 证书极易因过期引发服务中断。云原生业界标准解决方案是集成 cert-manager 与 Let's Encrypt，实现证书申请、DNS/HTTP-01 验证、分发与自动续期的全自动闭环。

1. 定义全局 Let's Encrypt ClusterIssuer ​

yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    # 接收证书过期告警与 ACME 注册邮箱
    email: admin@yishen.uk
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-production-account-key
    solvers:
      # 使用 HTTP-01 挑战协议验证域名所有权
      - http01:
          ingress:
            class: nginx

2. 定义生产级 Ingress 路由规则 ​

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: platform-gateway
  namespace: production
  annotations:
    # 关联上述 cert-manager 自动签发证书
    cert-manager.io/cluster-issuer: letsencrypt-production
    # 指定网关类型为 nginx
    kubernetes.io/ingress.class: nginx
    # 配置 Nginx 缓冲区与高并发调优
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    # 强制重定向至 HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts:
        - learn.yishen.uk
      # 签发成功的 TLS 证书与私钥将自动加密写入该 Secret
      secretName: learn-yishen-uk-tls
  rules:
    - host: learn.yishen.uk
      http:
        paths:
          # 静态内容与主站路由
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80
          # 后端微服务 API 路由
          - path: /api/v1
            pathType: Prefix
            backend:
              service:
                name: api-gateway-service
                port:
                  number: 8080

4.3 Kubernetes 网络与流量连通性生产排障决策树 ​

网络链路是云原生分布式系统中最容易出现“隐形故障”的地带。以下决策树梳理了从七层网关到 CNI 底层隧道连通性的典型排障路径：

云原生网络黄金排障工具链与速查指令 ​

排查维度工具与执行命令核心诊断目标与排查意义
四层转发表检索ipvsadm -ln查看内核 IPVS 散列转发池，确认 VIP 是否正确绑定了所有 Real Server（Pod IP）
端点就绪切片kubectl get endpointslices -l kubernetes.io/service-name=<svc>查看 Service 是否有健康的后端 Ready Pod，排除就绪探针失败拦截
DNS 解析测试kubectl exec -it <pod> -- nslookup <svc>.<ns>.svc.cluster.local验证 CoreDNS 集群域名解析延迟与应答，排查 ndots 搜索域污染
抓包分析握手tcpdump -i eth0 -nn -vv 'port 80 or port 8080'观察三次握手 SYN 包是否正常送达，排查 iptables DROP 规则阻断
网络全能瑞士军刀kubectl run net-debug --rm -it --image=nicolaka/netshoot -- /bin/bash内置 curl, dig, traceroute, grpcurl, iperf3 等全套诊断网络工具

5. 本章小结 ​

  1. 扁平网络基石：K8s 确保所有 Pod 在无 NAT 的大二/三层网络内直接互联，CNI 插件（Flannel, Calico, Cilium）负责在物理网络之上搭建该平面。
  2. 四层负载引擎：Service 通过 ClusterIP 屏蔽 Pod IP 的易变性。在大规模高并发集群中，IPVS 模式凭借其 O(1) 哈希散列复杂度与丰富算法全面碾压传统的 iptables 顺序链表。
  3. 七层网关与 TLS：Ingress Controller 充当南北向集群统一大门，集中承接外部流量分发；配合 cert-manager 实现企业级 HTTPS 证书的全自动托管闭环。

在微服务集群中，代码和路由已经就绪，那么应用所需的配置、秘钥，以及数据库等持久化存储应该如何解耦？下一章见：04. 配置与持久化存储解耦。

学思并济 · 躬行求索 | Released under MIT License

Copyright © 2026 yishen.uk · Deployed on Cloudflare Workers