<p>From the Kubernetes' <a href="https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/validation/validation.go" rel="nofollow noreferrer">validation source code</a>, at least those resources are immutable after creation:</p>
<ul>
<li><em>Persistent Volumes</em></li>
<li><em>Storage Classes</em></li>
</ul>
<p>Why is that ?</p>

<p>This is a core concept on Kubernetes. A few specs are immutable because their change has impact in the basic structure of the resource it's connected. </p>

<p>For example, changing the Persistent Volumes may impact pods that are using this PV. Let's suppose you have a mysql pod running on a PV and you change it in a way that all the data is gone. </p>

<p>On Kubernetes 1.18 Secrets and ConfigMaps also became immutable as an Alpha feature, meaning that this will be the new default soon. Check the GitHub Issue <a href="https://github.com/kubernetes/enhancements/issues/1412" rel="nofollow noreferrer">here</a>. </p>

<p><a href="https://blog.alcide.io/kubernetes-1.18-introduces-immutable-configmaps-and-secretes" rel="nofollow noreferrer">What is it good for?</a></p>

<blockquote>
  <p>The most popular and the most convenient way of consuming Secrets and
  ConfigMaps by Pods is consuming it as a file. However, any update to a
  Secret or ConfigMap object is quickly (roughly within a minute)
  reflected in updates of the file mounted for all Pods consuming them.
  That means that a bad update (push) of Secret and/or ConfigMap can
  very quickly break the entire application.</p>
</blockquote>

<p><a href="https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1412-immutable-secrets-and-configmaps/README.md#motivation" rel="nofollow noreferrer">Here</a> you can read more about the motivation behind this decision.</p>

<blockquote>
  <p>In this KEP, we are proposing to introduce an ability to specify that
  contents of a particular Secret/ConfigMap should be immutable for its
  whole lifetime. For those Secrets/ConfigMap, Kubelets will not be
  trying to watch/poll for changes to updated mounts for their Pods.
  Given there are a lot of users not really taking advantage of
  automatic updates of Secrets/ConfigMaps due to consequences described
  above, this will allow them to:</p>
  
  <ul>
  <li>protect themselves better for accidental bad updates that could cause outages of their applications</li>
  <li>achieve better performance of their cluster thanks to significant reduction of load on apiserver</li>
  </ul>
</blockquote>
