Skip to main content
< All Topics

EKS Ingress & Gateway API

Posted
Updated
Author -Rajkumar Aute
Views9

1. What is Ingress? Think of an Ingress as a “Smart Router” or a “Receptionist” at the front of your cluster. Instead of giving every room (Service) its own front door, everyone enters through the main lobby. The receptionist looks at the URL and says:

  • “Oh, you want /api? Go to the Backend Service.”
  • “You want shop.guru.in? Go to the Frontend Service.”

2. The Ingress Controller (The Engine) An Ingress resource (the YAML) is just a set of rules. It doesn’t actually “do” anything until you install an Ingress Controller. In AWS EKS, the standard is the AWS Load Balancer Controller. When you apply an Ingress YAML, this controller talks to the AWS API and automatically creates a single Application Load Balancer (ALB) that handles all the routing for you.

3. The Gateway API: The 2026 Standard Ingress has been around for a long time, but it’s a bit limited. It tries to pack everything into one file, which makes it hard for big teams to share. The Gateway API is the evolution of Ingress. It breaks the “Front Door” into three roles:

  • Infrastructure Provider: Manages the actual Load Balancer.
  • Cluster Operator: Decides which domains (like *.guru.in) are allowed.
  • Developer: Decides how their specific app’s paths (like /payment) are routed.

4. Path-based vs. Host-based Routing

  • Path-based: guru.in/app1 vs guru.in/app2.
  • Host-based: app1.guru.in vs app2.guru.in. Ingress and Gateway API handle both effortlessly.

1. The AWS Load Balancer Controller (The Magic Engine) In EKS, you don’t manually create ALBs or NLBs in the AWS Console. You install the AWS Load Balancer Controller inside your cluster.

  • It “watches” your Kubernetes API.
  • When you create an Ingress or a Gateway, it talks to the AWS API and provisions the physical hardware.
  • ALB (Application Load Balancer): Used for Layer 7 (HTTP/HTTPS) traffic. It’s smart and can look at URLs.
  • NLB (Network Load Balancer): Used for Layer 4 (TCP/UDP) traffic. It’s incredibly fast and used for things like databases or high-throughput gaming servers.

2. The Paradigm Shift: Ingress vs. Gateway API For years, the Ingress object was the standard. But it was limited—it was like a “one-size-fits-all” jacket that didn’t fit anyone perfectly. The Gateway API is the new standard because it is Role-Oriented:

  • Infrastructure Provider (AWS): Manages the GatewayClass.
  • Cluster Operator (You): Manages the Gateway (The Load Balancer itself, SSL certs, and IPs).
  • Application Developer: Manages the HTTPRoute (Where /api goes).

3. ⚠️ The March 2026 Warning: The End of Ingress-NGINX As of this month, the community-led Ingress-NGINX project has officially entered its retirement phase. While it served us well, its monolithic architecture was prone to security vulnerabilities and scaling bottlenecks.

  • The DevSecOps Reality: Companies are now frantically migrating from NGINX Ingress to the Gateway API. This is why your knowledge of the Gateway API is your “Superpower” in interviews right now.

To further refine this for your technical documentation or knowledge base, here is a more detailed look at the evolution from Ingress to the Gateway API and how these routing types function in a production environment like AWS EKS.

1. Ingress vs. Gateway API: The Evolution

While Ingress is a single-resource model, the Gateway API is designed for Role-Based Infrastructure. It solves the “one giant YAML file” problem by splitting responsibilities across different personas.

FeatureIngressGateway API
ModelMonolithic (Single resource)Component-based (GatewayClass, Gateway, HTTPRoute)
PersonasUsually managed by one person/teamInfrastructure Provider, Cluster Operator, and Developer
Traffic SplitLimited (requires vendor-specific annotations)Native support for weight-based routing and canaries
Protocol SupportPrimarily HTTP/HTTPSHTTP, HTTPS, gRPC, TCP, and UDP
FlexibilityRigid; depends heavily on annotationsHighly extensible and standardized across providers

2. Deep Dive: Routing Strategies

You correctly identified the two main ways to direct traffic. In a production EKS environment using the AWS Load Balancer Controller, these manifest as specific rules in the Application Load Balancer (ALB) listener.

Path-based Routing

This is often used for Microservices where a single domain hosts multiple functional units.

  • Example: * guru.in/api $\rightarrow$ backend-service
    • guru.in/static $\rightarrow$ frontend-service
  • Best for: Simplifying SSL certificate management (you only need one certificate for the root domain).

Host-based Routing

This is used for Multi-tenancy or separating distinct applications.

  • Example: * dev.guru.in $\rightarrow$ dev-service
    • prod.guru.in $\rightarrow$ prod-service
  • Best for: Complete isolation of environments or branding (e.g., blog.guru.in vs shop.guru.in).

3. The “Engine” in EKS: AWS Load Balancer Controller

In EKS, the relationship between your YAML and AWS is crucial:

  1. Deployment: You apply an Ingress or HTTPRoute resource.
  2. Discovery: The AWS Load Balancer Controller (running in your cluster) watches for these resources.
  3. Provisioning: It calls the AWS APIs to create an ALB and configures the Target Groups to point to your Kubernetes Pod IPs (using “IP mode” for better performance).
  4. Integration: It can also automatically manage AWS Certificate Manager (ACM) certificates and Route 53 DNS records if configured with the right annotations or ExternalDNS.

4. Why Use Gateway API in 2026?

The shift to Gateway API isn’t just about “new features”—it’s about separation of concerns.

  • Infrastructure Providers define the GatewayClass (e.g., an AWS ALB).
  • Cluster Operators define the Gateway (the entry point, ports, and allowed namespaces).
  • Developers simply define HTTPRoutes to attach their specific application paths to that Gateway. This prevents a developer from accidentally breaking the entire cluster’s routing by misconfiguring a single Ingress file.

In these examples, we are routing traffic for a Frontend and a Backend service, both using path-based and host-based logic.

1. The Standard Ingress (The “Monolith”)

In this model, the Developer or SRE has to define everything—annotations for the AWS Load Balancer, SSL certificates, and all routing rules—in a single file.

YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: guru-ingress
  annotations:
    # AWS Specific Annotations
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
spec:
  ingressClassName: alb
  rules:
  - host: devsecopsguru.in
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

2. The Gateway API (The “Modular” Approach)

The Gateway API breaks this into two distinct parts: the Gateway (the infrastructure) and the HTTPRoute (the application logic).

Part A: The Gateway (Managed by Cluster/Cloud Ops)

This defines where the traffic enters and which load balancer to use. It’s the “Lobby” of your cluster.

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: guru-gateway
spec:
  gatewayClassName: amazon-vpc-lattice # or 'aws-alb'
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.devsecopsguru.in"
    allowedRoutes:
      namespaces:
        from: All

Part B: The HTTPRoute (Managed by Developers)

The developer only cares about their specific app. They “attach” their route to the Gateway created above.

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: backend-route
spec:
  parentRefs:
  - name: guru-gateway
  hostnames:
  - "devsecopsguru.in"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: backend-service
      port: 8080

Key Differences & Why It Matters

FeatureStandard IngressGateway API
SeparationAll-in-one. If a Dev changes a path, they might break the ALB config.Separated. Ops manages the LB; Devs manage the paths.
Multi-ServiceHard to split paths across different namespaces easily.Native Support. Routes in different namespaces can attach to one Gateway.
Traffic ControlRequires complex “Canary” annotations (vendor-specific).Built-in. You can easily set weight: 50 to split traffic for A/B testing.

Summary of the “Shift”

  • Ingress is like a Swiss Army Knife: It does a lot, but it’s hard to change one blade without affecting the others.
  • Gateway API is like a Lego Set: You can swap the “Load Balancer” block (Gateway) without ever touching the “App Routing” block (HTTPRoute).

Looking at these side-by-side perfectly illustrates why the industry is moving away from the standard Ingress model.

1. The Legacy Way: Standard Ingress (AWS ALB)

To do traffic splitting with the standard AWS Load Balancer Controller, you have to hijack the annotations. You define a “fake” backend service in the spec, and then write a raw JSON string in the annotations to tell the AWS ALB how to actually split the traffic.

The pain point: It is highly vendor-specific, difficult to read, and prone to syntax errors (a single misplaced quote in the JSON breaks the routing).

YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: guru-canary-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    # The messy part: defining the routing logic inside a string annotation
    alb.ingress.kubernetes.io/actions.split-traffic: >
      {"type":"forward","forwardConfig":{"targetGroups":[{"serviceName":"frontend-v1","servicePort":"80","weight":90},{"serviceName":"frontend-v2","servicePort":"80","weight":10}]}}
spec:
  ingressClassName: alb
  rules:
  - host: devsecopsguru.in
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: split-traffic # This must match the action name in the annotation exactly
            port:
              name: use-annotation

2. The Modern Way: Gateway API (HTTPRoute)

The Gateway API promotes traffic splitting to a first-class citizen. There are no messy annotations or fake services. You simply list your backend targets and assign a weight to each.

The benefit: It is incredibly readable, standardized across any cloud provider, and completely decouples the routing logic from the underlying load balancer infrastructure.

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: frontend-canary-route
spec:
  parentRefs:
  - name: guru-gateway
  hostnames:
  - "devsecopsguru.in"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    # 90% goes to the stable version
    - name: frontend-v1
      port: 80
      weight: 90
    # 10% goes to the new version
    - name: frontend-v2
      port: 80
      weight: 10

Why this matters for DevSecOps

Because the HTTPRoute uses standard Kubernetes syntax rather than raw JSON strings, it is infinitely easier to manage in a CI/CD pipeline.

Contents
Scroll to Top