A pod template is the pod definition embedded in a workload resource. It describes the pods to create, including their metadata and container configuration. Instead of creating each pod separately, you provide a template and let a controller create pods when they are needed. section 14.1.1 section 14.3.1
A ReplicaSet template
In a ReplicaSet manifest, `spec.template.metadata.labels` supplies the new pods’ labels, while `spec.template.spec` supplies their containers and other pod settings. The separate `spec.replicas` field sets how many pods are wanted. The selector’s labels must match labels in the template; otherwise, the API rejects the ReplicaSet. You do not give each pod a name in the template: Kubernetes generates names from the ReplicaSet name. section 14.1.1
Listing 14.1 The Kiada ReplicaSet object manifest
apiVersion: apps/v1 #1
kind: ReplicaSet #1
metadata: #1
name: kiada #2
spec:
replicas: 5 #3
selector: #4
matchLabels: #4
app: kiada #4
rel: stable #4
template: #5
metadata: #5
labels: #5
app: kiada #5
rel: stable #5
spec: #5
containers: #5
- name: kiada #5
image: luksa/kiada:0.5 #5
... #5
volumes: #5
- ... #5
See the ReplicaSet’s replica count, selector, and embedded pod template together in a manifest. section 14.1.1
A template is not a command to rewrite every running pod. A ReplicaSet controller counts pods matching its label selector. If there are too few, it creates more from the template; if there are too many, it removes the excess. Pods already matching the selector can count toward the total even if they were created earlier. section 14.3.1 section 14.1.2
Changing a label
Suppose a ReplicaSet’s template labels are `app: kiada` and `rel: stable`. Add `ver: '0.5'` under `spec.template.metadata.labels`, leaving the selector unchanged. Existing pods keep their old labels; after you scale up, the newly created pod gets the version label. Quote the value so YAML treats it as a string. section 14.2.2
Other controllers also use pod templates, but respond to changes differently:
- A Deployment replaces pods when its template changes; its update strategy controls whether replacement is simultaneous or gradual. section 15.2
- A StatefulSet recreates pods from an updated template. It can also give each replica its own persistent storage and stable identity. section 16.3 section 16.1.2
- A DaemonSet uses its template to run pods across nodes rather than to meet a specified replica count; an updated template can trigger replacement according to its update strategy. section 17.1.1 section 17.1.4
- A Job can put a `subdomain` in its template so its pods can find one another through a headless Service. section 18.1.6
When checking what a ReplicaSet will create next, use `kubectl get rs -o wide` to see template container names and images, or `kubectl describe rs` to see the full template. Inspect the pods separately to see what is actually running now. section 14.1.2 section 14.2.2
