Cluster-api-provider-aws: only create one NatGateWay in a vpc, instead of one NatGW in every public subnet

[Kevin-fqh]

/kind feature

Describe the solution you'd like

we are charged for creating and using a NAT gateway in our account , and it takes too long to create/delete a NAT gateway.

so can we only create one NatGateWay in a vpc, instead of one NatGW in every public subnet ?

Correspondingly, all private subnet 's RouteTable , will has a route lead to the only one NatGateWay.

The only one NatGateWay is shared in a vpc, but not only one AvailableZone.

Environment:

• Cluster-api-provider-aws version: master

[detiber]

@Kevin-fqh I think this is one of those scenarios that present challenges either way. If there is only a single NAT gateway, then all NAT traffic will be subject to cross-AZ data transfer costs.

@randomvariable do you have thoughts here?

[chuckha]

/milestone v0.5.0
/priority important-longterm

[randomvariable]

Believe we should return to the original feature list and solve the topology support issue cohesively. My fear is we're getting a bit too fragmented by adding things in a piecemeal fashion. Happy to come up with a proposal for the next meeting, which is likely to be 2019/12/2 because of kubecon.

[Kevin-fqh]

follow https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/getting-started-eksctl.html， we use eksctl to create an eks, it has three public and there private subnet, but only has a single NATGateWay in a vpc as above.

[root@142node ~]#  eksctl create cluster --name prod --version 1.14 --nodegroup-name standard-workers --node-type t3.medium --nodes 2 --nodes-min 1 --nodes-max 3 --node-ami auto
[ℹ]  eksctl version 0.8.0
[ℹ]  using region ap-southeast-1
[ℹ]  setting availability zones to [ap-southeast-1b ap-southeast-1a ap-southeast-1c]
[ℹ]  subnets for ap-southeast-1b - public:192.168.0.0/19 private:192.168.96.0/19
[ℹ]  subnets for ap-southeast-1a - public:192.168.32.0/19 private:192.168.128.0/19
[ℹ]  subnets for ap-southeast-1c - public:192.168.64.0/19 private:192.168.160.0/19
[ℹ]  nodegroup "standard-workers" will use "ami-03a2cce9abe958c6c" [AmazonLinux2/1.14]
[ℹ]  using Kubernetes version 1.14
[ℹ]  creating EKS cluster "prod" in "ap-southeast-1" region
[ℹ]  will create 2 separate CloudFormation stacks for cluster itself and the initial nodegroup
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=ap-southeast-1 --cluster=prod'
[ℹ]  CloudWatch logging will not be enabled for cluster "prod" in "ap-southeast-1"
[ℹ]  you can enable it with 'eksctl utils update-cluster-logging --region=ap-southeast-1 --cluster=prod'
[ℹ]  Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "prod" in "ap-southeast-1"
[ℹ]  2 sequential tasks: { create cluster control plane "prod", create nodegroup "standard-workers" }
[ℹ]  building cluster stack "eksctl-prod-cluster"
[ℹ]  deploying stack "eksctl-prod-cluster"
[ℹ]  building nodegroup stack "eksctl-prod-nodegroup-standard-workers"
[ℹ]  deploying stack "eksctl-prod-nodegroup-standard-workers"

[vincepri]

It sounds like this might qualify (for the time being / until we have a proposal on how to address topologies) for bringing your own network, rather than relying on CAPA to create one for you.

[Kevin-fqh]

It sounds like this might qualify (for the time being / until we have a proposal on how to address topologies) for bringing your own network, rather than relying on CAPA to create one for you.

yes, agree

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[detiber]

/lifecycle frozen

[richardcase]

I have run up against this as part of #1534 (EKS control plane) as i made changes to the default subnets (see #1643).

[seh]

Is there another issue that's holding up progress on this one? @randomvariable alluded to "the topology support issue" in https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/1323#issuecomment-549509720. Is that #1484?

[detiber]

I think the biggest challenge here is around documentation related to the topologies that we wish to support (both through full management and BYO scenarios) as well as how to approach those changes in a way that would limit impact on existing clusters.

I would highly suspect that changes we make around topology support are also likely to have an impact on the API types, and if that is the case means that we would have to wait until v1alpha4 as well.