Why Kubernetes?
Docker Compose takes a project a long way. Once a platform runs many services across several servers, needs zero-downtime deploys and has to recover on its own when a node dies, you need an orchestrator. For me that is Kubernetes: declarative, self-healing, and the same model whether the cluster runs on Hetzner or AWS.
I’ve used it in two very different situations, which is the best way to learn it.
Building it: Exlink
At Exlink I did the full migration myself. The platform started on Windows servers with IIS, so the first step was moving it to Linux. Then we moved providers from Forpsi to Hetzner, and finally onto a Kubernetes cluster I built from the ground up. That meant designing the cluster, containerising every part of the Laravel platform, moving production traffic over safely, and setting up ArgoCD so every deployment comes from Git.
Running it: Luigi’s Box
At Luigi’s Box I joined an existing, already configured production setup on AWS as an Infrastructure Consultant. The job there was the other half of Kubernetes: operating clusters someone else designed, deploying and configuring internal services, and shipping changes safely through GitHub Actions and ArgoCD, with AWS managed by Terraform and visibility through Grafana.
Learning it: my own cluster
Alongside client work I ran my own Kubernetes cluster at home to try things out without risking production. It did its job, and I’ve since shut it down.
How I Use It
- Cluster builds and migrations: moving existing applications from VMs or Docker Compose onto Kubernetes step by step, with a rollback path at every stage
- GitOps: manifests in Git, ArgoCD keeps the cluster in sync, every change reviewed and auditable
- Day-2 operations: deploying internal services, configuration, upgrades and keeping workloads consistent across environments
- Observability: Grafana dashboards so cluster and application problems show up before users notice them
- Infrastructure work: helping teams decide whether they need Kubernetes at all, or whether Docker Compose is still the simpler answer
Status
Active: my default choice for multi-service platforms that have outgrown a single Docker host.