On 2018-03-14 at 01:26 -0400, Jeremy T. Bouse wrote: > First of all the cluster is in a private subnet with no direct > internet so it gets NAT'd outbound from an IP address that would not > match the inbound IP address to be used.
Membership tests from your peers would reject this. > As I understand it the gossip port (11370/tcp) is not > HTTP based so it couldn't go through an ALB (application) and would need > to be pass-thru so that would mean NLB (network) or ELB (classic). The > HKP port (11371/tcp) could still be ran through any LB but since you can > only have a container configured to join one LB that would likely mean > needing to use an ELB so I could perform pass-thru for gossip and > HTTP/HTTPS for HKP port wheere the NLB would just pass-thru both to the > container. Oh eww, I'd missed that ECS containers can only be in one LB. That's ... horrible. How about using IPv6 and peering IPv6-only? As long as you don't set the v6 gateway to egress-only, and if you set the networking mode to `awsvpc` then you get ENIs on each task ... though I'm not seeing a way to attach a persistent ENI to get fixed addresses. It might be worth considering dynamic DNS which is updated every time a task is started or stopped, so that you peer with a changing set of IPv6 addresses? Or wait to see what Amazon announce in their EKS tech talk on Monday, to see if their EKS will be flexible enough that a Kubernetes service definition could be rigged up which lets you use the same IP for inbound and outbound? -Phil _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel