Ambassador 1.0: API Gateway for Kubernetes

Introduction

If your cluster is past the “one ingress, a few services” stage, you eventually need more than basic routing: request authentication, rate limits, sane timeouts, and a way to debug what happened at the edge.

Ambassador 1.0, released on September 20, 2018, positioned itself as a Kubernetes-native API gateway built on Envoy. The pitch is simple: configure the gateway using Kubernetes resources, get dynamic updates without restarts, and add API-gateway features (rate limiting, auth, observability) without hand-rolling NGINX templates.

Kubernetes-Native Configuration

• Annotations-based configuration enables managing routing rules through Kubernetes annotations.
• Dynamic updates provide instant configuration changes without gateway restarts.
• CRD support enables managing gateway configuration as Kubernetes resources.
• Declarative approach ensures configuration is version-controlled and GitOps-friendly.

Core Features

1. Routing capabilities provide sophisticated path-based and header-based routing.
2. Rate limiting enables protecting backends from traffic spikes and abuse.
3. TLS termination provides automatic certificate management and HTTPS support.
4. Load balancing delivers intelligent traffic distribution across service instances.

Observability

• Metrics integration exposes detailed gateway metrics for Prometheus.
• Distributed tracing support enables correlation of requests across services.
• Access logs provide detailed request/response logging for debugging.
• Dashboard integration enables visualization of gateway traffic and health.

Getting Started

kubectl apply -f https://www.getambassador.io/yaml/ambassador/ambassador-rbac.yaml
kubectl apply -f https://www.getambassador.io/yaml/ambassador/ambassador-service.yaml

Create a Mapping:

apiVersion: ambassador/v1
kind: Mapping
metadata:
  name: backend-mapping
spec:
  prefix: /backend/
  service: backend-service:8080
  timeout_ms: 3000
  rate_limits:
  - name: basic
    requests_per_second: 100

When to use an API gateway (vs “just Ingress”)

• Ingress is a great baseline for L7 routing, but it tends to stop at “get traffic to the Service.”
• An API gateway becomes compelling when you need consistent cross-cutting controls: auth, quotas, retries/timeouts, per-route observability, and policy that’s shared across teams.

If you already run a service mesh, think of the gateway as “the edge contract” — the place where north-south traffic gets normalized before it enters the mesh.

Practical gotchas

• Pin manifests: public install URLs can change over time; in production, prefer versioned manifests checked into Git.
• Decide on CRDs vs annotations early: mixing models across teams can make behavior harder to reason about during incidents.
• Rate limiting is a dependency: “enabled” isn’t the same as “enforced” — confirm the rate limit service is reachable and that failure modes are what you expect.

Summary

Ambassador 1.0 establishes a new approach to API gateways in Kubernetes, providing dynamic configuration and comprehensive features for managing microservices traffic.