Kubernetes — The Basics

A one-page primer on what Kubernetes is and how it actually works.

01What is Kubernetes?

Kubernetes (often written K8s — "K", eight letters, "s") is an open-source system for running containers across many machines. You tell it the state you want ("run 3 copies of this app, always"), and it works continuously to make reality match — restarting crashed containers, replacing dead machines, and scaling up or down.

The core idea — declarative, not imperative: you don't say "start this container on that server." You describe the desired state in a YAML file, and Kubernetes figures out how to get there and keep it there.

02The architecture

A Kubernetes cluster has two halves:

🧠Control plane

The brain. Makes decisions and stores the desired state — the API server, scheduler, controllers, and etcd (the database).

💪Worker nodes

The muscle. The machines that actually run your containers, each with a kubelet agent taking orders from the control plane.

You talk to the API server (usually via kubectl); the scheduler decides which node runs each workload; and controllers constantly reconcile actual state toward desired state.

03Core objects you'll actually use

Pod — the smallest unit: one (or a few tightly-coupled) containers sharing network & storage. You rarely create these directly.
Deployment — manages a set of identical Pods: rolling updates, rollbacks, and self-healing. This is what you deploy most of the time.
ReplicaSet — keeps N copies of a Pod running. Usually managed for you by a Deployment.
Service — a stable network address + load balancer in front of Pods (which come and go). How things find each other.
Ingress — routes external HTTP(S) traffic to Services (hostnames, paths, TLS).
ConfigMap / Secret — inject configuration and sensitive values into Pods without baking them into the image.
Namespace — a virtual partition to isolate and organize resources (e.g. dev, prod).

04How you deploy something

You write a YAML manifest describing what you want, then apply it:

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:alpine
          ports:
            - containerPort: 80

Run kubectl apply -f web.yaml and Kubernetes creates 3 Pods, keeps them alive, and reschedules them if a node dies — no manual babysitting.

05Essential kubectl commands

kubectl get pods — list what's running
kubectl apply -f file.yaml — create/update from a manifest
kubectl describe pod <name> — detailed status & events (great for debugging)
kubectl logs <pod> — see a container's output
kubectl scale deploy/web --replicas=5 — scale up or down
kubectl rollout undo deploy/web — roll back a bad deploy

06Why teams use it (and the cost catch)

Kubernetes gives you self-healing, easy scaling, rolling deploys, and a consistent way to run anything anywhere. But that power has a cost side: it's easy to over-request resources, leave idle nodes running, and let clusters sprawl.

FinOps tie-in: the #1 Kubernetes cost mistake is Pods that request far more CPU/memory than they use — forcing the cluster to add nodes it doesn't need. Right-size pod requests and autoscale, and most K8s bills drop sharply.

07Mini glossary

Cluster: A set of machines (nodes) running Kubernetes together, managed as one.
Node: A single machine (VM or physical) in the cluster that runs your Pods.
Pod: The smallest deployable unit — one or more containers that share a network and storage.
kubectl: The command-line tool you use to talk to a cluster.
Manifest: A YAML/JSON file describing the desired state of a resource.
Reconciliation: The control loop that continuously nudges actual state toward desired state.