Suppose you need an application to keep running through updates and node failures. A Pod describes its containers, but a Pod created directly is not managed by a controller that will reschedule it after eviction. A Deployment embeds a Pod template and manages the Pods it creates. This embedding of one object’s specification inside a higher-order object is Kubernetes object composition. section 3.2.4
The same pattern serves different jobs:
- A Deployment embeds a Pod template. Its controller creates the requested replicas, replaces Pods during updates, and reschedules evicted Pods. section 3.2.4
- A Job embeds a Pod template for a task that should finish. The embedded PodSpec can use container settings such as environment variables; the Job also sets a backoffLimit for attempts. section 10.2.1
- A CronJob embeds a Job template, which embeds a Pod template. Its schedule field determines when to create Jobs. section 10.2.2
Read nested YAML from the outside in: identify the higher-order resource, find its template, then find the embedded object’s spec. A PodSpec keeps its Pod capabilities when embedded, although the surrounding resource may rule out combinations that do not fit its purpose. For example, a Job can use a Pod restartPolicy of Never or OnFailure, but not Always. section 3.2.4 section 10.2.1
Listing 10.10 Chapter10/10.2.2_CronJob/cronjob_addwork.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: addwork
spec:
schedule: "*/5 * * * *" #1
jobTemplate:
spec: #2
backoffLimit: 2
template:
spec:
containers:
- name: pi-container
image: docker.io/wdenniss/pi_worker:2
command: ["python3", "add_tasks.py"]
env:
- name: REDIS_HOST
value: redis-0.redis-service
- name: PYTHONUNBUFFERED
value: "1"
restartPolicy: Never
The CronJob manifest makes the nesting concrete: schedule sits on the CronJob, backoffLimit sits in jobTemplate.spec, and containers sit in the Job’s embedded Pod spec. section 10.2.2
