EKS Anywhere, Environmental substrate & prerequisites

This article is a part of the multi-part story of EKS Anywhere. Access it here EKS Anywhere series EKS Anywhere, extending the Hybrid cloud momentum

Step-1 Collect basic information for the EKS Anywhere cluster deployment

EKS Anywhere can get very granular to the point of having the control plane master nodes, worker nodes and etcd nodes placed in different networks, different configurations, etc. However, in this particular case we will simplify the specifications by keeping the control plane master nodes, worker and etcd nodes of the cluster in the same network with default configurations.

To simplify what is essential to a successful implementation, here is a handy table that you can use to collect information.

Attribute	Description	Value
vCenter username	Preferably a full admin	value
vCenter password	password	value
vCenter FQDN or IP	vCenter server fully qualified domain name or IP address	value
vCenter cert thumbprint	SHA1 thumbprint of the vCenter server certificate	value
Datacenter name	vSphere datacenter to deploy the EKS Anywhere cluster on	value
Network name	VM network to deploy your EKS Anywhere cluster on	value
Datastore name	vSphere datastore to deploy your EKS Anywhere cluster on	value
Resource pool name	vSphere Resource pools for your VMs in the EKS Anywhere cluster	value
VM folder name	VM folder for your EKS anywhere cluster VMs	value
Static IP Pool	A DHCP excluded scope of IP from same network segment used for the cluster nodes	value
DHCP server IP	IP address of the DHCP server	value
DNS server IP	IP address of the DNS server	value
AWS IAM Keys (Optional)	Required only in case of EKS console integration. Permissions documented in the respective article	value

 

Note: You will need at-least 10–15 static IP addresses for the exercises in this saga series.

Step-2 Capacity requirements

Since we will be running a classic production grade environment, ensure an approximate usable capacity of 60 vCPUs, 400GiB memory and 900GiB storage. This should exclude any other overheads required by the virtualization layer and techniques used for the infrastructure (e.g., HCI overheads, etc.). The breakup is provided in the below gist

Category	Description	vCPU	Memory	Storage
Admin machine	EKS-Anywhere and any other packages	4	16GiB	100GiB
Management cluster	2 Control plane plus 3 etcd and 2 worker node	14	56GiB	175GiB
Workload cluster-1	3 control plane plus 3 etcd and 3 worker nodes	18	144GiB	225GiB
Workload cluster-2	3 control plane plus 3 etcd and 3 worker nodes	18	144GiB	225GiB
Harbor image registry	Optional in case of local registry support	4	8GiB	160GiB

Step-3 vSphere related requirements

vSphere user: Create a vSphere user with administrative privileges

vSphere folder/s: 

• Create a folder named "Templates" if it already does not exist right under the Data center resource in vSphere. This folder will be used to host the ubuntu base template for EKS Anywhere administrative machine and the ubuntu OS template/s for the EKS Anywhere cluster nodes
• In addition to that create another folder named "test-eks-anywhere". This will be used to host all the cluster virtual machines. While you can use any other name for this folder, it is best to keep it as "test-eks-anywhere" as the cluster YAMLs used in this saga series are configured with this particular name

Local networking: Ensure adequate network connectivity between vCenter/vSphere, DHCP/DNS, EKS-Anywhere subnet. In this series, we will let all IP communications flow between these entities without any restrictions. Else you might want to evaluate specific port requirements as listed in this URL Ports and protocols | EKS Anywhere (amazonaws.com)

Internet connectivity: For the sake of simplicity, we will assume that the target environment has unrestricted outbound access to internet. Note that Proxy access and local registry support for restricted environments is also supported.

Inbound firewall ports are a non-issue as all connectivity is originated from within the environment.

You can create also create a narrower permissions model as described below:

The administrative machine and the target workload environment will need network access to:

• public.ecr.aws
• anywhere-assets.eks.amazonaws.com to download the EKS Anywhere binaries, manifests and OVAs
• distro.eks.amazonaws.com to download EKS Distro binaries and manifests
• d2glxqk2uabbnd.cloudfront.net for EKS Anywhere and EKS Distro ECR container images
• github.com
• Access to the specific AWS regions (required only if you are planning for EKS console integration)

And with all that, you are all set to explore the EKS Anywhere stack!

cheers,

Ambar Hassani

#iwork4dell