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.