Gateway API Slides

Transcript

1. 15.10.2025 by Mücahit Ündemir Gateway API Routing Reinvented: The Rise of Gateway API over Ingress Welcome to a deep dive into the evolution from traditional Ingress to the modern Gateway API
2. 15.10.2025 2 Agenda Ingress Introduction Missing Features with Ingress What is Gateway API? Why use Gateway API? Implementation & Transition Demo Q&A
3. Ingress
4. 15.10.2025 4 Ingress What: Ingress is a Kubernetes resource used to manage external access to services within a cluster Usage: Utilizes Ingress Controllers (e.g., NGINX, Traefik) to route HTTP and HTTPS traffic to backend services Why: Simplifies the process of exposing services to the internet by consolidating routing rules in a single resource Common Scenarios: HTTP(S) routing based on hostnames or paths SSL termination for secure communication Basic load balancing across multiple backend pods
5. 15.10.2025 5 Ingress | Simple Example rules: # this configuration for traffic split - host: example.com http: paths: - path: / backend: service: name: service-v1 weight: 80 - path: / backend: service: name: service-v2 weight: 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14
6. 15.10.2025 6 Ingress Advanced Traffic Management Limited support for complex routing rules like weighted traffic splitting or header-based routing Example: Cannot natively split 80% of traffic to v1 and 20% to v2 of a service | Limitations: Traffic Split rules: # this configuration for traffic split - host: example.com http: paths: - path: / backend: service: name: service-v1 # won't weight: 80 - path: / backend: service: name: service-v2 # work weight: 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14
7. 15.10.2025 7 Ingress | Limitations: Traffic Split apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-v2 annotations: # workaround configuration for ingress-nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "20" nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: service-v2 port: number: 80 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
8. 15.10.2025 8 Ingress Standardization Issues Different Ingress Controllers (e.g., NGINX, Traefik, HAProxy,…) implement features differently Example: Annotations for configuring the ingress vary between controllers | Everywhere somehow different apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example annotations: traefik.ingress.kubernetes.io/service-weights: | service-v1: 80% service-v2: 20% spec: ingressClassName: traefik 1 2 3 4 5 6 7 8 9 10
9. 15.10.2025 9 Ingress Scalability Challenges in managing large-scale environments with dynamic traffic patterns Example: Handling thousands of routes or services can lead to performance bottlenecks Security & Observability Lacks fine-grained security policies like per-route authentication or authorization Example: Cannot enforce mTLS or JWT validation directly in Ingress Limited observability tools for monitoring traffic metrics or debugging issues Extensibility Difficult to integrate new features or custom configurations Example: Adding support for advanced protocols like gRPC or WebSockets often requires workarounds | More Issues
10. 15.10.2025 10 Why Move Beyond Ingress? The limitations of Ingress highlight the need for a more flexible and standardized solution, paving the way for the Gateway API
11. Gateway API
12. 15.10.2025 12 Gateway API Evolving Standard: A new set of Kubernetes APIs designed to overcome Ingress limitations Improved Design: Offers a more flexible and expressive model for routing and traffic management Core Components: Gateway: Represents the actual load balancer or proxy Route: Defines how requests are routed to backend services Ecosystem: Built to work across different implementations with a standardized approach | What’s that?
13. 15.10.2025 13 Gateway API Enhanced Flexibility: Fine-grained control over routing and traffic policies Better Standardization: Uniform API across different vendors and implementations Scalability: Optimized to manage complex, large-scale environments Security & Observability: Improved mechanisms for enforcing security and monitoring traffic Future-Proofing: Designed to evolve with the growing needs of Kubernetes networking | Why use it?
14. 15.10.2025 14 Gateway API Built on CRDs: GatewayClass , Gateway , HTTPRoute , TLSRoute - Clear separation of concerns - Ops handle infra with GatewayClass/Gateway - Devs focus on HTTP/TLS routes | Ownership Model
15. 15.10.2025 15 Gateway API | HTTPRoute rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: example-service port: 80 1 apiVersion: gateway.networking.k8s.io/v1 2 kind: HTTPRoute 3 metadata: 4 name: example-http-route 5 spec: 6 parentRefs: 7 - name: example-gateway 8 hostnames: 9 - "example.com" 10 11 12 13 14 15 16 17
16. 15.10.2025 16 Attaching Routes to Gateways Routes connect to Gateways to configure how traffic is exposed. Both resources offer controls to restrict or allow attachments, supporting organizational policies. Attachment Models: One-to-one: Single owner for both Gateway and Route One-to-many: Gateway serves multiple Routes from different teams Many-to-one: Routes can also be bound to more than one Gateway, allowing a single Route to control application exposure simultaneously across different IPs, load balancers, or networks
17. 15.10.2025 17 Shared vs Dedicated Gateways
18. 15.10.2025 18 Restricting Route Attachment Each Gateway listener can control which Routes may be attached using: Hostname: Only Routes with matching hostnames can attach Namespaces: Use allowedRoutes.namespaces to restrict attachment: Same (default): Only Routes in the same namespace All : Routes from any namespace Selector : Routes from namespaces matching label selectors Kinds: Use allowedRoutes.kinds to specify which Route types can attach | Gateway
19. 15.10.2025 19 Example Restriction | Gateway 12 allowedRoutes: 13 kinds: 14 - kind: HTTPRoute 15 namespaces: 16 from: Selector 17 selector: 18 matchLabels: 19 expose-apps: "true" 1 apiVersion: gateway.networking.k8s.io/v1 2 kind: Gateway 3 metadata: 4 name: prod-gateway 5 namespace: gateway-api-example-ns1 6 spec: 7 gatewayClassName: foo-lb 8 listeners: 9 - name: prod-web 10 port: 80 11 protocol: HTTP
20. 15.10.2025 20 Route Summary Table Object OSI Layer Routing Discriminator TLS Support Purpose HTTPRoute Layer 7 HTTP protocol fields Terminated only HTTP and HTTPS routing TLSRoute Layer 4– 7 SNI / TLS properties Passthrough or Terminated Routing TLS protocols (incl. HTTPS) without HTTP inspection TCPRoute Layer 4 Destination port Passthrough or Terminated Forwarding TCP streams from Listener to Backends UDPRoute Layer 4 Destination port None Forwarding UDP streams from Listener to Backends GRPCRoute Layer 7 gRPC protocol fields Terminated only gRPC routing over HTTP/2 and HTTP/2 cleartext
21. 15.10.2025 21 ListenerSets apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: httproute-example namespace: app spec: parentRefs: - name: app kind: XListenerSet sectionName: second - name: parent-gateway kind: Gateway sectionName: foo namespace: infra ... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
22. 15.10.2025 22 Recap Ingress Limitations: Traditional Ingress struggles with advanced traffic management, standardization, scalability, security, and extensibility. Gateway API Evolution: Gateway API introduces a flexible, standardized, and scalable approach for Kubernetes traffic routing. Ownership Model: Separation of concerns between infrastructure, operations, and application development using CRDs ( GatewayClass , Gateway , HTTPRoute , TLSRoute ). Advanced Features: Fine-grained route attachment, listener sets, and support for multiple protocols (HTTP, TLS, TCP, UDP, gRPC). Why Gateway API: Enhanced flexibility, better security, improved observability, and future-proof networking for Kubernetes.
23. DEMO
24. 15.10.2025 24 References https://gateway-api.sigs.k8s.io/
25. Thank You
26. 15.10.2025 26 Happy Deploying! My LinkedIn