Design Proposal #002: Existing VPC

[errordeveloper]

No description provided.

[anodyne4j]

This looks really cool, @errordeveloper, and it has all the flags I'd need for the cluster I'm bringing up.

One question - could we run into issues deploying into existing subnets while using EKS-native CNI, with its need for many secondary IPs? What would happen if all the pods in the cluster weren't able to get IP addrs?

[errordeveloper]

@anodyne4j thanks a lot for your feedback!

One question - could we run into issues deploying into existing subnets while using EKS-native CNI, with its need for many secondary IPs? What would happen if all the pods in the cluster weren't able to get IP addrs?

I am not deeply familiar with the implementation, but I am pretty certain it's meant to coexist very happily with anything you have in your VPC, from plain EC2 instances, through load balancers and gateways to Lambda functions. So I would expect it to try and use what IP addresses are available, which is only a subject to IP address space usage, of course. You can monitor allocations (and other properties of the CNI driver) via CloudWatch (#278) and/or Prometheus.

However, if you have a short subnet in your VPC, or there are many resources using up the IP address space, you will ultimately run into issue sooner than later. If that's the case, I would consider VPC peering, or something else. Peering should already be possible, and custom CIDR flag is available as of 0.1.8.

And, I must note, that exactly for this and other reasons we have plans to provide Weave Net as an overall option (#109, weaveworks/weave#3335). By definition overall is exactly for this purposes. I am not up to date on IPv6 support in EKS, I've not heard of it being commonly used in AWS just yet, but I'm keen to hear if anyone used it.

[errordeveloper]

I've clarified that this is still a draft and changes are welcome. I'd like to merge it soon, as well as --vpc-{private,public}-subnets implementation.

[errordeveloper]

I'm going to merge this, as this doesn't imply we have made a final decision. There is more we can do, and tweaks are welcome. Initial feature is underway in #305, let's use #306 to tracking progress on various features listed in this document.