# Kubernetes Explained: Running Containers at Scale

## Introduction

The Docker post taught you to package an application into a container. Kubernetes — usually shortened to `K8s` — answers the next question: what happens when you have hundreds of containers, across many machines, that must stay running, scale up under load, and update without downtime? It is the industry-standard container orchestrator, and it runs everything from small startups' backends to Google's own services.

## Pods: the smallest unit

Kubernetes doesn't manage containers directly — it manages pods. A pod is one or more containers that share networking and storage and are always scheduled together (typically one main container, sometimes with a small helper, or "sidecar", alongside it). Pods are disposable by design: if one dies, Kubernetes replaces it. You never nurse an individual pod back to health — you declare how many should exist, and Kubernetes makes it so.

## Deployments and services: desired state, and a stable address

You don't usually create pods by hand. You create a Deployment that declares the desired state — "run 3 copies of this container image, and update them one at a time" — and Kubernetes continuously works to match reality to that declaration:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: myapp:1.0
```

Pods come and go, so their addresses change — which is why Services exist: a stable address and load balancer in front of a set of pods, so the rest of your system talks to the service, never to a pod directly. Deployment plus Service is the core pattern of nearly every Kubernetes application.

## The honest trade

Kubernetes is powerful and famously complex: clusters, networking, storage, and security all have their own concepts to learn, and running a cluster for a single small application is overkill. Many teams start with a single server or a managed platform and move to Kubernetes only when scaling, reliability, or team size demands it. Learning its concepts — desired state, self-healing, declarative configuration — is valuable even before you need the full system, because those ideas now appear in every deployment tool.

## Takeaway

Pods are disposable containers, Deployments declare the desired state and keep it true, and Services give a stable address to changing pods. Kubernetes is the answer to "containers at scale" — and knowing when you don't need it yet is part of understanding it.

Originally published at https://practicaldevblog.blogspot.com/2026/10/kubernetes-explained-running-containers.html