Kubernetes Core Objects Cheat Sheet

This deck walks you through the foundational building blocks of a Kubernetes cluster, from the humble Pod all the way up through the controllers that manage them and the Services that expose them. The questions cover what each object is, what problem it solves, and how it relates to the others, so you can build a clear mental map of the core API rather than just memorizing isolated definitions.

It's a great fit if you're new to Kubernetes and trying to get comfortable with the vocabulary, or if you're preparing for a certification like the CKAD or CKA and want to drill the basics. Developers and operators who already work with clusters occasionally but want a more confident grasp of the "why" behind the YAML they write will also find it useful.

Because the cards are framed as short questions, try answering out loud or in writing before flipping each one over — active recall like this sticks far better than passive reading. It also helps to study related cards together in small batches (for example, all the workload controllers, or all the Service types), since the differences between them often become clearer when you compare them side by side.

A Pod is the smallest deployable unit in Kubernetes, encapsulating one or more tightly coupled containers that share a network namespace, inter-process communication, and optionally volumes. In the Kubernetes object model, a Pod represents a single instance of a running process and is described by a manifest containing metadata (such as labels and annotations) and a Pod spec. The required fields in any Pod spec are apiVersion, kind: Pod, metadata.name, spec.containers[].name, and at least one container image. Additional spec fields control runtime behavior, including imagePullPolicy, which determines when the kubelet pulls the image: Always, IfNotPresent, or Never, with :latest-tagged images defaulting to Always and other tags defaulting to IfNotPresent.

Beyond the main application containers, Pods may include Init Containers, which are specialized containers that run to completion before the main containers start. They are typically used for setup tasks such as database migrations or waiting for external dependencies. Native sidecar containers, GA in Kubernetes 1.29 and later, are declared within the initContainers array but use a restartPolicy: Always so they share the Pod's lifecycle and remain running alongside the main containers. The Pod-level spec.restartPolicy field accepts Always, OnFailure, or Never, with normal Pods defaulting to Always, Jobs defaulting to OnFailure, and CronJob-style workloads defaulting to Never.

A Pod's lifecycle is summarized by status phases: Pending, Running, Succeeded, Failed, and Unknown. A common failure indicator is CrashLoopBackOff, which signals that a container is repeatedly crashing; the kubelet waits an increasing backoff period (10s, 20s, 40s, up to 5 minutes) before each restart attempt. Kubernetes also emits time-stamped events for state changes, warnings, and errors, viewable through kubectl describe or kubectl get events, which are essential for diagnosing scheduling and runtime issues.

While Pods are the basic execution unit, they are usually managed by controllers that maintain a desired state. A ReplicaSet ensures a stable set of identical Pods and reconciles the running count to match a declared replica target using a label selector. In production, however, Deployments are far more commonly used because they manage a ReplicaSet and add declarative updates, rolling updates, and rollback capability. Deployment strategies control how Pods are replaced during an update: RollingUpdate incrementally replaces old Pods, while Recreate terminates all existing Pods before creating new ones, causing downtime but avoiding two versions running simultaneously, which is useful for incompatible schema migrations. The progressDeadlineSeconds field (default 600s) marks the Deployment as failed if no progress is made, while revisionHistoryLimit (default 10) controls how many old ReplicaSets are retained for kubectl rollout undo.

For stateful workloads, a StatefulSet manages the deployment and scaling of Pods that require stable, unique network identities and persistent per-pod storage. Each Pod in a StatefulSet is named with the pattern <statefulset-name>-<ordinal-index> (for example, web-0, web-1) and receives a stable DNS record through the governing Headless Service referenced by the StatefulSet's serviceName field. A DaemonSet, by contrast, ensures a copy of a Pod runs on every node or a designated subset, making it ideal for node-level agents like log shippers, monitoring daemons, and CNI plugins. For finite work, a Job runs one or more Pods to perform a batch task to completion and tracks successful completions, while a CronJob creates Job objects on a cron schedule and manages their lifecycle, including concurrency policy and history limits.

Kubernetes also provides automatic scaling primitives. A HorizontalPodAutoscaler (HPA) adjusts the replica count of a Deployment, StatefulSet, or ReplicaSet based on resource metrics (CPU, memory) from the metrics-server, custom metrics, or external metrics. The behavior field can configure scaleUp and scaleDown policies with stabilization windows to prevent flapping. A VerticalPodAutoscaler (VPA), in contrast, adjusts the CPU and memory requests and limits for containers based on historical usage, making it recommended for stateful or single-replica workloads. A PodDisruptionBudget (PDB) complements these by limiting the number of Pods that can be voluntarily disrupted at once (for example, during a node drain), specifying either minAvailable or maxUnavailable as an absolute count or percentage to maintain availability during maintenance.

A Service is an abstraction that defines a logical set of Pods and a policy to access them, typically through a stable virtual IP and DNS name. Services discover their backend Pods via a label selector, and the endpoints controller automatically updates the Service's backend list whenever matching Pods appear or disappear. In large clusters, the legacy Endpoints API has been superseded by EndpointSlices, which split backend Pods into multiple smaller objects, reducing update size and enabling scalable routing. kube-proxy on each node reads EndpointSlices (or Endpoints) and programs iptables, IPVS, or eBPF rules to implement the Service virtual IP and load-balance traffic to the right Pod IPs.

Kubernetes exposes several Service types for different access patterns. ClusterIP, the default, exposes the Service on a cluster-internal IP reachable only from within the cluster. NodePort exposes the Service on each node's IP at a static port (default range 30000-32767), making it reachable from outside the cluster as <NodeIP>:<NodePort>. LoadBalancer provisions a cloud-provider-specific external load balancer that routes traffic to backend nodes on a public IP. A Headless Service (clusterIP: None) does not allocate a virtual IP or perform load balancing; instead, DNS queries return the Pods' IPs directly, which is especially useful for StatefulSets and custom discovery. An ExternalName Service maps a Service to a CNAME DNS record, allowing Pods to reach an external service via a cluster-internal name.

Network security is controlled through NetworkPolicy resources, which specify how groups of Pods are allowed to communicate with each other and other network endpoints. NetworkPolicy enforcement requires a CNI plugin that supports it, such as Calico, Cilium, or Weave Net. A NetworkPolicy without a podSelector applies to all Pods in the namespace; if neither an ingress nor an egress rule list is provided, all matching traffic is allowed. The default cluster behavior is permissive: if no NetworkPolicy selects a Pod, all ingress and egress traffic is allowed. Cluster-internal name resolution is provided by kube-dns or coredns, and Service names resolve via the pattern <svc>.<ns>.svc.cluster.local.

A Namespace is a logical partition within a cluster used to divide resources between multiple users, teams, or environments and to enforce a scope for names and policies. When a resource is created without specifying a namespace, it is placed in the default namespace named default. Most workload and configuration resources are namespaced, including Pods, Services, Deployments, ConfigMaps, Secrets, and Jobs, while Nodes and PersistentVolumes are cluster-scoped. Namespaces can be bounded by ResourceQuota objects, which constrain aggregate resource consumption such as CPU, memory, and object counts, and by LimitRange objects, which enforce minimum, maximum, default requests, and default limits for individual containers or Pods within the namespace.

Configuration data is decoupled from Pod manifests through ConfigMaps and Secrets. A ConfigMap stores non-confidential key-value pairs that can be mounted into Pods as files or exposed as environment variables. A Secret is the equivalent for sensitive material such as passwords, tokens, or keys, base64-encoded and mountable in the same ways, with optional encryption at rest. The key distinction is that Secrets are intended for confidential data and may be encrypted at rest and exposed only on demand, while ConfigMaps hold plain, non-sensitive configuration.

Durable storage is modeled through PersistentVolumes (PVs), PersistentVolumeClaims (PVCs), and StorageClasses. A PersistentVolume is a piece of storage in the cluster provisioned by an administrator or dynamically by a StorageClass, and it represents a cluster-scoped resource. A PersistentVolumeClaim is a user's request for storage, consuming a PV that matches its requested size, access mode, and storage class. PVs support the access modes ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP, Kubernetes 1.22+), and the deprecated WriteOnce. A StorageClass describes the classes of storage offered by the cluster, defining the provisioner, parameters, and reclaim policy. The reclaimPolicy field controls what happens to a PV after its PVC is deleted: Retain, Recycle (deprecated), or Delete.

In the Pod context, a Volume is a directory accessible to the containers in a Pod, with a lifetime tied to the Pod unless backed by a PV. Common volume types include emptyDir, which is created when a Pod is scheduled and exists only as long as the Pod runs on the node's local medium; hostPath, which mounts a file or directory from the host filesystem and is suitable only for system-level or single-node development use; configMap, secret, and persistentVolumeClaim; and infrastructure-specific types such as nfs, awsElasticBlockStore, gcePersistentDisk, azureDisk, and csi.

A Kubernetes cluster is composed of a control plane and a set of worker Nodes. A Node is a worker machine (physical or virtual) where Pods run, identified by metadata.name, addresses (InternalIP, ExternalIP, Hostname), nodeInfo (kubelet version, OS, architecture), and conditions such as Ready, MemoryPressure, DiskPressure, and PIDPressure. The Node controller monitors heartbeats from kubelets; if a node stops reporting within the node-monitor-grace-period (default 40s), its status is marked NotReady and Pods are eventually rescheduled elsewhere.

The control plane consists of several cooperating components. The kube-apiserver is the front end of the cluster, exposing the REST API and being the only component that talks directly to etcd, the consistent distributed key-value store that holds all cluster state and requires a quorum for safety. The kube-controller-manager runs core control loops such as the Node controller, Job controller, EndpointSlice controller, and ServiceAccount controller, continuously reconciling actual state toward desired state. The cloud-controller-manager embeds cloud-specific logic for node lifecycle, routes, and load balancer integration, separating vendor concerns from the core control plane.

On each Node, the kubelet registers the Node with the API server, watches for Pod specs assigned to it, and ensures that the described containers are running and healthy. kube-proxy maintains iptables, IPVS, or eBPF rules to implement Service virtual IPs. The Scheduler is the control plane component that watches for newly created Pods without an assigned node and selects one based on resources, affinity rules, taints, and other policies. Scheduling decisions can be influenced by taints, which are key-value-effect triplets applied to nodes that repel Pods lacking a matching toleration; the standard effects are NoSchedule, PreferNoSchedule, and NoExecute. Pods may declare tolerations to allow (but not require) scheduling onto tainted nodes. Node affinity attracts Pods to a set of nodes based on labels, expressed as either requiredDuringSchedulingIgnoredDuringExecution or preferredDuringSchedulingIgnoredDuringExecution, while pod anti-affinity prevents Pods from being scheduled on the same node, zone, or topology domain as other matching Pods to spread load or improve availability.

Resource consumption in a Pod is governed by the distinction between requests and limits. Requests are the amount of a resource guaranteed to a container for scheduling purposes, while limits are the maximum amount the container is allowed to use and are enforced at runtime. When a container exceeds its memory limit, it is terminated with an OOMKilled exit status; for CPU, the container is throttled rather than killed. Together, requests and limits determine a Pod's Quality of Service (QoS) class, which in turn dictates its eviction priority under node pressure.

QoS classes are assigned as follows. Guaranteed applies when every container in the Pod has limits equal to requests for both CPU and memory. BestEffort applies when no container sets any requests or limits. Burstable covers every other configuration. Under node pressure, Pods are evicted in a predictable order: BestEffort first, then Burstable Pods that exceed their requests, then Burstable Pods within their requests, with Guaranteed Pods evicted last.

Kubernetes also uses probes to observe container health. A liveness probe determines when to restart a container: if the probe fails, the kubelet kills and restarts the container. A readiness probe determines whether a container is ready to receive traffic; Pods whose containers fail readiness are removed from Service endpoints until they recover. A startup probe indicates when an application has started and disables liveness and readiness checks until it succeeds, which is useful for slow-starting containers. Probes can be configured with handlers of type HTTPGetAction, TCPSocketAction, ExecAction, or grpc (added in 1.24), and their behavior is controlled by fields including initialDelaySeconds, periodSeconds, timeoutSeconds, successThreshold, failureThreshold, and terminationGracePeriodSeconds.

A ServiceAccount provides an identity for processes running in a Pod, used to authenticate to the API server and to be authorized by RBAC. Every namespace has a default ServiceAccount, and Pods that do not specify one are automatically assigned it. Role-Based Access Control (RBAC) is the standard authorization mode, using Roles and ClusterRoles to define permission sets, and RoleBindings and ClusterRoleBindings to grant those permissions to subjects (users, groups, or ServiceAccounts). A Role grants access within a single namespace, while a ClusterRole grants cluster-wide access or access to non-namespaced resources and can be reused across namespaces via a RoleBinding.

Pod-level security is configured through the PodSecurityContext, which sets security-relevant fields such as runAsUser, runAsGroup, fsGroup, seccompProfile, runAsNonRoot, and supplemental groups. Historically, PodSecurityPolicy (PSP) enforced similar controls, but PSP was deprecated in Kubernetes 1.21 and removed in 1.25. It has been replaced by Pod Security Admission (PSA), a built-in admission controller that enforces Pod Security Standards at three levels: privileged, baseline, and restricted, configured per namespace via labels.

Admission control can also be extended. A ValidatingAdmissionPolicy uses CEL-based rules to validate incoming API requests declaratively (beta in 1.30), and a MutatingAdmissionWebhook intercepts requests before persistence to mutate objects, used by service meshes, sidecar injectors (such as Istio), and secret backends. The API server's default authentication chain processes X509 client certificates, bearer tokens (including ServiceAccount tokens), OpenID Connect tokens, bootstrap tokens, and anonymous auth (when enabled). A bootstrap token is a short-lived token (24 hours or longer) used to authenticate new nodes joining the cluster, typically during kubeadm join.

The official command-line client for Kubernetes is kubectl, which interacts with the API server to perform CRUD operations on resources and stream logs or exec sessions. Common commands include kubectl get, kubectl describe, kubectl create, kubectl apply, kubectl delete, kubectl edit, and kubectl patch. For example, kubectl apply -f file.yaml applies the configuration in the YAML file to the cluster, creating or updating the described resources to match the desired state. The flag kubectl get pods -A lists all Pods across all namespaces, and kubectl logs <pod> [-c <container>] retrieves container logs, with --previous showing prior runs and -f enabling live tailing. kubectl exec runs a new command in a container, while kubectl attach connects to the main process's STDIN/STDOUT. kubectl port-forward forwards a local port to a port in a Pod for debugging without exposing the Pod cluster-wide. Forceful deletion with --grace-period=0 --force removes a Pod from the API server immediately without sending SIGTERM, which can cause data loss or in-flight errors.

Kubernetes is extensible through Custom Resource Definitions (CRDs), which extend the API by defining new resource types with their own OpenAPI v3-validated schemas, and Operators, which package, deploy, and manage Kubernetes applications by combining CRDs with custom controllers that encode operational knowledge. Labels and annotations both attach key-value metadata to objects: Labels are identifying and used by selectors and Service meshes for grouping, while annotations are non-identifying and typically consumed by tools, libraries, or operators for configuration. For application packaging, Helm charts bundle pre-configured Kubernetes resources templated with Go templates and parameterized via a values.yaml file, and each installed chart becomes a Helm release with its own name, namespace, version history, and support for upgrades, rollbacks, and uninstalls.

Cluster bootstrapping is handled by kubeadm, the official tool that creates a minimum viable, conformant cluster, including certificate issuance, control plane initialization, and node join. The Kubernetes release cadence is approximately three minor releases per year, with each minor release supported for about 14 months (9 months active and 5 months of security-only support). Cluster state is held in etcd, which requires a quorum and serves as the source of truth for all Kubernetes objects, while the self-healing nature of the control loops continuously observes actual state versus desired state, replacing failed Pods, rescheduling workloads after node loss, and removing unready Pods from Service backends.