Run a mock round

Probes let Kubernetes decide a container's health and readiness.

• readinessProbe: whether the Pod should receive traffic. Failing it removes the Pod from Service endpoints but does not restart it. Use it while warming up or when a dependency is down.
• livenessProbe: whether the container is alive. Failing it restarts the container. Use it to recover from deadlocks, not for dependency failures.
• startupProbe: gives slow-starting apps time to boot. Until it succeeds, liveness and readiness are disabled, preventing restart loops.

livenessProbe:
  httpGet: {path: /healthz, port: 8080}
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet: {path: /ready, port: 8080}

Set realistic thresholds. An aggressive liveness probe causes cascading restarts, and a missing readiness probe sends traffic to unready Pods. Prefer HTTP checks that test real dependencies.

A namespace is a virtual cluster inside a physical cluster. It scopes names, RBAC, resource quotas, and network policies.

• Objects such as Pods, Services, and ConfigMaps are namespaced, while nodes and PersistentVolumes are cluster-scoped.
• Default namespaces include default, kube-system, and kube-public.
• Names provide DNS isolation: a Service in the dev namespace is dev.svc.cluster.local.
• ResourceQuota and LimitRange apply per namespace, which is useful for multi-tenant clusters.

kubectl create namespace staging
kubectl get pods -n staging
kubectl config set-context --current --namespace=staging

Namespaces are not a strong security boundary by themselves; combine RBAC, network policies, and separate clusters for hard isolation. Use namespaces to separate environments or teams operationally.

The control plane maintains desired state and schedules workloads.

• kube-apiserver: the front door. It validates and persists objects to etcd, and all components talk to it.
• etcd: the consistent key-value store holding cluster state. Back it up; it is the source of truth.
• kube-scheduler: watches for unscheduled Pods and picks a node based on resource requests, affinity, taints, and topology.
• kube-controller-manager: runs controllers such as Deployment, ReplicaSet, Node, and Job that reconcile actual state toward desired state.
• cloud-controller-manager: integrates with the cloud provider for load balancers, routes, and nodes.

On each node:

• kubelet starts and monitors containers and reports status.
• kube-proxy implements Service networking.
• The container runtime pulls images and runs containers via CRI.

Flow: you apply a Deployment, the API server stores it, the Deployment controller creates a ReplicaSet, the scheduler assigns Pods to nodes, and kubelets start them.

Kubernetes gives stable access to moving Pods through Services and DNS.

• A Service selects Pods by label and gets a stable virtual IP, the ClusterIP, and a DNS name.
• kube-proxy programs iptables or IPVS rules on each node so traffic to the ClusterIP is load-balanced to healthy endpoints.
• Endpoints, or EndpointSlices, are updated by the control plane as Pods become ready or are removed.
• CoreDNS resolves service names in the form service.namespace.svc.cluster.local. Short names work within the same namespace.

Service types:

• ClusterIP: internal only, the default.
• NodePort: exposes a port on every node.
• LoadBalancer: provisions an external load balancer.
• ExternalName: aliases an external DNS name.

kubectl get svc,endpoints
nslookup api.default.svc.cluster.local

Headless Services with clusterIP set to None return Pod IPs directly, which is useful for StatefulSets.

Both manage Pods, but they make different guarantees.

Deployment:

• Manages stateless, interchangeable replicas identified by a random suffix.
• Supports rolling updates and rollbacks, and Pods are created and deleted in any order.
• Uses a ReplicaSet under the hood.

StatefulSet:

• Manages stateful workloads with stable identity. Pods get ordinal names such as web-0 and web-1, stable network identities through a headless Service, and stable PersistentVolumeClaims.
• Pods are created, scaled, and deleted in order, which matters for clustered databases.

apiVersion: apps/v1
kind: StatefulSet
metadata: {name: db}
spec:
  serviceName: db
  replicas: 3
  template: {spec: {containers: [{name: db, image: postgres:16}]}}

Use Deployments for stateless web apps and StatefulSets for databases, queues, and anything needing stable storage or ordering.

Both decouple configuration from container images, but they differ in intent and handling.

• ConfigMap: non-sensitive key-value data or files. Consume it as environment variables or mounted volumes.
• Secret: sensitive data such as passwords, tokens, and certificates. Stored base64-encoded, and by default not encrypted at rest unless you enable encryption or use a KMS provider. Restrict access with RBAC.

apiVersion: v1
kind: ConfigMap
metadata: {name: app-config}
data:
  LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata: {name: app-secret}
type: Opaque
stringData:
  DB_PASSWORD: change-me

kubectl create configmap app-config --from-file=config.yaml
kubectl create secret generic app-secret --from-literal=DB_PASSWORD=change-me

Mount as volumes when you want automatic updates; environment variables do not refresh. Avoid committing Secrets to Git, and use External Secrets or Sealed Secrets instead.

A Service exposes a set of Pods at the transport layer; an Ingress exposes HTTP and HTTPS routes into the cluster at the application layer.

• Service: stable virtual IP and DNS, layer 4 load balancing over TCP and UDP. Types are ClusterIP, NodePort, LoadBalancer, and ExternalName. It cannot route by host or path.
• Ingress: layer 7 rules that map hostnames and URL paths to Services, with TLS termination. It requires an Ingress controller, such as nginx, Traefik, or the AWS ALB controller, to be installed. Ingress itself only describes routing.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: {name: web}
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend: {service: {name: web, port: {number: 80}}}

Use a Service for internal and non-HTTP traffic, and add an Ingress or the newer Gateway API for HTTP routing and TLS.

CrashLoopBackOff means the container starts, exits, and Kubernetes restarts it with exponential backoff.

1. Get the state and previous logs.

kubectl get pod web-1 -o wide
kubectl describe pod web-1
kubectl logs web-1 --previous

1. Read the exit code: 1 is an application error, 137 is OOMKilled, and 127 is command not found.

1. Common causes:

• Application config or missing environment variables and Secrets.
• Failing readiness or liveness probes causing restarts.
• Out-of-memory: raise limits or fix a leak.
• Permission errors on mounted volumes.
• A wrong entrypoint or command.

1. Debug interactively by overriding the command, then exec in and reproduce.

1. Check events with kubectl get events --sort-by=.lastTimestamp and inspect the failing dependency.

Fix the root cause rather than only increasing the restart backoff.

A Pod is the smallest deployable unit in Kubernetes. It represents one or more containers that run together on the same node and share a network namespace, IP address, and storage volumes.

Key points:

• Containers in a Pod share localhost and can communicate over local ports.
• Pods are ephemeral. If a Pod dies, it is not restarted by itself; a controller such as a Deployment or StatefulSet recreates it.
• Common patterns include a main container plus sidecars for logging or proxying, init containers that run before the app, and ephemeral debug containers.
• Pods are usually managed indirectly rather than created directly.

kubectl get pods -o wide
kubectl describe pod web-6d4f9c-x2k
kubectl logs web-6d4f9c-x2k -c app

Because Pods share an IP, avoid binding two containers to the same port.