在GKE Ingress部署Apigee X：/api路径反向代理方案咨询

实现步骤 #

1. 部署反向代理服务
   用Nginx搭建中转服务，接收www.example.com/api的请求，重写URL后转发到Apigee X的api.example.com端点：

   • 创建Nginx配置的ConfigMap：

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: apigee-proxy-config
     data:
       proxy.conf: |
         server {
           listen 80;
           server_name _;
     
           location /api/ {
             proxy_pass https://api.example.com/;
             proxy_set_header Host api.example.com;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_set_header X-Forwarded-Proto $scheme;
             # 移除URL中的/api前缀，匹配Apigee代理路径
             rewrite ^/api/(.*)$ /$1 break;
           }
         }
     

   • 部署反向代理的Deployment和Service：

     # Deployment
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: apigee-proxy
     spec:
       replicas: 2
       selector:
         matchLabels:
           app: apigee-proxy
       template:
         metadata:
           labels:
             app: apigee-proxy
         spec:
           containers:
           - name: nginx
             image: nginx:alpine
             volumeMounts:
             - name: nginx-config
               mountPath: /etc/nginx/conf.d
           volumes:
           - name: nginx-config
             configMap:
               name: apigee-proxy-config
     
     # Service
     apiVersion: v1
     kind: Service
     metadata:
       name: apigee-proxy-svc
     spec:
       selector:
         app: apigee-proxy
       ports:
       - port: 80
         targetPort: 80
     

2. 修改GKE Ingress路由规则
   更新现有Ingress配置，将/api/**路径指向新的反向代理服务，保留前端根路径路由：

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-ingress
     annotations:
       kubernetes.io/ingress.class: "gce" # 根据集群环境调整（如gce-internal）
   spec:
     tls:
     - hosts:
       - www.example.com
       secretName: example-tls-secret # HTTPS场景下配置对应证书Secret
     rules:
     - host: www.example.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: frontend-svc
               port:
                 number: 80
         - path: /api/*
           pathType: Prefix
           backend:
             service:
               name: apigee-proxy-svc
               port:
                 number: 80
   

   注意：移除原有指向service1、service2的/api/service1、/api/service2路由规则，所有API流量将通过反向代理转发到Apigee X处理。

方案可行性分析 #

该方案完全可行，是GKE与Apigee X集成的典型落地方式，核心优势包括：

• 无前端侵入：前端仍保持调用www.example.com/api的原有逻辑，无需代码改造。
• 统一API管控：所有API流量经过Apigee X，可实现认证、限流、监控、日志等全生命周期管理。
• 灵活扩展：反向代理层可额外添加请求日志、头部修改等自定义逻辑，后续也可切换为Envoy等轻量化代理。

需注意的细节：

• 确保GKE集群与Apigee X网络连通：若Apigee部署在私有VPC内，需配置VPC peering或内部负载均衡实现双向访问。
• HTTPS证书验证：反向代理转发到api.example.com时，需在Nginx配置中添加proxy_ssl_verify on;验证对方证书。
• 性能影响：GKE内部部署的反向代理带来的延迟可忽略不计，不会影响业务体验。

内容的提问来源于stack exchange，提问作者Anurag