I have worked in this industry long enough to recognise how the end of an epoch feels.

It does not begin with a bang. It begins with a sensation. An inkling that what you have done for years is not wrong — but no longer enough. That the tools which carried you through the hardest nights have reached a boundary you cannot cross through diligence alone.

I am speaking about infrastructure. About servers. About the way we operate software. And about Kubernetes — the tool that has changed not only a technology but a mindset.

The old world: servers as pets

Once upon a time a server was an individual. You gave it a name — often a hero of mythology, a planet, a constellation. You knew its quirks. Knew that apollo ran an old kernel because the custom driver refused to compile otherwise. Knew that orion needed the RAID controller initialised before bringing services up after a restart. Knew that pegasus always hung briefly at eleven in the evening because a cron job ran there that nobody had documented.

These servers were pets. When they fell ill, you nursed them. Logged in, examined symptoms, groped through logs, tried, reverted, tried again. Hours could pass. And when the server ran again, it was the same as before — with all its scars, its workarounds, its inexplicable peculiarities understood only by the administrator who had built it.

That worked. As long as the number of servers stayed manageable. As long as complexity remained controllable. As long as the administrator who knew everything did not go on holiday or leave the company.

Then came Puppet, Chef, SaltStack. The first wave of automation. Suddenly configuration could be expressed in code — declarative, repeatable, versioned. Ansible followed and made it more accessible: YAML playbooks, SSH, no agent. And later Terraform — or OpenTofu, the free fork — to describe not only configuration but the existence of infrastructure itself: servers, networks, storage, load balancers, all as code.

That was enormous progress. But it was progress within the same paradigm. Servers remained individuals — merely better-documented, more reproducible individuals. You built them faster. Built them more consistently. But you still built them — fixed machines with fixed IPs, fixed roles, fixed dependencies.

The boundary was not the tools. The boundary was the thought pattern.

The new paradigm: cattle, herds, cells

Kubernetes breaks with that pattern radically. And that is the point where many administrators hesitate for the first time.

In the Kubernetes world individual servers are no longer individuals. They are anonymous, interchangeable, forgotten. A node is a node. It bears no meaningful name — only a UUID. It has no personality. It has resources: CPU, RAM, storage. Nothing else matters.

What runs on them are containers. And containers are the most rigorous implementation of the cattle principle: treat infrastructure like livestock. A crashing container is not healed. It is killed. Kubernetes notices the failure, discards the broken instance and starts a fresh copy — somewhere, on some available node. Within seconds. Without a human noticing.

You no longer care which server executes the code. You care only that the desired number of copies is running. If you want three instances and one crashes, Kubernetes ensures three run again. If you want five and load drops, it scales down. If an entire node fails, Kubernetes redistributes its workloads onto the remaining nodes — automatically, without intervention.

That is not an optimisation feature. It is a different relationship with infrastructure. A fundamental one.

Self-healing

Here it gets concrete. Self-healing is a pipe dream in the old world. In Kubernetes it is the default setting.

A process leaking memory is detected by the system — OOMKilled, restarted. A pod failing its health checks is marked unhealthy and replaced. A node stopping responding is evacuated; its pods migrate. CrashLoopBackOff is a state you know — but it means the system is already acting, not waiting.

In the old world “a service is down” meant: alert, login, investigation, repair. In the new world it often means: nothing at all. The service was down. For thirteen seconds. And is back now. The administrator learns it from the dashboard, not from a phone call at three in the morning.

That changes not only operational quality. It changes the role of the administrator. From firefighter to architect. From reacting to designing.

Scaling

Scaling used to be a project. Order servers, wait, rack, cable, install, configure, add to load balancing. Weeks. Months, when hardware was scarce.

Today scaling is a parameter. You say: “I need ten replicas instead of three.” Kubernetes creates them, distributes them, integrates them. Horizontal Pod Autoscaling monitors CPU and memory consumption and scales automatically. Cluster Autoscaler adds whole nodes when needed — in the cloud or, if built right, in your own data centre.

What used to be an organisational task — who orders? who approves? who installs? — is now a declarative specification. A value in a YAML file. A line triggering a cascade of events that formerly occupied an entire team.

High availability

High availability used to be expensive. Redundant hardware, redundant network paths, clustering software, split-brain risks, heartbeat lines, STONITH devices. You built it for the most critical services — and prayed the failover worked when it mattered.

In Kubernetes high availability is a by-product of the architecture. Want three replicas of a service? One runs on each of three nodes. Lose a node, two survive. Lose a second, one survives. The system replicates itself as soon as capacity is available. Anti-affinity rules ensure instances do not all land on the same node. PodDisruptionBudgets guarantee a minimum number stay available during maintenance.

You no longer define “how do I achieve availability”. You define the conditions under which availability should arise — and the system ensures it arises. And persists.

The learning curve — honestly

Now it gets uncomfortable. What I described so far sounds like a promise. And it is one. But the road there is steep.

Kubernetes has a vocabulary that overwhelms. Pods, Deployments, ReplicaSets, StatefulSets, DaemonSets, Services, Ingress, NetworkPolicies, ConfigMaps, Secrets, Namespaces, PersistentVolumeClaims, StorageClasses, ServiceAccounts, Roles, RoleBindings, ClusterRoles, CRDs, Operators, Helm Charts, Kustomize, kube-scheduler, kube-proxy, etcd, CNI, CSI, CRI — and each term carries semantics you must grasp to wield it properly.

That is not a complaint. It is the reality of a system modelling an entire data centre in software. Naturally it is complex. Naturally it overwhelms at first. Naturally there are moments you ask whether all this is necessary.

The answer is: yes. Because the complexity you learn here replaces complexity you would otherwise carry elsewhere — in scripts, in wikis, in heads, in midnight phone calls. Kubernetes centralises complexity to make it manageable. You trade chaotic, scattered complexity for structured, documented complexity.

And then comes the moment it clicks. When the terms arrange themselves. When you understand that a Deployment manages replicas, a ReplicaSet spawns pods, a Pod runs containers, a Service puts a stable name in front and an Ingress routes traffic from outside. When the diagram makes sense. When you write your first manifest, deploy it and watch the system execute it — precise, deterministic, without surprise.

After that moment you never want to go back. Ever.

A system that does not stand still

Anyone who grasps Kubernetes soon meets another property: it never stands still.

The project’s development speed is unprecedented. Quarterly releases appear that not only fix bugs but advance concepts. APIs are introduced, mature, become deprecated, eventually removed. Someone who learnt five years ago must relearn much today.

One example: Ingress. For a long time Ingress was the standard method of routing HTTP traffic into a cluster. But Ingress had weaknesses — it was HTTP-centric, limited in capability, fragmented across implementations behaving inconsistently. The community recognised this and developed the Gateway API — a new, generic routing model not restricted to HTTP, enabling role-based configuration and combating fragmentation through precise specifications.

Running Kubernetes in production today means living with this drift. Ingress has not disappeared, but Gateway API is the future. Migration is not optional — it is normal locomotion in a system evolving constantly.

That can weary you. But it is also a sign of health. A system that does not evolve dies. Kubernetes lives. And whoever lives with it learns that evolution is not a bug but a feature.

Architecture decides

Technology alone is not enough. That is the most important lesson I have learnt in over two decades of infrastructure work.

Kubernetes is powerful. But powerful tools in bad hands wreak more damage than weak tools in good ones. The choice of software running on Kubernetes determines success and failure. The architecture of clusters — how they are segmented, how policies enforced, how storage attached, how networking configured — decides whether you gain scalability or chaos. Whether self-healing works or causes outages. Whether high availability is real or a bluff.

A microservice architecture poorly conceived will not improve on Kubernetes — only spread faster. A stateful service not designed for orchestration will not grow more reliable under Kubernetes — only harder to debug. Kubernetes solves no architecture problems. It makes good architecture scalable and poor architecture visible.

Exactly here the wheat separates from the chaff. Exactly here experience becomes palpable that is not written in books.

What distinguishes libcom.de

libcom.de has operated Kubernetes since the early days. Not as an experiment — as production. We have shepherded clusters through version upgrades spanning multiple major releases. Accompanied migrations where Ingress became Gateway API. Seen what goes wrong when operators are misapplied, when storage classes mismatch, when NetworkPolicies tear gaps.

Our experience is not theoretical. It is scar-sharp.

But the most important experience is not technical. It is architectural. We know which software suits Kubernetes and which does not. We know when a service must become stateless before orchestration. We know when Helm is the right tool and when Kustomize. We know when an operator helps and when it creates a black box nobody understands anymore.

We help choose software. Architect clusters. Define policies that do not pit security against flexibility but enable both. We plan upgrades, accompany migrations, document decisions. And we are honest when Kubernetes is not the right answer — because sometimes it is not.

Whoever adopts Kubernetes without reconsidering architecture builds a new problem. Whoever adopts it with the right architecture gains something they will never relinquish: infrastructure that works because it is built — not because somebody watched over it.

If you wonder whether Kubernetes fits your case — or whether your existing cluster architecture is still the right one: write to us at contact@libcom.de. We make an honest inventory. Without sales pressure. With a view to what lasts long-term.

The paradigm shift is unavoidable. Whoever still treats servers as pets will eventually be overtaken by complexity. Whoever regards them as cattle has taken the first step. Whoever understands them as cells of a living system — self-healing, scaling, available — has grasped where the journey leads.

Kubernetes is no passing trend. It is the architecture on which the next generation of infrastructure is built. The question is not whether you join. The question is when — and with whom.