Notifications
Clear all
Topic starter
19/08/2026 3:47 pm
TL;DR: Ingress-nginx is being retired with best-effort support until March 2026, and ngrok’s migration guide shows how teams can move Kubernetes traffic handling to its operator while deciding whether to accept temporary downtime or preserve certificates, according to ngrok. The practical issue is not the replacement path itself but the operational risk of DNS, TLS, and controller cutover during migration.
NHIMG editorial — based on content published by ngrok: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
Q: How should teams migrate Kubernetes ingress without creating downtime?
A: Teams should pre-stage the destination route, validate certificates before DNS changes, and keep the old path in place until the new controller proves it can serve traffic.
Q: Why do certificate and DNS changes create security risk during ingress migration?
A: Because DNS cutover can move users to a new endpoint before trust material is ready, which temporarily breaks browser and client confidence in the service.
Q: What do teams get wrong when installing a new Kubernetes ingress controller?
A: They often validate pod health without validating identity binding, account ownership, and downstream routing state.
Practitioner guidance
- Map ingress dependencies before controller retirement Catalogue every ingress-nginx deployment, related DNS record, certificate source, and operator credential so the migration plan reflects the full trust path, not just the YAML change.
- Pre-stage certificates for zero-downtime cutover Where service continuity matters, upload an existing certificate and private key before switching DNS so the new ingress path can take over without an insecure window.
- Treat API keys and authtokens as migration-scoped secrets Bind operator installation credentials to the correct account and rotate them after migration if they were exposed during testing or hand-entered setup.
What's in the full article
ngrok's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Helm installation values and the exact operator setup sequence for Kubernetes clusters.
- Concrete manifest examples for creating the ngrok ingress alongside an existing nginx ingress.
- Troubleshooting output from operator logs and agent endpoint resources when the address does not appear.
- The certificate and DNS sequencing used to avoid downtime during domain cutover.
👉 Read ngrok's migration guide for moving from ingress-nginx to the ngrok operator →
Ingress-nginx retirement and Kubernetes migration: what should teams change?
Explore further
19/08/2026 4:24 pm
Ingress migration is a governance exercise, not a plumbing exercise. When a retired controller sits in production, the real risk is unmanaged change across routing, certificates, and privileged configuration. That is why platform teams should treat ingress replacement as a controlled trust-boundary transition rather than a simple image swap. The practical conclusion is that ownership, lifecycle, and rollback planning matter as much as manifests.
A question worth separating out:
Q: Who should own certificate and domain changes during platform migrations?
A: The team responsible for application access should own the change, but certificate handling should also be governed as a secrets process and reviewed with platform owners. These assets affect trust, reachability, and recovery, so the migration needs clear accountability for the certificate, the domain, and the operator credentials.
👉 Read our full editorial: Ingress-nginx retirement: what ngrok migration changes for Kubernetes
