Is Kubernetes right for you?

Kubernetes, the reference that became unavoidable

Kubernetes is an open-source system for automating the deployment, scaling and management of containerised applications. Originally built by Google to run its own infrastructure, it was made public in 2014 and has since established itself as the reference for container orchestration, well ahead of historical rivals such as Docker Swarm or Apache Mesos.

Its strength lies in combining the agility of containers with the resilience of distributed architectures, within a client/server design built for scale. But that power comes with real complexity, which can discourage teams new to containerisation. Hence the central question of this article: is Kubernetes genuinely right for your needs, or does its adoption cost outweigh the expected benefit?

From isolated containers to large-scale orchestration

Why containers alone are no longer enough

A container solves one specific problem: packaging an application and its dependencies into a portable, reproducible unit. But as soon as an organisation runs dozens of containers spread across several machines, new questions arise. How do you balance load across available nodes? How do you automatically restart a container that crashes? How do services that change IP address on every redeploy find each other? Docker alone answers none of these questions, that's the role of an orchestrator.

From Borg to Kubernetes: a decade of production experience

Kubernetes directly inherits from Borg and Omega, the internal systems Google had used since the mid-2000s to run millions of containers a week. That lineage explains why the project was designed from the outset for high availability and horizontal scale, rather than bolting it on later. Since being handed to the Cloud Native Computing Foundation (CNCF) in 2015, the project has followed a roughly four-month release cadence per minor version; by mid-2026 the stable branch is 1.36, under an N-2 support policy covering the three most recent minor versions.

Anatomy of the Kubernetes architecture

The control plane

The control plane groups the components that steer the cluster. The API server (kube-apiserver) is the single front door: every request, whether from kubectl, a GitOps operator or another internal component, passes through it, and it scales horizontally simply by adding instances. The controller manager (kube-controller-manager) continuously runs the reconciliation loops that converge the cluster's actual state toward the state declared by the user. The cloud controller manager abstracts provider-specific resources, load balancers, volumes, network routes, into standardised platform objects. The etcd cluster, a replicated, highly available key/value store, holds the entire state of the cluster: it is the single source of truth, and regularly backing it up is an absolute operational priority. Finally, the scheduler assigns every newly created pod to the most appropriate node, based on available resources, affinities and taint tolerations.

The data plane and application objects

The data plane consists of the worker nodes that actually run workloads, via a CRI-compliant container runtime (containerd or CRI-O in nearly all recent deployments, Docker Engine having been dropped from Kubernetes core back in 2022). On top of that base, application objects, Deployment, StatefulSet, DaemonSet, Job, describe how pods should be created, replicated and replaced. Internal networking relies on the CNI (Container Network Interface) model; by 2026, eBPF-based implementations such as Cilium dominate most new deployments, over older iptables-based solutions, for both performance and native network observability.

What Kubernetes genuinely brings to an organisation

Scalability and resilience by design

Isolating workloads makes scaling almost trivial: you simply add new instances to the cluster, or let an autoscaler handle it. The Horizontal Pod Autoscaler adjusts replica counts based on CPU or memory consumption, while projects like KEDA extend that logic to business metrics, queue depth, pending Kafka messages. On the infrastructure side, dynamic node-provisioning tools like Karpenter are progressively replacing static autoscaling groups, adjusting cluster capacity within seconds rather than minutes.

Multi-cloud portability and the CNCF ecosystem

Kubernetes accepts containerised applications regardless of programming language, simplifies coordinating distributed components as microservices, and above all runs in near-identical fashion across every major cloud provider as well as on-premises servers. This portability has fuelled a considerable CNCF ecosystem: Argo CD and Flux for GitOps deployment, Prometheus and OpenTelemetry for observability, and ambient service meshes (sidecar-free), which significantly lighten the network footprint compared to earlier generations of service mesh.

Hidden costs and limits you shouldn't underestimate

A learning curve measured in months, not weeks

The learning curve remains the first obstacle cited by teams adopting Kubernetes. Grasping the basics, pods, services, namespaces, ConfigMaps, takes a few weeks; mastering the topics that actually determine production reliability, fine-grained resource management, PodDisruptionBudgets, progressive rollout strategies, security hardening through admission policies, takes several months of real exposure to incidents. Not every provider offers a satisfying starting configuration, and careful upfront planning for containerising existing applications remains essential.

Infrastructure cost drift and the FinOps response

Related readPlatform engineering: scaling DevOps across the hybrid cloudA dedicated platform team, hybrid cloud architecture, developer portal, IaC and AI agents: how platform engineering scales DevOps across hybrid environments.Read the article

The second obstacle, often underestimated, is financial. Resource over-provisioning, CPU and memory reserved well beyond actual need, out of caution, is a documented phenomenon on most production clusters, and can account for a significant share of an organisation's cloud bill. That is precisely why FinOps has established itself as a discipline in its own right around Kubernetes, with dedicated tools to track consumption by namespace, team or product. Without that tooling, the operating cost frequently outweighs the expected gains, particularly for low-variability workloads that don't genuinely need automatic elasticity.

A four-step method to assess your need

Map workloads and dependencies

Start by identifying the types of workloads involved and the number of instances genuinely required at peak load. Then analyse each service's dependencies: proprietary cloud storage APIs, message queues, stateful databases, third-party services that are hard to containerise. A single monolithic application with stable traffic often has no real need for container orchestration.

Cost the total investment before deciding

Cost out total adoption: team training, engineering time for initial setup, the cost of a managed cluster (EKS, AKS, GKE or equivalent) versus current infrastructure, and ongoing operational load even in managed mode, the provider manages the control plane, not your application manifests or your production incidents.

Test on a local cluster before production

Finally, test locally with a tool like Minikube, Kind or k3d before any production deployment. This step validates the actual containerisation of applications and measures, under near-real conditions, the additional workload that day-to-day cluster operations represent.

Alternatives worth considering before you commit

Managed Kubernetes versus self-hosted Kubernetes

For the vast majority of organisations that decide to adopt Kubernetes, a managed service (EKS, AKS, GKE, or a sovereign European offering) is the most sensible entry point: the provider handles control-plane availability, version upgrades and part of the security hardening. Self-hosting, even with modern tools like Cluster API or hardened distributions like Talos Linux, generally only makes sense for strong sovereignty constraints or a scale that makes a managed service disproportionately expensive.

PaaS, serverless containers and lighter-weight solutions

Before committing, it's worth comparing against lighter alternatives: managed application platforms (PaaS) that hide orchestration entirely, serverless container offerings billed by usage without cluster management, or simply Docker Compose for simple, small-scale topologies. Kubernetes particularly suits teams building medium-to-large-scale container infrastructure with genuine scalability and portability needs, not as the default choice for every containerised application.

Conclusion: an architecture decision, not a trend

Related readKubernetes production best practices: the 2026 guideHealth probes, requests and limits, autoscaling with Karpenter and KEDA, RBAC, network policies, GitOps: the practices that make Kubernetes production-grade.Read the article

For a modest-sized organisation or a stable workload, the cost of implementing Kubernetes can prove disproportionate to the actual benefit. That is exactly where advisory support matters: at Adservio, our cloud architects and DevOps teams help you decide objectively and, where relevant, define a Kubernetes adoption strategy genuinely sized to your context, your teams and your budget.