Certified Kubernetes Application Developer

A container packages your app with everything it needs, code, runtime, libraries, into one isolated, portable unit. A Dockerfile builds an image; a running copy of that image is a container.

Kubernetes has a controller for each kind of app. A Deployment runs stateless apps; a StatefulSet runs apps that need stable names and their own storage (databases); a DaemonSet runs one Pod on every node (agents); a Job/CronJob runs batch work once or on a schedule.

A Pod is the smallest thing Kubernetes runs. It wraps one or more containers that share the same network address and can share storage. Most Pods hold a single container; in production a controller like a Deployment manages them for you.

Sometimes a Pod runs a helper beside the main app. An init container runs to completion before the app starts (setup); a sidecar runs alongside the app for its whole life (logging, proxying). They compose behaviour without changing the main app.

spec:
  initContainers:
  - name: wait-db
    image: busybox:1.36
    command: ['sh','-c','until nc -z db 5432; do sleep 2; done']
  containers:
  - name: app
    image: myapp:1.0

A Job runs a Pod until a task completes successfully, then stops, ideal for batch work like a migration. A CronJob runs Jobs on a schedule, like cron on Linux.

Containers lose their files when they restart, so Pods use Volumes for storage. An emptyDir lasts as long as the Pod and is shared between its containers (scratch space). For storage that survives the Pod, a PersistentVolumeClaim (PVC) requests durable storage, which Kubernetes binds to a PersistentVolume (PV).

spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: data
      mountPath: /usr/share/nginx/html
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: web-pvc
    # emptyDir: {}   # <- use this instead for pod-lifetime scratch

A Deployment runs an app reliably: you declare the desired state, "3 copies of this image", and Kubernetes keeps it true, replacing failed Pods. It manages a ReplicaSet, which actually keeps the right number of Pods running.

Changing a Deployment's image triggers a rolling update by default: new Pods come up and old ones leave gradually, so there's no downtime. If the new version is bad, roll back to the previous revision with one command.

kubectl set image deploy/web web=nginx:1.26   # trigger update
kubectl rollout status deploy/web             # watch it
kubectl rollout undo deploy/web               # revert to previous

RollingUpdate (default) replaces Pods gradually. Recreate kills all old Pods then starts new ones, simple but with downtime. Blue-green and canary (two Deployments + a Service or mesh) test a new version on some traffic before full cutover.

Real apps are many YAML files. Helm packages them as a reusable chart with values you override per environment. Kustomize layers patches on a base without templating. Both avoid copy-pasting YAML across dev/staging/prod.

Probes let Kubernetes check your app's health. Liveness asks "is this stuck? restart it if so". Readiness asks "is this ready for traffic? if not, stop sending requests (don't kill it)". Startup gives slow-booting apps time before the others kick in.

livenessProbe:                       # restart if this fails
  httpGet: { path: /healthz, port: 8080 }
  initialDelaySeconds: 5
  periodSeconds: 10
readinessProbe:                      # stop traffic if this fails
  httpGet: { path: /ready, port: 8080 }
  failureThreshold: 3

When something is wrong, two commands tell most of the story. kubectl logs shows what a container printed; kubectl describe shows recent Events, scheduling failures, image pull errors, probe failures.

Beyond logs, exec into a running container to poke around, and use kubectl top (when metrics-server is installed) for live CPU/memory. These find why something is slow or crashing.

Kubernetes evolves, and old API versions get removed in newer releases (e.g. an object that used a beta apiVersion now needs the stable one). Apply a manifest with a removed apiVersion and it fails, you fix it by updating the apiVersion to the current served one.

kubectl explain deployment        # shows: VERSION: apps/v1
kubectl api-resources | grep deployment

Keep configuration out of your image so the same image runs everywhere. A ConfigMap holds non-sensitive settings; a Secret holds sensitive values. Inject either as environment variables or mounted files.

envFrom:                         # all keys → env vars
- configMapRef: { name: app-config }
env:
- name: DB_PASS                  # one secret key → env var
  valueFrom:
    secretKeyRef: { name: db, key: password }
volumeMounts:                    # or mount as files
- name: cfg
  mountPath: /etc/config

A request is the resources a Pod is guaranteed (used by the scheduler to place it); a limit is the ceiling it can't exceed. Over a memory limit gets the container OOMKilled; over a CPU limit just throttles it. ResourceQuotas cap a whole namespace.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

A SecurityContext controls how securely a container runs: which user it runs as, whether it can gain extra privileges, and which Linux capabilities it has. Running as non-root and dropping capabilities is the baseline for a hardened app.

spec:
  securityContext:               # applies to all containers
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    image: myapp
    securityContext:             # overrides for this container
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities: { drop: ["ALL"] }

A ServiceAccount is the identity a Pod uses to talk to the Kubernetes API. By default Pods get the namespace's default account; for least privilege you create a dedicated ServiceAccount and grant it only the permissions (via RBAC) it needs.

RBAC decides who can do what. A Role is a set of allowed verbs (get, list, create…) on resources within a namespace; a RoleBinding grants that Role to a user or ServiceAccount. ClusterRole and ClusterRoleBinding do the same cluster-wide.

kubectl create role reader --verb=get,list,watch --resource=pods
kubectl create rolebinding read-pods \
  --role=reader --serviceaccount=dev:app-sa
kubectl auth can-i list pods --as=system:serviceaccount:dev:app-sa

After a request is authenticated and authorized, admission controllers get the final say, they can validate or even mutate it before it's stored. This is how rules like "every Pod must set resource limits" or "no privileged containers" get enforced. Pod Security Admission (PSA) is the built-in one you'll meet most.

kubectl label namespace dev \
  pod-security.kubernetes.io/enforce=restricted

Kubernetes can be extended with Custom Resource Definitions (CRDs), new object types beyond the built-ins. Operators use these to manage complex apps. For CKAD you mainly recognise them and interact with existing custom resources, not author controllers.

Pods are ephemeral and their IPs change, so you never talk to a Pod directly. A Service gives a stable name and IP that load-balances across Pods matched by labels. ClusterIP is internal-only, NodePort opens a port on every node, LoadBalancer provisions an external load balancer.

Every Service gets a DNS name inside the cluster, so apps find each other by name, not IP. Same namespace uses the short name; across namespaces use service.namespace. This is how microservices locate one another.

By default every Pod can talk to every other Pod. A NetworkPolicy locks that down, it specifies which Pods may send traffic to (ingress) or receive from (egress) a selected set of Pods. This is how you isolate workloads.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress }
spec:
  podSelector: {}              # selects ALL pods in the namespace
  policyTypes: ["Ingress"]     # no ingress rules = deny all inbound

A Service exposes one app; Ingress routes external HTTP/HTTPS to many Services by hostname and path, behind one entry point. An Ingress controller (like nginx) does the routing; the Ingress object is just the rules.