Replies: 1 comment 2 replies
-
@vchintal For the first part, do you mean that you want the IPs on the primary ENI to come from CIDR X and the IPs on the secondary ENI to come from CIDR Y? I am not sure I understand the third part. If the pods are in host networking mode, they do not get a pod IP from the VPC CNI, they just use the primary IP on the primary ENI. What does "use both ENIs" mean? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am working on a unique use case with the following requirement:
hostNetwork = true
where the pod will bind to both the ENIs.Since this is not possible out of the box with Launch Templates (LT) for the MNG, as the MNG doesn't allow any LTs with more than one network interface, I have resorted to using user data scripts to add the additional secondary ENI.
This is how I have automated the solution using Terraform:
data
of the LT EKS cluster creates by defaultuser data
of the LTInstance Profile
given adequate permissions to add/attach new ENIscreate-network-interface
andattach-network-interface
commands in the extracteduser data
at the end, after bootstrap script.managed node group
name to a new name in the parameters for the boostrap.sh scriptlaunch template
based on the updateduser data
scriptmanaged node group
based on the new LT createdThe above steps works fine as the new ENI displaces the secondary ENI attached to the node. Also, the new ENI come up as managed by the AWS VPC CNI with an IP address assigned from a distinct secondary VPC CIDR/subnet. I can also see secondary IP addresses, half belonging to the first ENI and half belonging to the second.
My questions are:
user data
created ENI, an expected behavior?node.k8s.amazonaws.com/no_manage: true
? If yes, why?Beta Was this translation helpful? Give feedback.
All reactions