@@ -191,6 +191,35 @@ details are abstracted away. That abstraction and separation of concerns simplif
191
191
system semantics, and makes it feasible to extend the cluster's behavior without
192
192
changing existing code.
193
193
194
+ ## Pod update and replacement
195
+
196
+ As mentioned in the previous section, when the Pod template for a workload
197
+ resource is changed, the controller creates new Pods based on the updated
198
+ template instead of updating or patching the existing Pods.
199
+
200
+ Kubernetes doesn't prevent you from managing Pods directly. It is possible to
201
+ update some fields of a running Pod, in place. However, Pod update operations
202
+ like
203
+ [ ` patch ` ] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), and
204
+ [ ` replace ` ] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
205
+ have some limitations:
206
+
207
+ - Most of the metadata about a Pod is immutable. For example, you cannot
208
+ change the ` namespace ` , ` name ` , ` uid ` , or ` creationTimestamp ` fields;
209
+ the ` generation ` field is unique. It only accepts updates that increment the
210
+ field's current value.
211
+ - If the ` metadata.deletionTimestamp ` is set, no new entry can be added to the
212
+ ` metadata.finalizers ` list.
213
+ - Pod updates may not change fields other than ` spec.containers[*].image ` ,
214
+ ` spec.initContainers[*].image ` , ` spec.activeDeadlineSeconds ` or
215
+ ` spec.tolerations ` . For ` spec.tolerations ` , you can only add new entries.
216
+ - When updating the ` spec.activeDeadlineSeconds ` field, two types of updates
217
+ are allowed:
218
+
219
+ 1 . setting the unassigned field to a positive number;
220
+ 1 . updating the field from a positive number to a smaller, non-negative
221
+ number.
222
+
194
223
## Resource sharing and communication
195
224
196
225
Pods enable data sharing and communication among their constituent
0 commit comments