HomeLab Migration From Ingress NGINX to Gateway API

Why It Matters

Adopting the Gateway API reduces reliance on vendor‑specific ingress controllers, streamlines TLS handling, and provides a scalable foundation for advanced traffic routing in production environments.

Key Takeaways

• Convert cert-manager from YAML to Helm for Gateway API compatibility
• Deploy K‑Gateway CRDs and control plane via Helm before migration
• Configure Gateway service as static node‑port to preserve port forwarding
• Copy existing TLS secret to K‑Gateway namespace to avoid downtime
• Switch router port‑forward rules to new node‑ports after route validation

Summary

The video walks through a step‑by‑step migration of a home‑lab Kubernetes cluster from the traditional NGINX Ingress controller to the emerging Gateway API, using the open‑source K‑Gateway implementation.

The presenter first removes a YAML‑based cert‑manager installation and reinstalls it via Helm, enabling the Gateway API feature flag. Next, K‑Gateway’s CRDs and control‑plane charts are deployed with Helm, and the Gateway is configured to expose static node‑port services for both HTTP (80) and HTTPS (443) traffic, ensuring existing port‑forward rules remain valid.

To avoid service interruption, the existing TLS secret from the NGINX Ingress is manually copied into the K‑Gateway system namespace and referenced in the HTTPS listener. The old Ingress stays active while an HTTPRoute binding the same host and path‑prefix rules is applied to the new Gateway, and the operator validates readiness with `kubectl get gc` and `kubectl get gateway`.

Once the HTTPRoute is confirmed, router port‑forward entries are updated to the new node‑ports, completing the cut‑over. This approach demonstrates a low‑risk path to adopt the standardized Gateway API, paving the way for more flexible traffic management and future multi‑cluster extensions.