Kubernetes essentials

What Kubernetes does

Kubernetes (K8s) runs containers across a cluster of machines. You describe the desired state (for example "three copies of this image, reachable at this address") and controllers continuously make reality match it: restarting failed containers, replacing lost nodes and rolling out new versions. (Containers themselves are introduced in the cloud models lesson.)

The cluster

• Control plane: the API server (everything talks to it), etcd (the consistent store of cluster state, built on Raft; see the consensus lesson), the scheduler (decides which node runs a pod) and controllers (reconcile desired and actual state).
• Nodes: machines that run pods, each with a node agent (kubelet), a container runtime and a networking component.

The core objects

100%

Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com

Object	Purpose
Pod	Smallest unit: one or more containers sharing network and volumes
ReplicaSet / Deployment	Keep N pods running; roll out updates and roll back
Service	Stable virtual IP and DNS name that load balances to matching pods
Ingress	HTTP routing from outside to services (host, path, TLS), handled by an ingress controller
ConfigMap / Secret	Configuration and sensitive values injected as environment variables or files
StatefulSet	Pods with stable identity and storage, for databases and brokers
DaemonSet	One pod per node (log shippers, agents)
Job / CronJob	Run to completion, once or on a schedule
Namespace	Logical separation of resources and quotas
PersistentVolume(Claim)	Durable storage requested by pods

Networking in one paragraph

Every pod gets its own IP and can reach every other pod without NAT. Because pods are short-lived, clients use Services (found through cluster DNS such as orders.shop.svc). Network policies restrict which pods may talk to which. An Ingress (or the newer Gateway API) handles external HTTP(S) traffic.

A deployment and a rolling update

apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: example/web:1.4.2
          resources: { requests: { cpu: 200m, memory: 256Mi }, limits: { memory: 512Mi } }
          readinessProbe: { httpGet: { path: /healthz, port: 8080 } }

100%

Figure SDA-ADS-07-2 · Rolling update · © forcsguy.com

Probes: readiness decides if a pod receives traffic; liveness decides if it should be restarted; startup gives slow starters time. Requests and limits tell the scheduler how much CPU and memory a pod needs and cap what it can use.

Autoscaling

A Horizontal Pod Autoscaler adds or removes pods by metrics such as CPU or request rate; a cluster autoscaler adds or removes nodes when pods cannot be placed. Scaling is useless without correct resource requests.

Extending Kubernetes: operators and CRDs

A Custom Resource Definition (CRD) adds a new object type (for example PostgresCluster). An operator is a controller that watches those objects and does the operational work (create replicas, take backups, fail over), encoding human runbooks as code. Many databases and brokers ship operators.

Things that often go wrong

Missing readiness probes (traffic to pods not ready), no resource requests (noisy neighbours, evictions), latest image tags (unrepeatable deploys), secrets in plain config, a single replica for a critical service, and running stateful systems without understanding storage and failure behaviour.

Real-world reading