AWS EKS를 활용해 서버 배포하기

지금까지의 쿠버네티스 핵심 개념은 다 배웠다. AWS EKS라고 크게 다를 건 없다. 셋팅법만 익히면 나머지는 다 똑같다.

셋팅 시 모든 옵션을 다 알 필요가 없다. 딱 필요하고 중요한 부분에 대해서만 알고 있으면 된다

---

EKS(Elastic Kubernetes Service)란? 

EKS란 AWS가 쿠버네티스 마스터 노드를 대신 관리해주어 사용자가 복잡한 설치나 관리에 신경 쓰지 않고 쉽게 쿠버네티스를 사용할 수 있도록 돕는 서비스

AWS에서 쿠버네티스를 편하게 관리하고 사용할 수 있게 만든 AWS용 쿠버네티스이다.

 

쿠버네티스를 직접 설치해서 관리하는 게 생각보다 손이 많이 가서,

현업에서는 쿠버네티스를 EC2와 같은 서버에 직접 설치해서 쓰지 않고 AWS에서 제공하는 EKS를 활용하는 경우가 많다.

 

쿠버네티스와 EKS의 아키텍처 구조

쿠버네티스의 복잡한 아키텍처 구조

쿠버네티스를 입문하는 입장에서 위와 같은 복잡한 아키텍처 구조를 전부 이해할 필요는 없다. 몰라도 쓸 수 있다.

하지만 EKS를 다룰 때 아키텍처에서 기본적인 부분을 알아야 할 필요가 있어서,

입문자 입장에서 알면 되는 부분만 간단화시켜서 살펴보자.

간단하게 표현한 쿠버네티스 아키텍처 구조

마스터 노드가 요청을 받아 워커 노드에게 파드 n개 생성해!라고 명령한다고 이해하면 된다.

• 쿠버네티스 클러스터 : 하나의 마스터 노드와 여러 워커 노드들을 한 묶음으로 부르는 단위
  docker desktop도 일종의 k8s 클러스터이다.
• 마스터 노드 : 쿠버네티스 클러스터 전체를 관리하는 서버 (쿠버네티스의 핵심 제어 영역)
  
• 워커 노드 : 쿠버네티스의 파드를 실행시키는 서버
  
  

EKS를 활용해 구성할 아키텍처 구조

로드밸런서를 통해 서비스에 요청을 전달하도록 구성할 것이다.

 

---

EKS 셋팅

1. EKS 클러스터 생성하기

• AWS EKS에 접속해서 클러스터 생성을 누르고, IAM 역할 생성하고 적용하면 된다.
• 구성은 대체로 기본값으로 했는데, 세세한 내용은 EKS에 익숙해지면 알아보자.
• 클러스터를 생성하면 마스터 노드까지는 생성된다.
  EKS 사용의 주요 이점 중 하나는,
  AWS가 마스터 노드를 완전히 관리하여 사용자는 애플리케이션 배포와 워커 노드 관리에 집중할 수 있다는 점이다.

 

2. EKS 워커 노드 생성하기

EKS 클러스터를 생성한 후, 애플리케이션 컨테이너(Pod)가 실행될 환경 제공하기 위해 워커 노드 그룹을 추가해야 한다.

• 생성한 EKS 클러스터에 들어가서 컴퓨팅 메뉴에서 노드를 생성한다.
• 권한 역할을 생성한 후 부여하고, 기본 셋팅 값으로 생성한다.
• 노드 생성 후 EC2 인스턴스 페이지에 들어가면 새로운 EC2 인스턴스 2개가 생성되어 있는 걸 확인할 수 있다.
  EKS 클러스터에서 하나의 워커 노드(Worker Node)가 하나의 EC2 인스턴스에서 실행되는 구조이기 때문이다.

---

로컬에서 EKS 클러스터 조정할 수 있게 셋팅하기

kubectl은 Kubernetes 클러스터와 통신하고 오브젝트를 배포, 관리하는 표준 명령줄 도구이다.
EKS 클러스터에도 동일하게 사용된다.

그런데 EC에 k3s를 설치해 사용했을 땐 kubectl 명령어를 EC2에 접속해서 수행할 수 있었지만, EKS 내부로는 진입이 불가능하다.

따라서 로컬에서 kubectl 명령어를 EKS로 보낼 수 있도록 셋팅해보자.

 

1. 현재 kubectl이 어떤 클러스터 환경에서 작동되고 있는 지 확인하기

$ kubectl config get-contexts

2. kubectl에 EKS 클러스터 추가하기

# aws eks --rgeion ap-northeast-2 update-kubeconfig --name <EKS 클러스터 이름>
$ aws eks --region ap-northeast-2 update-kubeconfig --name kube-practice

3. 잘 적용됐는 지 확인하기

$ kubectl config get-contexts

Current 항목에 * 가 붙은 것이 현재 작동하는 클러스터 환경이다.

[참고]

# 다른 클러스터로 전환
$ kubectl config use-context <컨텍스트 이름>

# 특정 컨텍스트 삭제
$ kubectl config unset contexts.<컨텍스트 이름>

---

EKS에 백엔드(Spring Boot) 서버 배포하기 (+ RDS, ECR)

이제 로컬에서 명령어를 보내면 EKS에 반영돼 수행된다.

따라서 로컬에서 deployment.yaml, service.yaml, config.yaml, secret.yaml을 수정하고 실행시켜보자.

• config.yaml, secret.yaml에는 RDS의 주소와 아이디, 패스워드 등을 입력하면 된다.
• deployment.yaml에는 이미지를 다운받을 ECR 주소와 버전을 기입하자.
• Service.yaml에는, 서비스의 종류를 LoadBalancer로 변경해주자.

Service 타입을 LoadBalancer로 지정하면, AWS 클라우드 제공자는 해당 Service에 자동으로 연결되는 ELB(Application 또는 Network Load Balancer)를 프로비저닝해준다.

• NodePort : 쿠버네티스 내부에서 해당 서비스에 접속하기 위한 포트를 열고 외부에서 접속 가능하도록 한다.
                          ⇒ 들어오는 요청을 여러 Worker Node로 트래픽을 분산시키지 않는다. (파드로 LB은 하지만)
• ClusterIP : 쿠버네티스 내부에서만 통신할 수 있는 IP 주소를 부여. 외부에서는 요청할 수 없다.
• LoadBalancer : 외부의 로드밸런서(AWS의 로드밸런서 등)를 활용해 외부에서 접속할 수 있도록 연결한다.
                          ⇒ 들어오는 요청을 여러 Worker Node로 트래픽을 분산시켜준다.

 

서비스를 실행하면, 외부에서 접속할 수 있는 external-ip가 LB 주소로 나타남을 확인할 수 있다.

그리고 AWS에 LB에 들어가보면 실제로 LB가 생성되어 있으며, 해당 주소로 배포된 웹사이트에 접속이 가능하다!

Service 의 Type 을 LoadBalancer 로 했더니 외부에서 접속할 수 있는 주소가 주어졌다.

 

아키텍처를 다시 한번 짚어보자.

---

참고 자료 & 이미지 출처
비전공자도 이해할 수 있는 쿠버네티스 입문/실전