面试题-从负载均衡访问K8S nodeport类型的pod的访问流程

从负载均衡访问K8S nodeport类型的pod的访问流程

基础知识：关于NodePort类型的pod

Kubernetes会在每个节点上分配一个静态端口（范围通常为30000-32767），并将该端口上的流量转发到Service背后的Pod。

访问流程

负载均衡器将外部流量分发到集群节点的NodePort上，再由kube-proxy转发到Service背后的Pod。

负载均衡将流量转发到某个Node节点的NodePort，

Node节点上的kube-proxy通过IPVS或iptables将请求转发到对应 Service，再根据 Service 的后端Endpoints将请求转发到具体 Pod，

最终由Pod内应用处理请求并返回响应。

完整访问链路

假设：

• Service 类型：NodePort
• NodePort：30080
• 后端 Pod：nginx

---

① 客户端 → 负载均衡器Load Banlancer（LB）

Client
  ↓
LoadBalancer (SLB / Nginx / F5)

• LB 配置后端：

  • Node1:30080
  • Node2:30080
  • Node3:30080

👉 LB 不知道 Pod 的存在，它只认识 Node。

---

② 负载均衡器 → 某个 Node 的 NodePort

LB → NodeX:30080

• 这个 Node：

  • 可能有 Pod
  • 也可能没有 Pod

⚠️ 这是 NodePort 的一个关键特性。

---

③ Node 上的 kube-proxy 接管流量（关键）

NodeX:30080
   ↓
kube-proxy

kube-proxy 做了三件事：

1. 监听 NodePort
2. 根据 Service selector 找 Endpoints
3. 建立转发规则（iptables / IPVS）

👉 kube-proxy 是 NodePort 的核心执行者

---

④ kube-proxy → Service → Endpoint

NodePort
   ↓
ClusterIP Service
   ↓
Endpoint (Pod IP:Port)

• Service 是 逻辑对象
• Endpoint 是 真实 Pod 列表

kube-proxy 会：

• 从 Endpoint 中选一个 Pod
• 转发流量过去

---

⑤ Pod 接收请求并响应

Pod (nginx)
   ↓
Response
   ↑
原路返回

---

一句话总结（可以重点记住这个）

外部流量先经负载均衡进入某个Node的NodePort，
再由该Node上的kube-proxy根据Service的Endpoint列表转发到具体Pod。

---

四、非常关键的 3 个容易被“问死”的点

1️⃣ Node 上没 Pod，为什么还能访问？

✅ 因为：

• kube-proxy 在 所有 Node 上
• 会把流量转发到 任何 Node 上的 Pod

👉 NodePort ≠ Pod 直连

---

2️⃣ kube-proxy 用的是什么机制？

• IPVS（高性能，推荐）
• iptables（之前默认，规则多）

👉 两者都是内核转发，不是用户态代理

---

3️⃣ Service / Endpoint / Pod 的关系

对象	本质
Service	虚拟 IP + 规则
Endpoint	Pod IP 列表
Pod	真正处理请求

---

加分点（面试能拉开差距）

可以补一句：

“NodePort 的流量路径较长，暴露所有 Node，
在生产环境通常配合外部负载均衡或 Ingress 使用，
而不是直接对公网暴露。”

---

一个「流程图」（脑海中要有印象）

Client
  ↓
LoadBalancer
  ↓
NodeIP:NodePort
  ↓
kube-proxy
  ↓
Service
  ↓
Endpoint
  ↓
Pod

只要能把这个顺序说清楚

这道题就已经能达到80分以上水准。

---

关于NodePort的总结

优点：NodePort不依赖额外组件，通过在每个 Node 上暴露端口，使集群外部能够访问Kubernetes服务，NodePort结合kube-proxy可以实现后端Pod的流量转发，适合做测试环境或作为外部负载均衡的接入点。

缺点：NodePort会拉长流量链路、暴露所有 Node，并增加网络与运维复杂度。

「加分回答」（可选）

“在生产环境中通常不会直接暴露 NodePort，而是作为Ingress或外部负载均衡的基础能力。”

深挖：从Ingress或者负载均衡访问NodePort架构是不是更复杂了？

一句话结论：

是更复杂了，但这是“受控复杂度”，而不是“无序复杂度”。

---

从链路上看，确实多了组件：

Client
  ↓
LB / Ingress
  ↓
Service
  ↓
Pod

相比直接 NodePort：

Client
  ↓
NodeIP:NodePort
  ↓
Pod

👉 组件多了，步骤多了，这是“表象复杂度”。

---

但生产环境真正怕的不是“组件多”

生产环境最怕的是：

• 不可控
• 不可观测
• 不可扩展
• 不可隔离

而 Ingress / LB 正是在“消灭这些风险”。

Ingress / LB 可以把“混乱”集中到“一个地方”。

NodePort 的复杂度是：

• 每个 Node 都暴露端口
• 防火墙、ACL、端口冲突难控
• 排错要查很多节点

Ingress / LB 的复杂度是：

• 集中在入口层
• 后端集群保持干净

👉 复杂度被收敛了，而不是扩散了。

---

Ingress / LB 带来的能力包括：

• HTTPS 终止
• 统一证书管理
• 路由规则
• 灰度 / 限流 / 鉴权
• 访问日志

这些能力即使没有 Ingress，迟早也需要自己去实现，

站在运维工程师角度看，短期可能导致学习成本上升，
但是长期收益显著，包括但不限于：

• 排错路径清晰
• 责任边界明确
• 变更影响可控

👉 这是典型的“前期复杂，后期省力”。

---

补充：一个非常重要的架构区分（必须明确）

类型	特点
必要复杂度	为了可靠性、扩展性、治理能力
意外复杂度	临时方案、补丁、历史包袱

Ingress / LB 属于前者。
NodePort 滥用往往会制造后者。

---

面试时可以直接使用的表述

“Ingress 和负载均衡确实引入了额外组件，但它们把访问控制、证书、路由等复杂度集中在入口层，使集群内部保持简单和可治理，这在生产环境是必要的架构取舍。”

一个简单的类比

• NodePort：
  👉 每个房间都开一扇对外的门
• Ingress / LB：
  👉 统一大门 + 门禁 + 前台

门多不是安全，门少但可控才是。