Gateway Does Not Always Mean the Same Thing
- date
- category
- Networking
- also in
- Containers
- reading
- 2 min / 369 words
During an ingress-nginx migration, it is easy to hear:
we are moving to gateway
That sentence says almost nothing.
A gateway can be a product, an architectural role, a proxy at the edge of a cluster, or a set of Kubernetes resources.
If we do not split that apart, this question sounds reasonable:
does Gateway API replace an API gateway?
but it mixes two layers.
API gateway
An API gateway usually sits in front of applications and handles application or product behavior.
Typical features:
authentication
authorization
rate limiting
request validation
response transformation
API keys
developer portal
usage plans
This is where an organization often encodes rules for consuming an API.
A typical problem:
a client may send 1000 requests per minute
a partner has a different limit
/admin requires another policy
That is not automatically a Kubernetes problem.
It can be solved by Kong, Apigee, AWS API Gateway, Azure API Management, or a custom layer in front of services.
Ingress gateway
An ingress gateway is where traffic enters a cluster.
Typical features:
listen on 80 and 443
terminate TLS
match Host header
match path
route to Service
This is where ingress-nginx has lived for years.
In that model, Ingress declared:
this host and this path route to this Service
The controller turned that into proxy configuration.
That is closer to platform infrastructure than to product API management.
Service mesh gateway
A service mesh has a different boundary problem.
When traffic enters or leaves the mesh, you need to control the edge between:
world outside the mesh
world inside the mesh
A mesh gateway can handle:
mTLS
service identity
traffic policy
routing between clusters
egress control
It can still look like a gateway, because there is a proxy somewhere.
But the point is different: not only how traffic enters the cluster, but how it enters a model with service identity and mesh policies.
Cloud load balancer gateway
In a cloud environment, gateway can also be a way to request infrastructure.
A Kubernetes manifest can cause a resource outside the cluster to appear:
external load balancer
public IP
managed certificate
WAF policy
regional backend
Then the gateway is not only a proxy in a Pod.
It is an infrastructure declaration that a controller maps to cloud provider services.
Kubernetes Gateway API
Kubernetes Gateway API is not one gateway.
It is a resource model:
GatewayClass
Gateway
HTTPRoute
GRPCRoute
ReferenceGrant
policies
An implementation can be based on Envoy, NGINX, HAProxy, Traefik, Cilium, Istio, or cloud provider mechanisms.
So the question is not:
are we using Gateway API or Envoy?
It is:
are we using Gateway API, and if so, which implementation realizes that contract?
The simplest split
For an ingress-nginx migration, keep this split in mind:
Gateway API
= configuration language in Kubernetes
Gateway controller
= implementation of that language
Gateway
= concrete traffic entry point
API gateway
= often a broader product feature set
That prevents a bad migration.
The goal is not to replace the word Ingress with the word Gateway.
The goal is to decide which behaviors belong in portable Kubernetes API and which ones still belong to a product or implementation.