What Is Kubernetes?

Modern software runs in containers, and containers don't stay still. They start, stop, scale, fail, and move between machines hundreds of times a day. Once you're running more than a few, doing this by hand stops being practical. That's the gap container orchestration fills, and it's the reason Kubernetes exists.

Kubernetes (often abbreviated K8s) is an open source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Originally developed by Google and now governed by the Cloud Native Computing Foundation (CNCF), it has become the default runtime for cloud-native applications across on-premises data centers, public clouds, and hybrid environments.

This article covers what Kubernetes is, where it came from, how it works, how it compares to other orchestration tools, and the specific business outcomes enterprises see when they adopt it. Storage admins, DevOps teams, platform engineers, and infrastructure leaders evaluating containerization will find the framework they need to make informed decisions.

A brief history of Kubernetes

Kubernetes traces its lineage to Borg, an internal Google cluster manager that orchestrated workloads across hundreds of thousands of machines for over a decade. Concepts at the heart of Kubernetes—pods, services, labels, and declarative configuration—all came from Borg's design.

Google open-sourced Kubernetes on June 6, 2014, with the first public GitHub commit. The name comes from the Greek word for "helmsman" or "pilot," and the abbreviation K8s reflects the eight letters between K and s. The project was founded by Joe Beda, Brendan Burns, and Craig McLuckie, and engineers from Google and the broader industry soon joined the effort.

Version 1.0 shipped on July 21, 2015. That same day, Google and the Linux Foundation announced the Cloud Native Computing Foundation, with Kubernetes contributed as its seed project. That single move shaped everything that followed: vendor-neutral governance, broad industry buy-in, and a clear path away from the orchestrator competition with Docker Swarm and Apache Mesos that defined 2016–2017.

By 2026, the picture looks very different. According to CNCF's 2025 Annual Cloud Native Survey, 82% of container users now run Kubernetes in production, with cloud-native adoption hitting 89% across surveyed organisations. Kubernetes has moved from "emerging technology" to default infrastructure for everything from web applications to AI training pipelines.

How Kubernetes works

At its core, Kubernetes follows a simple model: You declare what you want the system to look like, and Kubernetes works continuously to make reality match that declaration. This is called declarative configuration, and it's the foundation that everything else builds on.

A Kubernetes deployment is organized into clusters. Every cluster has two main parts: the control plane, which makes decisions about the cluster, and a set of worker nodes, which actually run the application containers.

Control plane components

The control plane is the brain of a Kubernetes cluster. It's typically run on dedicated machines (or managed for you by a cloud provider) and includes several components:

• kube-apiserver: The front door of the cluster. Every request to read or change cluster state goes through the API server. It's designed to scale horizontally, so you can run multiple instances behind a load balancer for high availability.
• etcd: A distributed key-value store that holds the entire cluster state. If etcd is lost, the cluster is lost, which is why production clusters always back it up.
• kube-scheduler: Watches for new pods that haven't been assigned to a node, then picks a node for each one based on resource requirements, hardware constraints, affinity rules, and other policies.
• kube-controller-manager: Runs the controllers that drive the cluster toward its declared state. Node controller, replication controller, endpoints controller, and others all live here.
• cloud-controller-manager: Handles integration with the underlying cloud provider's APIs for things like load balancers and storage volumes.

Worker node components

Worker nodes run the actual workloads. Every node has three key components:

• kubelet: The agent that talks to the control plane and makes sure containers described in pod specs are running on the node
• kube-proxy: A network proxy that maintains the networking rules on each node, allowing communication to and from pods
• Container runtime: The software that actually runs containers, typically containerd or CRI-O, with Docker support deprecated in newer versions

Pods, services, and workloads

A pod is the smallest deployable unit in Kubernetes. Most pods run a single container, but a pod can hold multiple tightly coupled containers that share storage and a network namespace. Pods are ephemeral by design; they come and go as workloads change.

A service provides a stable network endpoint for a group of pods. Even as pods are created and destroyed, the service stays the same, which is how Kubernetes handles service discovery and load balancing inside the cluster.

Higher-level workload objects—Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs—describe how groups of pods should behave. A Deployment, for example, says "run three replicas of this container, do rolling updates when the image changes, and roll back automatically if the new version fails health checks."

Core features of Kubernetes

A few capabilities are worth calling out specifically because they're what make Kubernetes more than a basic container scheduler.

• Self-healing. If a container crashes, Kubernetes restarts it. If a node fails, Kubernetes reschedules its pods elsewhere. If a pod fails a readiness check, Kubernetes stops sending it traffic until it recovers. None of this requires human intervention.
• Horizontal scaling. Kubernetes can scale workloads up or down based on CPU usage, memory, or custom metrics through the Horizontal Pod Autoscaler. Combined with cluster autoscaling on the node level, this means capacity can track demand automatically.
• Service discovery and load balancing. Kubernetes assigns each pod its own IP address and gives each service a single DNS name. Traffic to a service gets distributed across the pods behind it without external load balancers in many cases.
• Automated rollouts and rollbacks. Deployments handle the gradual rollout of new versions, monitor health during the process, and automatically reverse course if something breaks. This is the foundation of safe, continuous delivery.
• Secrets and configuration management. Application configuration and sensitive data (API keys, passwords, certificates) can be stored and rotated separately from container images. This avoids the old anti-pattern of baking secrets into builds.
• Storage orchestration. Kubernetes can mount storage from local disks, cloud providers, or network storage systems through a consistent abstraction called PersistentVolumes. This matters more than it sounds; it's how stateful applications run on Kubernetes at all.

Kubernetes compared to alternatives

Kubernetes wasn't the only container orchestrator. It's just the one that won. The table below summarizes how the major options stack up today.

For most enterprises building or running modern applications today, the practical question is no longer "Kubernetes vs. alternatives;" it's "self-managed Kubernetes vs. a managed Kubernetes service."

Business benefits of adopting Kubernetes

The reasons organisations adopt Kubernetes look different depending on who you ask. CTOs talk about velocity. Operations leaders talk about reliability. Finance talks about cost. All of those are real.

• Application portability across environments. Because Kubernetes APIs are consistent across cloud providers and on-premises deployments, applications written for Kubernetes can move between environments with much less rewriting. This is the practical foundation of any multi-cloud or hybrid strategy.
• Faster delivery cycles. Teams running on Kubernetes routinely deploy multiple times per day. CNCF's 2024 survey found 29% of organisations deploy code multiple times daily, a pace that's effectively impossible without orchestrated, automated infrastructure.
• Better resource utilization. Kubernetes packs workloads onto nodes based on declared resource requirements. The 2024 Fairwinds Kubernetes Benchmark Report found that in 37% of organisations, at least half of workloads need rightsizing. This suggests potential cost savings for teams that gain better visibility into resource usage and allocation.
• Improved resilience. Self-healing, automated failover, and declarative state reconciliation reduce the kinds of incidents that used to require on-call pages.
• Foundation for AI and data workloads. According to the 2024 Voice of Kubernetes Experts Report, 98% of respondents run data-intensive workloads on cloud-native platforms, with databases (72%), analytics (67%), and AI/ML (54%) leading the list. Kubernetes is increasingly the platform on which AI runs.
• Reduced vendor lock-in. Standard Kubernetes APIs across major cloud providers mean migration between clouds is technically possible. Compared to proprietary PaaS offerings, this is a meaningful flexibility advantage.

Common Kubernetes use cases

Kubernetes shows up in production for several distinct workload patterns.

• Microservices architectures. Breaking a monolith into independently deployable services creates the kind of operational complexity that Kubernetes was designed to handle. Per-service scaling, isolated failures, and rolling updates per component all become straightforward.
• CI/CD pipelines. Kubernetes provides the runtime for build agents, test environments, ephemeral preview environments, and progressive delivery patterns like blue-green and canary deployments.
• Hybrid and multi-cloud deployments. When workloads need to run partly on premises and partly in public clouds, Kubernetes gives both environments a common deployment model and API surface.
• AI and machine learning workloads. Training jobs, inference services, and the data pipelines that feed them all benefit from Kubernetes resource scheduling and its ability to bin-pack GPUs across shared infrastructure.
• Stateful applications. Supporting them used to be a gap in Kubernetes and remains central to storage decisions. Databases, message queues, analytics platforms, and legacy applications with persistent data all run on Kubernetes today, but only because the persistent storage layer has matured enough to support them.
• VM consolidation. Enterprises running large VMware estates have started moving workloads onto Kubernetes virtualisation platforms to reduce licencing exposure and consolidate onto a single runtime.

Implementation considerations

Adopting Kubernetes isn't a one-command operation. A few decisions shape everything that follows.

• Managed vs. self-hosted. Cloud providers offer managed Kubernetes services (GKE, EKS, AKS) that handle control plane operations, upgrades, and integration with cloud-native services. Self-hosted clusters give more control but require dedicated operational expertise. For most enterprises, the calculus tips toward managed services for production unless there's a specific reason to run the control plane in-house.
• Persistent storage strategy. Kubernetes was built for stateless workloads, and the persistent storage layer is where many deployments hit problems. PersistentVolumes abstract storage from pods, but the underlying implementation—block storage, file storage, object storage, replication, snapshot management, disaster recovery—has to be chosen carefully. This is especially true for databases and any workload where data loss is unacceptable.
• Networking model. Kubernetes networking has its own learning curve. Container Network Interface (CNI) plugins like Calico, Cilium, and Flannel each handle traffic differently. Service mesh adoption (Istio, Linkerd) can add another layer of complexity.
• Security posture. Role-based access control (RBAC), network policies, pod security standards, secrets management, and supply chain security for container images all need explicit attention. Misconfigurations remain widespread—the 2024 Red Hat State of Kubernetes Security report found security gaps in most surveyed clusters.
• Skill set. Kubernetes has a steep learning curve. The majority of Kubernetes users are larger companies—a reflection of the operational investment required. Smaller teams should weigh managed services and platform abstractions like OpenShift, Rancher, or Tanzu to reduce the load.

Best practices for running Kubernetes

A few patterns separate clusters that run smoothly from clusters that page the on-call engineer at 2am.

1. Start with managed services. Unless there's a regulatory or technical reason to self-host, let the cloud provider operate the control plane.
2. Define resource requests and limits on every workload. Workloads without limits can starve neighbors; workloads without requests get scheduled poorly. Both can lead to instability.
3. Use namespaces to separate environments. Per a 2024 CNCF survey, namespaces have overtaken clusters as the preferred separation mechanism for cloud-native environments.
4. Plan persistent storage before deploying stateful workloads. Retrofitting storage decisions after the fact is significantly harder than choosing the right approach upfront.
5. Implement observability from day one. Logs, metrics, and traces should flow into a centralized system. Prometheus and Grafana for metrics, plus a logging stack like Loki or Elastic, cover most needs.
6. Treat cluster upgrades as a regular discipline. Kubernetes releases roughly every three months. Falling behind on versions creates a security risk and makes future upgrades harder.
7. Back up etcd and PersistentVolume data routinely. Self-healing doesn't help against data corruption or accidental deletion.

The future of Kubernetes

Two trends matter most for what comes next.

The first is AI. CNCF's 2025 survey explicitly described Kubernetes as the "de facto operating system for AI," and the data supports it. Production AI workloads are moving beyond experimentation, and Kubernetes with AI-specific extensions can help orchestrate them across shared GPU clusters.

The second is virtualisation consolidation. With significant shifts in the VMware licencing landscape following the Broadcom acquisition, more organisations are evaluating Kubernetes-based virtualisation platforms as a path to running both containers and VMs on a single runtime. This trend was already underway before the Broadcom deal; it's accelerated since.

Beyond those, expect continued maturation in security tooling, multi-cluster management, edge deployments, and developer experience. The platform itself is no longer changing in dramatic ways; the ecosystem around it is.

How Everpure supports Kubernetes workloads

Kubernetes solved orchestration. The harder remaining problem for most enterprises is data—keeping it available, protected, and fast enough for the workloads that matter most.

Portworx® is a Kubernetes data services platform built specifically for stateful applications running in cloud-native environments. It provides container-granular persistent storage, application-aware backup and disaster recovery, data security, and automated capacity management across on-premises, public cloud, and hybrid deployments. Portworx runs on any underlying storage infrastructure, but it pairs especially well with Everpure all-flash storage for the database, analytics, and AI workloads that increasingly anchor Kubernetes adoption.

For organisations consolidating VMware estates onto Kubernetes, Portworx supports both containerized and virtualised workloads on the same platform—including tens of thousands of VMs in production today. Combined with Everpure™ FlashArray™ and FlashBlade® platforms, organisations get a single data foundation for the entire application portfolio rather than separate storage silos for containers, VMs, and traditional workloads.

The shift to Kubernetes is one of the largest infrastructure changes most enterprises will make this decade. Getting the data layer right is the part that determines whether it succeeds.