What is GatewayApi

Gateway API is an evolution of the Ingress API designed to provide a more expressive, extensible, and role-oriented standard for service networking. It is implemented as a collection of Custom Resource Definitions (CRDs) rather than a single built-in resource like Ingress.

Here is a deep dive into the architecture, configuration, and advantages of the Gateway API.

---

1. The Architecture: Role-Oriented Design

The defining feature of Gateway API is that it decouples the infrastructure provisioning (Load Balancer) from the routing configuration (Application paths). This allows different teams to manage the parts of the network stack relevant to them.

• Infrastructure Provider: Manages GatewayClass. Defines what kind of load balancers are available (e.g., Nginx, AWS ELB, Istio).
• Cluster Operator: Manages Gateway. Provisions an actual load balancer instance (e.g., "Open port 80 and 443 on Load Balancer X").
• Application Developer: Manages HTTPRoute (or GRPCRoute). Defines how traffic entering that Gateway should reach their specific Service (e.g., "Send /api/v1 to my-backend-service").

---

2. Workflow and Examples

To use Gateway API, you must first install the CRDs and a compatible controller (implementation) in your cluster.

Step 1: The GatewayClass (Infrastructure Layer)

This resource is usually cluster-scoped and strictly defines the controller that will manage the gateways.

Example YAML:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-gateway-class
spec:
  # The name of the controller that implements this class
  controllerName: example.com/gateway-controller

**

Step 2: The Gateway (Cluster Operations Layer)

The Gateway resource requests a load balancer instance. It references the GatewayClass and defines the "Listeners" (ports and protocols) that allow traffic into the cluster.

Example YAML:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: infra-ns
spec:
  gatewayClassName: example-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    # Controls which namespaces can attach Routes to this listener.
    # Here, we allow Routes from the same namespace.
    allowedRoutes:
      namespaces:
        from: Same

**

CLI Command: To verify the Gateway is programmed (an IP is assigned):

kubectl get gateway my-gateway -n infra-ns

Step 3: The HTTPRoute (Application Layer)

The application developer creates a Route. Instead of defining the port details, they simply "attach" their route to a parent Gateway. This binds traffic matching specific rules (headers, paths) to a backend Service.

Example YAML:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: infra-ns
spec:
  parentRefs:
  - name: my-gateway  # Attaches this route to the Gateway defined above
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: my-auth-service
      port: 8080

**

---

3. Advantages Over Ingress

Gateway API was designed to solve specific limitations inherent in the older Ingress API.

Feature	Ingress API	Gateway API
Role Separation	Monolithic. The Ingress object mixes infrastructure settings (TLS/Ports) with routing rules.	Decoupled. Gateway (Ops) is separate from HTTPRoute (Dev).
Expressiveness	Limited. Advanced routing (header matching, traffic weighting) usually requires messy, vendor-specific annotations.	Native. Features like header matching, traffic splitting, and weighting are first-class fields in the API.
Protocol Support	Primarily HTTP/HTTPS.	Strong support for HTTP, HTTPS, and dedicated GRPCRoute for gRPC traffic.
Extensibility	Limited. Adding features often breaks portability.	High. Custom resources can be linked at various layers of the API structure.
Cross-Namespace	Difficult. Often requires complex ingress controller flags.	Native. Gateways can explicitly allow Routes from different namespaces via allowedRoutes.

4. Advanced Traffic: gRPC Example

One major advantage is the dedicated GRPCRoute, which handles gRPC traffic natively without requiring HTTP/1.x translation or complex annotations.

CLI Example:

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: example-grpc-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "svc.example.com"
  rules:
  - matches:
    - method:
        service: com.example.User
        method: Login
    backendRefs:
    - name: grpc-service
      port: 50051

5. Request Flow Summary

When a request hits a Gateway API implementation:

1. Client sends a request to the IP associated with the Gateway.
2. Gateway receives the traffic on the configured listener (e.g., Port 80).
3. Matching occurs based on the attached HTTPRoute rules (Host header, Path, Method, Headers).
4. Forwarding sends the traffic to the backendRefs (Services) defined in the Route.