Kubernetes Fundamentals

Overview

Kubernetes takes the same container primitives Docker introduced and adds a control plane that keeps a declared number of them running, healthy, and reachable across a fleet of machines, automatically. Where Docker Compose runs a fixed set of containers on one host, Kubernetes schedules Pods across many nodes, restarts them when they fail, moves them when a node dies, and continuously reconciles the cluster's actual state toward whatever you declared in a manifest. That extra layer is also where most of the initial confusion comes from, Pods, Deployments, and Services look similar to Compose services but solve genuinely different problems, and none of them behave like a single long-lived container.

Quick Reference

The commands below are grouped by what you're trying to do, not an exhaustive reference (see the official kubectl reference for every flag), but the set that covers nearly all day-to-day cluster work.

Syntax

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: my-registry/api:1.4.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector: { app: api }
  ports:
    - port: 80
      targetPort: 8080

Examples

kubectl apply -f deployment.yaml
kubectl get pods -l app=api
kubectl rollout status deployment/api
kubectl rollout undo deployment/api

// Inside any Pod in the cluster, the Service's DNS name resolves
// automatically - no hardcoded Pod IPs, no service registry to run.
const response = await fetch('http://api.default.svc.cluster.local/health')

kubectl scale deployment/api --replicas=5

Visual Diagram

Common Mistakes

• Editing a Pod directly (kubectl edit pod) instead of the Deployment that manages it; the change is lost the moment that Pod is replaced.
• Skipping resource requests/limits on containers, which lets one Pod starve others on the same node or get evicted unpredictably under pressure.
• Assuming a Service load-balances intelligently by response time or load; the default is simple round-robin/random across Pods matching the label selector, nothing more.
• Forgetting readiness probes, so a Deployment routes traffic to a Pod that's technically running but not yet able to serve requests (still warming up, DB connection not established).

Performance

• The control loop's reconciliation frequency and cluster size both affect how quickly Kubernetes reacts to failures, very large clusters need a properly sized and tuned control plane (etcd especially) to keep reconciliation fast.
• Resource requests directly drive the scheduler's bin-packing decisions; under-requesting causes overcommitted nodes and noisy-neighbor problems, over-requesting wastes capacity.
• Rolling updates (the Deployment default) trade deployment speed for zero downtime, maxUnavailable/maxSurge tune how aggressively old Pods are replaced.

Best Practices

• Always set resource requests and limits on every container; it's what makes scheduling and autoscaling behave predictably.
• Define both readiness and liveness probes; readiness controls traffic routing, liveness controls automatic restarts, and conflating them causes cascading restarts under load.
• Manage manifests through Deployments (or a higher-level tool like Helm/Kustomize), never edit live Pods or ReplicaSets directly.
• Use namespaces to separate environments or teams within a cluster, but don't treat them as a security boundary on their own, pair them with network policies and RBAC.