The Manager's Manager
You almost never create Pods directly in production. If you do, and the Pod dies, it stays dead — nothing recreates it. Instead, you create a Deployment.
A Deployment is a higher-level controller that manages a ReplicaSet, which in turn manages Pods. The hierarchy is:
Deployment
└── ReplicaSet (e.g., "my-app-rs-7d9f4b")
├── Pod (my-app-7d9f4b-xk2p9)
├── Pod (my-app-7d9f4b-mn7r1)
└── Pod (my-app-7d9f4b-q8w3t)
You tell the Deployment: "I want 3 replicas of the nginx:1.25 image." The Deployment creates a ReplicaSet to fulfill that request. The ReplicaSet continuously watches the cluster and ensures exactly 3 Pods matching its template are always running. If a node crashes and a Pod dies, the ReplicaSet notices the count dropped to 2 and immediately schedules a replacement. This is self-healing.
A Deployment spec names a desired replica count, a selector matching its own Pods, and a Pod template — the same shape as a bare Pod spec, embedded inside the Deployment. When you update the image field in that template (e.g., to a new tag), the Deployment creates a new ReplicaSet for the new version and gradually scales it up while scaling down the old one. The old ReplicaSet is kept around (with 0 replicas) to enable rollbacks — reverting to the previous version, or inspecting rollout history, are both single commands against the Deployment precisely because that old ReplicaSet is still sitting there, scaled to zero rather than deleted.
Deployments are the standard way to manage stateless applications — web servers, API backends, and microservices where any replica is interchangeable with any other.