Continuous delivery on Kubernetes and GKE

The reliability of the product a user sees depends on the layer they do not: how containers get scheduled, how traffic moves through the gateway, and how a bad deploy is stopped before it takes a service down.

What was built

Helm-based deployment patterns for production services, with per-environment value files (development, staging and production) and consistent rolling-update and readiness behaviour across services.

Migrations to the GKE Gateway API, replacing legacy Ingress configuration with the current model.

Per-environment GitHub Actions workflows that build the image, push it to the registry and roll out to the right cluster context based on branch and tag, with explicit promotion gates between environments.

Readiness and liveness probe tuning and rollout-safety work, to reduce the chance of a bad release reaching real traffic and to make rollbacks fast when one slips through.

Why it matters

Making that layer predictable and self-serve is what lets a small team ship faster without breaking things, and what turns incident response into a matter of minutes rather than hours.

On confidentiality

The client and the delivery channel are covered by a non-disclosure agreement, so this project is published without naming them. We can go into detail on scope and technical decisions in a meeting.