istio与nginx是分层协作关系：nginx作为边缘入口负责tls终止、粗粒度路由、限流和waf，istio专注网格内细粒度路由、熔断重试、mtls及可观测性，通过职责分离与流量接力实现无缝配合。
云原生架构下，Istio 和 Nginx 并非替代关系，而是分层协作：Nginx 通常作为边缘入口（Ingress 或 API 网关）处理最外层的 HTTP 路由、TLS 终止、WAF、限流等，而 Istio 则专注网格内部的服务间通信治理。二者配合的关键在于**职责分离 + 流量接力**——Nginx 把请求“交棒”给 Istio 管理的集群，后续所有服务调用、版本路由、熔断重试等均由 Istio 在 Sidecar 层完成，无需业务感知。
明确角色边界：Nginx 做什么，Istio 做什么
✅ Nginx（或 Nginx Ingress Controller）负责：
- 面向公网的 TLS 卸载与证书管理
- 基于 Host / Path / 请求头的粗粒度路由（如
api.example.com/v1→ 后端 Service） - 全局速率限制（如每 IP 每秒 100 请求）
- 静态内容缓存、Gzip 压缩、WAF 规则匹配
✅ Istio 负责：
- 网格内服务调用的细粒度路由（如 95% 流量到 user-v1，5% 到 user-v2）
- 基于延迟、错误率的自动熔断与重试（如超时 2s 后重试 2 次，退避 250ms）
- 服务间 mTLS 加密与双向认证
- 全链路追踪（Jaeger）、指标采集（Prometheus）、访问日志（Envoy access log）
典型协作流程：从用户请求到服务实例
一个完整请求路径如下：
- 用户访问
https://shop.example.com/api/user - Nginx Ingress Controller 接收请求，验证 TLS、检查 WAF 规则、执行全局限流
- Nginx 将请求转发至 Kubernetes Service（如
user-svc），该 Service 后端是启用了 Istio 自动注入的 Pod - 请求首先进入 Pod 内的 Envoy Sidecar，Sidecar 根据
VirtualService和DestinationRule执行灰度路由 - Sidecar 将流量按权重发往
user-v1或user-v2的具体实例，并在转发前执行超时、重试、熔断检查 - 若 user-v1 需调用 order-service，该调用同样经过其自身 Sidecar，继续由 Istio 控制
关键配置衔接点
要让两者无缝协作，需注意三个技术衔接：
-
Service 名称对齐：Nginx Ingress 的
backend.service.name必须与 Istio 中定义的DestinationRule.host一致（例如都用user-svc.demo-app.svc.cluster.local） -
Host 头透传：Nginx 需保留原始 Host 头（或显式设置
proxy_set_header Host $host;），否则 Istio 的 VirtualService 基于 Host 的路由会失效 -
健康探针兼容：Nginx 的 readiness check 应探测业务容器端口（如
:8080/health），而非 Sidecar 端口；Istio 的健康检查由 Envoy 自动管理，不干扰 Nginx 探测逻辑
进阶场景示例：灰度发布 + 外部限流兜底
假设你上线用户服务 v2，希望：
- 内部：80% 流量走 v1，20% 走 v2（由 Istio 控制）
- 外部：只允许特定 Header（
X-Canary: true）的请求进入 v2，且每分钟最多 100 次（由 Nginx 实现）
做法是：
- 在 Nginx Ingress 的 annotation 中添加限流策略：
nginx.ingress.kubernetes.io/limit-rpm: "100"，并配合nginx.ingress.kubernetes.io/configuration-snippet判断 Header 决定是否转发到 v2 的专用 Service - Istio 层保持默认路由（v1 主力），仅当 Nginx 显式将带标头的请求打到
user-canary-svc时，才通过独立的 VirtualService 将其导向 v2 子集
这样既利用 Nginx 快速拦截非法请求，又保留 Istio 对 v2 实例的精细化治理能力（如 v2 出错时自动降级回 v1）。
