Kubernetes Basics

What is it?#

Kubernetes (often "K8s") runs containers across many machines for you. You hand it a description — "I want 3 copies of this image, reachable on port 80" — and it decides where they run, restarts them when they crash, and replaces them when a machine dies.

Docker runs a container on one machine. Kubernetes runs containers across many, and keeps them running without you watching.

Why it exists#

With a handful of containers on one server, docker compose is enough. The problems appear at scale:

What it is made of#

A cluster has two halves.

Control plane#

Worker nodes#

The objects you will use#

You describe everything in YAML. These are the ones you actually need:

You almost never create a Pod directly. You create a Deployment, and it creates the Pods.

How to use it#

Talking to the cluster#

kubectl is the command-line tool. Everything goes through it.

kubectl cluster-info            # is the cluster reachable?
kubectl get nodes               # the machines. All should be Ready
kubectl get pods                # pods in the CURRENT namespace
kubectl get pods -A             # every namespace
kubectl get all                 # most object types in this namespace

Deploying something#

Write a manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3                  # desired state: three pods
  selector:
    matchLabels:
      app: web                 # which pods this Deployment owns
  template:                    # the recipe for each pod
    metadata:
      labels:
        app: web               # MUST match the selector above
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:          # what it is guaranteed
              memory: "64Mi"
              cpu: "100m"      # 100m = 0.1 of a CPU core
            limits:            # what it may never exceed
              memory: "128Mi"
              cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web                   # sends traffic to pods with this label
  ports:
    - port: 80
      targetPort: 80

Apply it:

kubectl apply -f deployment.yaml     # create or update. Use this, not `create`
kubectl get pods -l app=web          # see the three pods
kubectl rollout status deploy/web    # wait for the rollout to finish

kubectl apply is declarative — run it repeatedly and you converge on the file's contents. kubectl create fails if the object exists. Always use apply.

Labels are the glue#

Nothing in Kubernetes is linked by name. Objects find each other by labels.

Day-to-day commands#

kubectl describe pod <name>     # events + state. FIRST command when something is wrong
kubectl logs <pod>              # its output
kubectl logs <pod> -f           # follow
kubectl logs <pod> --previous   # the CRASHED container's logs, not the new one
kubectl exec -it <pod> -- sh    # shell inside the pod

kubectl scale deploy/web --replicas=5
kubectl rollout restart deploy/web    # restart all pods (picks up new config)
kubectl rollout undo deploy/web       # roll back to the previous version

kubectl delete -f deployment.yaml     # remove what the file created

kubectl describe is the most valuable debugging command. The Events at the bottom usually name the problem outright: image pull failure, insufficient memory, failing probe, missing ConfigMap.

Requests and limits#

These two numbers matter more than almost anything else:

Setting no requests at all means the scheduler is guessing, and your pods are first to be evicted when a node runs short.

What goes wrong first#

Interview corner · الأسئلة اللي بتتسأل#

kubectl scale deploy/web --replicas=0   # desired is now 0
kubectl delete deploy web               # desired no longer exists

Key takeaways#

• You declare desired state; controllers make reality match. That is the whole model.
• Deployment → Pods → Service. You create Deployments, not Pods.
• Labels connect everything. kubectl get endpoints showing <none> means a selector typo.
• kubectl describe pod first, then kubectl logs --previous for crashes.
• apply, never create.
• Memory limits kill; CPU limits throttle and make CPU graphs look deceptively low.
• Everything is namespaced — -A when you cannot find something.
• Running is not Ready. Services route only to Ready, and a missing readiness probe is why deploys emit unexplained 502s.

Last updated 2026-09-08