Navigating the various Kubernetes deployment approaches supported by the AWS cloud is arguably more complicated than understanding how to deploy Kubernetes in other public clouds. That is because, although AWS supports only two main Kubernetes deployment models – self-managed clusters on EC2 or AWS-managed clusters using the EKS service – there are multiple variants of the latter approach.
Let’s take a look at these various options to see how they compare.
To do this, you first need to create at least one EC2 VM instance. (If you want a multi-node Kubernetes cluster, you’ll need a separate instance for each node.) You can create EC2 instances in the AWS console at https://console.aws.amazon.com/ec2. The nodes should run some version of Linux (you can use Windows-based VMs as worker nodes in Kubernetes, but this is less common, and master nodes must be Linux-based).
Then, log into the EC2 instance that you want to serve as your master node, install a Kubernetes distribution on it and start the distribution. The exact process to follow here will depend on which Kubernetes distribution you use; as a basic example, however, here’s how to set up and run the Minikube distribution in a Linux environment:
At this point, your EC2 instance will be up and running as a master node. If you want to join other nodes to your cluster, you’ll have to repeat the setup process on each node.
Note that when you run Kubernetes on EC2 yourself, it’s up to you to manage the virtual infrastructure, as well as the Kubernetes environment. You’ll have to add more nodes manually, and you may need to change the resources allocated to each node depending on your workloads’ requirements. You will also be responsible for securing and upgrading your Kubernetes control plane entirely on your own.
The upside of this approach is that it gives you maximum control over how your Kubernetes clusters run. You can choose whichever distribution you want, and you can configure it however you want. Your total cost of operation will also be lower than using AWS EKS, which charges for the underlying EC2 instances you consume as well as an hourly per-cluster fee.
Let’s take a look at these various options to see how they compare.
To do this, you first need to create at least one EC2 VM instance. (If you want a multi-node Kubernetes cluster, you’ll need a separate instance for each node.) You can create EC2 instances in the AWS console at https://console.aws.amazon.com/ec2. The nodes should run some version of Linux (you can use Windows-based VMs as worker nodes in Kubernetes, but this is less common, and master nodes must be Linux-based).
Then, log into the EC2 instance that you want to serve as your master node, install a Kubernetes distribution on it and start the distribution. The exact process to follow here will depend on which Kubernetes distribution you use; as a basic example, however, here’s how to set up and run the Minikube distribution in a Linux environment:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 sudo install minikube-linux-amd64 /usr/local/bin/minikube minikube start
At this point, your EC2 instance will be up and running as a master node. If you want to join other nodes to your cluster, you’ll have to repeat the setup process on each node.
Note that when you run Kubernetes on EC2 yourself, it’s up to you to manage the virtual infrastructure, as well as the Kubernetes environment. You’ll have to add more nodes manually, and you may need to change the resources allocated to each node depending on your workloads’ requirements. You will also be responsible for securing and upgrading your Kubernetes control plane entirely on your own.
The upside of this approach is that it gives you maximum control over how your Kubernetes clusters run. You can choose whichever distribution you want, and you can configure it however you want. Your total cost of operation will also be lower than using AWS EKS, which charges for the underlying EC2 instances you consume as well as an hourly per-cluster fee.