Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
plugin-framework
pulumi-ai
pulumi-cdk
pulumi-cloud
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Title
q
quiet-leather-94755
01/27/2023, 3:57 PMHello! 👋
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 PMHi 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 PMYeah, 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 PMI'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 AMwhen I modify the ConfigMap that my deployment uses, it apparently has to be destroyed firstdo 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 AMNo, 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={...},
)m
many-telephone-49025
01/30/2023, 8:29 AMJust 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.