pulumi-kubernetes: Deployment diff causing replace instead of update

A deployment was changed with an environment variable inserted into the list, changing the order of env vars like so:

# many lines removed
~ spec      : {
    ~ template: {
        ~ spec    : {
            ~ containers                   : [
                ~ [0]: {
                        ~ env            : [
                        # many lines removed
                        ~ [14]: {
                                ~ name     : "ENV_VAR_A" => "SOME_NEW_ENV_VAR"
                                - value    : "env-var-a-value"
                                + valueFrom: {
                                    + secretKeyRef: {
                                        + key : "a-key"
                                        + name: "on-a-secret-resource"
                                    }
                                }
                            }
                        + [15]: {
                                + name : "ENV_VAR_A"
                                + value: "env-var-a-value"
                            }

This appeared to result in a replace instead of an update operation, as other Deployments in the same project were updated, but their containers[].env spec was not changed.

Errors & Logs

This resulted in spurious creation failures which had to be resolved by reverting the change and then re-running the deployment job several times:

  ++ kubernetes:apps:Deployment client-default-backend creating replacement [diff: ~spec]; error: resource vendor-sync/client-default-backend was not successfully created by the Kubernetes API server : deployments.apps "client-default-backend" already exists

The default create-and-delete policy for k8s resources has a race condition.

Affected product version(s)

Pulumi 1.14.1 Kubernetes provider 1.6.0

Suggestions for a fix

I wasn’t able to discern why a change to the env would key would result in a replace operation. Is it because of the valueFrom: { secretKeyRef: ... }? If so, that shouldn’t be cause for a replace, as the Deployment will take care of creating a new replicaset with the new env spec.

The only distinction between Deployments which were “updated” and “replaced” was that the latter had changes to their containers[].env, so I assume something there is causing a “replace”.