02 / Choose the owner of the Pods

Scroll the diagram sideways for readable labels.

Learning objective and mental model verified

Choose between Deployment for interchangeable replicas, StatefulSet for stable Pod identities and storage association, DaemonSet for node-local facilities, and Job or CronJob for tasks that complete. A StatefulSet does not implement database replication or application consistency for you.

Configuration mechanism verified

A ConfigMap stores non-confidential settings and can supply environment variables or mounted files. A Secret represents sensitive values. Base64 encoding does not make a secret confidential; control API access, storage protection and exposure through logs or manifests.

Worked example synthesis

Use a Deployment for HTTP quote servers, a Job for an export and a DaemonSet for a node log agent on compatible EC2 compute. If running a database inside Kubernetes, choose an operator and storage recovery plan deliberately; stable identities alone do not satisfy the data contract.

Decision and common pitfall synthesis

Use labels and selectors consistently so the right controller and Service identify the intended Pods. Updating a Deployment template creates a new ReplicaSet revision; editing a generated Pod is a short-lived change that its owner may replace. Treat runtime configuration changes as releases and verify the application reload behavior.

Further improvement synthesis

Build a small inventory mapping every workload to its owner, dependencies, configuration source and restart behavior. This makes lifecycle ownership reviewable before a rollout or recovery exercise.