What is Kubernetes?

What Kubernetes means

Kubernetes — often abbreviated K8s — is a container orchestrator. Once you have packaged your applications as containers, you still need something to decide which machine each container runs on, to restart the ones that crash, to add more copies when traffic spikes, and to route requests to the healthy ones. Kubernetes is that something. It takes a cluster of servers and presents them as a single pool of compute that it manages on your behalf.

Its defining idea is declarative management. Instead of issuing step-by-step commands, you describe the desired end state — "run five replicas of this service, expose it on this address, keep them all healthy" — and Kubernetes continuously works to make the actual state match. If a machine dies, it reschedules the lost work elsewhere without anyone being paged.

Where it came from

Kubernetes was created at Google and released as open source in 2014. It drew on roughly a decade of internal experience running containers at enormous scale with a system called Borg. Google donated the project to the newly formed Cloud Native Computing Foundation, which kept it vendor-neutral and helped it become the de facto industry standard for orchestration.

The timing mattered. Docker had just made containers easy to build, and teams were suddenly drowning in the operational problem of running hundreds of them. Kubernetes arrived as the answer, and every major cloud provider now offers a managed version, which is how most teams consume it today rather than operating the control plane themselves.

How it works

A Kubernetes cluster has a control plane — the brain that holds the desired state and makes scheduling decisions — and a set of worker nodes that actually run the workloads. The smallest thing it schedules is a pod, a wrapper around one or more containers that share a network address and storage. Higher-level objects build on pods: a Deployment keeps a set number of identical pods running and rolls out new versions gradually, while a Service gives them a stable address and load-balances traffic across them.

Kubernetes runs a constant control loop. Controllers compare what is actually running against what you declared and take corrective action — starting a replacement pod, draining a failing node, scaling out under load. That self-healing reconciliation is the engine that makes the whole system resilient without manual intervention.

When it matters

Kubernetes matters when you are running many services, at meaningful scale, and need them to stay up without a human babysitting each one. It shines for microservices architectures, for teams that want portability across clouds, and for workloads with variable traffic that benefit from automatic scaling. The honest counterpoint is that it carries real operational weight: most early-stage products do not need it and are better off on a managed platform or serverless hosting until their scale and team genuinely demand the control Kubernetes offers.

At QUANT LAB

We treat Kubernetes as a tool to reach for deliberately, not a default. For most of the products we build, a managed platform or serverless hosting ships faster and costs less to operate, so that is where we start. When a client genuinely outgrows that — many services, strict isolation requirements, or a need to run the same workloads across more than one cloud — our cloud infrastructure team designs and runs the cluster, almost always on a managed control plane so the client is not maintaining Kubernetes internals by hand.

Because everything we build is already containerized, moving onto Kubernetes is an infrastructure decision rather than a rewrite. Our DevOps engineering work covers the deployment manifests, autoscaling rules, and rollout strategy so the cluster stays boring and your team can keep shipping features instead of fighting infrastructure.