EKS is an AWS-managed service. You can use it to create easily one or several Kubernetes clusters. EKS is integrated with many other services like ECR (Elastic Container Registry) for Docker images, ELB (Elastic Load Balancing) for load balancing, and IAM for authentication.
When an EKS instance is deployed, you do not have to pay attention to the Kubernetes control plane, it is fully managed by EKS. When you create a new Kubernetes cluster, a control plane will be created (by default) with 2 nodes for the API server and 3 nodes for Etcd which is the Kubernetes distributed key-value storage.
You have two options before creating an EKS cluster, you can use AWS Fargate or EC2 instances to run your containers. The first one is a serverless service for containers therefore you can launch containers without worker nodes. This article will focus on the implementation with EC2 instances because it is the most used implementation.
Therefore, in this case, the creation of a Kubernetes cluster with EKS generates the setup of EC2 instances that are your worker nodes. They will connect to the control plane thanks to the API server endpoint. The set of nodes is split into different node groups. Every worker node in the same group has the same instance type.
These groups are useful for the Auto Scaling service that adapts the number of nodes depending on the use of nodes resources, so, it can add or remove one or several nodes on AWS.
In case you use EC2 instances to run your containers, EKS supports network load balancers and, logically, the Kubernetes load balancers for pods; that is the Kubernetes services of type LoadBalancer. If you used AWS Fargate (the Amazon serverless service), network load balancers are not supported.
AWS has its own Ingress Controller service which is ALB Ingress Controller. This service triggers the creation of ingresses and the necessary resources for the ingress operation.
In a basic Kubernetes cluster, you have to implement a virtual network like Calico or Flannel. However, EKS has a default CNI plugin (Container Network Interface plugin) which is Amazon CNI. It works differently than other CNI plugins. It allocates to every Kubernetes pod an IP address that is accessible in the Amazon VPC network whereas, for example with Calico, a pod IP address is only reachable inside the cluster.
Naturally, you can switch to another CNI plugin, you will have to delete the Amazon CNI implementation and install the CNI wanted in the Elastic Kubernetes Service (EKS) cluster.
Example with a virtual network like Calico
Example with Amazon CNI
You can deploy an EKS cluster on AWS with different tools like AWS cli but, in this article, we will focus on the EKS cli; that is eksctl. The goal is not to show you all the tools that allow you to create an EKS instance, but only an example that demonstrates how it is easy to deploy a Kubernetes cluster on AWS.
Eksctl is an open-source project created by WeaveWork and it is the official EKS cli.
To create a cluster, you have to use the following command:
eksctl create cluster
This command will create a cluster with all default parameters like the EKS cluster name, the AWS region, the EC2 instance type…
To customize your cluster, you can add some parameters, for example:
eksctl create cluster —name staging —region us-east-2
You can choose from many other options such as the EKS nodes groups, the type of EC2 instances in every group…
Instead of including all EKS options in the command, you have the possibility to create a file like the following YAML file and use it to launch your Kubernetes cluster:
eksctl create -f clusterCreation.yaml
As you can see, an EKS cluster is straightforward to deploy on AWS.
AWS has a powerful Kubernetes service, it can allow you to use Kubernetes without reducing its features and other Amazon services like IAM, VPC… The most important thing to remember is that the aim of the Elastic Kubernetes Service (EKS) is to facilitate your project to reduce the working time to build your Kubernetes infrastructure.