Every request to your app has to get *in* somehow — past DNS, through TLS termination, routed to the right service. The component that owns that front door is an API gateway / ingress controller, and Kong is one of the most widely deployed. This guide explains what an API gateway does, how Kong works, and where it sits in the request path.
What an API gateway is
An API gateway is a reverse proxy that sits in front of your services and handles cross-cutting concerns so each service doesn't have to:
- Routing: send
/api/usersto the user service,app.example.comto the frontend. - TLS termination: decrypt HTTPS at the edge.
- Authentication: validate keys, JWTs, or OAuth before requests reach your code.
- Rate limiting: cap requests per client.
- Observability: log, trace, and meter traffic in one place.
- Transformation: rewrite headers, paths, or payloads.
Without a gateway, every service reimplements auth, rate limiting, and TLS. With one, those live at the edge, consistently.
What Kong is
Kong is an open-source API gateway built on top of nginx and the OpenResty/LuaJIT stack, which is why it's fast and battle-tested under load. Its defining feature is a plugin architecture: core Kong does proxying and routing, and capabilities like auth, rate limiting, and logging are plugins you attach to routes or services.
Kong runs in two main shapes:
- Traditional gateway: a standalone proxy configured via its Admin API or declarative config.
- Kubernetes Ingress Controller: Kong watches Kubernetes Ingress/Gateway resources and configures itself automatically as services come and go.
Core Kong concepts
| Concept | What it is |
|---|---|
| Service | An upstream your gateway proxies to (your app) |
| Route | Rules (host, path, method) that map requests to a Service |
| Plugin | A unit of behavior (auth, rate-limit, logging) on a Route/Service/global |
| Consumer | An identified client, used for auth and rate limiting |
| Upstream | A set of targets for load balancing across instances |
A request flows: match a Route → run its Plugins → proxy to the Service's Upstream targets.
How routing works
Kong matches incoming requests against route rules. A declarative snippet:
services:
- name: my-app
url: http://my-app.default.svc:8080
routes:
- name: app-route
hosts:
- app.example.com
paths:
- /
plugins:
- name: rate-limiting
config:
minute: 100This routes app.example.com to the my-app service and caps each client at 100 requests/minute. In Kubernetes, you'd typically express this via Ingress annotations or Gateway API resources, and Kong reconciles automatically.
As a Kubernetes ingress controller
In Kubernetes, "ingress" is the layer that exposes services to the outside world. An *ingress controller* is the actual proxy that implements your ingress rules. Kong as an ingress controller:
- 1Watches the Kubernetes API for Ingress/Gateway/Service resources.
- 2Translates them into Kong routing config.
- 3Proxies live traffic, applying any attached plugins.
When you deploy a new service or change a route, Kong updates without a manual reconfigure — essential in a dynamic platform where apps come and go constantly.
Where Kong sits in the request path
For a request to a PandaStack app, the path looks like:
User → Cloudflare DNS → Kong ingress (TLS, routing) → GKE Service → your app podKong terminates TLS, matches the host/path to the right service, applies any edge policy, and forwards to your container. Because it's the single front door, it's also the natural place to capture server-side metrics and analytics — which is exactly how PandaStack records request data into ClickHouse without requiring any client-side SDK in your app. The gateway already sees every request; metering there is both accurate and zero-instrumentation.
Why platforms standardize on a gateway
Centralizing the edge buys you:
- Consistent security: auth and rate limiting enforced uniformly, not per-service.
- Operational leverage: one place to add logging, tracing, or a WAF.
- Decoupling: services don't need public IPs or their own TLS; they sit behind the gateway.
- Traffic control: canary routing, blue/green, and weighted splits at the edge.
This is why PandaStack uses Kong ingress across its multi-region GKE setup: it's the consistent, programmable control point for routing, TLS, and traffic policy, and it scales to many tenants and services.
Kong vs other ingress options
Kong isn't the only choice — NGINX Ingress, Traefik, Envoy-based gateways, and cloud-native gateways all compete here. Kong's differentiators are its mature plugin ecosystem and its dual identity as both a full API-management gateway and a Kubernetes ingress controller. If you only need basic ingress, lighter controllers may suffice; if you want auth, rate limiting, transformations, and analytics at the edge, a full gateway like Kong earns its keep.
References
- [Kong Gateway documentation](https://docs.konghq.com/gateway/latest/)
- [Kong Ingress Controller](https://docs.konghq.com/kubernetes-ingress-controller/latest/)
- [Kubernetes Ingress concept](https://kubernetes.io/docs/concepts/services-networking/ingress/)
- [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/)
- [OpenResty (nginx + LuaJIT)](https://openresty.org/en/)
---
On PandaStack, Kong handles routing, TLS, and edge metering so your app just serves requests — no ingress config, no cert management. Deploy a service and get a live URL with automatic SSL at [dashboard.pandastack.io](https://dashboard.pandastack.io).