카카오스타일 EKS 시리즈의 마지막 편으로, 앞선 글에서 손으로 만들던 클러스터를 잘 만들어진 Terraform 모듈로 빠르게 구성하는 방법을 다룬다. VPC 와 EKS 모듈에 더해 AWS Load Balancer Controller 설치까지 Terraform 으로 옮겼고, 그 과정에서 만난 CoreDNS 멈춤 같은 문제도 함께 적는다.
핵심 포인트- 모듈은 편하지만 내부 개념을 모른 채 쓰면 문제가 생겼을 때 해결이 어렵다는 점을 먼저 짚는다.
- terraform-aws-modules 의 VPC 모듈로 이전에 길게 쓰던 구성을 짧게 대체한다. 구조는 같지만 NAT 게이트웨이가 가용영역별로 따로 존재한다.
- 서브넷 태깅이 중요하다. 클러스터 이름 태그와 elb, internal-elb role 태그를 각각 퍼블릭과 프라이빗 서브넷에 붙여야 한다.
- Fargate 만 있는 상태에서는 coredns 모듈 생성이 멈춘다. kubectl patch 로 compute-type 어노테이션을 제거해 풀어야 한다.
- AWS Load Balancer Controller 는 관련 모듈이 여럿 있으나 미묘하게 동작하지 않아, 쉘에서 실행하던 명령을 Terraform 으로 직접 옮겨 구현했다.
상세 정리- EKS 모듈에서는 클러스터 엔드포인트의 프라이빗과 퍼블릭 접근 여부, CloudWatch 로그 보관 기간 같은 옵션을 지정한다.
- Load Balancer Controller 구성은 IRSA 부터 시작한다. iam-assumable-role-with-oidc 모듈로 OIDC 기반 역할을 만들고 서비스 어카운트를 subject 로 지정한다.
- 정책은 kubernetes-sigs 저장소의 iam_policy.json 을 http 데이터 소스로 받아와 그대로 역할 정책에 붙인다.
- 설치는 helm_release 로 aws-load-balancer-controller 차트를 kube-system 네임스페이스에 배포하고, 서비스 어카운트 이름과 리전 ECR 이미지 저장소, 역할 arn 어노테이션을 set 으로 넘긴다.
- 예제를 단순하게 하려고 쿠버네티스에서 도는 애플리케이션까지 Terraform 으로 구성했다. echoserver Deployment 와 Service, ALB Ingress 를 kubernetes provider 리소스로 정의한다.
- Ingress 어노테이션에는 scheme 과 target-type 을 지정한다. 생성 후 kubectl 로 hostname 을 뽑아 요청을 보내면 응답이 온다.
- 같은 Terraform 파일 안에 정의했기 때문에 EKS 모듈의 출력을 provider 설정에 그대로 썼다. 별도 스택으로 나누고 kubeconfig 가 설정돼 있다면 provider 를 다르게 구성할 수 있다.
- 저자는 시리즈를 쓰며 클러스터 생성을 여러 번 반복했고 매번 하나씩 빠뜨려 문제를 찾는 데 오래 걸렸다고 말한다. 잘 구성된 모듈이 확실히 편했지만, 각 단계를 직접 해봐서 이해가 된 상태였기에 모듈 활용도 가능했다고 본다.
- Terraform 으로 인프라를 통일하는 것은 좋지만 쿠버네티스는 별개의 정의 스펙이 있어 애매한 지점이 있고, 실서비스에서는 Terraform 이 아닌 다른 방식을 쓰고 있다고 덧붙인다.
왜 읽나EKS 를 손으로 몇 번 만들어보고 이제 코드로 굳히려는 인프라 담당자에게, 모듈 조합과 직접 구현이 필요한 지점을 갈라 보여주는 마무리 편.
카카오 스타일 (지그재그)·
AWS Korea Tech·
GitLab Blog·