Terraform으로 EKS 배포하기 4. EKS 클러스터 셋업

쿠버네티스를 사용하기 위해 바닐라 쿠버네티스를 설치하면, 컨트롤 플레인에 설정해야하는 오픈소스와 정책들이 많다.

 

결정해야하는게 많다는 것은 좋게보면 높은 자유도를 제공하는거지만, 나쁘게 보면 사용 허들이 높다.

 

그래서 여러 클라우드 벤더들은 컨트롤 플레인에서 결정해야하는 것들을 베스트 프랙티스로 제공해주는데, 이러한 제품들을 매니지드(Managed) 쿠버네티스라고 한다.

 

당연히 AWS에서도 매니지드 쿠버네티스 제품을 제공하는데, 이 제품이 Amazon Elastic Kubernetes Service(Amazon EKS)다. 

 

EKS 구성도

 

EKS 클러스터란?

Amazon EKS 클러스터에는 두 가지 기본 구성 요소가 있습니다.
1. Amazon EKS 제어 영역
2. 제어 영역에 등록된 Amazon EKS 노드
Amazon EKS 컨트롤 플레인에는 etcd 및 Kubernetes API 서버와 같은 Kubernetes 소프트웨어를 실행하는 컨트롤 플레인 노드가 포함되어 있습니다. 컨트롤 플레인은 AWS에서 관리하는 계정에서 실행되며, Kubernetes API는 클러스터와 연결된 Amazon EKS 엔드포인트를 통해 노출됩니다. 각 Amazon EKS 클러스터 제어 영역은 단일 테넌트이고 고유하며 자체 Amazon EC2 인스턴스 집합에서 실행합니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/clusters.html

 

여기서 표현한 제어 영역이 컨트롤 플레인이다. AWS가 그냥 직역해서 컨트롤 플레인이 제어 영역으로 번역되서 더 어렵게 느껴진다.

 

결국 EKS 클러스터는 컨트롤 플레인과 컨트롤 플레인에 연결된 AWS 리소스들로 구성되고, 둘은 반드시 한 쌍으로만 존재한다는 것이다.

 

가이드 문서보다 다른 공식 문서가 클러스터에 대해 더 잘 정리하고 있는 것 같다.

https://aws.amazon.com/ko/what-is/kubernetes-cluster/

 

EKS 클러스터 Terraform 구현

EKS 클러스터를 정의하기 위해 모든 리소스를 Terraform으로 만들어나간다면 너무 많은 양의 코드가 필요하다.

(다행히 카카오 스타일에서 EKS 클러스터 생성을 위해 필요한 리소스들을 정리한 자료가 있다.)

 

모듈도 적은 양은 아닌데, 일단 클러스터 생성을 위한 모듈을 정리해봤다.

 

대부분의 설정은 https://devblog.kakaostyle.com/ko/2022-03-31-3-build-eks-cluster-with-terraform/ 여기서 가져왔다.

 

eks module : https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest

locals {
  vpc_id          = data.terraform_remote_state.vpc.outputs.vpc_id
  private_subnets = data.terraform_remote_state.vpc.outputs.private_subnets
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name                   = "sample-eks"
  cluster_version                = "1.29"
  cluster_endpoint_private_access = false
  cluster_endpoint_public_access  = true

  # EKS 애드온
  cluster_addons = {
    coredns = {
      resolve_conflicts = "OVERWRITE"
    }
    kube-proxy = {}
    vpc-cni = {
      resolve_conflicts = "OVERWRITE"
    }
  }

  # vpc 설정
  vpc_id                   = local.vpc_id
  subnet_ids               = local.private_subnets
  control_plane_subnet_ids = local.private_subnets

  # Fargate
  fargate_profiles = {
    default = {
      name = "default"
      selectors = [
        {
          namespace = "kube-system"
        },
        {
          namespace = "default"
        }
      ]
    }
  }

  tags = {
    "karpenter.sh/discovery" = "sample-eks"
  }
}

 

2024.5.4 현재 AWS EKS 클러스터의 의 최신버전은 1.29 다.

 

하위 버전을 설치하면 업데이트하라고 알림이 온다.

 

그리고 예제로 사용하기 위해서 클러스터의 public access를 true로 뒀다.

 

추가 기능(add-on)은 따로 다룰 예정이니 skip. 설정한 세 가지는 별도의 설정이 없어도 자동으로 설치된다.

 

마지막으론 faragte_profile인데, EKS에서 노드를 어떻게 운영할 것인가를 정의한다.

 

노드를 정의하는 방식은 아래 그림과 같이 두 가지 방법이 있다.

 

 

Fargate를 사용하면, 자동으로 OS 업데이트도 해주고, 스케줄링도 해주고, 스케일링까지 지원해준다. 

 

EC2를 이용하면 더 세분화된 설정과 가격 측정에 용이하지만 손이 너무 많이 간다는 단점이 있다고 한다.

 

정리하면, Fargate를 사용하는 이유는 관리포인트가 적어지기 때문인데,

 

faragte_profile로 네임스페이스를 지정하고 자동으로 필요한 컴퓨팅 리소스를 할당하고 관리하도록 한다.

---

 

현재는 컨트롤 플레인 영역만 설정해주고 노드 그룹에 대한 설정이 없어서 컴퓨팅 영역에 아무것도 나타나지 않는다.

 

노드를 셋업하고, 외부 인터넷망과 연동하려면 로드 밸런서와 노드 오토스케일러가 필요하다.

 

둘 중에 오토 스케일러에 대해 먼저 알아보고 Karpenter로 설정하고 구성할 예정이다.

 

그 전에 추가 기능과 권한에 대해 짚고 넘어가려고 한다.

 

마치며

전까지는 AWS의 네트워크 영역과 Terraform으로 AWS 리소스를 가져오는 방법에 대해서 정리했었다.

 

이번 포스팅부터 본격적으로 쿠버네티스의 영역이 나오면서 조금씩 어려워지는데,

 

나도 하나씩 알아보면서 작성하는 거라 부족한 게 참 많다.

 

그래도 상용 어플리케이션을 배포하고 Grafana, argoCD, istio와 같은 CNCF 어플리케이션까지 배포하고 사용해보는 것까지 가보는 게 목표다.