Envoy acts as a sidecar proxy in Apigee setups, handling traffic management, observability, and security between services.

Practical Context

Apigee developers often manage API gateways and edge services, but modern setups increasingly integrate Envoy for service mesh capabilities. Envoy complements Apigee by offloading low-level networking tasks (e.g., TLS termination, retries, rate limiting) from application code, enabling consistent policy enforcement and observability across microservices.

Actionable Workflow

1. Deploy Envoy as a Sidecar

   • Inject Envoy into pods alongside Apigee-managed services using Kubernetes sideCars field or Istio mutations.
   • Validate with:

     kubectl describe pod <pod-name> | grep -i envoy  
     

2. Configure Traffic Routing

   • Define Envoy VirtualHost configurations for Apigee API routes.
   • Example snippet:

     {  
       "name": "apigee-api",  
       "domains": ["*"],  
       "routes": [  
         {  
           "match": { "prefix": "/v1" },  
           "route": { "cluster": "apigee-backend" }  
         }  
       ]  
     }  
     

3. Enable Observability

   • Expose Envoy metrics to Prometheus via --metrics-path and integrate with Apigee Analytics.
   • Check metrics:

     curl http://localhost:15000/stats/ -u admin:admin  
     

4. Apply Security Policies

   • Use Envoy’s RateLimit filters to enforce quotas independently of Apigee’s edge policies.

Policy Example: Rate Limiting

config:  
  rate_limits:  
    - window: 60s  
      tokens: 100  
      key: "x-api-key"  

Note: This decouples rate limiting from business logic but requires synchronization with Apigee’s API product configurations.

Tooling

• Envoy: Core proxy for traffic management.
• Istio: Optional for managing Envoy fleets at scale (adds complexity).
• Apigee Edge: For API lifecycle management; Envoy handles service-to-service communication.
• Prometheus/Grafana: For monitoring Envoy metrics alongside Apigee data.

Tradeoffs

• Latency: Sidecar proxying introduces minimal overhead (~1-3ms per request).
• Complexity: Managing Envoy configurations alongside Apigee policies requires careful documentation.
• Resource Usage: Envoy pods consume memory/CPU; budget ~100MB baseline per instance.

Troubleshooting

• Connectivity Failures:
  • Check Envoy listener ports:

    kubectl exec <pod> -c envoy -- nc -zv localhost 8080  
    

• Config Drift:
  • Validate Envoy config with:

    kubectl exec <pod> -c envoy -- envoy -t verbose  
    

• Missing Metrics:
  • Ensure Prometheus scrape config includes Envoy endpoints.

Prevention

• Policy Testing: Use canary deployments to validate Envoy rule changes in staging.
• Resource Quotas: Limit Envoy memory usage in production namespaces.
• Documentation: Maintain a matrix mapping Apigee API paths to Envoy route configurations.

Envoy doesn’t replace Apigee but extends it by standardizing service mesh patterns. Prioritize simplicity: avoid over-configuring Envoy if Apigee already handles the use case (e.g., basic rate limiting).

Source thread: what is Envoy to an Apigee developer?