Kubernetes Orchestration

This deck walks you through the core building blocks of Kubernetes, starting with the smallest deployable unit, the Pod, and working up through Services, Deployments, ReplicaSets, and configuration objects like ConfigMaps and Secrets. Each card targets a specific concept or pattern, so you can chip away at the vocabulary and mental models that make up modern container orchestration one piece at a time.

It is a good fit if you are new to Kubernetes and want a structured way to learn the essentials, or if you are preparing for a certification like the CKAD or CKA and need to drill foundational terminology. Developers and operators who already touch Kubernetes occasionally will also find it useful as a refresher on the patterns they use day to day, such as sidecars, init containers, and rolling updates.

Because the cards are designed to be reviewed repeatedly, try spacing your study sessions over several days rather than cramming them in one sitting. Reading about a concept is helpful, but the ideas really click when you also fire up a small cluster with minikube or kind and create the resources yourself. Pairing the flashcards with a little hands-on experimentation will make the recall stick far longer.

Kubernetes workloads are built from a small set of composable building blocks. The foundational unit is the Pod, which represents a single instance of a running process and may contain one or more containers that share a network namespace, storage volumes, and a common lifecycle. Multiple containers in a Pod are useful for tightly coupled processes that need to share resources: the sidecar pattern places a helper such as a logging agent alongside the main container, the ambassador pattern proxies network traffic on its behalf, and the adapter pattern transforms output for downstream consumers. Init containers run before the main application containers, executing to completion in order and typically handling setup tasks like pre-populating volumes, waiting for dependencies, or running migrations.

For long-running services, a Deployment manages a set of identical Pods through a ReplicaSet, supporting declarative updates, rolling updates governed by maxSurge and maxUnavailable parameters, easy scaling, and rollback to previous revisions via kubectl rollout undo. Deployments are the recommended way to manage replicated stateless workloads because the underlying ReplicaSet is hidden behind them. When stable network identity, ordered deployment, and persistent storage matter, as with databases like MySQL or distributed systems like Kafka and ZooKeeper, StatefulSets assign each Pod a persistent hostname such as web-0 and web-1 and bind each one to its own PersistentVolumeClaim. DaemonSets take a different approach, ensuring one copy of a Pod runs on every node (or a chosen subset) for cluster-wide agents like Fluentd, Prometheus node-exporter, or CNI plugins. For finite work, Jobs run Pods to successful completion with parameters like completions, parallelism, and backoffLimit, while CronJobs schedule Jobs on cron expressions and add concurrencyPolicy and history retention settings to control overlap and cleanup.

Pods come and go with their changing IP addresses, so Kubernetes abstracts them behind Services, which define a logical set of Pods and a stable access policy. A Service uses label selectors to match Pods and provides a stable IP, DNS name, and load balancing. The default ClusterIP type exposes the Service only inside the cluster for microservice-to-microservice traffic, while NodePort adds a static port in the 30000–32767 range on every node's IP, enabling external access via NodeIP:NodePort. LoadBalancer builds on top by provisioning a cloud-provider load balancer such as AWS ELB, with traffic flowing External LB → NodePort → ClusterIP → Pod. ExternalName maps a Service to a CNAME record pointing to an external DNS name, providing a cluster-internal alias for outside services, and headless Services (clusterIP: None) return Pod IPs directly through DNS, often paired with StatefulSets to give each Pod a stable address for peer-to-peer communication.

For HTTP and HTTPS traffic at higher layers, an Ingress resource defines host-based and path-based routing rules with optional TLS termination. An Ingress resource is inert on its own; it requires an Ingress Controller such as NGINX, Traefik, HAProxy, or AWS ALB to watch the resources and configure the underlying load balancer. TLS certificates are referenced through a Secret containing tls.crt and tls.key, and tools like cert-manager automate issuance from Let's Encrypt via ACME HTTP-01 or DNS-01 challenges, with the DNS-01 challenge supporting wildcard certificates. At the network level, NetworkPolicies are namespace-scoped rules enforced by CNI plugins such as Calico and Cilium that control Pod-to-Pod and Pod-to-external traffic by IP and port. Without any policy in a namespace, all Pods can talk to all Pods, so the recommended baseline is a default-deny policy that selects all Pods and blocks all traffic, layered with explicit allow rules including an egress allowance for UDP/53 to the kube-system namespace so CoreDNS continues to resolve names. Service meshes like Istio, Linkerd, and Consul Connect add a further layer for service-to-service communication, with sidecar proxies (typically Envoy) injected automatically by a mutating admission webhook that provide mutual TLS, retries, traffic splitting, and observability. Istio extends this with VirtualService for routing rules such as canary weights and DestinationRule for post-routing traffic policies including connection pools and outlier detection.

Applications need configuration and data, and Kubernetes offers dedicated primitives for both. ConfigMaps store non-confidential key-value pairs that Pods consume as environment variables, command-line arguments, or mounted files, while Secrets hold sensitive material such as passwords, tokens, and TLS certificates. Secret data is base64-encoded by default rather than encrypted, so production clusters should enable encryption at rest via the kube-apiserver's --encryption-provider-config, and many teams use external secret managers like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault with operators such as the External Secrets Operator to sync values into Kubernetes Secrets. Common Secret types include Opaque for arbitrary key-value data, kubernetes.io/tls for certificates, and kubernetes.io/dockerconfigjson for registry credentials, the last of which is referenced from a Pod's imagePullSecrets list when pulling from private registries.

Storage in Kubernetes is decoupled into three layers. PersistentVolumes are cluster-level resources that exist independently of any Pod, provisioned manually by an admin or dynamically through a StorageClass that names a provisioner such as kubernetes.io/aws-ebs or pd.csi.storage.gke.io along with parameters, reclaimPolicy, and volumeBindingMode. PersistentVolumeClaims are user requests for storage with a desired size and access mode; Kubernetes binds a matching PV to the PVC, and Pods reference the claim in their volume spec. Access modes include ReadWriteOnce for single-node read-write, ReadOnlyMany for many-node read-only, ReadWriteMany for many-node read-write (supported by NFS, CephFS, EFS), and the newer ReadWriteOncePod for single-Pod access. Setting volumeBindingMode to WaitForFirstConsumer delays PV binding until a Pod is scheduled so the volume is created in the same zone as the Pod, avoiding Pending PVCs caused by zone mismatch. Beyond persistent storage, lighter-weight volumes exist for ephemeral use: emptyDir is created when a Pod is assigned to a node, lives for the Pod's lifetime, and is shared between containers, while hostPath mounts a directory from the host filesystem and is restricted under the restricted Pod Security Standard because it couples Pods to specific nodes. VolumeSnapshots capture point-in-time copies of PVCs through a VolumeSnapshotClass, enabling database-style backups and clones, and Container Storage Interface (CSI) drivers have been the standard since in-tree plugins were removed in v1.26.

Packaging and templating these resources is the role of Helm, the de facto package manager for Kubernetes. A Helm chart is a directory containing Chart.yaml with metadata, values.yaml with default configuration, a templates/ directory of Go-templated Kubernetes manifests, optional dependency sub-charts under charts/, and a README. Installing a chart creates a release, a running instance with a specific configuration, and the same chart can be installed multiple times with different names and values. Charts are discovered through repositories added with helm repo add, refreshed with helm repo update, and searched with helm search repo.

Kubernetes offers fine-grained control over where Pods run and how many resources they consume. The scheduler selects an optimal node for each new Pod based on resource requests, affinity and anti-affinity rules, taints and tolerations, node selectors, and topology spread constraints. Taints applied to nodes repel Pods that lack matching tolerations, with effects NoSchedule for hard rejection, PreferNoSchedule for soft preference, and NoExecute for evicting already-running Pods. Node affinity constrains scheduling via node labels, with requiredDuringSchedulingIgnoredDuringExecution as a hard requirement and preferredDuringSchedulingIgnoredDuringExecution as a soft preference weighted numerically. Pod anti-affinity keeps replicas of the same workload spread across nodes or zones, while topology spread constraints generalize this idea by distributing Pods across failure domains defined by a topologyKey such as topology.kubernetes.io/zone, capped by a maxSkew value.

Scaling happens at two levels. The Horizontal Pod Autoscaler adjusts the replica count of a Deployment or ReplicaSet based on observed CPU, memory, or custom metrics, while the Vertical Pod Autoscaler tunes the CPU and memory requests and limits of individual containers using Off, Auto, or Initial modes. Because VPA may restart Pods to apply changes, it should not be used on the same CPU/memory metrics as HPA. The Cluster Autoscaler operates one level higher, adding or removing worker nodes when Pods cannot be scheduled or when nodes are underutilized. Resource requests and limits are central to all of this: requests drive scheduling decisions and must fit on a node, while limits drive runtime enforcement, with exceeded CPU limits causing throttling and exceeded memory limits triggering OOMKill. CPU is measured in millicores, where 1000m equals one vCPU.

Each Pod's combined settings give it a Quality of Service class: Guaranteed when every container's requests equal its limits, Burstable when some are set, and BestEffort when none are, with kubelet eviction preferring to kill BestEffort Pods first under node pressure. PriorityClass assigns a numeric priority to Pods so the scheduler can preempt lower-priority Pods when the cluster is full, with built-in classes such as system-node-critical and system-cluster-critical for system components. PodDisruptionBudgets complement replica counts by capping how many Pods of an application can be simultaneously unavailable during voluntary disruptions such as node drains, using either minAvailable or maxUnavailable. Throughout all of this, labels and selectors are the connective tissue: equality-based selectors like app=nginx and set-based selectors like env in (prod, staging) let Services, Deployments, ReplicaSets, and other controllers target the right Pods, while annotations carry non-identifying metadata that selectors cannot use but external tools can read.

A Kubernetes cluster is divided into a control plane that makes global decisions and worker nodes that actually run workloads. The control plane runs the kube-apiserver as its front-end and the only component that talks directly to etcd, which is a distributed consistent key-value store using the Raft consensus algorithm that holds all cluster state, including node information, Pod specs, and Secrets. Because losing etcd data effectively destroys the cluster, regular backups are essential. The kube-scheduler watches for newly created Pods without an assigned node and chooses one based on resource fit, affinity rules, taints and tolerations, and topology spread constraints, while the kube-controller-manager runs core controller loops that reconcile actual state toward desired state for resources such as nodes, Jobs, endpoints, and ServiceAccount tokens.

Worker nodes run the kubelet, kube-proxy, and a container runtime. The kubelet is the node agent that registers the node with the apiserver, watches for Pod specs assigned to it, runs init containers in order, pulls images through the Container Runtime Interface, sets up networking via a CNI plugin, mounts volumes, starts containers, runs health probes with configurable delay parameters, and reports status back. kube-proxy maintains iptables, IPVS, or eBPF rules on each node so traffic destined for Service cluster IPs is load-balanced to the correct backend Pods. The container runtime, which is responsible for actually running containers, must implement the CRI; supported options include containerd, CRI-O, and Mirantis Container Runtime, with Docker no longer supported directly since Kubernetes v1.24 because it sits on top of containerd. Every Pod also runs a tiny pause container that holds the network namespace and serves as the parent of all other containers in the Pod, giving them their shared IP and volume mount points. Networking is delegated to CNI plugins such as Calico, Cilium, Flannel, and Weave Net, which assign Pod IPs and configure routes when each Pod starts, and the kubelet's own configuration in /var/lib/kubelet/config.yaml controls cluster DNS, image pull policy, and cgroup driver settings. The apiserver exposes its REST interface at https://<apiserver>:6443 by default, with OpenAPI specifications available at /openapi/v2 and /openapi/v3, reachable only through client certificates, bearer tokens, or OIDC authentication. Pods transition through Pending, Running, Succeeded, Failed, and Unknown phases based on the kubelet's lifecycle, and graceful shutdown sends SIGTERM followed by SIGKILL after terminationGracePeriodSeconds, optionally preceded by a preStop hook for cleanup logic.

Kubernetes security spans authentication, authorization, admission control, runtime hardening, and network segmentation. Authorization is governed by Role-Based Access Control through four objects: Roles grant permissions within a specific namespace, ClusterRoles grant cluster-wide permissions or apply to non-namespaced resources like nodes and PersistentVolumes, RoleBindings attach a Role (or ClusterRole) to users, groups, or ServiceAccounts within a namespace, and ClusterRoleBindings do the same cluster-wide. Permissions are expressed as verb and resource pairs, with verbs covering get, list, watch, create, update, patch, delete, and deletecollection, and the wildcard * granting everything, which should be avoided in production. ClusterRoles can be bound to a single namespace through a RoleBinding to reuse permission sets across namespaces. kubectl auth can-i answers whether the current user (or an impersonated one via --as and --as-group) can perform a specific action, and is the standard tool for auditing RBAC.

Workload identity comes from ServiceAccounts, which are mounted into Pods at /var/run/secrets/kubernetes.io/serviceaccount/ by default. Every namespace has a default ServiceAccount, but the recommendation is to create a dedicated ServiceAccount per workload and to set automountServiceAccountToken: false unless the Pod actually calls the apiserver. Pod-level hardening is achieved through the SecurityContext, which controls runAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, and capabilities.drop. runAsNonRoot: true only requires that the UID be non-zero while the actual UID is decided by the image, and runAsUser sets a specific numeric UID; the two can be combined for strictness. Mounting the root filesystem read-only, combined with writable emptyDir volumes for paths like /tmp, is a hallmark of the restricted Pod Security Standard.

Pod Security Standards define three levels applied through namespace labels: Privileged is unrestricted, Baseline blocks known dangerous escalations, and Restricted enforces hardened best practices including no root, no host network, and no privileged containers. PodSecurity Admission is the built-in admission controller that implements these standards and replaced the older PodSecurityPolicy, which was removed in v1.25. Beyond Pod-level security, NetworkPolicies enforce traffic controls at the IP and port level via the CNI plugin, with default-deny as the recommended baseline, while ResourceQuotas and LimitRanges cap total and per-Pod consumption within a namespace. For richer policy, admission webhooks hook into the request pipeline: Mutating Admission Webhooks can modify objects before they are stored, and Validating Admission Webhooks can only accept or reject. Full policy engines like OPA Gatekeeper and Kyverno build on these webhooks: Gatekeeper uses Rego, while Kyverno uses YAML rules to validate, mutate, generate, and verify images across the cluster.

The kubectl command-line tool is the primary interface to the Kubernetes API, and a working knowledge of its verbs and flags is essential. kubectl get lists resources, with flags like -A for all namespaces, -o wide for additional columns such as node and IP, -o yaml or -o json for full output, --show-labels for inspecting labels, and -o jsonpath for scripted field extraction. kubectl describe shows detailed status including events, which makes it the first stop when debugging image pull failures, OOMKilled events, or probe failures. kubectl logs retrieves container output with -f to follow, --tail=N for the last N lines, -c to target a specific container in a multi-container Pod, --previous for the previous instance's logs, and -l to select by label. kubectl exec runs commands inside a container, supporting interactive shells with -it and multi-container targeting with -c, while kubectl cp moves files in and out using tar streams, kubectl port-forward opens local ports to Pods or Services for debugging, and kubectl debug launches an ephemeral container in a running Pod, the only way to shell into distroless images.

Lifecycle management uses kubectl apply -f to create or update resources from declarative manifests, kubectl delete -f or kubectl delete for removal, and kubectl diff -f as a preflight check that shows the difference between manifests on disk and live cluster state. Imperative shortcuts such as kubectl run, kubectl create deployment, and kubectl scale are quick but don't track history, whereas declarative manifests are versionable, diffable, and repeatable. kubectl edit opens a live resource in $EDITOR for quick changes, kubectl patch applies strategic merge, JSON merge, or JSON patches to specific fields, kubectl replace fully replaces an object requiring every field to be re-declared, and kubectl wait blocks until a condition is met, often used in CI/CD pipelines to wait for rollouts or ready replicas. kubectl top node and kubectl top pod display live CPU and memory usage sourced from the Metrics Server, kubectl events surfaces cluster events sorted by time, and Pods progress through Pending, Running, Succeeded, Failed, and Unknown phases with restartPolicy of Always, OnFailure, or Never depending on the workload kind.

Cluster access is configured through kubeconfig files in ~/.kube/config that bundle clusters (apiserver URL and CA cert), users (certificates, tokens, or OIDC), and contexts (cluster + user + namespace triples), and kubectl config use-context switches between them while --as and --as-group impersonate users for permission debugging. For node maintenance, kubectl cordon marks a node unschedulable without evicting workloads, kubectl drain safely evicts Pods while respecting PodDisruptionBudgets and is often combined with --ignore-daemonsets and --force for bare Pods, kubectl uncordon reverses the operation, and kubectl taint applies and removes taints; kubectl label and kubectl annotate manage metadata, while kubectl explain provides inline documentation for any resource field. Beyond the core CLI, kubectl proxy exposes a local HTTP proxy to the apiserver, and kubectl api-resources plus kubectl api-versions list everything the cluster supports.

The Kubernetes API itself is the central REST interface that all components use. It is organized into API groups such as apps/v1, batch/v1, and networking.k8s.io/v1, with core resources like Pod and Service in the core group. API versions progress through alpha (disabled by default, may break), beta (enabled by default, more stable), and GA/stable (versioned like v1, safe for production), with deprecated APIs eventually removed. Custom Resources extend the API with new object types you define yourself, and a CustomResourceDefinition registers a new kind with the apiserver. Combined with a custom controller, a CRD becomes a control loop, and this Operator pattern encodes operational knowledge such as backups, upgrades, scaling, and healing for specific applications; examples include etcd-operator, postgres-operator, and cert-manager. The Operator Framework provides tooling like the Operator SDK for scaffolding, the Operator Lifecycle Manager for installation and upgrades, and OperatorHub.io as a public registry. Observability typically combines the Metrics Server for short-term resource usage feeding the HPA and kubectl top, kube-state-metrics for raw object state metrics consumed by Prometheus, and the apiserver's audit log for security-relevant events when --audit-policy-file and --audit-log-path are configured.