https://pulumi.com logo
Title
q

quiet-leather-94755

01/27/2023, 3:57 PM
Hello! 👋 I've noticed that some changes (eg. ConfigMaps) cause Kubernetes deployments to be replaced, which means immediately terminating all the existing pods before the new deployment is verified to be up and running in a healthy state. Is there any way around this? What I guess I'd like, is for a new ConfigMap + a new Deployment to be created, then wait until it's healthy, and then destroy the existing Deployment + ConfigMap 😅
m

many-telephone-49025

01/27/2023, 6:30 PM
Hi Johan, Rolling Update should be the default in k8s. To see if the pod is really healty and ready you should have the healthiness and readiness probes in place.
q

quiet-leather-94755

01/28/2023, 4:54 PM
Yeah, for regular updates to the deployment there's no issue - I can update the image version just fine, for example. Liveness & readiness probes are also configured, and I have a pod disruption budget configured. However, when I modify the ConfigMap that my deployment uses, it apparently has to be destroyed first, before the new version can be created, and this propagates to the deployment itself.
From the research I did, it seems to be a longstanding issue due to how Pulumi and Kubernetes interact.
In general I'm fine with replacing instead of updating the deployment, but I would like to create the new deployment first, and only destroy the old one after the new one is up and running in a healthy state.
e

early-cat-34152

01/28/2023, 5:08 PM
I've read a GitHub issue about this, but can't find it. Do you know the issue URL?
s

steep-toddler-94095

01/29/2023, 7:46 AM
when I modify the ConfigMap that my deployment uses, it apparently has to be destroyed first
do you have "deleteBeforeReplace: true" set on the ConfigMap? The default behavior of Pulumi should not be to delete the ConfigMap before creating the new one. Pulumi should create the new ConfigMap, trigger a rolling update on the Deployment, and if successful, lastly delete the old ConfigMap.
q

quiet-leather-94755

01/30/2023, 6:48 AM
No, I haven't touched that one.. but apparently Pulumi uses that strategy by default in this case 😅
Ah.. 😂 I had originally copied parts of the Pulumi code from elsewhere, and it was setting a hardcoded name for the ConfigMap resource in Kubernetes, thus forcing a delete-before-replace:
config = k8s.core.v1.ConfigMap(
    f"{app_name}-config",
    metadata=k8s.meta.v1.ObjectMetaArgs(
        name=f"{app_name}-config",
    ),
    data={...},
)
Once I removed that, to let it pick an autogenerated suffix for the name, things work as I expected, just doing an update of the deployment instead 🎉
m

many-telephone-49025

01/30/2023, 8:29 AM
Just for the records: The update of the content of the CM has to be handled from the app itself. Thats, why having the name with a hash (like kustomize is doing too on secrets and cm) is handy if you want the redeploy of the pod to pickup the changes due to no app intern mechanism.