It depends on the architecture and requirements—there isn't a single "current" approach.
Here are the common patterns:
| Approach | When it's used | Pros | Cons |
|---|
| Kubernetes Ingress (or Gateway API) | Simple HTTP routing | Lightweight, native | Limited advanced API features |
| API Gateway (e.g. Spring Cloud Gateway, Kong, Ambassador, APISIX) | Authentication, rate limiting, request transformation, API management | Rich API features | Additional component to operate |
| Service Mesh (e.g. Istio, Linkerd) | Service-to-service traffic | mTLS, traffic shaping, observability | Doesn't replace an API gateway for external APIs |
| Direct Kubernetes Services | Internal microservice communication | Simple, fast | No centralized policy |
A common modern architecture looks like:
Internet
│
Load Balancer
│
Ingress / Gateway API
│
API Gateway (optional)
│
Kubernetes Services
│
Pods
or, for simpler deployments:
Internet
│
Load Balancer
│
Ingress Controller
│
Services
│
Pods
Do teams still use Spring Cloud Gateway?
Yes. It's still a solid choice, particularly when:
- Your backend is already based on the Spring ecosystem.
- You want gateway logic implemented in Java.
- You need JWT validation, routing, filters, circuit breakers, or custom request handling.
It's common in Spring Boot microservice environments.
Do teams still use Kong?
Yes. Kong remains popular for:
- API management
- OAuth/JWT authentication
- Rate limiting
- Developer portals
- Multi-language environments
- Kubernetes via its ingress controller
Many organizations choose Kong when they want a gateway independent of their application framework.
Can Kubernetes handle routing by itself?
Kubernetes provides:
- Service discovery
- Load balancing
- Ingress or Gateway API resources
- Network policies
However, Kubernetes alone does not provide many API gateway capabilities such as:
- API keys
- Per-client rate limiting
- Request/response transformation
- Developer portals
- Advanced authentication
- API analytics
Those features typically come from an API gateway.
Current trend
Many newer Kubernetes deployments are moving toward:
- Gateway API instead of the older Ingress API for more expressive routing.
- A dedicated API gateway only when advanced API management is needed.
- A service mesh for internal traffic, separate from external API management.
So rather than replacing API gateways entirely, Kubernetes has taken over basic routing, while API gateways are used when organizations need richer API functionality. This separation keeps infrastructure simpler for straightforward applications and adds gateway capabilities only where they provide clear value.
