Tutorial Highlights & Transcript
00:00 - EKS Optimizations Intro
00:49 - Addressing the IP Exhaust Problem
For this demo, I have used three availability zones in the US East one in North Virginia. As we want to create the three private subnets for the EKS and we also need a CIDR range for the public subnets and the database subnets. For that, I split the /16 CIDR range into four and make up four larger subnets and after the four larger subnet CIDR range, the first CIDR range will be 10.0.0/18. I kept it for the public subnet, database subnets, and different kinds of data layer and content layers, front-end tier subnets, and kept this private CIDR – this 22.214.171.124 CIDRs for the EKS worker nodes. That way, I will have enough IP addresses for the public subnets and database, also. Even EKS will also have enough subnets. As for the Solutions Architects and DevOps, they need to make a decision based on the future, also. Based on that, AWS VPC supports a total number of 5/16 CIDR ranges and if we convert it into the IP addresses allowed to allocate is around 329k IP addresses. If a client has more required IP addresses than 329k, then we have to split up the EKS cluster also into the multiple VPC and multiple EKS clusters If the client wants to stick with a single VPC and single EKS cluster only, for that kind of scenario, we don’t have to use VPC CNI, because it’s not supported. And for that kind of scenario, we have to go with overlay-based CNI and some of the best CNIs available are Calico and Selenium. Calico is the most efficient and fastest CNI load for the overlay right So, this concludes the first IP address issue.
05:05 - Addressing the Worker Node Storage Full Problem
Parth is a DevOps Engineer at nClouds with multiple AWS certifications including AWS Certified Solutions Architect - Professional, AWS Certified DevOps Engineer - Professional, AWS Certified Developer - Associate, and AWS Certified SysOps Administrator - Associate.