Rationale

AWS EKS (Elastic Kubernetes Service) is the service we use for hosting our Kubernetes Cluster in the cloud. It allows us to completely manage the system using an IaaS approach.

The main reasons why we chose it over other alternatives are the following:

• It seamlessly integrates with other AWS services, allowing us to easily integrate with EC2 for automatic worker provisioning, IAM for in-cluster authentication and authorization, and Elastic Load Balancing for serving applications.
• As all its infrastructure is cloud based, administering it becomes a much simpler task.
• It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
• It is supported by almost all Kubernetes SIGs utilities.
• Clusters can be fully managed using Terraform.
• It is constantly updated to support new Kubernetes versions.
• It supports OIDC, allowing our Kubernetes Cluster to perform actions within AWS like automatically creating load balancers when applications are deployed.
  

Alternatives

We tested Google Kubernetes Engine (GKE) a few years ago. Google engineers are the creators of Kubernetes, and that is one of the main reasons why GCP offers a more complete service. Overall, its GUI offered many more insights regarding nodes and pods. It also supported Terraform, configuring it was easier, and support for new versions was faster. The reason why we did not choose it over EKS was simple: We needed it to integrate with other cloud solutions that were already hosted on AWS. This is a clear example of cloud dependency.

Note: Azure Kubernetes Service (AKS) is another alternative. A review is pending.

Usage

We use EKS for

• providing networking infrastructure for our Kubernetes Cluster;
• automatically deploying worker groups;
• connecting to EC2 for automatic worker provisioning;
• connecting to IAM for in-cluster authentication and authorization;