No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Yes. It uses an AutoScalingGroup to manage the Node pool, and configures that ASG to do rolling updates that replace a single instance at a time and fail the update if the new instances don’t boot cleanly. 

How do we achieve draining policy similar to `KOPS`?

I assume it doesn’t drain the nodes, should be fine for stateless apps but anything persisting data might cause an issue

So if the master is upgraded by aws to a newer version and if I change the AMI on the pulumi code and do an `apply` it will do a rolling upgrade using ASG?

Also will it taint nodes with something like this `kubectl taint nodes node_name key=value:NoSchedule`

<@UB3BGTV63> Will it also drain? `<https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/>`

<@UEEUJNR9B> The masters are entirely manged by AWS. You never need to worry about upgrades. That happens automatically.

For the nodes, you will need to do a pulumi update.

<@UEEUJNR9B> Taking a look at it, it doesn’t looks like it uses the `drain` api call

I feel like it should trigger a drain if the node gets told to shutdown, but I might be wrong

Sorry for the delay getting back on this.  You are right that `drain` is not currently triggered during ASG turnover.  This is not supported directly in EKS, but it is something that could be done on top - I'll open an issue to see if we can do something automatic in the `@pulumi/eks` package to support this.

<@UB3BGTV63> for ECS we use a lamda function with lifecycle hooks that triggers the drain before kicking the node.

Not sure how overkill that would be

<@UB3BGTV63> Is there a github issue for this?

<@UD2HJDBCL> Yes - that's what would be needed here - either built-in to `@pulumi/eks` or built on top.  Something along the lines of <https://aws.amazon.com/blogs/compute/how-to-automate-container-instance-draining-in-amazon-ecs/>, but for EKS.

<@UEEUJNR9B> Opened <https://github.com/pulumi/pulumi-eks/issues/40> about this. Note that it should techincally be possible to build something like this yourself on top of existing `@pulumi/eks`, though we may need to expose the ASG as a property on the `Cluster` (easy PR if you want to go this direction).