This message was deleted.

Hello. I don’t think this is related to Pulumi, since the replicaset management in a deployment is part of k8s. Here’s more info of what k8s does when you update a Deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment

thanks @plain-businessperson-30883 and @better-rainbow-14549 for pointing this out, I’m still new to k8s. Since the cluster is managed by pulumi, I’m not sure if we need this mechanism. In this case the rollback should be by reverting our code and/or our stack config to deploy (

pulumi up

) the previous version of the deployment right ?

To be honest, I’m not sure if one thing replace the other. k8s deployments will create a new RS anyways to switch to the new one. Maybe just lowering the “rs to keep” as @better-rainbow-14549 pointed out would be enough for you.

Yes, but I mean, I don’t know how/if pulumi can use the previous RS to do a rollback, and if not, mixing manual operations like rolling back a deployment and automated management with pulumi could lead to inconsistencies. So I feel like we have to choose one over the other in this case (and yes, if so we can/have to lower the RS to keep after a deployment)

pulumi wouldnt use previous ones but up until the point where the every deployment in the replica set is running without error, kube will

@better-rainbow-14549 @plain-businessperson-30883 I realize I didn’t thank you both for the insights here. Was really helpful to better understand it. So thanks guys 🙂

No problem. I’m glad to help 🙂