Eksctl: VPC creation should be more customizable

Created on 12 Feb 2020  路  2Comments  路  Source: weaveworks/eksctl

Why do you want this feature?
Currently you can create a VPC with the CIDR block, but you cannot customize the subnet CIDR range and AZs that they belong to.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: foo-cluster
  region: ap-northeast-1

vpc:
  cidr: "10.0.0.0/16"

What feature/behavior/change do you want?
Without giving a subnet ID, it should be able to create new subnets on the AZs

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: foo-cluster
  region: ap-northeast-1

vpc:
  cidr: "10.0.0.0/16"
  subnets:
    private:
      ap-northeast-1a:
        cidr: "10.0.0.0/24"
      ap-northeast-1b:
        cidr: "10.0.1.0/24"
    public:
      ap-northeast-1a:
        cidr: "10.0.2.0/24"
      ap-northeast-1b:
        cidr: "10.0.3.0/24"
areaws-vpc kinfeature prioritimportant-longterm

Most helpful comment

This is useful when you want to deploy other AWS resources on your VPC/subnets.
For example, when you want to create prd/stg/dev environment with EKS + RDS in your PRD/STG/DEV environment, you need to set different subnet IDs on each environment and it has to be specified without using any sort of alias.

If this feature is implemented, all you need is just create a cluster with eksctl first, then you use the CloudFormation output from eksctl to refer which subnets it has to be and create RDS environment on top of it.

All 2 comments

This is useful when you want to deploy other AWS resources on your VPC/subnets.
For example, when you want to create prd/stg/dev environment with EKS + RDS in your PRD/STG/DEV environment, you need to set different subnet IDs on each environment and it has to be specified without using any sort of alias.

If this feature is implemented, all you need is just create a cluster with eksctl first, then you use the CloudFormation output from eksctl to refer which subnets it has to be and create RDS environment on top of it.

I agree, this is a useful feature. I would go even further and allow someone to pass in a VPC ID for it to do what the other people said above. From a perspective of an infrastructure operator, Kubernetes is just another application and I have many applications in my VPC that has to work together in an environment. I mostly don't want my Kubernetes tool to be building my VPC. What if later I dont want to use this tool anymore? I am then stuck with it managing my VPC state.

Here is my usual workflow:

  1. Launch VPC with default routing via Terraform
  2. Do necessary peering via Terraform
  3. Start launching apps
  4. Launch a Kubernetes cluster in the VPC - I want this to build it's own world that it needs in my VPC (subnets, routing, etc). This would allow me to perform CRUD operations on it without affecting anything else.
  5. Launch RDS in the VPC - I want this to build it's own world that it needs in my VPC (subnets, routing, etc). This would allow me to perform CRUD operations on it without affecting anything else.
  6. Launch other apps in a similar way

I get why the current deployment model is in place. It is the first pass at this eksctl tool. Kops is another kubernetes tool and that has a semantics to do the above and I think eksctl should also.

Was this page helpful?
0 / 5 - 0 ratings