AWS EKS 클러스터 구성 및 배포하기 [1/2]

AWS EKS?

EKS는 Elastic Kubernetes Service의 준말로, k8s 클러스터를 AWS에서 fully managed 해주는 서비스이다.

 

k8s 클러스터를 구축하는 방법에는 크게 3가지가 있다.

 

1. On-Premise 환경
2. 클라우드 플랫폼
3. 클라우드 Managed 서비스

On-Premise 환경에 가까워질수록 클라우드의 의존성은 감소하지만, 관리의 복잡함이 늘어난다.

 

AWS EKS 3번 환경에 속하며 클라우드의 의존성은 증가하지만, 관리가 매우 쉬워진다!

 

소마에 들어오기 전에, On-Premise환경에 k8s 클러스터 구축 경험을 쌓고자 하는 욕심이 있었지만

 

소마 프로젝트를 진행하면서, 팀별 AWS 지원비도 나올뿐더러 팀원이 3명밖에 안되기에 

 

현실적으로 On-Premise 환경에 k8s 클러스터 구축을 하기는 어렵다고 판단했다.

 

그래서 AWS EKS를 선택했다.

 

EKS에 대한 설명은 다른 포스트에서 자세하게 다루기로 하고,

 

이 포스트는 EKS 클러스터를 생성하면서 겪었던 문제점이나 어려웠던 점을 정리하려 한다.

 

참고로 예시로 나오는 화면은 이미 클러스터가 생성된 화면이니

 

이 글을 보고 EKS를 처음부터 구축하려는 분들은 적절히 감안하고 봐주길 바란다.

 

무작정 EKS 클러스터 생성

클러스터를 생성하기 전에, 나의 k8s 지식은 그저 minikube를 통해 Deployment를 생성해본게 전부였다.

 

Google Cloud Jam을 통해 GCP 상에서도 managed 서비스인 GKE를 조금 다뤄 본 경험이 있지만 

 

EKS는 처음이어서 어떻게 시작해야할지 몰랐다.

 

그래서 부딪혀보기로 했다.

 

EKS 콘솔에 접근하면 나오는 화면

지금은 성공적으로 EKS 클러스터를 생성하고 배포까지 끝난 상태지만, 클러스터의 이름은 멘붕상태 였던 나를 보여준다...

 

여튼 클러스터 추가 버튼을 누르면 생성과 등록이 나온다.

 

등록 버튼을 누르면 나오는 화면

 

호기심에 등록 버튼을 눌러보니 다음과 같이 공급자를 선택하라는 화면을 볼 수 있었다.

 

기존에 구축된 k8s 클러스터를 EKS가 Manage 할 수 있게 등록하라는 것이었다.(타사 서비스인 GKE, AKS가 보인다)

 

나는 가지고 있는 k8s 클러스터가 없으니 생성을 눌렀다.

 

생성 버튼을 누르면 나오는 화면

 

EKS를 처음 써본다면 클러스터 서비스 역할이 비어있을 것이다.

 

비어있길래 일단 무시하고 다음 단계로 넘어가려 하니 진행이 되지 않았다.

IAM

첫번째로 부딪힌 곳이다.

 

클러스터 서비스 역할에 적힌 설명을 읽다보면 k8s Control Plane이 우리를 대신하여

 

AWS 리소스를 관리하도록 IAM 역할을 선택하라는 문구를 볼 수 있다.

 

내가 아는 IAM 관련 지식은 '우리가 보통 쓰는 AWS 계정은 모든 리소스를 건들 수 있는 root 계정인데

 

하나의 AWS 계정으로 여러 사용자가 쓸 수 있으니 IAM을 통해 사용자별로 권한을 다르게 설정한다' 가 전부였다.

 

이 지식을 바탕으로 이해해보면 EKS는 AWS의 서비스이고, 우리를 대신해 클러스터를 Manage 하려는 직원이 된다.

 

직원은 Manage를 하면서 AWS 리소스를 건들기 때문에 직원이 쓰려는 IAM 계정을 만들어준다고 생각하면 된다.

 

새 역할을 생성하려면 눌러보라하니 눌러보았다.

 

EKS를 위한 IAM Role을 생성하는 방법이 나와있다.

 

IAM 생성 콘솔에 들어가서 Role을 만들던 중에 문득 궁금해졌다.

 

얘는 무슨 권한을 가지고 있을까?

 

위의 AWS가 올린 예시에서도 permission tab 에서 별다른 설정을 하지 않고 넘어가라 되어있다.

 

자동으로 권한이 추가되어 있다.

 

궁금하니까 들어가보자

 

 

요약을 보면 우리를 대신하여 EC2 인스턴스 생성부터 Security Group, ENI등을 생성할 수 있는 권한이라고 되어있다.

 

실제 권한을 보면 Auto Scaling, ELB등이 있다.

 

ELB는 포스트 후반에서 다시 등장하니 잘 봐두자.

 

이렇게 IAM은 해결이 됐으니 2단계로 넘어가보자.

 

VPC? Subnet?

 

2차 난관에 봉착했다.

 

VPC와 Subnet, Region, AZ

부끄러운 얘기지만 그간 AWS를 써오면서 VPC, Subnet등 네트워크 요소들을 크게 신경쓰지 않고 사용했었다.

 

학부 컴퓨터네트워크 시간때 배운 지식으로 그냥 뭐 이런 느낌이겠지~~~ 하고 넘겨왔었다.

 

하지만 AWS EKS에 대해 제대로 이해하고 어떤 네트워크 환경에서 클러스터를 구성해주는지 알고 싶었다.

 

이에 대한 자세한 내용은 또 다른 포스트에서 다루기로 하자. 네트워크 지식은 알면 알수록 어렵다 ㅠㅠ

 

아래 포스트를 확인해보자!

 

https://imsongkk.tistory.com/68

[AW] VPC, Subnet 정리

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/creating-a-vpc.html

Amazon EKS 클러스터에 대해 VPC 생성 - Amazon EKS

 

AWS 공식 문서를 읽어보면 EKS 클러스터를 구축할 때 Public과 Private Subnet을 구분하는것이 좋다고 한다.

 

Private Subnet에는 EKS 클러스터를 구축하는 실제 노드들이 배치되고

 

Public Subnet에는 노드들에게 트래픽을 전달할 로드 밸런서가 존재하며

 

노드들로부터 받은 트래픽을 Internet Gateway로 전달할 Nat Gateway가 존재한다.

 

최종적으로 우리가 구축해야 하는 형태는 다음과 같다.

 

소마 프로젝트에 사용할 백엔드 아키텍쳐중 일부

 

RDS Component는 무시해도 된다.

 

VPC와 Subnet 생성하기

기존에 우리가 쓰던 VPC는 172.31.0.0/16 의 cidr 블록을 가지고 있으며 4개의 public subnet을 가지고 있다.

 

따라서 EKS 클러스터만을 위한 VPC를 새로 생성해보자.

 

VPC 등이 선택된 화면

우리는 VPC 뿐만 아니라 Subnet, AZ, Nat Gateway까지 생성해야 하므로 VPC 등을 선택해준다.

 

넉넉하게 2^16개의 IP를 VPC에 할당하고, 이름을 test로 바꿔준다.

 

오른쪽 미리 보기 화면에서 해당 VPC의 내부 설정과 라우팅 경로를 살펴볼 수 있다.

 

 

아래로 내리면 AZ와 서브넷, Nat Gateway를 선택할 수 있다.

 

AZ의 설명을 보면 고가용성(HA)를 위해 최소 2개 이상의 Multi-AZ를 선택하라고 되어있다.

 

ap-northeast-2a, ap-northeast-2b 총 2개의 AZ가 할당되고 각 AZ 마다 Public, Private Subnet을 가지고 있는것을 볼 수 있다.

 

Nat Gateway($)를 선택하지 않음

EKS는 비쌀거라는 걱정이 있었다. 단순히 생각해도 4대의 노드로 클러스터를 구축한다면 EC2를 4대나 생성하는것과 똑같다.

 

게다가 사양도 프리티어 수준이 아닌 적어도 t3.medium이 되어야 하니 더 비쌀것이다.

 

저 $라는 표현을 본 순간 나도 모르게 없음에 체크해버렸다... 요금이 부과된다는 말이 무서웠다.

 

결론부터 말하면 우리는 EKS 클러스터 노드들을 Private Subnet에 배치하므로 무조건 AZ 마다 Nat Gateway가 있어야 한다.

 

Nat Gateway가 없으면..?

Nat Gateway가 없으면 Private Subnet은 Internet Gateway까지 도달하지 못한다.

 

꼭 체크하고 넘어가자.

 

VPC 엔드포인트

없음 이든 S3 게이트웨이든 어떤것을 선택해도 크게 상관없다.

 

서로 다른 VPC들끼리 통신을 하려면 Internet Gateway를 타고 넘어가야 한다. 

 

우리가 평소 사용하는 S3도 분명 어느 VPC에 속해있을 것이다.

 

우리는 우리만의 VPC를 따로 구축했으며, 이 VPC와는 다르다.

 

S3는 AWS가 자체적으로 Manage 하는 VPC에 속해있다.

 

VPC 엔드포인트는 IG를 타지 않고 다른 VPC와 통신할 수 있도록 해주어 비용을 절감시켜준다.

 

만약 S3 게이트웨이를 선택하고 VPC를 생성하면 다음과 같은 라우팅 테이블을 확인할 수 있다.

 

 

private subnet중 하나에 적용된 라우팅 테이블이며, 라우팅 대상을 보면

 

10.0.0.0/16은 local로, 0.0.0.0/0은 Nat Gateway, pl-78a~라고 되어있는것은 또 다른 VPC Endpoint를 가리키고 있다.

 

 네트워킹 지정

네트워킹 지정을 위한 사전 준비가 끝났다.

 

다시 돌아와서 마저 끝내도록 하자.

 

 

미리 구성한 VPC를 선택하고, Private Subnet에만 클러스터 노드를 배치할것이므로 2개의 Private Subnet만 고른다.

 

클러스터 엔드포인트 엑세스

얘는 또 무엇인가

 

3차 난관에 봉착했다. 설명을 자세히 읽어보자.

 

k8s api server 엔드포인트? api server는 컨트롤 플레인에 있는거 아닌가?

 

아하 컨트롤 플레인에 접근하기 위한 방식을 설정하는거구나!

 

근데 컨트롤 플레인이 어디에 있을까?

 

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

Amazon EKS clusters - Amazon EKS

 

공식 문서를 읽다보면

 

The control plane runs in an account managed by AWS, and the Kubernetes API is exposed via the Amazon EKS endpoint associated with your cluster.

 

라는 문구를 볼 수 있다.

 

Control Plane은 우리가 생성하는게 아닌 AWS에서 자체적으로 관리해준다고 한다.

 

Control Plane은 k8s 클러스터에서 핵심적인 역할로 etcd, scheduler, kube-apiserver 등을 가지고 있다.

 

클러스터 엔드포인트를 어디에 위치시키냐에 따라 API Server에 접근할 수 있는 위치가 달라진다.

 

보다 자세한 설명은 아래 공식 문서를 참고하자.

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cluster-endpoint.html

Amazon EKS 클러스터 엔드포인트 액세스 제어 - Amazon EKS

 

나는 퍼블릭 및 프라이빗으로 설정해 두어 VPC 외부에서 kubectl로도 접근할 수 있고

 

VPC 내부에서도 접근할 수 있게 했다.

 

로깅

이제 3단계인 로깅에 도달했다.

 

 

로그도 다 돈이다. CloudWatch에 쌓이면 과금이 되니 일단은 다 꺼놓고 진행했다.

 

이하 4,5,6 단계는 기본 설정을 그대로 두었다.

 

클러스터 생성까지는 대략 10~15분 정도 걸리는것 같다.

 

생각보다 오래걸려서 이것저것 실험하기 힘들었다.

 

클러스터 생성 완료

클러스터가 활성화 되면 네트워킹 탭을 확인해보자.

 

우리가 설정한 VPC, Subnet, SG가 제대로 할당되어 있는것을 확인할 수 있다.

 

노드 그룹 생성하기

이제 클러스터는 생성됐으니, 실제 EC2 노드들을 생성할 차례이다.

 

EKS는 노드들을 노드 그룹이라는 단위로 관리한다.

 

컴퓨팅 탭을 눌러보자.

 

 

이미 노드 그룹을 만들어서 노드가 생성이 됐지만 아무것도 없다 치고 노드 그룹 추가를 해보자.

 

 

또 다시 IAM이 등장했다. 얘는 무슨 역할을 해야할까?

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/create-node-role.html

Amazon EKS 노드 IAM 역할 - Amazon EKS

 

공식 문서에 따르면 노드에 있는 kubelet 데몬은 우리를 대신하여 AWS API를 호출한다고 한다.

 

IAM

 

노드 그룹의 IAM을 만들 때 다음과 같이 3개의 권한을 추가해준다.

 

노드에서 ECR에 접근할 수 있는 Policy

 

컨테이너간의 네트워킹을 제어하는 CNI Policy

 

EKS 클러스터에 접근할 수 있는 Policy를 추가해준다.

 

노드 사양

생성할 노드들의 AMI와 사양 및 스토리지, 오토스케일링 Factor 를 구성할 수 있다.

 

Subnet

 

우리는 미리 구성해둔 Private Subnet에 노드들을 배치할것이므로 private subnet만 골라준다.

 

이렇게 하면 노드 그룹까지 생성이 끝난다.

 

이것도 10~15분정도 걸리니 인내심을 가지고 기다리자.

 

노드가 생성된 모습

 

다음 포스팅에서는 이번에 생성한 클러스터를 배포하는 방법에 대해 다뤄보겠다.

 

https://imsongkk.tistory.com/60

AWS EKS 클러스터 구성 및 배포하기 [2/2]