Changing a ConfigMap's data causes a replacement

Changing a ConfigMap’s data causes a replacement of that resource, causing other resources that depend on it to be replaced as well (e.g. Deployment using envFrom), causing downtime.

Expected behavior

The ConfigMap should be updated in place.

Steps to reproduce

Running pulumi up twice with the following code:

const testConfigMap = new k8s.core.v1.ConfigMap(
  'test',
  {
    data: {foo: `${Date.now()}`},
  }
);

will result in a replacement of that configMap

 +-  └─ kubernetes:core/v1:ConfigMap  test                                       replace     [diff: ~data]

[iridian-ks]

I know this is a closed issue so happy to start a new ticket. Unrelated to deployments, in EKS there is an aws-auth ConfigMap. I noticed when trying to add new users and roles Pulumi will replace the ConfigMap. This causes all of the NodeGroups to permanently enter a failing state and never recover (it does seems random and it doesn’t happen all of the time [but most of the time]).

I understand for Deployments that a replace is beneficial, but it would be nice if the user could control the behavior if they need to instead of making assumptions on what is using the ConfigMap.

[lblackstone]

Ah, ok. The reason you’re seeing the replacement is because you are manually specifying the ConfigMap name rather than using auto-naming:

metadata: {
  name: "configmap",
},

If you remove that and let Pulumi auto-name the ConfigMap, the Deployment will update rather than replace.

---

Our k8s provider intentionally treats ConfigMap and Secret resources as immutable rather than using the PATCH API for a couple reasons:

1. Pods referencing the ConfigMap/Secret have to be restarted for changes to take effect. This is a common source of subtle errors where a subset of Pods are referencing the updated ConfigMap/Secret values, while others are still using stale data.
2. With autonamed ConfigMap/Secret resources, Pulumi will create a new instance, update dependents to refer to the new instance, and only remove the old instance once that update is successful. This makes it easier to rollback errors because the original data is still present.

I’d be interested to hear more about the use case if you are intentionally trying to reuse the same ConfigMap.