Kubernetes clusters within AWS EKS

Cloud Clusters

When a Kubernetes laboratory environment is required, the excellent localized Minikube and the tiny production-ready k3s distributions are fantastic. They permit a level of interaction with Kubernetes that lets developers prove workloads will act as expected in staging and production environments.

However, as cloud-native technology stacks lean more on the managed service offerings of Kubernetes, courtesy of the popular cloud platforms, it has become easier to test more thoroughly on a managed Kubernetes service. These managed services include the Google Kubernetes Engine (GKE) [1], Azure Kubernetes Service (AKS) [2], and Amazon Elastic Kubernetes Service (EKS) [3].

In this article, I walk through the automated deployment of the Amazon Elastic Kubernetes Service (EKS), a mature and battle-hardened offering that is widely trusted for production workloads all over the world by household names. For accessibility, suitable for those who do not want to run their own clusters fully, EKS abstracts the Kubernetes control plane away from users completely and provides access directly to the worker nodes that run on AWS Elastic Compute Cloud (EC2) [4] server instances.

In the Box

By concealing the Kubernetes control plane, EKS users are given the luxury of leaving the complexity of running a cluster almost entirely to AWS. You still need to understand the key concepts, however.

When it comes to redundancy, the EKS control plane provides a unique set of resources that are not shared with other clients – referred to as a single tenant – and the control plane also runs on EC2 instances that are abstracted from the user. The control plane of Kubernetes typically includes the

...

Use Express-Checkout link below to read the full article (PDF).