Yes, the Kubernetes Gateway API is intended to be an evolution and successor to the traditional Ingress API in Kubernetes.

Table of Contents

Toggle

First lets understand the differnce between ingress vs egress traffic

Ingress = something from outside coming in

Egress = something from inside going out

Now, Lets understand what are the ingress options we have in Kubernetes

• Kubernetes NodePort Service
• Kubernetes LoadBalancer Service
• Kubernetes Ingress Resource (Legacy)
• Kubernetes Gateway API (Modern)

Now, Lets understand How Kubernetes Ingress resources works?

Components of Kubernetes Ingress

There are primarily three main components that make up a functional Kubernetes Ingress setup:

1. Ingress Resource (Kubernetes Object)
2. Ingress Controller
3. Load Balancer (Optional, based on infrastructure)

Let’s understand each clearly:

1. Ingress Resource

• It’s a Kubernetes API object (Ingress) defined in YAML.
• Defines how external HTTP/HTTPS traffic is routed to Kubernetes services based on rules like host and path.

2. Ingress Controller

• Ingress Controller is a specialized controller pod running inside Kubernetes.
• Continuously monitors Kubernetes Ingress objects and updates its internal configuration based on these definitions.

Examples of popular Ingress Controllers:

• NGINX Ingress Controller (most common)
• Traefik
• AWS Load Balancer Controller (ALB)
• HAProxy Ingress
• Contour (Envoy-based), etc.
• Ingress Controllers do:
  • Watch Kubernetes API for changes in Ingress resources.
  • Dynamically update configurations (e.g., NGINX config, Traefik config, Envoy proxy settings).
  • Perform L7 routing (based on hosts/paths), SSL termination, and load balancing.

3. Load Balancer (Optional Component)

• External load balancer (like AWS ELB, ALB, GCP LB, Azure LB, or MetalLB) provides a single entry point (external IP) to your Ingress Controller pods.
• If you’re on a cloud-managed Kubernetes service (e.g., EKS), this load balancer is typically automatically created by setting the ingress controller’s service type to LoadBalancer.
• It distributes incoming external traffic across multiple Ingress Controller pods, ensuring high availability and scalability.

4. Ingress Controller Pod (Deployed as Deployment or DaemonSet)

• This component runs inside Kubernetes as pods (part of Deployment or DaemonSet).
• Continuously updates load-balancing rules as per changes in Ingress resources.
• Manages configurations for the underlying proxy (NGINX, Traefik, Envoy, HAProxy, etc.)

How the Components Work Together:

External Traffic
      |
Load Balancer (e.g., AWS ELB/ALB, NGINX)
      |
Ingress Controller Pods (e.g., NGINX or Traefik)
      |
Ingress Resource YAML rules (Routing Rules)
      |
Kubernetes Service
      |
Application Pods

• External traffic hits a Load Balancer.
• The load balancer forwards traffic to your Ingress Controller pods.
• The Ingress Controller checks the Ingress Resource rules from Kubernetes API.
• It routes requests to the correct Kubernetes Services and ultimately to Pods.

Now, Lets understand Kubernetes Gateway API

Here’s a clear, precise, and practical overview of:

---

What is Kubernetes Gateway API?

The Kubernetes Gateway API is a modern, standardized set of Kubernetes resources designed to route and manage network traffic into, out of, and within Kubernetes clusters.

It’s a successor and evolution to the traditional Kubernetes Ingress Resource, created to solve limitations of the legacy Ingress and support advanced use cases in a standardized, extensible, and portable manner.

---

Why was Gateway API Created?

• Traditional Ingress had limitations:
  • HTTP/HTTPS only, limited multi-protocol support.
  • Complexity with vendor-specific annotations.
  • Lack of advanced routing and traffic management features.
  • Poor support for multi-team and multi-tenant scenarios.

The Gateway API addresses these gaps by introducing a cleaner, standardized, and more flexible set of APIs.

---

Key Components of Gateway API

Gateway API introduces several new Kubernetes objects:

1. GatewayClass
2. Gateway
3. HTTPRoute, TCPRoute, UDPRoute (and other route types)
4. ReferenceGrant (security-related resource)

---

1. GatewayClass

• Defines a type of load balancer or gateway, managed by a specific controller.
• Similar conceptually to StorageClass for persistent storage.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: aws-alb
spec:
  controller: ingress.k8s.aws/alb

---

2. Gateway

• Represents the actual load balancer instance or network gateway itself.
• Defines listeners (protocols, ports), certificates, and overall traffic entry points.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
spec:
  gatewayClassName: aws-alb
  listeners:
  - protocol: HTTPS
    port: 443
    name: https
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-cert

---

3. HTTPRoute (TCPRoute, UDPRoute, etc.)

• Defines detailed routing rules based on hostnames, paths, headers, etc.
• Routes attach to Gateways.

Example HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
spec:
  parentRefs:
  - name: main-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/api"
    backendRefs:
    - name: api-service
      port: 80

---

4. ReferenceGrant

• Manages security by explicitly allowing namespaces to reference resources across namespace boundaries.
• Prevents unauthorized cross-namespace configurations.

---

High-Level Architecture of Gateway API

External Traffic
      |
 Gateway (Load Balancer/Proxy)
      |
 HTTPRoute/TCPRoute Rules
      |
 Kubernetes Service
      |
 Application Pods

• Gateway: Entry point for network traffic, defined through a GatewayClass.
• Route Resources: Define how traffic flows to internal services.
• GatewayClass: Connects Gateways to Controllers (Istio, AWS ALB, Contour, etc.).

---

Key Benefits of Kubernetes Gateway API

• Standardized & Vendor-Neutral
  • Works consistently across multiple Kubernetes providers (AWS, GKE, Azure).
• Advanced Traffic Management
  • Multi-protocol support (HTTP, HTTPS, TCP, UDP).
  • Rich routing capabilities: header-based, weighted, and path-based routing.
• Role-based Access Control (RBAC)
  • Separate Gateway and Route resources allowing multiple teams to securely manage traffic.
• Multi-tenant Friendly
  • Clear separation between infrastructure operators (Gateways) and application developers (Routes).
• Extensible & Portable
  • Clear APIs enable easy extension and interoperability across environments.

---

Controllers Supporting Gateway API:

• AWS Gateway API Controller (ALB integration)
• Istio Gateway
• Traefik Gateway API Controller
• Contour (Envoy-based)
• Ambassador Edge Stack
• GKE Gateway Controller (Google Kubernetes Engine)

---

Ingress vs. Gateway API (Summary)

Feature	Ingress Resource (Legacy)	Gateway API (Modern)
Routing	HTTP/HTTPS only	HTTP, HTTPS, TCP, UDP, gRPC, etc.
Multi-protocol Support	Limited	Extensive
Advanced Routing Rules	Limited (annotations required)	Rich, explicit API
Role Separation & Security	Limited	Explicit (Gateway & Routes)
Vendor neutrality	Poor (annotations)	Strong (standardized APIs)
Extensibility	Limited	High (designed to be extensible)

---

When Should You Use Gateway API?

• You’re running modern, production-level Kubernetes environments.
• You require advanced routing, security, observability, and multi-protocol support.
• You want clear role separation (RBAC) between infrastructure teams and developers.
• You’re looking for a standardized approach compatible with multiple Kubernetes providers.

---

Quick Practical Example (Complete):

# GatewayClass
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: external-lb
spec:
  controller: example.io/gateway-controller

---
# Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: external-lb
  listeners:
  - protocol: HTTPS
    port: 443
    name: https
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-cert

---
# HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: frontend-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/"
    backendRefs:
    - name: frontend-service
      port: 80

This simple example clearly demonstrates how Gateway API is structured and how components interact.

---

Summary (One-line):

Gateway API is the modern Kubernetes standard for flexible, secure, and advanced multi-protocol traffic routing and management in Kubernetes.

That’s the Kubernetes Gateway API explained practically, clearly, and comprehensively!