DevOps and Kubernetes platforms

For us DevOps is not a set of tools but the answer to one question: what does it cost to ship a change safely? If the answer is "a day of work and a lot of stress", there will be few changes, and each one will be risky.

Fewer on-call shifts: a server failure is no longer an emergency

Failures always happen — sometimes a disk or a power supply gives out, sometimes the software does. When an application runs on one specific server, every such failure means downtime and a call to whoever is on duty. Guaranteeing even minimal availability then takes on-call shifts, Sundays and holidays included — expensive and exhausting for the team.

In a redundant Kubernetes cluster, applications run as several copies spread across different servers. When one server goes down:

• traffic automatically moves to the copies on the remaining nodes,
• the cluster starts the missing copies elsewhere on its own,
• users notice nothing — only the monitoring systems see the failure.

Losing an entire server often needs no immediate action at all. Fixing the hardware becomes a task for the next working day rather than a middle-of-the-night intervention. Monitoring still watches everything, but far fewer alerts need a human to react right away — which directly lowers the cost of running the system.

Cheaper deployments: no weekend windows, no overtime

When deploying a new version means downtime, it gets scheduled for the night or the weekend — with overtime and the risk of something going wrong while everyone is tired. In a Kubernetes cluster with a CI/CD pipeline it works differently:

• Health checks hold back a faulty release. A new version gets traffic only once it responds fully correctly. If it never does, the previous version keeps serving users and only the team sees the problem.
• Canary deployments. A new version goes to a canary environment and a limited share of traffic first, so errors surface before they reach everyone.
• Fast rollback. The previous version is always at hand. Rolling back is one command and a few minutes, not restoring a server from backup.
• Deployments during working hours. Since a deployment does not interrupt service, there is no need to wait for a weekend maintenance window. New versions reach production when they are ready — on a working day, with no overtime costs.

The result: changes ship more often and in smaller batches, and each one is less risky and cheaper.

What we do

• Bare-metal Kubernetes clusters — designed and built from scratch: virtualisation on Proxmox, a highly available control plane, load balancers, distributed storage, overlay networking. We run clusters with hundreds of pods across several environments.
• CI/CD — from commit to production: build, tests, image, registry, deployment. Test, beta, canary and production environments with rolling updates and health checks.
• Legacy modernisation — moving applications from decade-old application servers into containers, step by step and backed by comparison tests.
• Infrastructure automation — Ansible for nodes, Helm for applications, certificates and DNS managed automatically.
• Observability — metrics, logs and alerts that tell you what happened before the customer calls.

Why our own clusters

Kubernetes platforms managed by third parties are convenient, but they do not always give you full flexibility:

• limited access to the scheduler — you cannot influence everything that decides where and how your applications run,
• scaling limits — the number of nodes, resources or machine types depends on the provider's offer and quotas,
• extra procedures — more storage or a higher resource quota can mean a separate request and waiting for approval.

Your own cluster means complete freedom: you decide on application placement, scaling and resources — and on what they cost. Under steady load, your own hardware can be several times cheaper, and your data stays where you want it.

That freedom does require more expertise: you need to know how such a cluster breaks and how to fix it. We have that expertise — we have been running a production bare-metal cluster since November 2023. We describe the details in our article on migrating to k3s.