<p>I have a pod in my kubernetes which needed an update to have securityContext. So generated a yaml file using -</p>
<pre><code>kubectl get pod pod_name -o yaml &gt; mypod.yaml
</code></pre>
<p>After updating the required securityContext and executing command -</p>
<pre><code>kubectl apply -f mypod.yaml
</code></pre>
<p>no changes are observed in pod.</p>
<p>Where as a fresh newly created yaml file works perfectly fine.
new yaml file -</p>
<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: default
spec:
  securityContext:
    runAsUser: 1010
  containers:
  - command:
    - sleep
    - &quot;4800&quot;
    image: ubuntu
    name: myubuntuimage
</code></pre>

Khilesh Chauhan
<h3>Immutable fields</h3>
<p>In Kubernetes you can find information about <a href="https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190603-immutable-fields.md" rel="nofollow noreferrer">Immutable fields</a>.</p>
<blockquote>
<p>A lot of fields in APIs tend to be <code>immutable</code>, they can't be changed after creation. This is true for example for many of the fields in pods. There is currently no way to declaratively specify that fields are immutable, and one has to rely on either built-in validation for core types, or have to build a validating webhooks for CRDs.</p>
</blockquote>
<p>Why ?</p>
<blockquote>
<p>There are resources in Kubernetes which have <code>immutable fields</code> by design, i.e. after creation of an object, those fields cannot be mutated anymore. E.g. a pod's specification is mostly unchangeable once it is created. To change the pod, it must be deleted, recreated and rescheduled.</p>
</blockquote>
<h3>Editing existing pod configuration</h3>
<p>If you want to apply new config with <code>security context</code> using <code>kubectl apply</code> you will get error like below:</p>
<pre><code>The Pod &quot;mypod&quot; is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or `spec.tolerations` (only additions to existing tolerations)
</code></pre>
<p>Same output will be if you would use <code>kubectl patch</code>
<code>kubectl patch pod mypod -p '{&quot;spec&quot;:{&quot;securityContext&quot;:{&quot;runAsUser&quot;:1010}}}'</code></p>
<p>Also <code>kubectl edit</code> will not change this specific configuration</p>
<pre><code>$ kubectl edit pod
Edit cancelled, no changes made.
</code></pre>
<h3>Solution</h3>
<p>If you need only one <code>pod</code>, you must delete it and create new one with requested configuration.</p>
<p>Better solution is to use resource which will make sure to fulfil some own requirements, like <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployment</a>. After change of the current configuration, <code>deployment</code> will create new <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" rel="nofollow noreferrer">Replicaset</a> which will create new pods with new configuration.</p>
<blockquote>
<p>by updating the <code>PodTemplateSpec</code> of the <code>Deployment</code>. A new <code>ReplicaSet</code> is created and the <code>Deployment</code> manages moving the Pods from the old <code>ReplicaSet</code> to the new one at a controlled rate. Each new <code>ReplicaSet</code> updates the revision of the Deployment.</p>
</blockquote>
