Kubernetes, run the boring way.
Most Kubernetes pain is self inflicted. A cluster assembled by hand, manifests that live on somebody's laptop, secrets pasted into environment variables, and a deploy process only one person can perform. None of that is Kubernetes being difficult. It is Kubernetes being run without a delivery model.
Ilmino runs on EKS. Ten services are delivered from Helm charts by Argo CD, which treats a Git repository as the deployment source of truth: staging syncs automatically, production does not, and every image is pinned by digest rather than by tag. The cluster, its namespaces, autoscaling, observability and queues are all Terraform, and runtime secrets come from AWS SSM through External Secrets rather than living in the manifests.
Kubernetes in practice.
Cluster provisioning
EKS in Terraform with remote state, so the cluster can be reproduced rather than remembered. Namespaces come from the platform code, not from whoever deployed last.
GitOps delivery
Argo CD reconciles the cluster against a Git repository. What is running is what is committed, and rolling back is reverting rather than an incident.
A chart per service
Each service gets its own Helm chart and its own values per environment, so staging and production differ in configuration and not in code.
Secrets that are not in the repository
External Secrets pulls from AWS SSM at runtime. The manifests hold references, never values, and CI scans for anything that slips through.
Observability and autoscaling
Dashboards and scaling policies provisioned with the cluster rather than bolted on after the first bad week.
Load testing
Knowing where a platform falls over before your users find out, which is the only way an autoscaling policy is more than a guess.
The honest view.
Most projects should not use Kubernetes. If you run one application with predictable traffic, a managed platform will cost less, take less attention and go wrong in more obvious ways. Kubernetes earns its place when you have several services that need to be deployed independently, when scaling is genuinely uneven, or when you need the same environment reproduced more than once. Below that threshold it is infrastructure you maintain instead of a product you improve, and we will tell you so.
Straight answers.
Do we actually need Kubernetes?
Probably not, and that is a serious answer rather than a modest one. One application with steady traffic belongs on a managed platform. Ask again when you have several services with different scaling profiles, or when you need to stand the whole environment up a second time.
Can you take over a cluster somebody else built?
Yes, and it is a sensible first engagement. The usual findings are the same: no infrastructure as code, secrets in environment variables, images pinned to tags that have since moved, and a deploy nobody but one person can do.
Why Argo CD rather than deploying from CI?
Because deploying from CI means the cluster's state is whatever the last pipeline did, and nobody can tell you what is running without looking. With GitOps the repository is the answer, and a rollback is a revert.
Managed Kubernetes or self hosted?
Managed, in almost every case. EKS, GKE or AKS. Running your own control plane is a decision that needs a reason beyond cost, because the savings rarely survive contact with the first upgrade.
How do you handle secrets?
They never enter the repository. External Secrets pulls from AWS SSM at runtime and the manifests carry references only, with secret scanning in CI as the backstop.
Building in Kubernetes?
Whether it is a new build, a rescue or a second pair of hands alongside your team, tell us what you need and you will get a straight answer within one working day.