KnoAI 技术站

主题

一、先理清：kube-proxy、iptables/IPVS 各自职责 ​

1. kube-proxy（运行在每个节点上的用户态进程） ​

它不直接处理数据包转发，核心工作是【配置规则】：

  1. 持续监听 apiserver，感知 Service、Endpoint（健康Pod列表） 的新增/删除/更新；
  2. 根据代理模式（iptables / ipvs），向Linux内核下发转发规则；
  3. 维护规则同步：Pod扩缩容、服务变更时，自动更新内核转发策略；
  4. 实现会话亲和、负载均衡策略、NodePort端口映射等逻辑。

一句话总结：kube-proxy = 规则管理器；真正拦截、转发数据包的是 Linux 内核模块（iptables/netfilter / IPVS）。

2. iptables 模式（内核netfilter框架，k8s早期默认） ​

  • iptables 是 Linux 内核数据包过滤框架，kube-proxy 在节点上创建大量自定义链；
  • 当数据包目标地址为 ClusterIP:Port，匹配规则后执行 DNAT：把目标IP从ClusterIP改写为某一个健康PodIP；
  • 缺点：规则是线性遍历查找，集群Service上千条时性能急剧下降；负载均衡策略只有随机。

3. IPVS 模式（内核虚拟服务器，大规模集群推荐） ​

  • IPVS 是内核原生负载均衡模块，kube-proxy 在内核创建虚拟服务（ClusterIP）+ 后端真实服务器（PodIP）；
  • 内核使用哈希表存储转发规则，查询效率O(1)，大量服务场景性能远优于iptables；
  • 支持多种负载均衡算法（轮询、加权轮询、最小连接等），支持会话保持。

3. 系统如何捕获「发往ClusterIP的请求」？ ​

ClusterIP 是虚拟IP，不存在任何网卡上，数据包依靠内核规则捕获：

  1. Pod发起请求 → 目标IP=Service ClusterIP；
  2. 数据包经过宿主机内核 netfilter 钩子；
  3. kube-proxy预先写入内核规则：匹配 目标IP=ClusterIP + 端口 的数据包；
  4. 匹配成功后触发DNAT：改写目标IP为后端PodIP，完成转发。

⚠️ 重点：不是kube-proxy进程拦包！是内核直接拦截并转发，数据包不会进入kube-proxy用户进程（早已淘汰userspace模式）。

二、两种流量完整旅程对比 ​

路径A：集群内部访问 ClusterIP（对应PPT里4步流程） ​

  1. STEP01 客户端Pod发起请求 Pod应用调用 service-name.svc.cluster.local:port，不直接访问PodIP。
  2. STEP02 CoreDNS域名解析 集群内DNS将服务域名解析为Service虚拟IP ClusterIP。
  3. STEP03 数据包抵达节点内核，被 iptables/IPVS 规则捕获 内核识别目标地址是ClusterIP，触发预先由kube-proxy下发的转发规则。
  4. STEP04 DNAT转发至Endpoint（Pod） 内核选中一个健康PodIP，修改数据包目标地址（DNAT）；数据包经由集群网络转发到目标Pod； Pod回包时内核自动做反向地址转换，响应正常返回客户端。

路径B：外部流量 NodeIP:NodePort 完整流量旅程（重点） ​

假设：外部客户端访问 节点IP:NodePort（30xxx端口）

  1. 外部客户端发送数据包 → NodeIP:NodePort 数据包先到达集群某节点宿主机网卡。
  2. 内核匹配kube-proxy配置的NodePort规则 iptables/IPVS捕获访问该宿主机NodePort端口的流量；规则自动将流量转发至对应Service的ClusterIP:ServicePort。
  3. 复用ClusterIP转发逻辑 内核再次匹配ClusterIP规则，执行DNAT，随机挑选一个健康PodIP。

⚠️ 关键点：Pod不一定运行在当前节点！

  1. 两种分支：
  • 选中的Pod运行在当前节点：数据包直接转发到本机Pod；
  • 选中的Pod运行在其他节点：数据包通过集群网络跨节点转发到目标节点Pod。
  1. 应答回流（SNAT） 默认情况下节点会做SNAT：把数据包源IP修改为本节点IP。

副作用：后端Pod日志看到的源IP是节点IP，看不到真实客户端IP；如需保留源IP需要配置 externalTrafficPolicy: Local（限制流量只能转发本机Pod）。

NodePort流量简易时序 ​

外部客户端 → NodeIP:NodePort →【内核规则】→ ClusterIP →【内核DNAT】→ PodIP → Pod应用 响应原路返回。

三、高频面试区分要点整理 ​

  1. kube-proxy 不转发数据包，只负责同步内核转发规则；
  2. ClusterIP 只是虚拟IP，依靠内核netfilter/IPVS规则捕获流量；
  3. NodePort本质：节点端口流量先跳转至ClusterIP，再走相同的Pod转发链路；
  4. iptables线性遍历规则，适合小规模集群；IPVS哈希查找，适合大规模集群；
  5. NodePort默认SNAT丢失真实源IP，开启externalTrafficPolicy=Local可保留源IP，但失去跨节点负载均衡。

如果你需要，我可以把两段流量旅程整理成一页PPT文字脚本，直接适配你这张架构图。