KCNA cheat sheet — every exam topic on one page

Kubernetes Fundamentals

Kubernetes Core Concepts: Architecture, Pods, Deployments, and Services

• A Pod is the smallest deployable unit; its containers share one network namespace (one IP) and can share volumes such as an emptyDir.
• The kube-apiserver is the front door: kubectl, the kubelet, and all controllers talk to the cluster only through it.
• etcd is the cluster's key-value datastore and single source of truth; it needs a majority quorum to accept writes, and an etcd snapshot is the cluster backup.
• The kube-scheduler only picks a node for each Pod; the kubelet on that node starts the containers via the runtime and sends the node heartbeat.
• kube-controller-manager runs the provider-neutral controllers (including the node controller); cloud-controller-manager provisions cloud resources such as LoadBalancer Services.
• A ReplicaSet keeps N Pods matching its selector alive; a Deployment owns ReplicaSets and adds rolling updates (maxSurge/maxUnavailable) and rollback via kubectl rollout undo, with no automatic rollback on failure.
• A Service gives a stable virtual IP and DNS name to the ready Pods matching its selector; readiness failures remove a Pod from traffic, liveness failures restart it.
• Namespaces scope names, access, and quotas; labels plus selectors are the glue that connects Services and controllers to Pods.
• Kubernetes is declarative: controllers continuously reconcile observed state toward the desired state stored in etcd, so control plane outages freeze change and healing but leave running Pods running.

Kubernetes Administration: kubectl, RBAC, Namespaces, and Resource Quotas

• Every kubectl command is a request to the kube-apiserver; for logs and exec the API server relays to the kubelet on the Pod's node (port 10250), so a blocked path to one kubelet breaks only those commands.
• kubectl config use-context rewrites current-context in the kubeconfig file and switches cluster, user, and namespace together.
• kubectl apply is declarative and idempotent; an imperative scale or edit is reverted by the next apply of a manifest that sets that field.
• Localise failures along the chain: no ReplicaSet or Pods means the controller manager, Pending Pods the scheduler, a ClusterIP failing on one node that node's kube-proxy.
• etcd needs a majority (floor(n/2)+1): 3 and 4 members both tolerate one failure, 5 tolerate two - hence odd counts. Back up etcd to back up the cluster.
• A Role grants permissions in one namespace; a ClusterRole via a ClusterRoleBinding reaches every namespace and cluster-scoped resources, but via RoleBindings never reaches cluster-scoped ones like Nodes.
• RBAC is additive and allow-only: no deny rules, so excluding one namespace means replacing a ClusterRoleBinding with per-namespace RoleBindings.
• Rules name API groups ("" is core; Deployments are in apps) and subresources separately: logs needs get on pods/log, exec needs create on pods/exec.
• Test a ServiceAccount with --as=system:serviceaccount:<namespace>:<name>; a bare name impersonates a user instead.
• A ResourceQuota caps a namespace's totals at admission and is not retroactive; a LimitRange sets per-container defaults, minimums, and maximums.
• Namespaces scope names, access, and quotas, but not the network or the nodes; deleting one does not remove cluster-scoped objects such as ClusterRoleBindings that reference it.

Kubernetes Scheduling: Requests, Node Affinity, Taints and Tolerations

• The kube-scheduler filters out infeasible nodes, sums weighted plugin scores for the rest, and binds the Pod to the winner; setting spec.nodeName bypasses it entirely.
• Requests drive scheduling and are compared with allocatable minus already-requested capacity; limits are enforced at runtime and play no part in placement.
• A limit with no request (and no LimitRange default) makes the request equal to the limit, so it counts in full for scheduling.
• A container over its CPU limit is throttled; one over its memory limit is OOMKilled and its restart policy applies.
• nodeSelector labels are ANDed with no OR; node affinity adds operators like In, with expressions ANDed inside a term and terms ORed.
• Required rules filter and can leave Pods Pending; preferred rules only score. Required zone anti-affinity allows at most one matching Pod per zone.
• Topology spread constraints balance Pods within maxSkew: DoNotSchedule is a hard filter, ScheduleAnyway a scoring preference.
• Taints repel, tolerations permit but never attract; dedicated nodes need a taint plus a toleration plus a nodeSelector or required affinity.
• NoExecute evicts running Pods (after tolerationSeconds); NoSchedule and kubectl cordon only block new ones.
• A higher-priority Pending Pod can preempt lower-priority Pods; preemptionPolicy: Never keeps its queue priority without evicting anything.
• A DaemonSet runs one Pod on every eligible node; a nodeSelector narrows eligibility, tolerations widen it.
• A Pod stays Pending when no single node passes filtering; kubectl describe pod shows a FailedScheduling event with the reason per node.

Containerization: Images, Container Runtimes, CRI and the OCI Explained

• A container is an isolated process on a shared host kernel: namespaces control what it sees, cgroups control what it uses, seccomp and AppArmor control what it may do.
• Containers virtualize the operating system; VMs virtualize the hardware. A base image supplies user-space files only, never a kernel.
• Isolation is one-way: containers cannot see host processes, but the host sees every container process unless a VM-sandboxed runtime such as Kata is used.
• Images are stacks of immutable read-only layers; tags are mutable pointers, digests are immutable content hashes. nginx expands to docker.io/library/nginx:latest.
• Order Dockerfiles so dependency installs come before copying source; clean up temporary files in the same RUN or use a multi-stage build, because a later delete does not shrink the image.
• The OCI publishes the image, runtime and distribution specs (runc is the reference runtime). The kubelet drives the runtime through the CRI; containerd defaults to runc, CRI-O to crun, and crictl is the CRI-level debugging tool.
• A RuntimeClass maps a name to a runtime handler, letting Pods opt into sandboxed runtimes such as gVisor or Kata via runtimeClassName.
• Kubernetes removed the Dockershim in 1.24; Docker-built images still run because they are OCI images, and cri-dockerd is the only way to keep Docker Engine as the node runtime.
• Images tagged latest or untagged default to imagePullPolicy Always, other tags and digests to IfNotPresent; only a digest pins content, and private pulls need imagePullSecrets.
• Podman is daemonless and rootless-friendly, runs pods locally and round-trips Kubernetes YAML with podman kube generate and podman kube play; skopeo copies images between registries without a daemon.

Container Orchestration

Kubernetes Networking: Services, kube-proxy, CNI, DNS, and Ingress

• Every Pod gets its own IP address, and Pods reach each other across nodes without NAT and without a Service; that flat model is implemented by the CNI plugin, and kubeadm leaves nodes NotReady until you install one.
• A Service provides a stable virtual IP and DNS name in front of ephemeral Pods; any running Pod whose labels match becomes an endpoint, whichever controller created it, and a Pod without a readiness probe counts as ready once running.
• kube-proxy runs on every node and programs iptables (default), nftables or IPVS (deprecated) rules that turn Service IPs into Pod endpoints; it never handles traffic sent directly to a Pod IP.
• ClusterIP is internal-only and the default; NodePort opens a high port (30000-32767) on every node; LoadBalancer provisions a cloud load balancer that by default targets those node ports.
• A headless Service (clusterIP: None) returns Pod IPs directly in DNS and gives StatefulSet Pods names like db-0.db.shop.svc.cluster.local; ExternalName returns a CNAME to an outside hostname.
• CoreDNS resolves names like api.shop.svc.cluster.local; short names work within the same namespace.
• Ingress defines layer 7 host and path routing but needs a controller (ingress-nginx is retired); the Gateway API splits a platform-owned Gateway from team-owned HTTPRoutes and supports weighted backends as standard.
• Pods are default-allow until a NetworkPolicy selects them; a bare podSelector matches only the policy's own namespace, cross-namespace peers need a namespaceSelector, and default-deny egress must explicitly allow DNS on port 53.

Kubernetes Security: The 4Cs, RBAC, Secrets, and Pod Security Admission

• The 4Cs are Cloud, Cluster, Container, Code, outermost to innermost: nested layers of defense in depth where a weakness in an outer layer undermines the inner ones.
• RBAC is additive and allow-only; a RoleBinding can reference a Role in its own namespace or a ClusterRole, granting its rules only in that namespace, while a ClusterRoleBinding grants cluster-wide.
• A ServiceAccount is a Pod's API identity; give workloads dedicated minimal ServiceAccounts and set automountServiceAccountToken: false when the API is not needed.
• Secrets are base64-encoded in the API (an encoding, not protection) and unencrypted in etcd by upstream default; RBAC guards API access, and an EncryptionConfiguration with a real provider before identity guards etcd data.
• PodSecurityPolicy was deprecated in 1.21 and removed in 1.25; Pod Security Admission applies Privileged, Baseline, or Restricted per namespace label in enforce (reject), audit (record only) or warn (message only) mode, and modes can use different levels.
• runAsNonRoot is a start-time check by the kubelet and does not choose a user (runAsUser does); allowPrivilegeEscalation: false blocks later escalation such as setuid.
• Admission runs after authorization: mutating admission first, then validating admission on the mutated object, with webhooks to engines like OPA Gatekeeper and Kyverno.
• Supply chain security means scanning for CVEs, signing images and verifying signatures at admission, keeping SBOMs and using minimal base images; pull secrets and digests do not prove provenance.
• NetworkPolicies turn default-allow networking into allow-lists that block lateral movement, but only when the CNI plugin enforces them.

Troubleshooting Kubernetes: Pod Status, Events, Logs, and Probes

• The five Pod phases are Pending, Running, Succeeded, Failed, and Unknown; containers have their own states (Waiting, Running, Terminated), and kubectl shows a Succeeded Pod as Completed.
• Images are pulled by the kubelet only after the Pod is bound to a node; imagePullPolicy Always contacts the registry on every container start, IfNotPresent uses a cached copy, and Never fails with ErrImageNeverPull when the image is absent.
• ImagePullBackOff means the image cannot be pulled; CreateContainerConfigError means an env reference to a ConfigMap or Secret (or key) is missing; CrashLoopBackOff means the container ran and keeps exiting.
• A missing ConfigMap or Secret mounted as a volume gives FailedMount and ContainerCreating; an unbound PVC gives FailedScheduling and Pending.
• OOMKilled is per container and can happen on a node with free memory; a CPU limit only throttles; node-pressure eviction (memory, disk, PIDs) ends a Pod as Failed with reason Evicted.
• kubectl logs --previous reads the crashed instance; --since and --tail only filter the instance being read; -c picks a container, --all-containers reads them all, -l selects Pods by label.
• A failing liveness probe restarts the container; a failing readiness probe only removes the Pod from Service endpoints; a startup probe holds both off - init containers and postStart hooks do not.
• A Service with no endpoints means its selector matches no Pods or they are not ready; a wrong targetPort leaves ready endpoints that refuse connections, and containerPort is informational.
• kubectl top shows live usage from metrics-server; kubectl describe shows configured requests and limits.
• kubectl describe ends with the Events section - FailedScheduling, FailedMount, BackOff and Unhealthy name the cause; events expire after about an hour by default.
• A NotReady node means its kubelet stopped reporting healthy; kubectl describe node shows the conditions (Ready, MemoryPressure, DiskPressure, PIDPressure).

Kubernetes Storage: Volumes, PersistentVolumes, PVCs, and CSI

• A Volume is declared once in spec.volumes and is visible only to containers that mount it via their own volumeMounts; emptyDir survives container restarts but not Pod deletion.
• Secrets are the object for sensitive values (own RBAC, optional encryption at rest, tmpfs-backed volumes), but their data is only base64-encoded by default; ConfigMap and Secret keys can also be consumed as environment variables.
• PersistentVolumes are the cluster-scoped supply of storage; PersistentVolumeClaims are namespaced requests that bind to them one-to-one (receiving the whole PV), and a Pod references a claim in its own namespace, never the PV.
• The four access modes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), and ReadWriteOncePod (RWOP) - the abbreviations kubectl prints.
• ReadWriteOnce limits the volume to one node, not one Pod - a Pod on a second node hits a Multi-Attach error; only ReadWriteOncePod guarantees a single Pod, and it requires CSI.
• Reclaim policy Retain keeps the PV and its data (status Released, manual cleanup); Delete removes the PV and the underlying storage, and is the default when a StorageClass sets no reclaimPolicy.
• A StorageClass defines a provisioner and parameters; a PVC referencing it (or the default class) triggers dynamic provisioning, and WaitForFirstConsumer delays it until a Pod is scheduled so zonal disks land in the right zone.
• CSI is the standard interface storage vendors implement, alongside CRI for runtimes and CNI for networking; it replaced in-tree volume plugins.
• StatefulSet volumeClaimTemplates create one PVC per replica (like data-db-0); the default retention policy (Retain on scale-down and delete) keeps them, so a recreated replica reattaches its own claim.

Cloud Native Application Delivery

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies

• RollingUpdate is the default Deployment strategy; no RollingUpdate setting guarantees old and new versions never overlap, so only Recreate does - at the cost of downtime
• maxSurge sets the ceiling (replicas + surge, percentages round up) and maxUnavailable the floor (replicas - unavailable, percentages round down); both cannot be 0, and on a full cluster use maxSurge 0
• kubectl rollout status blocks and exits non-zero when progressDeadlineSeconds passes, making it a pipeline gate; kubectl rollout undo returns to the previous revision
• Blue-green switches a Service selector between full environments; without a mesh, a canary's traffic share follows its Pod ratio
• Pin images by a unique version tag or digest - latest and per-environment tags like prod move, and imagePullPolicy only changes when the kubelet pulls
• The four OpenGitOps principles: declarative, versioned and immutable, pulled automatically, continuously reconciled; deploys are merged pull requests and rollback is git revert
• Drift is reverted only when the controller is set to do so (Argo CD automated sync with selfHeal; Flux Kustomizations reapply each interval, while HelmRelease drift correction is opt-in) - an imperative rollback on a GitOps-managed object is itself drift
• Helm: chart (package), chart archive (.tgz), values, release (installed instance), revision; helm rollback records a new revision
• Kustomize keeps every file valid YAML: kubectl kustomize renders, kubectl diff -k previews, kubectl apply -k applies
• Cloud Native Buildpacks build images without a Dockerfile; Harbor stores, scans and signs them; Tekton runs CI pipelines, Argo CD and Flux do GitOps

Debugging Application Delivery: Stuck Rollouts, Failed Releases, and Rollbacks

• A rolling update only progresses as new Pods become available; a bad release stalls while the old ReplicaSet keeps serving
• maxSurge and maxUnavailable default to 25% (surge rounds up, unavailable rounds down), so a broken 4-replica rollout freezes at 3 old + 2 new Pods
• Deployment conditions: Available, Progressing and, when Pod creation is rejected, ReplicaFailure; ProgressDeadlineExceeded is a reason on Progressing
• progressDeadlineSeconds (default 600) counts from the last progress, and exceeding it triggers no automatic rollback
• ImagePullBackOff = bad image; Running 0/1 with no restarts = readiness failing; climbing RESTARTS = liveness failing; Pending = unschedulable; FailedCreate on the ReplicaSet = quota rejection
• kubectl rollout history --revision=N only shows a revision; rollout undo --to-revision=N restores it, within revisionHistoryLimit (default 10); CHANGE-CAUSE reads kubernetes.io/change-cause
• Match the remedy to the diagnosis: rollback cannot add capacity, and restarting Pods reuses the same broken template
• Helm 4 renamed --atomic to --rollback-on-failure (a failed install is uninstalled) and --wait now takes a strategy; the default hookOnly does not wait for resource readiness
• Alerts notify and HPAs scale; only a metric-gated rollout such as Argo Rollouts analysis aborts a bad release automatically

Cloud Native Architecture

Observability in Cloud Native: Metrics, Logs, and Traces

• Metrics measure trends over time, logs record discrete events, traces follow one request across services; Kubernetes Events record what the cluster did to objects and expire after about an hour.
• Prometheus pulls metrics by scraping HTTP endpoints, keeps 15 days of local history by default, and is queried with PromQL; short-lived batch jobs push to a Pushgateway that Prometheus scrapes.
• Alertmanager, not Prometheus itself, deduplicates, groups, silences, and routes alerts; a rule's for: duration only delays firing.
• metrics-server powers kubectl top and the HPA with current CPU and memory only; it keeps no history, has no PromQL, and kubectl logs does not depend on it.
• Containers log to stdout and stderr; a DaemonSet agent like Fluent Bit ships every container's logs without changing Pod specs, while a sidecar needs a change to each Pod.
• OpenTelemetry instruments code and propagates trace context vendor-neutrally; Jaeger stores and visualizes traces. Missing context propagation splits one request into several traces.
• Prometheus, Fluentd, and Jaeger are CNCF graduated projects; exporters adapt third-party systems to Prometheus without changing them.
• Requests compared with observed usage is the evidence for right-sizing; saturation, read from Prometheus history, tests a resource-bottleneck theory.

Cloud Native Principles and the CNCF Ecosystem

• The CNCF definition names five techniques: containers, service meshes, microservices, immutable infrastructure, and declarative APIs. GitOps and serverless are popular practices, not among the five.
• Cloud native systems aim to be loosely coupled, resilient, manageable, and observable, with change driven by automation.
• Microservices trade operational complexity for independent scaling, deployment, and team autonomy; monoliths are simpler to run and debug.
• A service mesh handles east-west service-to-service traffic (mTLS, retries, traffic shifting) without code changes; API gateways and Ingress handle north-south traffic entering the application.
• Immutable infrastructure means replace, not patch: ship a new container image instead of modifying a running instance.
• Declarative APIs plus reconciliation loops produce self-healing: after a node failure, Pods are evicted after the default 300-second toleration and the ReplicaSet controller creates replacements, which the scheduler places on healthy nodes.
• HPA scales Pod replicas (minimum one by default; zero only on object or external metrics), VPA right-sizes Pod requests, Cluster Autoscaler changes node count, and KEDA scales on events down to zero.
• Diagnose by symptom: Pending Pods for lack of CPU need nodes (Cluster Autoscaler); OOMKills need a bigger memory limit, not more replicas. Do not let HPA and VPA act on the same metric.
• Serverless means no server management and scale-to-zero; Knative brings request-driven and event-driven serverless to Kubernetes.
• OPA is a general-purpose policy engine (Rego); Falco detects runtime threats; Alertmanager routes Prometheus alerts; the OpenTelemetry Collector moves telemetry.

CNCF Community, Project Maturity Levels, and Open Source Governance

• The CNCF is a project of the Linux Foundation and a vendor-neutral home for cloud native open source; Kubernetes was its first hosted project and first to graduate.
• CNCF projects climb three maturity levels in order: Sandbox, Incubating, Graduated. Archived is a status for inactive projects, not a fourth level.
• Incubating needs independent adopters (dev/test use is enough) and a healthy contributor base; Graduated adds production use, maintainers from at least two organizations and a third-party security review.
• The TOC accepts projects and votes on maturity moves and archiving by a two-thirds supermajority; the Governing Board handles budget, marketing and business oversight.
• Archived projects lose CNCF support services and cannot advertise their former level, but the CNCF and Linux Foundation keep their trademarks and domains.
• Kubernetes SIGs own areas of the code long-term; working groups are temporary, cross-SIG and own no code; the Steering Committee governs Kubernetes as a whole.
• Maintainers are nominated and approved by existing maintainers under each project's governance, not appointed by the TOC, CNCF staff or employers.
• End users run the technology, vendors sell around it, ambassadors advocate for it, and Kubestronauts hold all the Kubernetes certifications.