Loading...
Quick Definition
A pod is the smallest deployable unit in Kubernetes, wrapping one or more containers that share storage, network, and a lifecycle. Pods are scheduled onto nodes, and their resource requests and limits drive both scheduling decisions and cost allocation.
A pod is the smallest unit Kubernetes deploys and manages: one or more containers that share networking and storage and are scheduled together onto a node. Applications run as sets of identical pods, with more added or removed as demand changes.
For cost purposes, the pod's most important property is its resource request: the CPU and memory it claims from the cluster. The scheduler reserves that amount on a node whether the pod uses it or not, so requests, not actual usage, determine how many nodes a cluster needs. Inflated requests are invisible overprovisioning, multiplied by every replica.
Example. A service's pods request 2 CPU cores each but use 200 millicores at peak. Cutting the request to 500 millicores lets the same nodes hold four times as many of these pods, and the cluster autoscaler quietly removes the machines no longer needed.
Set requests from measured usage, give honest limits, and revisit after launch when real traffic data exists. The node vs pod vs cluster explainer covers the model, and the Kubernetes Cost Management Guide covers request tuning in depth.
The request is reserved capacity used for scheduling; the limit is the ceiling the container may use. Cost is driven by requests.
Crashes, failed health checks, exceeding memory limits, node maintenance, or deployments. Kubernetes replaces them automatically by design.
Usually one. Additional helper containers belong only when they must share the same network and lifecycle.