What Is Kubernetes? Containers, Clusters, and Core Concepts

What Is Kubernetes?

Kubernetes is a platform for deploying, scaling, and managing applications packaged in containers. A container bundles an application with its code and runtime dependencies, while Kubernetes decides where those containers should run and keeps them available.

The project began at Google and is now maintained as an open-source project under the Cloud Native Computing Foundation. The official Kubernetes documentation describes it as a system for automating deployment, scaling, and management of containerized applications.

Without an orchestrator, you might start containers manually on individual virtual machines, configure networking yourself, and write scripts to replace failed processes. Kubernetes provides a common control layer for those jobs through an application programming interface (API), command-line tools, and declarative configuration files.

For a small WordPress site or a single web application, Kubernetes can be more infrastructure than you need. It becomes more useful when you operate multiple services, need repeatable deployments, or must spread workloads across several machines or availability zones.

Why Use Kubernetes? Key Benefits

Kubernetes reduces repetitive operations by turning deployment and infrastructure rules into objects that the platform can inspect and reconcile. Its benefits are strongest when your application has multiple services, frequent releases, or variable traffic.

• Automated rollouts and rollbacks: A Deployment can replace old application pods gradually, pause when a rollout fails, and return to a previous revision.
• Service discovery and load balancing: A Service gives a changing group of pods a stable network identity and distributes requests among healthy instances.
• Self-healing and high availability: Controllers restart failed containers, recreate missing pods, and place replicas on available nodes when possible.
• Storage orchestration: Persistent volumes let applications request durable storage separately from the machine running a pod.
• Horizontal and vertical scaling: Horizontal scaling adds pod replicas, while vertical scaling adjusts CPU and memory resources assigned to containers.

Automated Rollouts and Rollbacks

A Kubernetes Deployment changes application versions gradually instead of replacing every running instance at once. You can define the number of replicas, the container image, and update behavior in a YAML manifest, then apply it with kubectl apply -f deployment.yaml.

For example, this command changes the image used by a Deployment:

kubectl set image deployment/store-api store-api=example/store-api:2.4

Kubernetes tracks ReplicaSets, which represent different versions of a Deployment. If the new version fails its readiness checks, you can run kubectl rollout undo deployment/store-api to restore the previous version. A rollback is not a substitute for testing, because a bad database migration or incompatible data change may not be reversible.

Service Discovery and Load Balancing

A Service provides a stable endpoint for pods whose individual addresses can change. Kubernetes assigns pods an internal address, but a pod may be replaced during an update or after a node failure.

A Service selects pods using labels such as app: store-api. Internal clients can then call a stable Service name instead of tracking pod addresses. Kubernetes also provides cluster DNS, meaning the Domain Name System used inside the cluster can resolve a Service name to its virtual address.

Self-Healing and High Availability

Kubernetes can restore the number of running replicas you declared, but it cannot guarantee that your application itself is healthy. Controllers create replacement pods when a pod disappears, and the scheduler places pending pods on nodes with suitable resources.

Health checks make this behavior more useful. A liveness probe tells Kubernetes whether a container should be restarted, while a readiness probe controls whether the pod receives traffic. The official Kubernetes documentation recommends treating these probes as separate signals, because an application can be alive but temporarily unable to serve requests.

Storage Orchestration

Kubernetes separates storage requests from the pods that use them. A PersistentVolumeClaim (PVC) asks for storage with a required capacity and access mode, while a StorageClass can provision that storage through a compatible plugin.

This separation matters because containers are normally replaceable and their writable filesystem may disappear when they are recreated. A database should use a supported persistent storage system, scheduled backups, and a tested restore process rather than relying only on a mounted volume.

Horizontal and Vertical Scaling

Horizontal scaling changes the number of pod replicas, while vertical scaling changes the resources assigned to each pod. A Horizontal Pod Autoscaler can use CPU, memory, or custom metrics to adjust replicas within limits you specify.

Resource requests help the scheduler place pods, and resource limits restrict how much CPU or memory a container can consume. For example, a workload might request 250m of CPU and 256Mi of memory, then set higher limits. These values must reflect measurements from your application, not generic defaults.

What Kubernetes Is Not

Kubernetes is not a container image builder, a container runtime, or a complete application monitoring system. It coordinates workloads, but other tools perform several surrounding tasks.

• Not Docker: Docker Engine builds and runs containers, while Kubernetes orchestrates workloads across nodes. Kubernetes can use container runtimes such as containerd through the Container Runtime Interface (CRI).
• Not a virtual machine: A pod is scheduled onto a node, but Kubernetes does not replace the operating system or hardware layer beneath that node.
• Not a database: Kubernetes can run a database, but it does not automatically provide a safe schema migration plan, backup policy, or disaster recovery design.
• Not a security guarantee: You still need patching, identity controls, network policies, secret management, image scanning, and least-privilege access.
• Not automatically cheaper: Control-plane fees, worker nodes, storage, network traffic, observability, and engineering time can make a cluster expensive for a small project.

The practical Kubernetes versus Docker question is usually not which product replaces the other. Docker or another build tool can create images, and Kubernetes can schedule those images when you need multi-machine coordination.

How Kubernetes Works: Desired State Management

Kubernetes works by comparing the desired state you declare with the current state it observes, then taking actions to reduce the difference. You might declare that a web application should have 3 replicas using a particular image and should receive traffic through a Service.

You usually store that configuration in YAML, a human-readable data format:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80

The API server receives this object and stores cluster data in etcd, a distributed key-value store. Controllers watch the API for changes, and the scheduler selects a suitable node for each unscheduled pod. The kubelet on each node then asks the container runtime to start the assigned containers and reports their status back to the API.

This model explains why running kubectl delete pod web-abc123 often does not reduce the application permanently. The pod is part of a Deployment with 3 desired replicas, so its controller creates a replacement.

Kubernetes Architecture and Core Components

A Kubernetes cluster has a control plane that makes decisions and worker nodes that run application workloads. The components communicate through the Kubernetes API, which acts as the central interface for configuration and status.

Control Plane vs. Worker Nodes

The control plane manages cluster state, while worker nodes provide compute capacity for pods. In a production cluster, control-plane components are commonly distributed for resilience, and worker nodes are added according to workload requirements.

The API server handles requests from kubectl, controllers, and other clients. The scheduler assigns unscheduled pods to nodes, controllers reconcile resources, and etcd stores the cluster’s persistent state. On each worker node, the kubelet manages pods and a container runtime starts the containers.

Cloud providers can operate the control plane for you through managed services. You still configure workloads, permissions, networking, storage, upgrades, and observability unless the provider’s service explicitly includes those responsibilities.

Pods: The Basic Building Block

A pod is the smallest unit Kubernetes schedules and runs. Most pods contain a single application container, but a pod can include helper containers that share the same network namespace and mounted volumes.

Containers in one pod communicate over localhost, while each pod receives its own cluster network address. Do not treat a pod as a permanent server because Kubernetes may replace it at any time. Store durable data outside the pod and expose applications through Services.

Services and Networking

Services connect clients to groups of pods through stable virtual endpoints. A ClusterIP Service is reachable inside the cluster, a NodePort exposes a port on nodes, and a LoadBalancer Service can request an external load balancer from a compatible cloud environment.

For HTTP and HTTPS routing, an Ingress or the newer Gateway API can direct hostnames and paths to Services. You also need a network plugin that provides pod-to-pod connectivity and can enforce NetworkPolicy rules. Kubernetes networking behavior depends on the selected environment, so verify supported features with your provider and plugin documentation.

Storage, ConfigMaps, and Secrets

Applications typically keep configuration, credentials, and durable data in separate Kubernetes resources. ConfigMaps hold non-sensitive settings, Secrets hold sensitive values, and PersistentVolumeClaims request storage for workloads.

• ConfigMap: Store values such as APP_MODE=production and inject them as environment variables or mounted files.
• Secret: Store passwords, tokens, or certificates, but restrict access with Role-Based Access Control (RBAC) and encrypt stored data where supported.
• PersistentVolumeClaim: Request durable capacity, such as 10Gi, from a configured StorageClass.

Kubernetes Secrets are not automatically safe merely because they use a Secret object. Limit who can read them, avoid committing raw values to Git, rotate credentials, and confirm how your cluster encrypts data at rest.

Kubernetes Ecosystem and Distributions

You can run Kubernetes yourself or choose a managed distribution that removes some cluster administration work. The core APIs are broadly consistent, but networking, storage, identity, upgrades, and add-ons vary between environments.

• Managed cloud services: Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and Microsoft Azure Kubernetes Service (AKS) operate much of the control plane, while you pay for worker resources and related services.
• Open-source and on-premises options: kubeadm, k3s, and MicroK8s support self-managed clusters, but you remain responsible for upgrades, certificates, backups, capacity, and incident response.
• Platform distributions: Red Hat OpenShift and other enterprise platforms add supported workflows, security controls, and developer tooling around Kubernetes.

Managed Cloud Services

A managed Kubernetes service is usually the practical starting point when you need Kubernetes but do not want to maintain the control plane. It can reduce work around API-server availability and control-plane upgrades, but it does not remove the need to understand deployments, resource requests, networking, and access policies.

Compare services by regional availability, control-plane pricing, node options, storage integration, identity features, upgrade policy, and support for the Kubernetes versions you require. Provider pricing and included features change, so re-check the official service calculator and documentation before budgeting.

Open-Source and On-Premises Options

Self-managed Kubernetes offers more control but gives your team more operational responsibility. You must provision machines, install a supported container runtime, configure a network plugin, secure certificates, monitor components, and test recovery procedures.

For learning or a small single-node environment, tools such as Minikube, kind, or k3d can create a local cluster. For production, follow the current Kubernetes release documentation rather than copying an old Kubernetes deployment guide for beginners. The official documentation currently lists multiple supported release branches, and versions, commands, and compatibility requirements should be re-checked before installation.

Frequently Asked Questions

• Is Kubernetes suitable for a beginner? It is useful for learning modern deployment practices, but start locally with kind or Minikube and learn pods, Deployments, Services, logs, and resource limits before operating a production cluster.
• What is the difference between Kubernetes and Docker? Docker commonly builds and runs containers on one machine, while Kubernetes schedules and manages containers across a cluster. Kubernetes can use images built with Docker-compatible tooling.
• Does Kubernetes run containers directly? Kubernetes delegates container execution to a runtime through the CRI. The runtime may be containerd or another supported implementation, depending on the cluster.
• Do I need Kubernetes for WordPress? Usually not for a single conventional WordPress installation. Managed WordPress hosting or a virtual private server is often simpler, while Kubernetes may fit a large, containerized WordPress platform with specialized scaling and deployment requirements.
• How do I inspect a Kubernetes application? Run kubectl get pods to view pod status, kubectl describe pod POD_NAME for scheduling events, and kubectl logs POD_NAME for container output. Replace POD_NAME with the actual pod name.
• Is Kubernetes free? The Kubernetes software is open source, but running it can incur costs for compute, storage, network traffic, support, monitoring, and engineering time. Managed-service prices and included resources must be checked against current provider documentation.