This message was deleted.

Unfortunately, not really. Pulumi drives towards a desired state, and shutting down instances is an imperative action. However, it sounds like you maybe want to do a rolling upgrade on your Kubernetes nodes? there are solutions to that problem we can implement

yeah, a rolling update would be great! i had the idea of a pulumi option I could pass to the resources to say "these are related so wait for some to come back before the others are taken down". in this case I was changing the number of cpus and memory available to the worker nodes, so it's not necessarily a kubernetes thing but it could be any cluster of machines.

which cloud provider are you using? how are you building the cluster?

i'm using the vsphere provider in Go. I'm building the masters in a loop and then building the workers in a loop. all in the same pulumi stack

ahh vmware. I believe (although I’m not an expert) you could use the cluster autoscaler and a pod disruption budget to achieve that

yeah, sorry. i had to step away. i have two loops in my custom "cluster create" method that each call

vsphere.NewVirtualMachine

to create either the master nodes (first loop) or the agent nodes (second loop). I'm not actually using any vmware kubernetes providers or implementation for this.