Eksctl: Add --subnets parameter to "create nodegroup " command

[stevensu1977]

Before creating a feature request, please search existing feature requests to see if you find a similar one. If there is a similar feature request please up-vote it and/or add your comments to it instead

Why do you want this feature?
Customer want set specifically subnet for they work node

What feature/behavior/change do you want?
eksctl create nodegroup add specific setup parameter etc . --subnets

Do not hesitate, when appropriate, to share the exact commands or API you would like, and/or to share a diagram (e.g.: asciiflow.com): "a picture is worth a thousand words".

[agbanagba]

This is very interesting because you can lock down the nodegroup autoscaling to a subnet or a list of subnets in the VPC.

@martina-if I can raise a WIP pull request for this.

[cPu1]

This does sound like a useful feature. We recently had someone ask for a similar feature on Slack (for a pre-existing VPC).

However, I think this feature makes more sense when a pre-existing VPC is specified and the subnets have been configured for a specific purpose.

OTOH, when you let eksctl create a dedicated VPC, subnets with the same topology (public/private) are created with the same configuration, so explicitly setting the subnets for a nodegroup here is not very useful unless the subnet configuration was changed manually. Changing the configuration for eksctl-created subnets (or any other VPC resources) is not recommended and if you find yourself doing this, you may be better off pre-creating the VPC and subnets for more control. I'd be happy to know if there are any use cases where setting the subnets may be desirable for eksctl-created VPCs.

[stevensu1977]

@cPu1 thanks your comments , when EKS cluster completed , some user want add more subnet for new deployment/project , they can use managed nodegroup, add subnet to exits EKS vpc , and tag it , EKS console create new managed nodegroup use new subnet. I think if we support it at unmanaged nodegroup level it's very useful .

[efim-a-efim]

I think it may be a highly desired feature for many people. Use cases:

• Using cluster with nodes across multiple VPCs. You'll definitely need to specify subnets list and/or VPC ID for a nodegroup in this case.
• Different network security policies for different subnets (enforced by NACLs, VPC endpoints, etc.). In this case user needs a better control over what's launched in particular subnet group.

From my sight, this feature can augment or even replace AZ specification for nodegroup.

[kjdelisle]

In my case, I want to create a node group that uses specific subnets because those subnets have access to a VPN connection that the other subnets within the VPC do not.

Using the AWS EKS console directly, I can create node groups that meet my criteria and allow me to specify exactly those subnets. Combining this with nodeSelectors means I can ensure that pods can be deployed into that space and make use of the VPN connection.

There is no equivalent way to do this using the eksctl tool, which is unfortunate because I'm trying to keep as much of my EKS cluster configuration in code/config as possible for reuse and disaster recovery.

[martina-if]

Hi @kjdelisle I think you could achieve that by selecting the AZ for the nodegroup as in this example. That would select the corresponding subnet. (Don't forget to also select the AZs in the top level (last line of that file)

[kjdelisle]

@martina-if Pretty nice workaround!

Unfortunately, the subnets I'm working with already exist and they have overlapping AZs, so I can't take advantage of your suggestion, but hopefully it helps someone else. :)

[martina-if]

Hi @kjdelisle , I see, and probably this is another reason to work on #806.

This is a bit hacky but since eksctl only understands one topology based on private/public and then divided by AZs perhaps you can leverage that to select the subnets. You would declare the subnet in one of the AZs in the eksctl config, and then select that AZ in the nodegroup that you want: https://github.com/weaveworks/eksctl/blob/master/examples/04-existing-vpc.yaml#L17

I have not tried this and I don't know if it will succeed but might be worth trying as a hacky workaround for now.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[michaelbeaumont]

@kjdelisle This should be possible now that #806 is solved.