Case study · Platform Engineering
Kubernetes Delivery on EKS
Shipping to Kubernetes is a merge, not a run of kubectl
A containerised application on Amazon EKS with rolling updates, health probes and a build-push-deploy workflow.
- Kubernetes
- Amazon EKS
- Docker
- GitHub Actions
What it is
A web application containerised and deployed to Amazon EKS, with the manifests that decide what happens during a release and the pipeline that performs it. The interesting part is not that it runs — it is what happens on the fourth deploy of the day.
The problem
A container that runs on a laptop proves very little. The questions that decide whether a platform is usable come later: what happens to traffic during a deploy, what happens when a pod is unhealthy, and who is permitted to push.
Answer those with manual kubectl commands and the answers change depending on who is at the keyboard and whether they remembered the runbook.
What we built
Three decisions that shaped it.
Rolling updates by default
The Deployment replaces pods gradually rather than all at once, so a release does not drop traffic and a bad build does not take the service with it.
Probes that make the decision
Liveness and readiness probes decide when a pod is fit to serve, so an unhealthy instance is replaced instead of quietly returning errors.
The pipeline does the deploy
GitHub Actions builds the image, pushes it to the registry and rolls the deployment. Shipping is a merge, and the record of what shipped is the commit history.
What it does
Six things, plainly.
One image, promoted rather than rebuilt.
Pods replaced gradually, traffic held.
An unhealthy pod is replaced, not served.
Three steps, one workflow, no kubectl.
Routing declared with the rest of it.
The fourth deploy looks like the first.
Built with
- Orchestration
- KubernetesAmazon EKS
- Containers
- Docker
- Manifests
- DeploymentServiceIngress
- Health
- Liveness probesReadiness probes
- Pipeline
- GitHub ActionsContainer registry
What came out of it
The outcome.
Rolling updates and probes mean a deploy is not an event anyone has to schedule.
Merging is the deploy, so releasing is not gated on who knows the commands.
A bad image is replaced by rolling the previous one, on the same path.
Built in-house as the reference for how we hand over a container platform.
Have a problem shaped like this one?
Describe the situation and a senior engineer will tell you what it needs.