The Kubernetes Gateway API and how it impacts Cloud Native API Management. This presentation introduces the Kubernetes Gateway API, the Envoy Gateway project and discusses how these impact the modern/cloud-native world of API Management.

1. March, 2024
The rise of the Kubernetes Gateway API and
its role in Cloud Native API Management

2. Hello!
Nuwan Dias
VP and deputy CTO - WSO2
Co-author, Microservices Security In Action
@nuwandias

3. The evolution of API Gateways
3
Credit: Pubudu Gunatilaka

4. The world of Kubernetes and how it all works
4

5. The Ingress API in Kubernetes
5
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-rule-ingress
spec:
ingressClassName: nginx
rules:
- host: api.example.com
http:
backend:
service:
name: default-api-service
port:
number: 80
- path: /admin
pathType: Prefix
backend:
service:
name: admin-service
port:
number: 8080

6. Limitations of the Ingress API
6
● HTTP Only
○ The Ingress API does not support other protocols other than HTTP.
● Limited matching rules
○ Matches based on host and path only.
● Lack of portability due to many vendor specific annotations
○ Limited functionality has led to a proliferation of vendor specific annotations,
making the resource non-portable.
● Works only on 1 namespace
○ Cannot route traffic across namespaces.
● No separation of concerns
○ App developers have to play the role of platform engineers.

7. The Kubernetes
Gateway API
7

8. The Kubernetes Gateway API - Resource Model
8
Image source: https://gateway-api.sigs.k8s.io/

9. The Kubernetes Gateway API - Infra provider and cluster operator
9
apiVersion: networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: my-provider-gatewayclass
spec:
controller: my-provider-gateway-controller
apiVersion: networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: my-provider-gatewayclass
listeners:
- name: http-listener
port: 80
protocol: HTTP
allowedRoutes:
kinds:
- kind: HTTPRoute
namespaces:
from: Selector
selector:
matchLabels:
kubernetes.io/metadata.name: ns1

10. The Kubernetes Gateway API - Application Developers
10
apiVersion: networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
hostnames:
- "foo.com"
rules:
- matches:
- path:
type: PathPrefix
value: /bar
backendRefs:
- name: my-service1
port: 8080

11. Ingress controller vs Gateway API
11
Ingress Gateway API
Traffic Routing Basic HTTP routing Header matching, weighted
routing, backend types
Extensibility With custom annotations Through CRDs
Standardization Lots of vendor specific
annotations
Has a universal API
Separation of concerns N/A Applied by design
Protocols HTTP only HTTP, TCP, UDP, gRPC, etc
Security TLS termination Supports advanced security

12. Gateway API != API Gateway

13. API Gateway vs Kubernetes Gateway API
13

14. The Envoy Gateway Project
14
● Reference: https://gateway.envoyproxy.io/
● The Kubernetes Gateway API doesn’t (yet) provide all the
features required for an API Gateway.
○ It focuses on addressing limitations of the ingress
API.
● The Envoy Gateway project provides an API that extends the
Kubernetes Gateway API.
○ This includes features required for a proper API
Gateway.

15. The Envoy Gateway Project
15
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
name: jwt-authn-policy
namespace: default
spec:
jwt:
providers:
- name: example
remoteJWKS:
uri:
https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes
/jwt/jwks.json
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: eg
namespace: default
Create a security
policy
Attach it to the
Gateway

16. Benefits of using the Gateway API configurations instead of an API
Gateway configs
16
● Standardization and Consistency
○ Abstraction - The Gateway API defines a common language and API for traffic
routing.
○ Simplicity - Separation of the “what” from the “how”.
● Better Manageability
○ Declarative approach - Developer specifies the desired routing rules. The
Gateway controller is responsible for the rest.
○ Kubernetes Integration for APIs - Makes APIs a first-class citizen in Kubernetes.
● Flexibility and Extensibility
○ Works with multiple Gateway providers - New providers can be added, old ones
can be replaced, without migrating data.
○ Future proof approach - Leaves space for new protocols and features to be
supported in the future.

17. What does this mean for modern API Management?
17
● Vendor neutral control-plane for APIs
○ With a universal configuration for
APIs, a single control-plane can
govern any gateway provider.
● API Gateways are becoming part of the
woodwork
○ Kubernetes has become the
operating system of the cloud.
○ API Gateways are now part of that
operating system.
○ You don’t focus on it anymore, you
focus on the “what”, not on the
“how”.
Universal Control
Plane
GW - 1 GW - 2 GW - 3

18. How should you prepare?
18
● Shift to using the Gateway API spec instead of relying on vendor specific configurations.
● Have a clear separation between traffic routing rules vs business logic.
○ Don’t implement business logic on the API Gateway.
○ Use BFFs for cases which require logic outside the core API.
● Treat API publishing and API deployments as two distinct practices.
○ Have a clear separation between API control plane vs data-plane.
● Use vendor specific extensions carefully.

19. Internal Developer Platforms and API Management
19
● Internal developer platforms create useful abstractions that helps developers focus
away from mundane tasks.
○ They help them focus on what’s important, their business.
● API Management is one such practise that organizations cannot live without.
○ It takes away the focus on what’s important, the actual API.
● The Kubernetes Gateway API is a universal API for managing API behaviour.
● API operations will be embedded into internal developer platforms.
● Developers will finally be able to focus on what’s important, the actual API.

20. wso2.com
Thanks!
@nuwandias