Kubernetes for beginners: what it is, and whether you need it

Short answer: Kubernetes is a system that runs containers across a group of machines and keeps them in the state you declared: the right number of copies running, restarted when they fail, updated gradually and reachable through stable addresses. It is powerful and complex. If your application fits on one or two servers, Docker Compose is usually the better choice.

What problem does it solve?

Running one container is easy. Running fifty across ten machines is not. Who restarts a crashed container? Where does a new one go when a machine dies? How do you roll out a new version with no downtime, and send traffic only to healthy copies? Kubernetes automates those jobs.

What are the main concepts?

• Cluster: the machines. A control plane makes decisions, worker nodes run workloads.
• Pod: the smallest unit, one or more containers that share a network address. You rarely create pods directly.
• Deployment: declares "run 3 copies of this image" and handles rolling updates and restarts.
• Service: a stable name and address that load-balances across a set of pods.
• Ingress: rules that route outside HTTP traffic to services, with TLS. It needs an ingress controller.
• ConfigMap and Secret: configuration and sensitive values injected into pods.
• PersistentVolume and PersistentVolumeClaim: storage that outlives a pod.
• Namespace: a way to group and separate resources.

What does a minimal deployment look like?

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: registry.example.com/web:1.4.2
          ports: [{ containerPort: 3000 }]
          readinessProbe:
            httpGet: { path: /healthz, port: 3000 }
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector: { app: web }
  ports: [{ port: 80, targetPort: 3000 }]

kubectl apply -f web.yaml
kubectl get pods
kubectl rollout status deployment/web
kubectl logs deploy/web

What does it cost?

• Learning time. There is a lot of vocabulary and many ways to get networking and storage wrong.
• Operations. A self-managed cluster needs upgrades, certificate rotation and monitoring. Managed services (GKE, EKS, AKS) remove some of it, and cost money.
• Resource overhead. The control plane and system components use memory and CPU.
• Complexity budget. Every extra tool, such as Helm, an ingress controller, a service mesh and GitOps, is more to understand and secure.
• Stateful workloads such as databases are harder than stateless ones.

When do you need it?

• Many services owned by multiple teams that need independent releases.
• Workloads that must scale out and in automatically.
• Requirements for self-healing across several machines.
• A platform team that wants one standard way to run everything.

When do you not?

• One application with a database, on one server. Compose with a restart policy and a reverse proxy covers this. See Docker Compose in practice.
• A monolith that you deploy a few times a week. A modular monolith is easier to run than a cluster.
• Self-hosted business software installed on a customer's single server. Fewer moving parts is the kindest thing you can do for them.

What are the middle options?

• Compose on one or two servers with a load balancer in front and a tested restore.
• A managed container platform where you hand over an image and it runs it.
• k3s or MicroK8s, lightweight Kubernetes distributions for small clusters, if you do want the API without the weight.

How can you learn it without risk?

Install kind or minikube on your laptop, deploy a small app with the manifests above, kill a pod and watch it come back, change the image tag and watch the rolling update. An evening of that will tell you whether the model suits you. For managing deployments from Git once you do use it, see Argo CD vs Flux.