【K8S】从请求到容器：Service、Kube-Proxy与Pod的流量寻址之旅

1. 当请求敲开K8S的大门：一次流量寻址的奇幻漂流

想象你是一位外卖骑手，手里拿着写着"幸福小区3号楼2单元1201室"的订单。这个地址就像Kubernetes集群中的Service——它不直接对应具体的住户（Pod），而是通过楼栋单元号（ClusterIP）引导你找到最终目的地。让我们跟随这个外卖订单，看看Kubernetes如何完成从抽象地址到具体容器的导航。

在这个旅程中，Service就像小区的快递柜，kube-proxy是负责分拣的智能系统，而Pod则是最终收件的住户。当外部请求进入集群时，首先会遇到Ingress这个小区大门保安，它根据域名或路径（比如"美团外卖/饿了么"）决定将请求引导到哪个快递柜（Service）。不过今天我们要重点探索的是快递柜背后的故事——当请求已经到达Service之后，如何经过kube-proxy的智能调度，最终精准投递到某个具体的Pod容器。

2. Service：集群内部的智能快递柜

2.1 服务发现与负载均衡的核心枢纽

Service在Kubernetes中本质上是个四层(TCP/UDP)负载均衡器，我更喜欢把它比作写字楼的前台接待系统。当你在YAML里定义这样一个Service时：

yaml复制apiVersion: v1
kind: Service
metadata:
  name: frontend-svc
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

这就相当于在写字楼大堂安装了一个智能导览屏。其中关键元素包括：

• selector：这个"标签识别系统"会持续扫描所有带着app=frontend标签的Pod（就像识别员工工牌）
• 虚拟IP(VIP)：系统自动分配的ClusterIP（如10.96.123.45），相当于前台总机号码
• 端口映射：外部访问80端口的请求会被转发到Pod的8080端口（就像总机帮你转分机）

我在实际运维中发现，Service最神奇的地方在于它的"永不消逝"特性。即使后端的Pod因为版本更新全部被替换，只要新Pod保持相同的标签，Service就能