在 AKS 上的 Kubernetes Gateway API 通过 Azure Application Gateway 暴露
Source: Dev.to
介绍
我们需要通过 Azure Application Gateway 将多租户 AKS 集群中的 Kubernetes Gateway API 暴露出来。最初的集成失败了：健康探针显示不健康，后端也显示不健康，流量无法通过。本文档记录了一个可行的解决方案，并为面临相同挑战的团队提供参考架构。完整的解决方案可在 GitHub 上获取。
概念验证概述
该概念验证演示了如何在 AKS 上部署 Kubernetes Gateway API，并通过 Azure Application Gateway 在多租户环境中进行暴露。集群中部署了两个示例应用（app1 和 app2），每个应用都通过各自的 HTTPRoute 暴露，同时共享同一个 Istio Gateway 资源。
示例应用
| 组件 | 描述 |
|---|---|
sample-app-1 | Nginx pod 在路径 /app1 上返回 “Hello from App 1” |
sample-app-2 | Nginx pod 在路径 /app2 上返回 “Hello from App 2” |
health-responder | 专用 pod 用于 Application Gateway 健康探针，路径为 /healthz |
| Istio Gateway | 实现 K8s Gateway API 的共享 Gateway 资源 |
| HTTPRoutes | 应用命名空间中的按路径路由规则 |
每个应用在其命名空间中都有自己的 HTTPRoute，展示了自助式路由模型——应用团队管理路由，同时使用统一的网关基础设施。
注意： 本 POC 保持场景简洁，以聚焦 Azure 集成挑战。
app1和app2模拟运行在两个不同租户中的应用。后续文章将介绍使用 Capsule 和 Gateway API 在 Kubernetes 上实现多租户。
架构组件
| 组件 | 目的 |
|---|---|
| Azure Application Gateway | 具有 WAF 和 TLS 终止的公共入口点 |
| Internal Load Balancer | 将 Application Gateway 连接到 AKS 集群 |
| Istio Gateway | 实现 Kubernetes Gateway API |
| HTTPRoutes | 为租户提供每个命名空间的路由规则 |
| Istio Ambient Mesh | 在服务之间实现无 sidecar 的 mTLS |
实现挑战与解决方案
问题 1：健康探针失败
问题 – Azure Application Gateway 的健康探针返回 404，因为 Istio 的 Envoy 代理没有匹配探针路径的 HTTPRoute。
解决方案 – 创建一个显式的 HTTPRoute，匹配健康探针路径并将请求转发到 health‑responder Pod。
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: health-route
namespace: gateway-health
spec:
parentRefs:
- name: shared-gateway
namespace: istio-ingress
rules:
- matches:
- path:
type: PathPrefix
value: /healthz
backendRefs:
- name: health-responder
port: 8080问题 2：Azure DSR 的 ExternalTrafficPolicy
问题 – Azure 内部负载均衡器以直接服务器返回（DSR）模式运行。使用默认的 externalTrafficPolicy: Cluster 时，kube‑proxy 在跨节点转发流量时会进行 SNAT，破坏 DSR 所需的非对称路由，导致连接超时。
解决方案 – 为 Gateway Service 打补丁，将 externalTrafficPolicy 设置为 Local，确保流量仅路由到接收请求的节点上的 Pod，从而保持 DSR 流程。
kubectl patch svc -n \
-p '{"spec":{"externalTrafficPolicy":"Local"}}'