Kubernetes HTTP请求 全面解析 Kubernetes 外部 HTTP 请求到达 Pod 容器的详细流程

Kubernetes | HTTP请求：从外部到Pod容器的完整旅程

场景引入

想象一下,你正在开发一个电商应用，部署在Kubernetes集群中，当用户点击"购买"按钮时，这个HTTP请求要经历怎样的奇幻漂流才能最终到达你的应用容器呢？今天我们就来揭开这个技术黑箱，看看一个外部HTTP请求是如何穿越Kubernetes的层层关卡，最终抵达目标Pod的全过程。

请求的起点：用户浏览器

一切始于用户在浏览器中输入网址或点击链接,假设我们的电商应用域名为shop.example.com，用户发起请求：

GET /products/42 HTTP/1.1
Host: shop.example.com

这个请求首先会通过DNS解析,找到对应的IP地址，在Kubernetes环境中，这个IP通常指向：

• 云服务商的负载均衡器（如AWS ALB、GCP LB）
• 自建数据中心的硬件负载均衡设备
• 或者直接是Kubernetes集群边缘节点的IP（如果是NodePort服务）

第一站：负载均衡器

云服务商的负载均衡器收到请求后,会根据配置的规则将流量转发到Kubernetes集群的适当位置，这里可能有几种情况：

情况A：使用Ingress Controller

大多数生产环境会使用Ingress资源,这意味着负载均衡器会将请求转发到集群内的Ingress Controller Pod，常见的Ingress Controller有：

• Nginx Ingress Controller
• Traefik
• HAProxy Ingress
• AWS ALB Ingress Controller

情况B：使用LoadBalancer类型的Service

如果直接创建了LoadBalancer类型的Service,云提供商会自动配置负载均衡器，将请求直接转发到该Service的后端Pod。

Ingress Controller的工作

假设我们使用的是Ingress方式,请求现在到达了Ingress Controller Pod，Controller会根据Ingress资源配置的规则进行路由决策，例如我们的Ingress配置可能是这样的：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
spec:
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /products
        pathType: Prefix
        backend:
          service:
            name: product-service
            port:
              number: 80

Ingress Controller会：

1. 检查Host头匹配shop.example.com
2. 检查URL路径以/products开头
3. 将请求转发到名为product-service的Kubernetes Service

Service层：虚拟IP和端口转发

请求现在到达了Service层,Kubernetes Service是一个抽象层，它通过标签选择器找到匹配的Pod，我们的product-service可能这样定义：

apiVersion: v1
kind: Service
metadata:
  name: product-service
spec:
  selector:
    app: product
    tier: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

这里发生了几个关键步骤：

1. 端点选择：Service通过标签选择器app=product,tier=backend找到所有匹配的Pod
2. 负载均衡：Service在可用Pod之间进行负载均衡（默认是轮询）
3. 端口转换：Service将请求从80端口转发到Pod的8080端口（targetPort）

kube-proxy的魔法

Service的虚拟IP到实际Pod IP的转换是由每个节点上的kube-proxy组件实现的，根据集群配置，kube-proxy可能使用以下三种模式之一：

1. iptables模式（默认）：创建复杂的iptables规则链实现负载均衡
2. ipvs模式：使用Linux内核的IP Virtual Server功能，性能更好
3. userspace模式（已弃用）：在用户空间进行代理

在iptables模式下,kube-proxy会为每个Service创建一系列iptables规则，当数据包到达节点时，内核会根据这些规则进行DNAT（目标地址转换），将Service IP:Port重写为具体Pod的IP:Port。

网络插件：Pod间通信

请求现在需要从节点网络进入Pod网络,这是由CNI（容器网络接口）插件负责的，常见的有：

• Calico
• Flannel
• Weave Net
• Cilium

这些插件通过不同的方式实现Pod网络,但基本原理都是：

1. 为每个Pod分配唯一IP
2. 建立跨节点的网络路由
3. 处理网络策略（如果有）

请求数据包会被封装（如VXLAN）或直接路由到目标Pod所在的节点。

容器网络接口：veth pair

在目标节点内部,每个Pod都有自己的网络命名空间，通过一对虚拟以太网设备（veth pair）连接到节点的根命名空间，数据包通过这个隧道从节点网络进入Pod网络。

最终目的地：Pod内的容器

请求终于到达了目标Pod！在Pod内部：

1. 数据包到达Pod的网络命名空间
2. 被监听在指定端口（本例中是8080）的应用容器接收
3. 应用处理请求并生成响应

响应的返回路径

响应基本上沿着原路返回：

1. 从Pod发出,经过veth pair到节点网络
2. 经过Service的负载均衡（可能被转发到不同节点）
3. 通过Ingress Controller（如果使用Ingress）
4. 经过负载均衡器回到用户

整个流程涉及的主要Kubernetes组件：

性能考量

了解这个流程有助于优化应用性能：

1. 减少跳数：避免不必要的Ingress层
2. 会话保持：确保相关请求到达同一Pod
3. 网络策略：合理配置减少安全检查开销
4. 服务网格：如Istio会增加更多控制层

从外部HTTP请求到最终到达Pod容器,Kubernetes构建了一个复杂但高度灵活的网络栈，理解这个流程不仅有助于故障排查，还能帮助开发者设计更高效的云原生应用架构，下次当你的电商应用处理用户请求时，不妨想想这个请求在集群中完成的奇妙旅程。