A PodSpec is the Kubernetes specification for a Pod’s containers and settings. It identifies each container and its image, and can also define health checks, resource requirements, environment variables, and restart behavior. section 3.2.4 section 10.2.1
Kubernetes embeds PodSpecs inside higher-order objects such as Deployments, StatefulSets, and Jobs. A Deployment controller uses the embedded specification to create and manage Pods; a Job uses it to run a task in its own Pod. section 3.2.4 section 10.2.1
Choose how to use a PodSpec based on the required lifecycle:
- Embed it in a Deployment or another controller when Pods need replacement or rescheduling after eviction or node failure. section 3.2.4
- Create it as a standalone Pod for direct execution, accepting that crashes trigger reboot but eviction does not trigger rescheduling. section 3.2.4
- Embed it in a Job for one-off work, using restartPolicy and the Job’s backoffLimit to control retries. section 10.2.1
A minimal standalone PodSpec
A Pod manifest can place the PodSpec directly under spec: apiVersion: v1, kind: Pod, metadata for the name and labels, then spec.containers with a container name and image such as docker.io/wdeniss/timeserver:1. Apply it with kubectl, but use a controller when eviction recovery matters. section 3.2.4
