As a result of ENI prefix limits issue encountered during EKS Module v18 upgrade work, we need to explore better ways of allocating and managing ip addresses within Cloud Platform VPC.
Currently we provision AWS resources such as RDS, ElasticSearch etc into the same private subnets as our cluster nodes themselves. These subnets have a CIDR range /19 (8190 addresses)
We should investigate moving these resources into their own private subnets within the VPC so that we have more ip addresses available in our cluster subnets for CNI to provision as prefix blocks.
Things to look at:
Can we allocate additional subnets within our existing VPC range?
What changes would be required for the AWS modules to provision resources in these separate subnets?
Route tables & security group configurations to enable secure comms between cluster / resource subnets.
Background
As a result of ENI prefix limits issue encountered during EKS Module v18 upgrade work, we need to explore better ways of allocating and managing ip addresses within Cloud Platform VPC.
Currently we provision AWS resources such as RDS, ElasticSearch etc into the same private subnets as our cluster nodes themselves. These subnets have a CIDR range /19 (8190 addresses)
We should investigate moving these resources into their own private subnets within the VPC so that we have more ip addresses available in our cluster subnets for CNI to provision as prefix blocks.
Things to look at:
Proposed user journey
Approach
Which part of the user docs does this impact
Communicate changes
Questions / Assumptions
Definition of done
Reference
How to write good user stories