4. Deployment 架构概览：Kubernetes Deployment、Service、Ingress 的基本概念与流量路径
在进入鉴权拦截的移植适配之前，必须首先厘清目标部署环境的核心拓扑。Kubernetes 原生提供了三个抽象层——Deployment、Service、Ingress——它们共同构成了生产级应用的流量骨架。理解每一层的职责以及请求如何穿越这些层，是后续将鉴权逻辑正确插入流量路径的前提。
4.1 三层抽象的定义与职责
| 抽象层 | API 资源 | 核心职责 | 典型场景 |
|---|---|---|---|
| 工作负载 | Deployment | 管理 Pod 副本数、滚动更新、回滚 | 无状态应用（API Server、Web 前端） |
| 服务发现与负载均衡 | Service | 为 Pod 提供稳定的虚拟 IP 和 DNS 名称，实现四层负载均衡 | 内部微服务间通信、ClusterIP 暴露 |
| 南北向流量入口 | Ingress | 基于 HTTP/HTTPS 的路由规则，将外部流量分发到内部 Service | 域名绑定、TLS 终止、路径转发 |
关键认知：Deployment 只关心 Pod 的生命周期，不关心网络可达性；Service 只关心四层转发，不关心 HTTP 语义；Ingress 只关心七层路由，不关心 Pod 扩缩。鉴权拦截的插入点必须根据这三层的边界来选择。
4.2 完整流量路径：从外部请求到 Pod 实例
下图展示了用户请求从互联网到达后端 Pod 的完整路径，以及每一层发生的网络转换。
4.3 各层关键属性对比
在移植鉴权拦截时，需要根据每一层的网络特性选择适配策略。下表从协议、可见性、拦截粒度三个维度进行对比：
| 属性 | Ingress | Service | Deployment / Pod |
|---|---|---|---|
| 协议层 | L7（HTTP/HTTPS/gRPC） | L4（TCP/UDP） | L7（应用协议） |
| 请求可见性 | 完整 HTTP 头、路径、Cookie | 仅 IP 和端口 | 完整请求体 |
| 拦截粒度 | 域名、路径、请求头 | 源 IP、端口 | 任意应用逻辑 |
| 鉴权适用性 | Token 校验、OAuth 回调 | IP 白名单 | JWT 解析、RBAC |
| 性能开销 | 中等（需解析 HTTP） | 极低（内核转发） | 取决于实现 |
移植适配陷阱：不要试图在 Service 层做 HTTP 鉴权。Service 工作在四层，无法读取 Token 或 Cookie。如果鉴权逻辑原本依赖 HTTP 头部，必须将其上移至 Ingress 层或下移至 Pod 内的 Sidecar 代理。
4.4 典型部署拓扑：鉴权拦截的三种模式
根据鉴权拦截的部署位置，业界存在三种主流模式。本课程后续章节将重点围绕模式二和模式三展开移植适配。
- 模式一：Ingress 集中式鉴权 —— 在 Ingress Controller 侧通过 Lua/Go 插件拦截所有入站请求，适合统一认证网关场景。
- 模式二：Sidecar 代理鉴权 —— 在每个 Pod 内注入 Envoy/Istio Sidecar，实现透明拦截，适合多语言微服务架构。
- 模式三：应用内嵌鉴权 —— 在业务代码中直接集成鉴权中间件，适合单体或少量服务场景。
4.5 流量路径中的关键网络转换
在移植鉴权拦截时，必须理解请求经过每一层时发生的网络地址转换，否则鉴权逻辑可能拿到错误的客户端 IP 或协议信息。
- Ingress → Service：Ingress Controller 将请求转发到 Service 的 ClusterIP（虚拟 IP），源 IP 变为 Ingress Pod 的 IP，原始客户端 IP 通常通过
X-Forwarded-For头传递。 - Service → Pod：kube-proxy 通过 iptables/IPVS 将 ClusterIP 转换为具体 Pod IP，默认使用 NAT 模式，Pod 内看到的源 IP 为节点 IP 或 Service IP。
- Pod 内 Sidecar → 业务容器：如果使用 Sidecar 模式，流量经过本地 loopback 接口转发，源 IP 为
127.0.0.1，需通过PROXY 协议或 HTTP 头保留原始信息。
移植适配要点：如果原系统鉴权依赖客户端真实 IP（如 IP 白名单），在 Kubernetes 中必须启用
externalTrafficPolicy: Local 或通过 Ingress 传递 X-Real-IP 头。否则鉴权拦截将始终看到集群内部 IP，导致白名单失效。