CKAD study materials
CKAD study resources

CKAD cheat sheet

CKAD · Keep the key ideas within reach.

Quick reference

Application Design and Build

  • Workload selection rule: Deployment for stateless replicated pods, StatefulSet for stable names and ordered start, DaemonSet for one pod per node, Job or CronJob for run-to-completion work.

  • A Job's pod template accepts only restartPolicy Never or OnFailure; OnFailure restarts the container inside the existing pod, Never causes a replacement pod to be created.

  • CronJob spec.schedule uses five-field cron (minute hour day-of-month month day-of-week) evaluated in the controller manager's time zone, UTC by default.

  • initContainers run sequentially in declaration order and must each exit 0 before any app container starts; a failure restarts the pod according to its restartPolicy.

  • All containers in a pod share one network namespace (same pod IP, reachable via localhost) and can mount volumes declared at pod level.

  • emptyDir is created when the pod is assigned to a node and deleted when the pod is removed from the node; container restarts preserve its contents.

  • Image pull policy: IfNotPresent is the default for tagged images, Always is the default for the :latest tag or no tag, Never requires the image to already exist on the node.

  • Multi-stage builds keep build tooling out of the final image: each FROM begins a new stage and COPY --from= copies only the wanted artifacts forward.

  • Access modes: ReadWriteOnce binds a volume to a single node, ReadOnlyMany and ReadWriteMany span nodes, ReadWriteOncePod restricts to one pod; a PVC binds to a PV matching capacity, access modes and storageClassName.

Quick reference

Application Deployment

  • RollingUpdate defaults are maxSurge 25% and maxUnavailable 25%; maxUnavailable 0 with maxSurge above 0 yields a zero-downtime rollout that temporarily exceeds desired replicas.

  • Recreate terminates every old pod before any new pod starts, producing downtime but guaranteeing that two versions never run simultaneously.

  • Only a change to the pod template creates a new ReplicaSet and a new revision; editing spec.replicas alone scales the existing ReplicaSet.

  • kubectl rollout status|history|undo|pause|resume deployment/; undo --to-revision=N reverts to a stored revision, retained per revisionHistoryLimit (default 10).

  • Blue/green deployment: both versions run as separate Deployments with distinct labels; cutover and rollback are done by repointing the Service selector.

  • Canary deployment: both Deployments carry a shared label matched by the Service plus a unique version label, so the traffic share approximates canaryReplicas divided by totalReplicas.

  • helm install / upgrade --install / rollback / uninstall operate against the cluster; helm template renders manifests locally with no cluster contact; values are overridden with -f or --set over helm show values output.

  • kubectl set image deployment/ = patches the pod template and triggers a rollout; the reason can be recorded with the kubernetes.io/change-cause annotation.

Quick reference

Application Observability and Maintenance

  • A failing livenessProbe causes the kubelet to restart the container; a failing readinessProbe only removes the pod from Service Endpoints; a startupProbe suppresses both until it succeeds.

  • Probe defaults: periodSeconds 10, timeoutSeconds 1, failureThreshold 3, successThreshold 1, initialDelaySeconds 0.

  • Probe handlers: httpGet succeeds on status 200-399, exec succeeds on exit code 0, tcpSocket succeeds if the connection opens, gRPC uses the standard health checking protocol.

  • Container exit code 137 means SIGKILL (memory-limit OOM kill or liveness restart); 143 means SIGTERM; 0 means clean completion.

  • kubectl logs -c --previous reads the logs of the prior terminated container instance; -f follows and --tail=N limits output.

  • kubectl debug -it --image= --target= injects an ephemeral container sharing the target's process namespace; kubectl debug node/ creates a debugging pod on the node.

  • kubectl top pod|node requires metrics-server to be installed; kubectl describe and kubectl get events --sort-by=.lastTimestamp expose image pull, scheduling and probe failures.

  • Deprecation checks: kubectl api-resources and kubectl api-versions list served groups and versions; a workload using a removed API version fails to apply.

  • A pod stuck Pending reports the reason (insufficient cpu, nodeSelector mismatch, unbound PVC, taints) in its Events, not in status.phase.

Quick reference

Application Environment, Configuration and Security

  • kubectl create configmap --from-literal=k=v --from-file=; consumption is via envFrom, valueFrom.configMapKeyRef, or a volume mount of the whole object.

  • Keys consumed as env vars are frozen at container start, while keys mounted as a volume are refreshed in the container after the ConfigMap or Secret changes.

  • Secret data fields must be base64-encoded; stringData accepts plain text and is encoded server-side. Common types are Opaque (default), kubernetes.io/dockerconfigjson and kubernetes.io/tls.

  • requests are used by the scheduler to place pods; limits are enforced by the kubelet - exceeding a memory limit causes an OOM kill, exceeding a CPU limit causes throttling.

  • QoS classes: Guaranteed requires requests equal to limits for CPU and memory in every container, BestEffort requires none set, everything else is Burstable.

  • ResourceQuota caps aggregate namespace consumption and object counts; LimitRange supplies per-container default requests and limits and enforces min/max bounds.

  • runAsUser, runAsGroup, runAsNonRoot, fsGroup and supplementalGroups are pod-level securityContext fields; readOnlyRootFilesystem, allowPrivilegeEscalation and capabilities are container-level and take precedence.

  • ServiceAccount tokens are projected at /var/run/secrets/kubernetes.io/serviceaccount; automountServiceAccountToken: false on the pod or ServiceAccount disables the mount.

  • Authorization uses RBAC after authentication and before admission: Role/RoleBinding is namespaced, ClusterRole/ClusterRoleBinding is cluster-wide; kubectl auth can-i --as= verifies it.

Quick reference

Services and Networking

  • Service types: ClusterIP (default, cluster-internal virtual IP), NodePort (opens a port on every node), LoadBalancer (provisions an external load balancer), ExternalName (returns a CNAME to an external DNS name).

  • port is the port the Service exposes, targetPort is the container port traffic is forwarded to and defaults to port, nodePort is the port opened on each node.

  • Endpoints include only pods whose labels match the selector and whose readinessProbe passes; setting publishNotReadyAddresses: true includes unready pods.

  • A headless Service sets clusterIP: None and returns individual pod A records through DNS, which is how StatefulSets expose stable per-pod names.

  • DNS naming: ..svc.cluster.local for Services and ..pod.cluster.local for pods; pods in the same namespace can use the bare Service name.

  • In a NetworkPolicy an empty podSelector {} selects all pods in the namespace, an empty from/to list denies all, and policies are purely additive allow rules with no explicit deny.

  • A default-deny ingress policy is policyTypes: [Ingress] with podSelector: {} and no ingress rules; enforcement requires a CNI plugin that implements NetworkPolicy.

  • Ingress requires an installed controller; rules match on host and path with pathType Prefix, Exact or ImplementationSpecific, and TLS terminates using the certificate in spec.tls[].secretName.

  • kubectl port-forward svc/ 8080:80 forwards local traffic through the Service and its load balancing; port-forward pod/ targets one pod directly.