The Myth of “Finished Kubernetes”

“We now have Kubernetes.”

Hardly any phrase is uttered more frequently in IT projects—and yet understood so differently.

For some, it means that the technical foundation for a modern application platform has been established. For others, it equates to the assumption that the most challenging part of the transformation is already behind them. Often, there is even the expectation that issues like high availability, scalability, security, or resilience are largely solved with the introduction of Kubernetes.

This expectation is understandable.

After all, almost all major cloud providers convey exactly this image.

Within minutes, an EKS cluster can be created on Amazon Web Services. Microsoft promises a fully managed Kubernetes service with Azure Kubernetes Service (AKS). Google, whose engineers were instrumental in the development of Kubernetes, offers Google Kubernetes Engine (GKE), a platform where a production-ready cluster can be set up with just a few clicks.

Numerous hosting providers also advertise with similarly simple promises. Kubernetes appears there as a service that can be booked as easily as a virtual machine used to be.

The message is always the same:

The cluster is quickly created.

And that is indeed true.

A Kubernetes cluster can actually be provisioned within minutes today. What required deep knowledge of distributed systems, certificate infrastructures, and network concepts a few years ago is now largely handled by automation. The API server is set up, etcd is initialized, worker nodes are registered, and the basic components of the control plane start without manual intervention.

From an infrastructure perspective, this is a remarkable advancement.

From an operational perspective, however, it is merely the beginning.

The Confusion Between Deployment and Operation

This is precisely where the misconception begins, which runs through surprisingly many Kubernetes projects.

Companies confuse the deployment of a platform with its operation.

This distinction may seem like linguistic hair-splitting at first glance. In reality, it describes two entirely different disciplines.

Deployment answers a relatively simple question:

“Can I start Kubernetes?”

Operation answers a much more complex one:

“Can I reliably run business-critical applications with Kubernetes over the years?”

There is a world of difference between these two questions.

A cluster can be created within minutes.

A robust operational platform often emerges only after months—and continues to evolve thereafter.

This difference is underestimated in many projects because visible success occurs very early.

After a short time, the first application can be deployed. Pods start. Services are created. An ingress exposes the application externally. The first load tests are successful. The project seems complete.

In reality, the platform is still in its simplest form at this point.

Many of the actual challenges only arise when a demonstration becomes a production system.

The Difference Between a Demo and a Production Platform

Almost every Kubernetes demonstration follows the same pattern.

A developer creates a cluster.

Then an application is deployed.

Within minutes, it is accessible via a browser.

The presentation usually ends with an automatic scaling or a rollout of a new version.

This is indeed impressive.

However, it conveys an image that has little in common with everyday operations.

Because productive systems rarely consist of a single application.

A medium-sized software company often operates dozens of microservices. There are also databases, messaging systems, caches, search indices, monitoring components, authentication services, CI/CD systems, and numerous internal tools.

Each of these components has its own requirements regarding availability, data security, performance, and maintainability.

With each additional service, the number of possible interactions increases.

An error in the network configuration can suddenly affect multiple applications simultaneously.

A faulty DNS configuration may prevent communication between internal services.

A misconfigured admission controller blocks all deployments.

An overlooked certificate expiration results in external clients being unable to connect.

None of this is a Kubernetes problem.

And that is precisely what makes these situations so challenging.

Kubernetes Solves Exactly the Problem It Was Developed For

Another reason for the widespread misconception lies in the public perception of Kubernetes itself.

Kubernetes is often talked about as if it were a universal platform for operating modern software.

In reality, Kubernetes pursues a much more narrowly defined goal.

The project originated at Google from experiences with Borg—an internal system that coordinated millions of containers over many years. The central question was not how applications should be developed, but how a large number of independent workloads could be reliably orchestrated across thousands of servers.

Kubernetes was therefore developed as a container orchestrator.

Not as a monitoring system.

Not as a security platform.

Not as a backup solution.

Not as a CI/CD system.

Not as an identity provider.

Not as a platform for meeting regulatory requirements.

This deliberate focus is one of the project’s greatest strengths.

However, it also leads to companies often expecting capabilities that Kubernetes was never intended to provide.

An orchestrator answers a clearly defined question:

Which containers should run with which configuration on which resources—and how can this desired state be reliably maintained?

Nothing more.

Everything else arises outside of Kubernetes.

The Influence of Cloud Marketing

Why is this distinction still so often overlooked?

A significant reason lies in the marketing of recent years.

Few technologies have been promoted as intensively as Kubernetes.

Cloud providers presented Kubernetes as the foundation of modern software development. Consulting firms described Kubernetes as an indispensable component of any digitalization strategy. Job postings demanded Kubernetes skills almost regardless of the actual task.

This created a remarkable effect.

The decision for Kubernetes was often made before it was even clear what problem needed to be solved.

The question was no longer:

“What are the requirements of our applications?”

But rather:

“How do we implement these requirements with Kubernetes?”

Technologically, this is a crucial difference.

Architecture should always emerge from the functional requirements.

Not from the popularity of a particular technology.

Kubernetes is an excellent tool.

But like any tool, it only fully realizes its utility when used for the right task.

The Real Challenge Begins After Go-live

Those who have successfully brought a Kubernetes project into production often experience a brief moment of relief.

The application runs.

The deployments work.

The monitoring provides initial metrics.

The cluster seems stable.

From a project perspective, the goal seems achieved.

From an operational perspective, the real work is just beginning.

Because productive platforms age.

Not abruptly, but continuously.

New security vulnerabilities are published.

APIs are deprecated.

Container images need to be updated.

Dependencies change.

Compliance requirements grow.

New applications pose new demands on networking, storage, or identity management.

With each passing month, the number of technical decisions that need to be consciously made, documented, and regularly reviewed increases.

This ongoing process of change is often underestimated.

Kubernetes is not a project with a defined endpoint.

Kubernetes is an operational decision.

And therein lies the fundamental difference.

While traditional infrastructure projects could often be concluded with successful commissioning, with Kubernetes, the real responsibility begins after commissioning.

Those who realistically assess this responsibility from the outset lay the foundation for a robust platform.

Those who underestimate it will sooner or later find that it is not the cluster that has become the problem, but the multitude of operational tasks that have developed around it.

In the next chapter, we will therefore take a closer look at what Kubernetes technically actually achieves—and why its architecture explains why operating modern platforms goes far beyond merely orchestrating containers.

What Kubernetes Actually Is—and Why This Is Its Greatest Strength

Before we can discuss why operating a Kubernetes platform is so demanding, we must first understand what task Kubernetes fulfills at all.

Because a remarkable contradiction runs through many projects to this day.

The more popular Kubernetes has become, the more diffuse the understanding of its actual function often is.

For some, Kubernetes is a cloud.

For others, a virtualization technology.

Some understand it as a development platform, others as a deployment tool or an operating system for containers.

None of this hits the core.

Kubernetes is neither an operating system nor a cloud platform. It is also not software that “runs” applications. Kubernetes makes no functional decisions. It knows neither the purpose of an application nor its business significance. Whether a pod provides a webshop, a hospital information system, or a Minecraft server is irrelevant to Kubernetes.

This strict indifference to functionality is not a deficiency.

It is the reason why Kubernetes is capable of orchestrating almost any type of application.

From Imperative to Declarative Operation

To understand this concept, it is worth taking a brief look at how infrastructure was operated in the past.

For decades, an imperative operational model dominated.

An administrator logged onto a server and executed specific commands.

They installed packages.

They started processes.

They changed configuration files.

They opened firewall rules.

They adjusted memory limits.

Each of these steps immediately altered the state of the system.

The problem, however, was that the actual state of a server was hardly traceable after a few months.

Why did this configuration exist?

When was it changed?

By whom?

Was the same change also made on all other servers?

With an increasing number of systems, this approach became practically unmanageable.

Infrastructure as Code was the first answer to this problem.