The Ingress-Nginx Funeral: Gateway API & Hybrid Canary

Hybrid Canary: Gateway API traffic split 99% AWS / 1% Hetzner

DevOps Tutorials Infrastructure Architecture February 3, 2026

Part 1: Why Ingress-Nginx Died (and Why Gateway API is Better)

To understand the opportunity, we have to understand the tech.

`Ingress` was a resource designed in the early days of Kubernetes. It was simple: “Take traffic from the outside and dump it into a Service.” It was too simple. It lacked standardization for advanced features like header-based routing, weighted traffic splitting, or cross-namespace ownership.

Every vendor (AWS, GKE, Nginx, Traefik) added their own “Annotations” to hack these features in. Your YAML became a mess of vendor-specific spaghetti:

# The Old Way (Vendor Lock-in)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    alb.ingress.kubernetes.io/scheme: internet-facing

This mess is why `Ingress` is dying.

Enter Gateway API.

Gateway API is role-oriented. It separates the Infrastructure (The Gateway) from the Routing (The HTTPRoute). It makes advanced traffic management a first-class citizen, not a hacky annotation.

But the killer feature—the one that matters for your budget—is native, multi-backend traffic splitting.

Part 2: The “Hybrid Canary” Strategy

For years, I have preached the benefits of “Repatriation” or moving workloads from AWS to Bare Metal (Hetzner/OVH) to save 60-80% on compute.

And for years, the number one objection from CTOs has been: “It’s too risky. What if the bare metal server goes down? We can’t migrate everything at once.”

They are right. “Big Bang” migrations are terrifying.

But with Gateway API, you don’t have to migrate “everything.” You don’t even have to migrate an entire service. You can migrate 1% of the requests.

This is the Hybrid Canary.

The Architecture

Imagine you have a backend API running on AWS EKS. It costs you $5,000/month. You want to move it to Hetzner, where it would cost $400/month.

Instead of switching DNS and praying, you set up a Federated Gateway (or simply use DNS weighted routing if you are cross-cluster, but let’s stick to the logical flow of traffic splitting).

You keep your reliable, expensive AWS environment as the “Primary.”

You spin up a small, cheap Hetzner environment as the “Canary.”

Then, you use the Gateway API’s `HTTPRoute` to define the split:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-api-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - backendRefs:
    - name: aws-backend-service
      weight: 99
    - name: hetzner-backend-service
      weight: 1

*(Note: In a true multi-cluster setup, this routing often happens at a Global Load Balancer level or via a Service Mesh, but the principle of weighted backend references is the standardized core of Gateway API).*

Why This Changes Everything

1. Zero Risk: If the Hetzner server explodes, only 1% of users see an error (and with proper health checks, 0% see it, as traffic fails back).

2. The “Trojan Horse”: You aren’t asking for a budget to “migrate to Hetzner.” You are asking for time to “upgrade to Gateway API.” The migration is just a side effect of the upgrade.

3. The Data Proof: After one week, you go to your boss with a Grafana dashboard.

“Look, the Hetzner backend handled 1% of traffic.”

“Latency was actually 10ms lower than AWS.”

“Error rate was 0%.”

“Cost for that 1% was $0.10.”

4. The Dial: Once the trust is established, you change `weight: 1` to `weight: 10`. Then `50`. Then `99`.

You migrate by turning a dial, not flipping a switch.

Part 3: Migration Guide: From Ingress-Nginx to Gateway API

Since you have to migrate by March 2026 anyway, here is how to do it in a way that sets you up for the Hybrid Canary.

Step 1: Install the Gateway API CRDs

Gateway API is not installed by default in most clusters yet.

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

Step 2: Choose Your Implementation

While Nginx (the controller) is retiring its legacy Ingress support, they (and others like Envoy Gateway, Istio, and Cilium) have excellent Gateway API implementations.

For a high-performance bare-metal setup, I recommend Cilium or Envoy Gateway. They are built for modern eBPF networking and handle the “cross-cluster” routing scenarios much better than legacy Nginx.

Step 3: Rewrite the Route

Stop thinking in “Ingress.” Start thinking in “Routes.”

Old Ingress (Legacy):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: legacy-app
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

New HTTPRoute (Modern):

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: modern-app
spec:
  parentRefs:
  - name: external-gateway
  hostnames:
  - "app.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-service
      port: 80

It looks similar, but the power is in what you add next.

Part 4: The Economics of the “Dip Your Toe” Strategy

Let’s look at the financial impact of using this migration to test the waters.

Scenario: A SaaS startup spending $10,000/mo on AWS.

Goal: Reduce spend without risking stability.

The “Standard” Migration Plan:

Spend 3 months architecting a “Lift and Shift.”

Spend $50k in engineering hours.

Execute a “Cutover Night.”

Fail. Rollback.

Net Cost: $50k wasted. Savings: $0.

The “Gateway API” Plan:

1. Month 1: Mandatory migration to Gateway API (must be done anyway).

*Engineering Cost:* Sunk cost (maintenance).

2. Month 2: Rent ONE Hetzner AX52 server ($60/mo).

Connect it to the cluster (or via VPN).

3. Month 3: Route 5% of “Stateless” traffic (e.g., Image processing, read-only API calls) to the AX52 via Gateway API weights.

Savings: You offload the most compute-heavy tasks first.

*Realized Savings:* potentially $1,000/mo in AWS compute reduction.

Cost: $60/mo.

ROI: 1,500%.

The beauty of this approach is that it validates the Hybrid Cloud model using the *maintenance budget*, not the *innovation budget*.

Conclusion: Don’t Let a Good Crisis Go to Waste

The deprecation of `ingress-nginx` is a crisis for your backlog. It is a mandatory, un-fun task that no developer wants to do.

But if you reframe it, it is a strategic gift.

It breaks the inertia. It forces you to touch the networking layer. And while you are there, with the hood open, you have a choice:

You can swap the part and close the hood (staying on AWS, paying the premium).

You can install the upgrade that lets you burn 80% less fuel.

The “Zombie Infrastructure” audit we discussed previously frees up cash. The “Ingress Funeral” frees up architecture.

March 2026 is coming. Don’t just replace your Ingress. Upgrade your leverage.

*Planning your Ingress migration? We’ve built a Terraform module that deploys a “Hybrid Gateway” stack (AWS + Hetzner) using the new Gateway API standard. It comes pre-wired for weighted traffic splitting. Grab the repo here.*

Ready to see your savings? Our Cloud Exit Calculator compares AWS vs Hetzner in 30 seconds. Or get an Infrastructure Audit ($495) for a migration blueprint.