AWS Elastic Container Service for Kubernetes (EKS) was announced as Generally Available (GA) recently. prior to EKS, AWS customers used tools like KOPS, Kubeadm and Terraform to provision Kuberntes cluster in AWS. EKS is now a solution also for creating clusters on AWS. EKS was designed to simplify the process involved in setting up Kubernetes, scaling kubernetes and making easier networking configuration. In this design AWS has decided to fully manage the Kubernetes control plane by providing high availability using AWS multi AZ. Here is an image that I got from the AWS documentation page that illustrates the cluster setup.
The Control plane parts such as ETCD and the API-server are spread across three Availability Zones (AZ). The Kubernetes command line tool “kubectl” uses the IAM roles created by the AWS user and Heptio Authenticator to access and authenticate the cluster.There is also the Eksctl which is a command line tool that can be used for creating EKS clusters in minutes with a one line command
eksctl create cluster . AWS uses Elastic Network Interfaces for CNI purposes in EKS to allocate IPs to Pods.
A couple of really interesting things about EKS is that the cluster is highly available and can be scaled based on utilization. We also have the option of using the different types of load balancers in AWS such as Elastic Load Balancer (ELB), Network Load Balancer (NLB) and Application Load Balancer (ALB) for the purpose of routing traffic to pods running in the cluster. EKS also uses Route 53 for exposing services running in the cluster and allows this services to be reachable using Route 53 DNS records.
EKS introduces some limitations to what customers can utilize or manage in the cluster. With EKS, users are limited to CNI provided by AWS, Kubernetes API cannot be extended as we do not have control of API configuration and certain controllers are not implemented that kubernetes uses might need such as Pod Disruption Budget(PDB).
I will be making a post showing how to setup EKS cluster later on.