Alek's Blog - ingress-nginx

ingress-nginx Annotation Compatibility Matrix

2026-07-18T00:00:00+00:00

Part 2 built the inventory. This part answers the question that inventory exists to feed: for the annotations that actually turn out to be hard cases — not every annotation, but the ones where the answer isn’t obvious — does migration go cleanly, or does it silently break? The honest answer changes row by row — and, in one case in this matrix, changes depending on the value of the annotation, not just its name.

ingress-nginx Replacement Candidates: Envoy, HAProxy, NGINX

2026-07-18T00:00:00+00:00

Part 3 answered which annotations survive a migration and which don’t. This part answers the question that matrix exists to feed into: given those findings, which target do you actually move to? Five candidates get the same source-verified depth as Part 3’s matrix here — not because the other seven considered for this series are less real, but because “tested with the same rigor” and “worth a mention” are different claims, and this guide tries not to blur them.

ingress-nginx Hard Cases: Auth, Rate Limits, gRPC, Snippets

2026-07-18T00:00:00+00:00

Every earlier part of this series was research: read the source, read the docs, verify a claim against a repo. This one is different. A real OVH Managed Kubernetes Service (MKS) cluster, a real domain, one deliberately nasty sample application, and the exact same 10-request test script run against ingress-nginx, then Envoy Gateway, then HAProxy Unified Gateway. Every result below is a real HTTP response or a real line read out of a running pod, not a docs claim.

ingress-nginx Inventory: Annotations, ConfigMaps, Flags

2026-07-18T00:00:00+00:00

Most migration guides start by comparing replacement Ingress controllers. That’s the wrong first step. The first step is finding out which ingress-nginx</code> behaviours your own clusters actually depend on — because the answer changes which controller (or Gateway API implementation) is even a candidate, and it’s usually smaller than a full annotation reference makes it look.
ingress-nginx Migration: A Field Guide 2026-07-18T00:00:00+00:00 This is the index for a field guide to migrating away from ingress-nginx</code>, the Kubernetes Ingress controller that was archived and retired in March 2026. Each part stands on its own, but together they cover the whole path: deciding whether to act, finding out what you actually depend on, knowing which annotations translate cleanly, choosing a target, and doing the migration itself without a flag day. ingress-nginx Migration Mechanics: ingress2gateway and Cutover 2026-07-18T00:00:00+00:00 Parts 3 through 5 answered what migrates cleanly and to which target. This part answers the question every migration guide owes its reader eventually: how do you actually move traffic without a flag day? A converter tool, a coexistence window, a staged cutover, and — the section every migration plan needs but few write down — an actual rollback plan. ingress-nginx Alternatives: Cilium, Traefik, Kong, AKS, GKE 2026-07-18T00:00:00+00:00 Part 4 covered the five candidates source-verified with the same depth as the Part 3 matrix. This part covers the rest of what this series set out to compare: three candidates this series tests but doesn’t deep-dive — Cilium, Traefik, Kong — and a survey of what migrating off ingress-nginx looks like on four managed Kubernetes platforms that were never part of the empirical lab at all. ingress-nginx Retirement: Four Ways Forward 2026-07-18T00:00:00+00:00 The ingress-nginx</code> Kubernetes controller is not “retiring soon.” It already has. The GitHub repository was archived and made read-only on 2026-03-24, and its own description now reads in the past tense: it was an Ingress controller. For a piece of software that reportedly still runs in front of roughly half of all cloud-native workloads, that is a completed fact, not a countdown. This is Part 1 of a field guide to migrating away from it. This part is deliberately non-technical — it is for whoever has to decide what to do, not yet for whoever will do the migration work. Parts 2 onward get concrete: inventorying what you actually depend on, an annotation compatibility matrix, migration mechanics, and a reproducible lab.