Service 与服务发现

滚动更新前:
  后端 Pod-A  IP: 10.244.2.3   ← 前端代码写死了这个地址
  后端 Pod-B  IP: 10.244.2.4
  后端 Pod-C  IP: 10.244.3.7

滚动更新后:
  后端 Pod-A' IP: 10.244.2.9   ← 新 Pod,新 IP
  后端 Pod-B' IP: 10.244.3.2   ← 甚至可能调度到不同 Node
  后端 Pod-C' IP: 10.244.1.8

前端还在连 10.244.2.3 → 连接失败,服务中断

1. 分配 ClusterIP(如 10.96.0.100)
   → 集群内任何 Pod 连 10.96.0.100:80 就能到达后端

2. 在 CoreDNS 注册记录
   → backend-svc.default.svc.cluster.local → 10.96.0.100
   → 同 namespace 内可以直接用 "backend-svc" 当域名

3. kube-proxy 在每个节点写转发规则
   → 10.96.0.100:80 → 负载均衡到所有 app=backend 的 Pod
   → Pod 增减时自动更新规则

┌─────────────┐
│ ClusterIP   │
├─────────────┤
│  • 集群内部访问    │
└─────────────┘
┌────────────┐
│ NodePort   │
├────────────┤
│  • 节点端口暴露   │
│  • A        │
└────────────┘
┌────────────────┐
│ LoadBalancer   │
├────────────────┤
│  • 云 LB 外部 IP   │
│  • B            │
└────────────────┘

流量路径:
  外部客户端 → 192.168.1.10:30080(任意节点 IP)
                    ↓
             kube-proxy 拦截
                    ↓
             负载均衡到 Pod(可能在本节点,也可能跨节点)

注意:即使 Pod 不在 node-1 上,node-1:30080 仍然能转发到正确的 Pod
      因为 kube-proxy 在每个节点都写了转发规则

流量路径:
  互联网用户 → 203.0.113.10:80(云 LB 公网 IP)
                    ↓
             云负载均衡器(健康检查 + 流量分发)
                    ↓
             Node-1:31234 / Node-2:31234 / Node-3:31234
                    ↓
             kube-proxy → Pod

Pod-A 访问 backend-svc (ClusterIP: 10.96.0.100:80)
后端有 3 个 Pod: 10.244.1.5:8080, 10.244.2.3:8080, 10.244.3.7:8080

┌─────────────────────────────────────────────────────┐
│ Pod-A 发出报文:dst = 10.96.0.100:80                 │
│                                                     │
│ → 进入节点的 iptables 链                              │
│                                                     │
│ PREROUTING → KUBE-SERVICES 链                        │
│   匹配规则: dst == 10.96.0.100:80                    │
│   → 跳转到 KUBE-SVC-XXXX 链                          │
│                                                     │
│ KUBE-SVC-XXXX(Service 链 - 负载均衡)               │
│   ├── 33% 概率 → KUBE-SEP-AAA(Endpoint 1)         │
│   ├── 33% 概率 → KUBE-SEP-BBB(Endpoint 2)         │
│   └── 34% 概率 → KUBE-SEP-CCC(Endpoint 3)         │
│                                                     │
│ KUBE-SEP-AAA:                                       │
│   DNAT dst 10.96.0.100:80 → 10.244.1.5:8080         │
│   → 报文 dst 变成了真实 Pod IP                        │
│                                                     │
│ → 走正常的 Pod 网络路由到达目标 Pod                     │
└─────────────────────────────────────────────────────┘

iptables 模式:
  规则是链式匹配 → O(n) 查找
  更新需要全量刷新 → 规则多时耗时长
  只支持随机负载均衡

IPVS 模式:
  规则存在哈希表 → O(1) 查找
  增量更新 → 只改变动的 Endpoint
  支持多种算法:rr(轮询)/ lc(最少连接)/ sh(源地址哈希)等

控制循环:
  Endpoints Controller(在 Controller Manager 中)
    watch: Service + Pod
    逻辑:
      for each Service with selector:
        找到所有匹配 selector 的 Pod
        过滤出 status.conditions 中 Ready=True 的
        更新 Endpoints 对象的地址列表

  kube-proxy(在每个 Node 上)
    watch: Service + Endpoints
    逻辑:
      Endpoints 变了 → 重写本节点的 iptables/IPVS 规则

Endpoints 的问题(大规模场景):
  Service "big-app" 有 5000 个 Pod
  → 一个 Endpoints 对象包含 5000 个地址
  → 某个 Pod 重启 → 更新整个 5000 条的对象
  → etcd 存储/网络传输的开销随 Pod 数量线性增长
  → 推送给集群所有 Node 的 kube-proxy → 放大 N 倍

EndpointSlice 的解法:
  Service "big-app" 有 5000 个 Pod
  → 拆成 50 个 EndpointSlice(每个最多 100 条)
  → 某个 Pod 重启 → 只更新它所在的那 1 个 Slice
  → 传输量:1/50
  → 其他 49 个 Slice 不动,kube-proxy 增量更新

普通 Service(clusterIP: 10.96.0.100):
  DNS 查询 my-svc → A 记录 → 10.96.0.100(ClusterIP)
  → kube-proxy 负载均衡到后端 Pod
  → 客户端不知道有几个后端,各自 IP 是什么

Headless Service(clusterIP: None):
  DNS 查询 my-svc → A 记录 → 10.244.1.5, 10.244.2.3, 10.244.3.7
  → 直接返回所有后端 Pod 的 IP(不经过 kube-proxy)
  → 客户端自己决定连谁

  如果配合 StatefulSet,还有逐 Pod 的 DNS:
  DNS 查询 pod-0.my-svc → A 记录 → 10.244.1.5(只有这个 Pod)

应用代码: curl http://backend-svc:80
                       │
          ① 服务发现(DNS)
          "backend-svc" → 10.96.0.100
                       │
          ② 流量转发(kube-proxy / iptables)
          dst 10.96.0.100:80 → DNAT → 10.244.1.5:8080(某个 Pod)

完整格式:
  <service-name>.<namespace>.svc.cluster.local

解析规则:
  同 namespace 内可以省略后缀:
    backend-svc                              → 同 ns 直接用名字
    backend-svc.default                      → 带 namespace
    backend-svc.default.svc                  → 带 svc
    backend-svc.default.svc.cluster.local    → 完整 FQDN

  跨 namespace 至少带 namespace:
    backend-svc.production                   → 访问 production ns 的服务