Skip to main content

Kubernetes

GKE Gateway API migration

Traffic left ingress-nginx without downtime. Several non-production clusters moved first. Production, Argo CD, and its workflows moved on the DNS only after that held.

Client

A small team on GKE. ingress-nginx was still serving clients, including production and the tools around it, and they did not want a gateway they would have to operate themselves.

Stack

  • GKE
  • ingress-nginx
  • GKE Gateway API
  • Argo CD
  • DNS

Situation

ingress-nginx was being retired, so it would stop receiving security fixes. Traffic was live, across several non-production clusters and production. The team was small, and they wanted the replacement managed for them.

What we did

GKE Gateway API beside nginx, proved on non-production clusters, then a DNS cutover for production, Argo CD, and workflows.

  1. 1.GKE Gateway API

    We chose the GKE Gateway API, Google’s managed controller, so the team would not operate a gateway themselves. The trade-off was explicit: less control than running an Envoy-based gateway in the cluster, and a higher cost.

  2. 2.Side by side with nginx

    The gateway was configured next to ingress-nginx. nginx kept serving clients. Routes were tested by overriding the host locally, against the gateway, before any client was sent there.

  3. 3.Non-production first

    Several non-production clusters moved first. Production stayed on nginx until that path had proved stable.

  4. 4.Production, then the tools

    Once the non-production clusters held, production moved with a DNS change, and Argo CD and its workflows moved with it.

What changed

  • No downtime during the move
  • Several non-production clusters moved before production
  • Production, Argo CD, and workflows moved on the DNS after that path held
  • The team runs Google’s managed gateway
Book a call

Related service: Kubernetes