Alek's Blog - networking

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. 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. Linkerd: Service Mesh on Kubernetes 2026-05-12T00:00:00+00:00 Both Istio</a> and Linkerd</a> are CNCF Graduated service meshes that provide automatic mTLS, traffic policy, and observability for Kubernetes workloads. Both run in sidecar mode for this comparison — a proxy container injected into every pod. The fundamental difference is the data plane: Istio uses Envoy</a>, Linkerd uses its own Rust-based proxy (linkerd2-proxy</code></a>). That choice drives the differences in overhead, extensibility, and egress control. This post compares them on the dimensions that matter for a production deployment. For the broader question of Istio vs. Envoy Gateway (ingress-only), ambient mode, and managed cloud specifics (AKS, GKE, OVH MKS), see the companion post Istio vs. Envoy Gateway: Gateway API on Kubernetes</a>. 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. haproxy-spoe-rs: A Rust SPOA Agent Library for HAProxy 2026-04-12T00:00:00+00:00 haproxy-spoe-rs</a> is a Rust library for writing HAProxy SPOE</a> agents. This post covers what SPOE is, the design decisions behind the library, and how its throughput compares to the Go reference implementation. Running pdns_recursor as a root-independent validating resolver 2026-04-06T00:00:00+00:00 PowerDNS Recursor</a> is a mature, production-grade recursive DNS resolver. This post documents how to configure it to bootstrap directly from a local root.zone</code> file — so it never needs to reach the root name servers at runtime — with full DNSSEC validation producing the ad</code> flag in responses. Running a validating DNS recursor from the root zone with Hickory DNS 2026-04-04T00:00:00+00:00 Hickory DNS</a> is a Rust-based DNS implementation that covers the full stack: resolver, recursor, authoritative server, and DNSSEC. This post documents how to run it as a full recursive resolver — starting directly from the root zone, with DNSSEC validation and encrypted upstream transport — based on the changes developed in the recurser-from-root-zone</code></a> branch. tls-proxy-tunnel: Transparent TLS Tunnelling Through Corporate HTTP Proxies 2024-07-02T00:00:00+00:00 Many enterprise networks sit behind a corporate HTTP CONNECT proxy. Applications that speak TLS natively — think git</code>, curl</code>, SSH-over-HTTPS, or any custom binary — often have no built-in proxy support. Configuring every single tool is tedious, fragile, and sometimes impossible when you don’t control the binary. tls-proxy-tunnel</code> (tpt</code>) solves this at layer 4: it sits between your application and the outside world, intercepts the TLS connection, extracts the Server Name Indication (SNI) from the ClientHello, and tunnels the raw bytes through your corporate HTTP CONNECT proxy — without ever terminating TLS. curl:// for Network Debugging — curlup 2017 2017-03-18T00:00:00+00:00 Talk I gave at curlup 2017</a> in Nürnberg. The slides cover three practical curl techniques that are useful for everyday network debugging. The slides are available as PDF</a> and the video recording (MP4)</a> is hosted on curl.se.