[Kubernetes] EKS 시작

들어가며

 최근 내가 속한 조직이 분사되어 새로운 회사로 출범했다. 새 회사의 기조 중 하나가 퍼블릭 클라우드로의 '트랜스포메이션(transformation)' 인데, 이에 따라 내가 속한 팀의 신규 프로젝트 또한 AWS 기반으로 진행하게 되었다. 퍼블릭 클라우드에 새롭게 시작하는 프로젝트라니. 이 보다 쿠버네티스를 도입하기에 적절한 기회는 없다 싶어 직접 PoC(Poof Of Concept)를 준비하여 진행했고, 약간의 논쟁(?) 끝에 결국 도입이 결정되었다. 그런고로, 그간 쿠버네티스를 학습하며 작업했던 내용들을 틈틈히 블로그에 정리하고자 한다. 물론 앞으로 갈길은 매우매우 멀다. 이제 시작일 뿐..

 

개요

쿠버네티스는 이미 알만한 사람들은 다 아는 도구이다.

 

 소프트웨어를 지탱해왔던 인프라가 '온 프레미스'에서 '클라우드'로 패러다임이 변화되었고, 이러한 환경에서는 보통 다양한 장애 상황 및 오토 스케일링(auto scaling)과 같은 매커니즘으로 인해 인스턴스의 생성/제거가 잦다. 때문에 컨테이너 기술을 사용, 어플리케이션이 동작하는 환경을 경량으로 패키징한 이미지로 만들어 클라우드에 배포하게 되는데, 쿠버네티스는 이러한 컨테이너들을 오케스트레이션 해 주는 도구라고 정의할 수 있다. 이 컨테이너 오케스트레이션이 무엇이며, 본질적으로 쿠버네티스가 왜 필요한지는 여러 블로거나 유투버들이 정리해 놓은 좋은 컨텐츠들이 많으니 따로 이야기 하진 않을 것이다. (아니면 추후에 포스팅하는 것으로..)

 

쿠버네티스는 클라우드 프로바이더(GCP, Azuer, AWS 등)마다 각각의 관리형 서비스로서 제공된다. 이번 포스트에는 AWS 기반의 'EKS(Elastic Kubernetes Service)' 관련, 기본적인 설정 및 클러스터 생성까지의 내용을 다루고자 한다.

 

관리형 쿠버네티스 서비스

 쿠버네티스 클러스터의 기본 구성요소는 마스터 노드와 워커 노드이다. 마스터 노드는 핵심이라고 할 수 있는 '컨트롤 플레인(Control Plane)'을 비롯하여 API 서버, 클러스터 상태를 저장하는 etcd, 파드(Pod)를 워커 노드에 스케줄링하는 스케줄러 등의 구성요소를 가지고 있고, 워커 노드는 파드가 실행되는 노드로서, 컨테이너 런타임과 kubelet 이라는 모듈을 품고있다. 아래의 그림을 참고하자.

 

출처: https://platform9.com/wp-content/uploads/2019/05/kubernetes-constructs-concepts-architecture.jpg

 

 이러한 클러스터를 직접 구축하는 것은 쉽지 않다. 마스터 노드와 워커 노드의 각각 구성요소 설정이나 클러스터의 전체적인 네트워킹 설정이 생각외로(생각대로?) 매우 복잡하기 때문이다. 특히나 전문 데브옵스 인력이 없는 이상, 비즈니스 로직 개발에 집중할 시간도 부족한 개발자들이 이러한 작업을 하기엔 더더욱 어렵다.

 

 AWS의 관리형 쿠버네티스 서비스인 EKS를 이용하면 이러한 부담을 상당 부분 덜어준다. 간단한 커맨드라인으로 쿠버네티스 클러스터의 구성요소들의 설치와 설정이 자동으로 이루어지기 때문에, 개발자는 이미 안정적으로 만들어진 클러스터에 어플리케이션만 배포하면 된다.

 

AWS Cli 설정

 본 포스트에서는 AWS 콘솔이 아닌 커맨드 라인으로 작업할 것이므로, AWS Cli 를 설치해야한다. Mac OS 기준, 홈브루(Homebrew)를 이용해 간단히 설치 가능하다.

$ brew install awscli

 설치가 끝났으면 자격증명 설정을 해야하는데, IAM 계정의 Access Key ID 및 Secret Key ID 를 발급해 놓아야 한다. 발급 절차는 이곳을 참고 바라고, 아래와 같이 설정한다.

$ aws configure
AWS Access Key ID [****************GFND]:
AWS Secret Access Key [****************XlGN]:
Default region name [ap-northeast-2]:
Default output format [None]:

 

`eksctl` 소개 및 설치

 EKS 클러스터는 AWS 콘솔에서는 물론 AWS Cli 의  `aws eks create-cluster` 명령을 사용해서도 생성할 수 있다. 지금 소개할 `eksctl` 또한 커맨드 라인으로  EKS 클러스터를 생성해주지만, CloudFormation 스택 및 Auto Scaling Group 생성, Elastic IP 와 NAT 게이트웨이 자동 설정 등등 좀 더 고수준으로 추상화 된 도구로서 여러 개별 작업들을 자동화 해준다.

 

 다만 주의할 것은 클러스터 삭제시에도 반드시 `eksctl` 을 사용해야 한다는 것인데, 이를 지키지 않고 콘솔이나 AWS Cli 로 EKS 클러스터만 삭제하게 된다면 Elastic IP, NAT 등등이 찌꺼기 리소스로 남아 있어 나도 모르게 과금이 되어 버린다..!

 

어쨌든, 일단 `eksctl` 을 설치한다.

$ brew tap weaveworks/tap

$ brew install weaveworks/tap/eksctl

$ brew upgrade eksctl && brew link

이제 아래 명령어로 확인을 해보자

$ eksctl version
0.35.0

 

클러스터 생성

`eksctl` 을 통해 클러스터 생성 및 제어를 하기 위해선 몇가지 IAM 정책 권한이 필요하다. 내가 여러모로 헤맨 부분인데, 아래 공식 도큐먼트에 친절히 정리되어 있더라.. 

 

eksctl.io/usage/minimum-iam-policies/

 

위의 IAM 정책들을 생성 한 후, IAM 계정에 해당 정책들을 연결시켜 준다. 그리고 아래의 명령어로 클러스터를 생성해 보자.

$ eksctl create cluster \
--name eks-demo \
--region ap-northeast-2 \
--nodes 2 \
--node-type t2.medium \
--nodegroup-name eks-demo

 클러스터 이름, 리전, 노드로 구성할 EC2 인스턴스 유형 등등을 커맨드라인의 옵션으로 정의한다. 번외로 말하자면, AWS의 EC2 인스턴스 유형마다 배포 가능한 '파드'의 갯수는 한정되어 있다. 이곳을 참고하자.

 

`eksctl` 로 클러스터 생성을 시작하면, 아래와 같은 로그가 출력된다. 앞서 말했지만 EKS 클러스터와 노드 그룹에 대한 CloudFormation 스택이 자동생성되는 것을 알 수 있다.

 

클러스터 생성을 아래와 같이 콘솔에서도 확인 가능하다.

 

`kubectl` 설치 및 EKS 클러스터와 연동

 클러스터를 제어하기 위해서는 쿠버네티스 API 서버와 통신하는 클라이언트 프로그램이 필요한데, 그것이 `kubectl` 이다. 이 또한 어렵지 않게 설치 할 수 있다. 다른 OS에서의 좀더 자세한 설치 과정은 이곳을 참고하자.

brew install kubectl

설치 확인은 아래와 같이 한다.

$ kubectl version --short
Client Version: v1.19.3

이제 방금 전 생성한 EKS 클러스터와 연동을 해보자.

$ aws eks update-kubeconfig --name eks-demo
Added new context arn:aws:eks:ap-northeast-2:<계정 ID>:cluster/eks-demo to /Users/asuraiv/.kube/config

`.kube` 디렉토리 아래에 config 파일이 생성되는데, 이 파일은 `kubectl` 의 설정파일이라고 할 수 있으며 EKS 클러스터의 메타 정보와 인증용 서명 데이터를 포함하고 있다. 이제 노드 정보를 가져와 EKS 클러스터와 제대로 연동이 되었는지 확인한다.

$ kubectl get nodes

 

마치며

 간단하게(?) 여러 요구되는 프로그램과 EKS 클러스터 설치 및 연동까지 해봤다. 이제 어플리케이션을 배포할 클러스터 준비가 끝난 것이다. 지금 만들어진 클러스터에 앞으로 이것저것 실험해보며 그 내용을 정리하려 한다. 오늘은 여기까지..