Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Addons such as aws_vpc_cni should optionally be installable via helm #523

Closed
andrewhibbert opened this issue May 10, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@andrewhibbert
Copy link

Is your feature request related to a problem? Please describe

Since many people use custom networking for aws_vpc_cni the modules should allow this to either be configurable via add on or via helm so this extra config can be set.

Describe the solution you'd like

Option to install via helm and provide helm values

@bryantbiggs bryantbiggs added enhancement New feature or request addon labels May 10, 2022
@bryantbiggs
Copy link
Contributor

Thank you for the request @andrewhibbert ! Would you mind sharing how you manage this in your cluster today? Do you manually remove the EKS provided VPC CNI plugin and then re-install using Helm? Is your primary use case here to be able to configure VPC CNI custom networking or do you have other use cases you can share?

@andrewhibbert
Copy link
Author

Currently we just edit the resources on the fly, but we'd like to do this via code. Primary use case is for VPC CNI custom networking, though I think the module should just provide minimal helm config similar to things like the karpenter module

@bryantbiggs
Copy link
Contributor

Thank you for sharing that info @andrewhibbert - there are a number of similar tickets on the containers roadmap where users are looking for various alternative means of handling the VPC CNI such as aws/containers-roadmap#71

It should be possible to apply a helm config over top of the VPC CNI manifests provided by the EKS service, but we'll have to check out whats possible/feasible and see if there are any issues with managing it this way

@vara-bonthu
Copy link
Contributor

vara-bonthu commented May 12, 2022

@andrewhibbert I understand and I see lot of customers wants to customize the parameters for VPC CNI deployment. Currently we don't support the self-managed add-on for VPC CNI.

EKS Blueprints supports only EKS Managed Add-on for VPC CNI which makes it easy for customers to manage the Add-on and upgrade to the latest versions. However this doesn't provide flexibility to update the config

For now if you want to implement the self managed VPC CNI add-on use this link https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on

We will look at adding VPC CNI Self Managed add-on Helm Chart to our roadmap. This will provide both options for customer to choose between EKS Managed and Self managed

@lupindeterd
Copy link

@bryantbiggs I'm not sure if this relevant to this but it seems that the custom value I set through amazon_eks_vpc_cni_config doesn't get applied to the running DaemonSet, I want to change the SNAT env to true from false.

amazon_eks_vpc_cni_config = { set = [{ name = "env.AWS_VPC_K8S_CNI_EXTERNALSNAT" value = "true" } ] }

@bryantbiggs
Copy link
Contributor

@bryantbiggs I'm not sure if this relevant to this but it seems that the custom value I set through amazon_eks_vpc_cni_config doesn't get applied to the running DaemonSet, I want to change the SNAT env to true from false.

amazon_eks_vpc_cni_config = { set = [{ name = "env.AWS_VPC_K8S_CNI_EXTERNALSNAT" value = "true" } ] }

@lupindeterd - the VPC CNI addon is a managed addon and therefore does not currently support custom configurations such as setting environment variables.

@bryantbiggs
Copy link
Contributor

with EKS now supporting addon custom configuration, we are going to close out this issue. thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants