网格与 API 网关

用户与系统的 第一跳 通常是 API 网关或反向代理；集群 内部 则靠 Sidecar。厘清 Ingress / Gateway API / Istio Gateway / Nginx / Spring Cloud Gateway 各自管哪一段，避免重复鉴权、重复 TLS 或路由规则打架。

学习目标

• 对比 Kubernetes Ingress、Gateway API、Istio Gateway
• 对照 nginx-essentials 与 sc-gateway
• 设计 CodeRoadMap 式「北向入口 + 东西向网格」拓扑

流量分段

Internet
   ↓
[Nginx / 云 LB]           ← TLS、WAF、静态资源（[ngx-proxy](/tracks/nginx-essentials/lessons/ngx-proxy)）
   ↓
[Ingress / Istio Gateway] ← K8s 北向，Host/Path 路由（[k8s-ingress](/tracks/kubernetes-essentials/lessons/k8s-ingress)）
   ↓
[Service Mesh Sidecar]    ← 东西向 mTLS、金丝雀、熔断
   ↓
业务 Pod

北向：集群外 → 集群内；东西向：服务 ↔ 服务。

Ingress vs Gateway API

	Ingress（传统）	Gateway API
模型	单一 Ingress 资源	Gateway + HTTPRoute 分角色
扩展	注解驱动，厂商差异大	更结构化，多租户友好
与 Istio	Ingress 可转 Istio	Istio 原生支持 Gateway API

Istio Gateway CRD 定义入口端口与证书；VirtualService 绑定 Gateway，决定 /api/* 进哪个内部 Service。

与 Nginx 的关系

本站生产架构（见 ngx-api）：

• /api → Spring Boot
• / → Next.js

若后端再拆微服务并上 K8s：

• 方案 A：仍用裸机 / VM 前 Nginx，后面 K8s Ingress Gateway
• 方案 B：云 LB → Istio Ingress Gateway → mesh 内服务
• 方案 C：Spring Cloud Gateway 作 BFF，后面 mesh（适合聚合 API）

ngx-k8s 说明 Nginx Ingress Controller 与裸机 Nginx 的差异——控制器 把 Ingress 规则转成 Nginx/Envoy 配置。

Spring Cloud Gateway 还要吗？

保留 Gateway 当 BFF	尽量只用网格 + Ingress
聚合多服务为一个 REST