Service 流量路由的具体路径

Service 流量路由的具体路径 时，他们希望考察你对 Kubernetes 网络底层原理的理解。以下是结构化回答，涵盖从客户端请求到后端 Pod 的完整路径及关键技术点：

---

1. 核心路由路径（以 ClusterIP 类型为例）

阶段 1：客户端发起请求

• 请求发起方：可以是集群内 Pod 或集群外（通过 Ingress/NodePort 访问）。
• DNS 解析：
  • 客户端通过 <service-name>.<namespace>.svc.cluster.local 解析 Service 的 ClusterIP（由 CoreDNS 提供）。

阶段 2：Service 的虚拟 IP 处理

• kube-proxy 的作用：
  • 每个节点上的 kube-proxy 监听 Service 和 Endpoint 变化，维护流量规则（根据代理模式不同，规则形式不同）。

代理模式	规则实现方式	流量路径关键点
iptables（默认）	生成 iptables 规则链	通过 KUBE-SERVICES 链跳转到 Pod IP
IPVS	使用内核 IPVS 负载均衡表	高性能，支持更多调度算法（rr/wrr等）
userspace	用户态代理（已淘汰）	性能差，仅用于兼容旧环境

iptables 模式示例规则：

# 查看 Service 规则链
sudo iptables -t nat -L KUBE-SERVICES | grep <service-name>
# 规则示例：将目标为 ClusterIP 的流量转发到 Pod
-A KUBE-SERVICES -d 10.96.123.45/32 -j KUBE-SVC-XXXXXX

阶段 3：负载均衡到后端 Pod

• EndpointSlice 关联：
  • Service 通过 LabelSelector 关联 Pod，Pod IP 列表存储在 EndpointSlice 对象中。
  • 示例查看命令：

    kubectl get endpoints <service-name>
    kubectl get endpointslices -l kubernetes.io/service-name=<service-name>
    

• 负载均衡逻辑：
  • iptables/IPVS 根据概率或算法（如轮询）选择后端 Pod。
  • 会话保持（SessionAffinity）：若配置 service.spec.sessionAffinity: ClientIP，则相同客户端 IP 会路由到同一 Pod。

阶段 4：到达 Pod 容器网络

• CNI 插件路由：
  • 流量通过节点上的 veth pair 进入 Pod 网络命名空间。
  • 不同 CNI 插件实现方式：
    • Calico：基于 BGP 或 VXLAN 跨节点路由。
    • Flannel：通过 overlay 网络（如 VXLAN）封装流量。

---

2. 完整路径示例（以 iptables 模式为例）

1. 客户端 Pod 发起请求：curl http://my-svc:80
2. CoreDNS 解析 my-svc 为 ClusterIP（如 10.96.123.45）。
3. 内核协议栈 匹配到目标 IP 为 Service IP，进入 KUBE-SERVICES iptables 链。
4. iptables 将目标 IP 替换为 Pod IP（DNAT），并通过 KUBE-SEP-XXXX 链选择具体 Pod（如 10.244.1.2:80）。
5. 节点网络栈 根据路由表将流量发送到目标 Pod 所在节点（若跨节点）。
6. 目标节点 的 CNI 插件通过 veth pair 将流量送入目标 Pod 的容器网络空间。

---

3. 面试回答示例

面试官：
“Service 的流量是如何路由到 Pod 的？具体路径是什么？”

回答：
“Service 流量路由的核心路径分为四步：

1. 请求发起：客户端通过 Service 域名（如 my-svc.default.svc.cluster.local）解析到 ClusterIP。
2. kube-proxy 拦截：
   • 在 iptables 模式下，节点内核通过 KUBE-SERVICES 链将 ClusterIP 的请求 DNAT 为后端 Pod IP（从 EndpointSlice 获取）。
   • 例如，10.96.123.45:80 → 10.244.1.2:80。
3. 负载均衡：iptables 按概率随机选择 Pod（或 IPVS 按配置的算法调度）。
4. 跨节点路由：若 Pod 在其他节点，Calico/Flannel 会通过 overlay 网络封装流量到目标节点。

我们曾用 iptables -t nat -L -v 排查过 DNAT 规则丢失导致的 Service 不可用问题，最终发现是 kube-proxy 异常重启导致规则未刷新。”

---

4. 深入追问与应对

(1) 如果 Pod 和客户端在同一节点？

→ “流量直接通过节点的 veth pair 进入目标 Pod，不经过跨节点网络（性能更高）。”

(2) NodePort 和 LoadBalancer 的区别？

→ “NodePort 会在所有节点开放同一端口（通过 KUBE-NODEPORTS 链），而 LoadBalancer 依赖云厂商的 LB 将外部流量导到 NodePort。”

(3) 如何验证路由路径？

→ “工具链：

• kubectl get endpoints <svc> 确认 Pod IP 列表。
• iptables -t nat -L KUBE-SERVICES -v 查看规则命中计数。
• tcpdump -i eth0 host <pod-ip> 在 Pod 所在节点抓包。”

---

5. 关键总结

• kube-proxy 是路由的核心，理解其模式（iptables/IPVS）差异。
• CNI 插件 负责跨节点 Pod 间通信。
• 排障能力：熟悉 iptables/IPVS 命令和 DNS 解析流程。