How did Kubernetes become the default choice for modern infrastructure platforms?

It’s interesting that its now been 10 years since the release of Kubernetes, but still I come across people every day who have near zero understanding into the background of this transformation technology. They dont have any exposure to the problem it is built to solve, and why its now the defacto “language” of Infrastructure. Off the back of this, I thought it prudent to restate what those in the industry have come to love about Kubernetes.

So, to understand why Kubernetes has become so widely adopted, it helps to look back at how IT infrastructure platforms were previously built and operated. For many years, these platforms were assembled from a collection of technologies supplied by different vendors, each managed through its own interface. Networks were configured using the toolsets provided by the likes of Cisco, Juniper, or Arista. Storage platforms were administered through the consoles associated with NetApp, EMC, or IBM. Virtualisation ran on VMware or Hyper-V. Cloud platforms introduced their own dashboards and APIs. Security teams maintained their own systems. Each component served its purpose, but each required its own operational knowledge.

In parallel, IT teams worked to automate these activities through the tools available at the time. This often meant maintaining extensive sets of bash scripts, or adopting automation frameworks such as Ansible or SaltStack, or earlier tools like Jeeves, or VMware vRealize Automation. These approaches reduced repeated manual effort, but they still relied on the different vendor interfaces and the expertise required to operate each one. Every script or playbook ultimately reflected the underlying structure of the system it interacted with.

When the business needed something delivered, the work usually crossed multiple domains. Each domain had its own processes, its own scripts, and its own sequence of actions. Requests moved through design sessions, change reviews, and ticket workflows, with timelines shaped as much by cross-team coordination as by the work itself. Introducing a new vendor added another interface and another operational model to support. The platform functioned through the accumulated knowledge of people who managed their part of the system and the organisational procedures that connected them.

Kubernetes introduced a different approach. For the first time in mainstream infrastructure management, there was an attempt to create a unified framework for describing the desired state of a platform. Instead of interacting directly with each vendor’s tools, teams could communicate with Kubernetes in a consistent format, and Kubernetes would communicate with the underlying systems to carry out the required actions. It did not replace networking, storage, or compute. It provided a common orchestration layer across them.

By default, Kubernetes focuses on running containers through pods. Everything beyond that is added through extensions. Networking is introduced through CNI implementations. Storage is made available through CSI. More advanced or domain-specific behaviour comes through Operators and Custom Resource Definitions. These mechanisms allow Kubernetes to understand how to interact with a wide range of technologies, enabling it to adapt to many types of platforms and deployment models. It effectively becomes a framework that accepts declarative intent and relays that intent to the appropriate subsystems.

It is important to recognise that Kubernetes is not a product. It is a framework for building platforms. Organisations that do not wish to assemble and operate all the components themselves adopt a pre-defined Kubernetes platform from a vendor. Examples include OpenShift, Rancher, VMware’s Kubernetes offerings, Nutanix’s Kubernetes offering, and of course, Portainer. Kubernetes provides the orchestration layer, while these vendors supply the surrounding technology, packaging, operational controls, and opinions required for a complete platform. The underlying vendor systems remain essential. Kubernetes simply provides a consistent method to interact with them.

There was also an organisational context behind its rise. As development teams accelerated their release cycles, waiting for infrastructure to be assembled through multiple teams and tools became increasingly difficult. This contributed to the growth of shadow IT, where internal teams provisioned their own resources to move faster. Kubernetes offered a way to provide these internal users, particularly developers, with a more consistent and lower-friction method for deploying applications without bypassing central IT. It created a balance where platform teams could maintain reliability and governance, while developers gained a more predictable and efficient path to running their software.

Seen through this lens, the buzz around Kubernetes reflects a shift in how organisations structure their platforms rather than a shift in any single technology. Kubernetes introduced a unified way to describe platform behaviour, an extensible model for integrating diverse vendor systems, and a mechanism to support faster application delivery without fragmenting the organisation. Its position as the default choice emerged from this combination of consistency, extensibility, and alignment with how modern businesses need their platforms to operate.

So, in effect, Kubernetes is a universal translator “babelfish”, that accepts a common language, and then translates the request (intent) to near any back end vendor specific requests, effectively operating as a “super engineer” in software. This alone is sufficient value for Kubernetes to dominate the IT landscape, but then when you overlay the additional functionality it provides (self-healing etc), its very obvious why its the dominant way of running IT platforms.