diff --git a/docs/how-it-works/features/compute/k8s-eks.md b/docs/how-it-works/features/compute/k8s-eks/overview.md similarity index 94% rename from docs/how-it-works/features/compute/k8s-eks.md rename to docs/how-it-works/features/compute/k8s-eks/overview.md index 328505382..1a631d650 100644 --- a/docs/how-it-works/features/compute/k8s-eks.md +++ b/docs/how-it-works/features/compute/k8s-eks/overview.md @@ -12,7 +12,7 @@ to run **Kubernetes** on AWS without needing to install and operate your own Kub - [x] Built with the Community: AWS actively works with the Kubernetes community, including making contributions to the Kubernetes code base helping you take advantage of AWS services. -![leverage-aws-eks](../../../assets/images/diagrams/aws-k8s-eks.png "Leverage"){: style="width:950px"} +![leverage-aws-eks](../../../../assets/images/diagrams/aws-k8s-eks.png "Leverage"){: style="width:950px"}
Figure: AWS K8s EKS architecture diagram (just as reference). @@ -31,4 +31,4 @@ and [IaC Library EKS module](https://github.com/binbashar/terraform-aws-eks) We think this is a good balance between management overhead and an acceptable level of supported versions (at best effort). If your project have and older legacy version we could work along -your CloudOps team to safely migrate it to a Leverage supported EKS version. \ No newline at end of file +your CloudOps team to safely migrate it to a Leverage supported EKS version. diff --git a/docs/how-it-works/features/compute/k8s-eks/vpc-adressing.md b/docs/how-it-works/features/compute/k8s-eks/vpc-adressing.md new file mode 100644 index 000000000..b4d1c3b65 --- /dev/null +++ b/docs/how-it-works/features/compute/k8s-eks/vpc-adressing.md @@ -0,0 +1,98 @@ +# Kubernetes AWS EKS + +# Network Layer: EKS Network Requirements + +!!! info "In this section we detail all the network design related specifications" + * [x] VPCs CIDR blocks + * [x] Private & Public Subnets IP Ranges + +## Considerations +!!! attention "Design considerations" + * :ledger: **AWS EKS:** Docker runs in the 172.17.0.0/16 CIDR range in Amazon EKS clusters. + We recommend that your cluster's VPC subnets do not overlap this range. Otherwise, you will + receive the following error: + ``` + Error: : error upgrading connection: error dialing backend: dial tcp 172.17.nn.nn:10250: + getsockopt: no route to host + ``` + Read more: [AWS EKS network requirements](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html) + * :ledger: **Reserved IP Addresses** + The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, + and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP + addresses are reserved. For more [AWS VPC Subnets IP addressing](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4) +--- + +### VPCs IP Addressing Plan (CIDR blocks sizing) + +!!! summary "Introduction" + VPCs can vary in size from 16 addresses (/28 netmask) to 65,536 addresses (/16 netmask). + In order to size a VPC correctly, it is important to understand the number, types, and sizes of workloads + expected to run in it, as well as workload elasticity and load balancing requirements. + + Keep in mind that there is no charge for using Amazon VPC (aside from EC2 charges), therefore cost + should not be a factor when determining the appropriate size for your VPC, so make sure you size your + VPC for growth. + + Moving workloads or AWS resources between networks is not a trivial task, so be generous in your + IP address estimates to give yourself plenty of room to grow, deploy new workloads, or change your + VPC design configuration from one to another. The majority of AWS customers use VPCs with a /16 + netmask and subnets with /24 netmasks. The primary reason AWS customers select smaller VPC and + subnet sizes is to avoid overlapping network addresses with existing networks. + + So having [AWS single VPC Design](https://aws.amazon.com/answers/networking/aws-single-vpc-design/) we've chosen + a Medium/Small VPC/Subnet addressing plan which would probably fit a broad range variety of + use cases + +## Networking - IP Addressing + +!!! example "Starting CIDR Segment (AWS EKS clusters)" + * [x] AWS EKS clusters IP Addressing calculation is presented below based on segment `10.0.0.0/16` (starts at /16 due to AWS VPC limits) + * [x] We started from `10.0.0.0/16` and subnetted to `/19` + * [x] Resulting in **Total Subnets: 8** + * Number of available hosts for each subnet: 8190 + * Number of available IPs (AWS) for each subnet: 8187 + +!!! example "Individual CIDR Segments (VPCs)" + :fast_forward: Then each of these are /16 to /19 + + * [x] Considering the whole Starting CIDR Segment (AWS EKS clusters) before declared, we'll start at `10.0.0.0/16` + * **apps-devstg** + * 1ry VPC CIDR: `10.0.0.0/16` + * 1ry VPC DR CIDR: `10.20.0.0/16` + * **apps-prd** + * 1ry VPC CIDR: `10.10.0.0/16` + * 1ry VPC DR CIDR: `10.30.0.0/16` + + * [x] Resulting in **Subnets: 4 x VPC** + * VPC Subnets with Hosts/Net: 16. + * Eg: apps-devstg account → us-east-1 w/ 3 AZs → 3 x Private Subnets /az + 3 x Public Subnets /az + * 1ry VPC CIDR: `10.0.0.0/16 `Subnets: + * Private `10.0.0.0/19, 10.0.32.0/19 and 10.0.64.0/19` + * Public `10.0.96.0/19, 10.0.128.0/19 and 10.0.160.0/19` + +## Planned Subnets per VPC + +Having defined the initial VPC that will be created in the different accounts that were defined, we are going to create +subnets in each of these VPCs defining Private and Public subnets split among different availability zones: + + +| Subnet address | Range of addresses | Hosts | Assignment | +| :------------: | :-------------------------: | :---: | :--------------------------------------: | +| 10.0.0.0/19 | 10.0.0.0 - 10.0.31.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1a | +| 10.0.32.0/19 | 10.0.32.0 - 10.0.63.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1b | +| 10.0.64.0/19 | 10.0.64.0 - 10.0.95.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1c | +| 10.0.96.0/19 | 10.0.96.0 - 10.0.127.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1a | +| 10.0.128.0/19 | 10.0.128.0 - 10.0.159.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1b | +| 10.0.160.0/19 | 10.0.160.0 - 10.0.191.0/255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1c | +| 10.0.192.0/19 | 10.0.192.0 - 10.0.223.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1 | +| 10.0.224.0/19 | 10.0.224.0 - 10.0.224.255 | 8190 | 1ry VPC: apps-devstg
AZ: us-east-1 | + +**Note:** Additional clusters can use their own available VPC space under 10.x.0.0/16. + +- [Subnetting reference #1 | Visual Subnet Calculator (https://www.davidc.net/)](https://www.davidc.net/sites/default/subnets/subnets.html?network=10.0.0.0&mask=16&division=15.7231) + +- [Subnetting reference #2 | IP Calculator / IP Subnetting (https://jodies.de/)](http://jodies.de/ipcalc?host=10.0.0.0&mask1=16&mask2=19) + +## Read More +!!! info "EKS Reference Architecture Specs" + In case you would like to further understand the different tech specs and configs for this Ref Arch you could find some details like at the [Features/Compute/K8s EKS](./overview.md) \ No newline at end of file diff --git a/docs/how-it-works/features/compute/k8s-service-mesh.md b/docs/how-it-works/features/compute/k8s-service-mesh.md index fdf1a902e..853ee130a 100644 --- a/docs/how-it-works/features/compute/k8s-service-mesh.md +++ b/docs/how-it-works/features/compute/k8s-service-mesh.md @@ -37,5 +37,5 @@ Linkerd Doc, accessed June 14th 2021). ## Read more !!! info "Related resources" - * :ledger: [Linkerd vs Istio benchamrks](hhttps://linkerd.io/2021/05/27/linkerd-vs-istio-benchmarks/) + * :ledger: [Linkerd vs Istio benchmarks](https://linkerd.io/2021/05/27/linkerd-vs-istio-benchmarks/) diff --git a/docs/how-it-works/features/features-overview.md b/docs/how-it-works/features/features-overview.md index bf7248a2c..b2584dde3 100644 --- a/docs/how-it-works/features/features-overview.md +++ b/docs/how-it-works/features/features-overview.md @@ -37,7 +37,8 @@ ??? check "Compute" - [x] [**Compute**](./compute/overview.md) - - [x] [**K8s EKS**](./compute/k8s-eks.md) + - [x] [**K8s EKS Overview**](./compute/k8s-eks/overview.md) + - [x] [**K8s EKS VPC Adressing**](./compute/k8s-eks/vpc-adressing.md) - [x] [**K8s Kops**](./compute/k8s-kops.md) - [x] [**K8s Service Mesh**](./compute/k8s-service-mesh.md) - [x] [**Serverless**](./compute/serverless.md) diff --git a/docs/how-it-works/features/network/vpc-addressing.md b/docs/how-it-works/features/network/vpc-addressing.md index 8caa0b045..b8b85a2a2 100644 --- a/docs/how-it-works/features/network/vpc-addressing.md +++ b/docs/how-it-works/features/network/vpc-addressing.md @@ -31,8 +31,8 @@ ## Networking - IP Addressing !!! example "Starting CIDR Segment (AWS Org)" - * [x] AWS Org IP Addressing calculation is presented below based on segment `172.16.0.0.0/12` - * [x] We started from `172.16.0.0.0/12` and subnetted to `/20` + * [x] AWS Org IP Addressing calculation is presented below based on segment `172.16.0.0/12` + * [x] We started from `172.16.0.0/12` and subnetted to `/20` * [x] Resulting in **Total Subnets: 256** * 2 x AWS Account with Hosts/SubNet: 4094 * 1ry VPC + 2ry VPC @@ -66,38 +66,26 @@ * Private `172.18.64.0/24, 172.18.66.0/24 and 172.18.68.0/24` * Public `172.18.65.0/24, 172.18.67.0/24 and 172.18.69.0/24` -## Planned VPCs +## Planned Subnets per VPC Having defined the initial VPC that will be created in the different accounts that were defined, we are going to create subnets in each of these VPCs defining Private and Public subnets split among different availability zones: -| Subnet address | Netmask | Range of addresses | Hosts | Assignment | -|------------------|---------------|--------------------------------|-------|------------------------| -| 172.18.0.0/20 | 255.255.240.0 | 172.18.0.0 - 172.18.15.255 | 4094 | 1ry VPC: shared | -| 172.18.16.0/20 | 255.255.240.0 | 172.18.16.0 - 172.18.31.255 | 4094 | 2ry VPC: shared | -| 172.18.32.0/20 | 255.255.240.0 | 172.18.32.0 - 172.18.47.255 | 4094 | 1ry VPC DR: shared | -| 172.18.48.0/20 | 255.255.240.0 | 172.18.48.0 - 172.18.63.255 | 4094 | 2ry VPC DR: shared | -| 172.18.64.0/20 | 255.255.240.0 | 172.18.64.0 - 172.18.79.255 | 4094 | 1ry VPC: apps-devstg | -| 172.18.80.0/20 | 255.255.240.0 | 172.18.80.0 - 172.18.95.255 | 4094 | 2ry VPC: apps-devstg | -| 172.18.96.0/20 | 255.255.240.0 | 172.18.96.0 - 172.18.111.255 | 4094 | 1ry VPC DR: apps-devstg| -| 172.18.112.0/20 | 255.255.240.0 | 172.18.112.0 - 172.18.127.255 | 4094 | 2ry VPC DR: apps-devstg| -| 172.18.128.0/20 | 255.255.240.0 | 172.18.128.0 - 172.18.143.255 | 4094 | 1ry VPC: apps-prd | -| 172.18.144.0/20 | 255.255.240.0 | 172.18.144.0 - 172.18.159.255 | 4094 | 2ry VPC: apps-prd | -| 172.18.160.0/20 | 255.255.240.0 | 172.18.160.0 - 172.18.175.255 | 4094 | 1ry VPC DR: apps-prd | -| 172.18.176.0/20 | 255.255.240.0 | 172.18.176.0 - 172.18.191.255 | 4094 | 2ry VPC DR: apps-prd | +| Subnet address | Range of addresses | Hosts | Assignment | +| :-------------: | :---------------------------: | :---: | :---------------------: | +| 172.18.0.0/20 | 172.18.0.0 - 172.18.15.255 | 4094 | 1ry VPC: shared | +| 172.18.16.0/20 | 172.18.16.0 - 172.18.31.255 | 4094 | 2ry VPC: shared | +| 172.18.32.0/20 | 172.18.32.0 - 172.18.47.255 | 4094 | 1ry VPC DR: shared | +| 172.18.48.0/20 | 172.18.48.0 - 172.18.63.255 | 4094 | 2ry VPC DR: shared | +| 172.18.64.0/20 | 172.18.64.0 - 172.18.79.255 | 4094 | 1ry VPC: apps-devstg | +| 172.18.80.0/20 | 172.18.80.0 - 172.18.95.255 | 4094 | 2ry VPC: apps-devstg | +| 172.18.96.0/20 | 172.18.96.0 - 172.18.111.255 | 4094 | 1ry VPC DR: apps-devstg | +| 172.18.112.0/20 | 172.18.112.0 - 172.18.127.255 | 4094 | 2ry VPC DR: apps-devstg | +| 172.18.128.0/20 | 172.18.128.0 - 172.18.143.255 | 4094 | 1ry VPC: apps-prd | +| 172.18.144.0/20 | 172.18.144.0 - 172.18.159.255 | 4094 | 2ry VPC: apps-prd | +| 172.18.160.0/20 | 172.18.160.0 - 172.18.175.255 | 4094 | 1ry VPC DR: apps-prd | +| 172.18.176.0/20 | 172.18.176.0 - 172.18.191.255 | 4094 | 2ry VPC DR: apps-prd | ### Considerations -!!! attention "Design considerations" - * :ledger: **AWS EKS:** Docker runs in the 172.17.0.0/16 CIDR range in Amazon EKS clusters. - We recommend that your cluster's VPC subnets do not overlap this range. Otherwise, you will - receive the following error: - ``` - Error: : error upgrading connection: error dialing backend: dial tcp 172.17.nn.nn:10250: - getsockopt: no route to host - ``` - Read more: [AWS EKS network requirements](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html) - * :ledger: **Reserved IP Addresses** - The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, - and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP - addresses are reserved. For more [AWS VPC Subnets IP addressing](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4) +- Kubernetes on EKS General Requirements for Network Layer: [**K8s EKS Networking | VPC Adressing**](../compute/k8s-eks/vpc-adressing.md) diff --git a/mkdocs.yml b/mkdocs.yml index 6d5bc59b7..364d1cbd0 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -204,7 +204,9 @@ nav: - Compute: - Overview: "how-it-works/features/compute/overview.md" - K8s Kops: "how-it-works/features/compute/k8s-kops.md" - - K8s EKS: "how-it-works/features/compute/k8s-eks.md" + - K8s EKS: + - Overview: "how-it-works/features/compute/k8s-eks/overview.md" + - VPC Adressing: "how-it-works/features/compute/k8s-eks/vpc-adressing.md" - K8s Service Mesh: "how-it-works/features/compute/k8s-service-mesh.md" - Serverless: "how-it-works/features/compute/serverless.md" - Tools: "how-it-works/features/compute/tools.md"