How to provision a Kubernetes Cluster on AWS EKS with Terraform

This will show how to provision a Kubernetes cluster on AWS EKS with Terraform.

AWS EKS cluster

I also referred to this document extensively because HashiCorp provides an EKS cluster provisioning guide .

First, configure the Terraform provider.

 1terraform {
 2  required_providers {
 3    aws = {
 4      source  = "hashicorp/aws"
 5      version = ">= 4.23.0"
 6    }
 7  }
 8  required_version = ">= 1.0"
 9
10  backend "remote" {} // Terraform cloud 설정 생략
11}
12
13provider "aws" {
14  region = "ap-northeast-2"
15}

Since we need to use AWS, we configure the hashicorp/aws provider . Terraform v1.2.2 was used for testing.

terraform-aws-modules/eks/aws module

Although Kubernetes configuration is quite complex, the terraform-aws-modules/eks/aws module allows you to provision a cluster on AWS EKS relatively simply. Of course, the module itself is complex, so you will need to do a lot of testing to launch it with your desired configuration, but referring to the necessary settings in the examples can also be helpful.

Here, we create a cluster with only simple basic settings.

1module "eks_playground" {
2  source  = "terraform-aws-modules/eks/aws"
3  version = "18.26.6"
4}

I configured the EKS module to be used for testing.

1module "eks_playground" {
2  source  = "terraform-aws-modules/eks/aws"
3  version = "18.26.6"
4
5  cluster_name    = "playground"
6  cluster_version = "1.22"
7  vpc_id          = data.terraform_remote_state.YOUR_VPC.outputs.playground_id
8  subnet_ids      = data.terraform_remote_state.YOUR_VPC.outputs.playground_private_subnets

I specified a cluster name and used version 1.22, the latest version currently supported by EKS. The current latest version of Kubernetes is 1.24. Since VPC and subnets are beyond the scope of this article, I pulled pre-existing VPC and subnet information terraform_remote_stateas data and specified them. I also assigned a private subnet instead of a public one to the worker nodes to prevent external access.

 1module "eks_playground" {
 2  source  = "terraform-aws-modules/eks/aws"
 3  version = "18.26.6"
 4
 5  cluster_name    = local.name
 6  cluster_version = "1.22"
 7  vpc_id          = data.terraform_remote_state.apne2_vpc.outputs.playground_id
 8  subnet_ids      = data.terraform_remote_state.apne2_vpc.outputs.playground_private_subnets
 9
10  eks_managed_node_groups = {
11    default_node_group = {
12      min_size     = 2
13      max_size     = 3
14      desired_size = 2
15      instance_types = ["m6i.large"]
16    }
17  }
18
19  tags = {
20    Environment = "dev"
21  }
22}

I have now eks_managed_node_groupsspecified the default node group. Since this is for testing purposes, I only launched two nodes, and because I expect to experiment with additional node groups later as I study (though I wonder if I will...), I have only specified the default node group for now.

If you run it with this setting, terraform applyquite a lot of resources will be generated and the application will be completed.

If you go to the AWS console, playgroundyou can see that an EKS cluster has been created with the name.

Accessing a cluster with kubectl

kubectlTo check the connection, you need to configure kubeconfig . In AWS EKS, you can easily update it using the aws CLI.

1$ aws eks --region ap-northeast-2 update-kubeconfig --name playground --kubeconfig ~/.kube/playground
2Added new context arn:aws:eks:ap-northeast-2:252807701206:cluster/playground to /Users/outsider/.kube/playground

--regionYou just need to specify the region and --namethe cluster name. If you use it as is, a default value ~/.kube/configis generated, but to manage multiple clusters, you can explicitly specify the region --kubeconfigusing a flag , and you can also specify environment variables like this to read the desired kubeconfig.~/.kube/playgroundexport KUBECONFIG=$HOME/.kube/playgroundKUBECONFIG

Now, let’s check if we can access the cluster properly kubectl.

1$ kubectl get node
2NAME                                             STATUS   ROLES    AGE   VERSION
3ip-10-128-1-46.ap-northeast-2.compute.internal   Ready    <none>   46h   v1.22.9-eks-810597c
4ip-10-128-3-97.ap-northeast-2.compute.internal   Ready    <none>   46h   v1.22.9-eks-810597c

You can see that the two nodes specified above are floating well.

Since no additional accounts were registered to the cluster here, kubectlthe AWS account using it must be the AWS account that created the cluster (in this case, terraform applythe account that ran it). If you open the file aws ekscreated with the command above kubeconfig, you will find a section that executes commands for user authentication when accessing the cluster, as shown below.

 1users:
 2- name: arn:aws:eks:ap-northeast-2:252807701206:cluster/playground
 3  user:
 4    exec:
 5      apiVersion: client.authentication.k8s.io/v1beta1
 6      args:
 7      - --region
 8      - ap-northeast-2
 9      - eks
10      - get-token
11      - --cluster-name
12      - playground
13      command: aws
14      env:
15      - name: AWS_PROFILE
16        value: YOUR_ACCOUNT

As you can see above , the AWS account configured locally as an environment variable is specified aws --region ap-northeast-2 eks get-token --cluster-name playgroundwhen executing the command for user authentication . This means that this account must be the same as the account that created the cluster. Even if the accounts are different , while you may be able to create it if you have the necessary permissions , an error will occur when using it .AWS_PROFILEkubeconfigkubectlerror: You must be logged in to the server (Unauthorized)