Alek's Blog - gateway-api

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 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. Istio AuthorizationPolicy & HTTP/2 Coalescing 2026-07-13T00:00:00+00:00 Isolating an admin surface behind its own hostname and an IP-restricted Istio</a> AuthorizationPolicy</code> sounds like a Tuesday-afternoon change: add a second HTTPRoute</code>, add a DENY</code> policy with an allowlist, done. Two non-obvious Envoy behaviors turned it into a two-day debugging exercise instead — one in how AuthorizationPolicy</code> resolves “the client’s IP,” and one in how browsers reuse HTTP/2 connections across hostnames that share a certificate. Neither is specific to Keycloak or to this particular setup; both apply to any Istio or Envoy Gateway API ingress sitting behind a cloud load balancer with a shared wildcard certificate. This post walks through both bugs, how they were root-caused, and the fix for each — so the next person hitting either symptom can skip straight to the cause. Istio vs. Envoy Gateway: Gateway API on Kubernetes 2026-04-30T00:00:00+00:00 Both Istio</a> and Envoy Gateway</a> implement the Kubernetes Gateway API</a> and use Envoy as their data plane. That is roughly where the similarity ends. Istio is a full service mesh that happens to implement Gateway API; Envoy Gateway is a dedicated Gateway API controller with no mesh ambitions. Choosing between them is mostly a question of scope. This post starts with that comparison — architecture, mTLS, egress control, and resource overhead — then broadens to cover Cilium</a> as a lighter alternative for East-West security, how the choice plays out on managed Kubernetes offerings (AKS, GKE, and OVH MKS including their cloud-native ingress and egress options), and finally how to get the real client IP through a cloud load balancer to your application. Envoy Gateway v1.7: Global Rate Limiting with a Custom ratelimit Service 2026-04-19T00:00:00+00:00 Global rate limiting in Envoy Gateway (EG)</a> can be set up in two ways: the easy path (EG manages its own envoy-ratelimit</code> container) and the flexible path (you bring your own envoyproxy/ratelimit</a> service). This post covers the flexible path — Option B — and documents the three xDS patches required to wire it up, the EG v1.7 breaking changes that affect the approach, and a namespace-admin self-service deployment model.