EKS Node Groups update proposal

[Raffo]

eksctl should support updates of the node groups. Even if eks does not support updating clusters at the time of writing (kubernetes 1.10 is the only version supported), we should still have in place a way to update the nodes of the cluster as we might want to rollout fixes to the nodes (i.e. a new AMI with critical bugfixes at the OS level) even without updating Kubernetes itself.

To support that we can have different update strategy:

• create a new LaunchConfiguration for the existing AutoscalingGroup of the Node Group
• create a new AutoscalinGroup to attach to the cluster with the new configuration and let the users do the switch, i.e. by draining the old nodes gradually to have smooth upgrades.

We could think of having this feature implemented in a way that those alternative strategies can be gradually implemented.

Additionally, I propose having those functionalities implemented as CLI-only version at the beginning, such that we can execute individual steps manually as there are definitely multiple steps required and achieving fully automation of this would be mostly a matter of gluing those individual steps together.

Some inspirations for similar functionalities can be found in this kops PR, in progress or in Zalando's cluster update strategies. eksctl doesn't need to derive from any of those, but it can definitely learn some lessons :-)

Also, in my opinion, this feature is blocked by #46 as it would be a major new feature that would be better to build with a proper testing in place.

[errordeveloper]

I think #132 should make this much easier to implement, and it does make things more testable too. Also we have made some progress on #46 in general.

[errordeveloper]

Besides CLI, I think after we add Cluster API support (see #19 & #20), we should consider a nodegroup controller that could manage upgrades within the cluster it runs in.

[Raffo]

I think the first discussion around the cluster-api implementation happens tonight, not sure if I can join, but it would be lovely to get some idea to see what can be implemented here.

[errordeveloper]

Just wanted to make it clear for anyone looking at this issue – it should be possible to start on this already, nothing is blocking it (as far as I'm aware). One might wish to start by adding eksctl get nodegroup subcommand, which is an easy one.

[errordeveloper]

Related: #443.

[errordeveloper]

@Raffo I think we can close this now, nodegroup will handle draining once #593 lands, one would be able to eksctl create ng --cluster=<clusterName> && eksctl delete ng --cluster=<clusterName> --name=<oldNodeGroupname>. We have #443 as a follow-up for automating this.

[Raffo]

Sounds good to me, maybe we close this after #443 is merged?

[errordeveloper]

@Raffo sgtm :)

[martina-if]

Given that eksctl now has support for managed nodegroups I think we can close this.