外部请求至k8s集群内部对应节点全流程介绍

前言：默认集群内网络是扁平的，外部流量进不来，必须通过某种方式暴露服务，暴露服务的方式通常有三种：Ingress、LoadBalancer 或 NodePort

假设我们有一个域名 my-app.com，它指向一个外部 IP，并且我们在 Kubernetes 中通过 Ingress 资源暴露服务。

第 1 站：外部负载均衡器 (External Load Balancer)
角色：流量的“总入口”和“交通调度员”。

作用：

接收请求：客户端的 DNS 解析 my-app.com 后，请求会到达这个负载均衡器的 IP 地址。

终止 TLS（可选）：如果使用 HTTPS，负载均衡器可以在这里终止 SSL/TLS 连接，将解密后的 HTTP 请求转发给后端。

负载均衡：它将请求按照预设的负载均衡策略（如轮询、最少连接等）分发到后端的多个Ingress Controller 节点。

实体：这通常是由云服务商（如 AWS ALB/NLB、GCP Load Balancer、Azure Load Balancer）提供的托管服务，或者在本地机房可能是 F5、HAProxy 等硬件或软件负载均衡器。

第 2 站：Ingress Controller
角色：集群内部的“智能路由网关”或“门卫”。

作用：

监听变化：它监听 Kubernetes API 服务器，关注 Ingress 资源的变化。当你创建或修改 Ingress 规则时，Ingress Controller 会立即获取这些新配置。

应用路由规则：它根据 Ingress 规则（host, path）判断当前请求应该被转发到哪个 Service。例如，my-app.com/api 的请求被路由到 api-service。

反向代理：它本身作为一个强大的反向代理（通常是 Nginx、Traefik 或 Envoy），执行最终的请求转发。

实体：它是运行在 Kubernetes 集群中的一个或多个 Pod。为了高可用，通常会在多个节点上部署，并通过第 1 站的负载均衡器将流量分发给这些 Pod。

第 3 站：Service
角色：服务的“稳定抽象层”和“内部负载均衡器”。

作用：

提供稳定访问点：Pod 是脆弱的，可能会频繁重启或缩放，IP 地址会变。Service 提供了一个固定的虚拟 IP（ClusterIP）和 DNS 名称，使得 Ingres Controller 等内部组件无需关心后端 Pod 的具体位置。

负载均衡：当请求到达 Service 后，Service 会将请求再次负载均衡到一组健康的 Pod 上。

实现机制：这个负载均衡能力并非由某个单独的进程实现，而是由每个节点上的 kube-proxy 组件通过维护 iptables 或 IPVS 规则来实现的。请求到达 Service VIP 后，被这些网络规则直接拦截并转发到真实的 Pod IP。

第 4 站：Pod (最终目的地)
角色：实际处理请求的“工作单元”。

作用：

接收请求：请求经过上述层层转发，最终到达目标 Pod。

处理请求：Pod 内的业务容器（如 Nginx、Tomcat、Node.js、Golang 等）处理请求并生成响应。

实体：Pod 是 Kubernetes 的最小调度单位，包含一个或多个共享网络和存储空间的容器。

完整链路总结 (Ingress 方式)
外部客户端 → 外部负载均衡器 → Ingress Controller Pod → Service (虚拟IP) → 目标 Pod客户端 访问 https://my-app.com/api/v1。DNS 将该域名解析为外部负载均衡器的 IP。请求到达外部负载均衡器，完成 SSL 终止，并根据策略将请求转发到集群内某个Ingress Controller Pod 的 NodePort 或内部 IP。Ingress Controller Pod 接收到请求，根据其内置的规则（来自 Ingress 资源）判断：Host: my-app.com 且 Path: /api 的请求应被发送到 api-service:80。请求被发往 api-service 的虚拟 IP（ClusterIP）。当前节点上的 kube-proxy 设置的 iptables/IPVS 规则拦截到发往该 Service VIP 的请求，并将其直接 DNAT（目标地址转换） 到一个健康的 api-service 后端 Pod 的真实 IP 上。请求最终到达运行着实际应用程序的 Pod，由容器内的应用处理并返回响应。响应沿着原路（或类似的路径）返回给客户端。