# What is Kubernetes?

Kubernetes runs containers across a group of machines and keeps them running. You describe what should exist, how many copies of a service, how much memory each gets, which storage it mounts, how traffic reaches it, and Kubernetes works continuously to make reality match that description. A machine dies and the workloads move. A container crashes and it is restarted. You ask for a new version and it is rolled out gradually.

The phrase for this is declarative: you write down the desired state rather than the steps to reach it. That is the whole idea, and most of what people find confusing about Kubernetes follows from taking it seriously.

## What it deliberately does not do

This is the more useful half of the answer, because it is where the surprises are.

Kubernetes is not an application platform. Out of the box it will not build your code, store your container images, give you a URL with a valid certificate, collect your logs, monitor anything, or back up a database. Each of those is a separate component that someone chooses, installs, configures, secures and upgrades.

The closest familiar parallel is Linux. You can download the kernel and compile it, and you will have something that boots and does almost nothing you want. What people actually run is a distribution: Ubuntu, Debian, Red Hat Enterprise Linux. The kernel is the same in each; the distribution is the package manager, the init system, the default file layout, the security policy, the update channel and the support contract, chosen and made to work together by somebody.

Kubernetes is at the kernel end of that comparison. It is an open base that lets other tools solve the concrete problems, and it does not solve them itself. Somebody still has to pick those tools and make them work together, and that somebody is either your platform team, a Kubernetes distribution such as [OpenShift](https://www.managed-openshift.ch/what-is-openshift/), or a provider you appoint.

That is a design decision, not a gap. It is why Kubernetes runs equally well under so many different setups. It is also why "we are moving to Kubernetes" is a larger project than it sounds: the cluster is the beginning of the platform, not the platform.

## When an organization actually needs it

**Several teams deploying independently.** Kubernetes gives each team a boundary with its own quotas and permissions on shared infrastructure, and that is difficult to arrange otherwise.

**Workloads whose demand varies.** Scaling with load is native. If your traffic is flat, this argument does not apply to you.

**Portability that has to be real.** The same manifests run on a Swiss provider, a hyperscaler and your own hardware. For organizations whose jurisdiction requirements could change, that is worth something concrete.

**A standard shape for many services.** Once one service is described in Kubernetes terms, the fiftieth follows the same pattern. The payoff scales with the number of services, which is also why it does not arrive early.

## When you do not

**A handful of services with steady traffic** are cheaper and calmer on virtual machines or a managed application platform. The honest version of this advice costs us consulting work and is still correct.

**No one to own it.** A cluster is infrastructure with a lifecycle. If nobody's job description includes it, it will be run by whoever is least able to say no, and it will drift.

**A deadline measured in weeks.** The learning curve is real. Adopting Kubernetes under time pressure produces a cluster that works and nobody understands.

## The commitment nobody mentions in the pitch

Kubernetes maintains release branches for the three most recent minor releases, and a given version receives roughly a year of patch support. In practice that means an upgrade several times a year, forever, on someone else's schedule.

Each upgrade touches the control plane, the nodes, the operating system underneath, and the add-ons for networking, storage and ingress, each with its own compatibility matrix. Deprecated APIs get removed on a published timetable, so an upgrade can require changing application manifests, not just infrastructure.

This is the single largest difference between a Kubernetes proof of concept and Kubernetes in production. The first is an afternoon. The second is a standing commitment, and it is the one organizations most often discover after committing.

## Managed, or your own

Broadly there are three arrangements, and the difference is where the line of responsibility sits.

**A hyperscaler's managed service** runs the control plane for you. The nodes, the add-ons, the upgrades of everything above the control plane and the jurisdiction question remain yours.

**Your own cluster** gives you complete control over version, configuration and location, and complete ownership of the treadmill above.

**An operated platform** is someone running the whole lifecycle, control plane, nodes, operating system and add-ons, against an SLA, on infrastructure you choose.

There is no universally right answer. There is an answer that fits how much platform engineering capacity your organization actually has, which is a different question from how much it wishes it had.

## Where VSHN fits

VSHN is Switzerland's first Kubernetes Certified Service Provider and has run Kubernetes in production since 2016. We design and operate clusters on Cloudscale and Exoscale, on AWS, Google Cloud and Azure, and on private cloud and on-premises infrastructure, with support up to a 99.99% SLA.

The most valuable conversation is usually the one before the cluster exists: whether Kubernetes is the right shape for your workloads at all, and if it is, what running it will actually require from your team.

[Schedule an architecture review](#contact)