You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
have a Pod use hostNetwork = true and have two services within the pod, each bind to different IP addresses on the node, one to the primary IP address and one to the secondary unmanaged ENI IP
I have tried to place the nodes both in Private and Public subnets (during testing). The routes are correctly set to route traffic from the unmanaged ENI IP subnet to the 0.0.0.0/0
There is IGW assigned to Public subnets and NAT Gateway for the private subnets via the routes
Used two Elastic IP address and bound them each to the different IP addresses of the nodes
With the above setting, in my tests I find that the service binding to the primary ENI IP is always reachable from the client running on my desktop. However I was unable to access the service (via Elastic IP) bound to the unmanaged ENI.
Can anyone confirm if the last two lines of this documentation is the reason for it?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have a use case where I am trying to
unmanaged
ENI to an EKS nodehostNetwork = true
and have two services within the pod, each bind to different IP addresses on the node, one to the primary IP address and one to the secondaryunmanaged
ENI IPunmanaged
ENI IP subnet to the0.0.0.0/0
With the above setting, in my tests I find that the service binding to the primary ENI IP is always reachable from the client running on my desktop. However I was unable to access the service (via Elastic IP) bound to the
unmanaged
ENI.Can anyone confirm if the last two lines of this documentation is the reason for it?
Beta Was this translation helpful? Give feedback.
All reactions