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

지난 포스팅 요약

https://imsongkk.tistory.com/59

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

 

우리는 VPC, Subnet, Nat Gateway, Routing Table, Internet Gateway를 만들고

 

EKS IAM, Node Group IAM을 생성했다.

 

그리고 클러스터 엔드포인트를 퍼블릭 및 프라이빗으로 설정해 VPC 내외부에서 접근가능하도록 만들었다.

 

클러스터도 만들고 노드도 만들었으니 실제 노드에 파드를 띄워보고 웹상에 배포해보자.

 

클러스터 관리

본격적으로 배포를 해보기 전에, 클러스터 관리 방법에 대해 알아보자.

 

이전 포스팅에서는 AWS Console 화면을 통해 클러스터를 생성하고 관리했다.

 

클라우드 생태계에서는 이렇게 다양한 리소스에 대해 관리해주고 할당해주는것을 프로비저닝이라 한다.

 

프로비저닝을 하는 방법은 우리가 사용한 방법말고도 여러가지가 있다.

 

1. AWS Console(우리가 사용한 방법)
2. eksctl
3. Terraform 과 같은 IaaC

이번 포스팅에서는 eksctl을 사용해 클러스터를 배포하려 한다.

 

사실 Terraform으로 하는것이 클러스터 관리, 팀원간 지식 공유에도 좋을것 같아 시도하려 했으나

 

Terraform에 대한 지식이 부족함으로 나중에 도전과제로 남겨두려한다.

 

eksctl

eksctl은 EKS 클러스터를 프로비저닝할 수 있는 CLI 툴이다.

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/getting-started-eksctl.html

Amazon EKS 시작하기 - eksctl - Amazon EKS

Console에서 우리가 수동으로 했던 작업들을 명령어로 수행할 수 있게 해준다.

 

Weaveworks 라는 곳에서 만든 오픈소스이다.

 

다음은 EKS 클러스터를 생성하는 eksctl 명령어 예시이다.

 

eksctl create cluster --name my-cluster --region region-code

 

우리는 이미 클러스터 생성을 수동으로 Console을 통해 진행했으므로 

 

eksctl을 배포에 이용해보자.

 

eksctl 설치

아래 링크로 들어가 각자의 OS에 맞게 설치하면 된다.

 

https://github.com/weaveworks/eksctl/blob/main/README.md#installation

GitHub - weaveworks/eksctl: The official CLI for Amazon EKS

 

나는 MacOS를 쓰고 있으므로 brew로 설치했다.

 

eksctl이 제대로 설치된 모습

EKS에 필요한 각종 AWS 리소스를 다룰 수 있다.

kubectl

eksctl은 eks만을 위한 CLI툴이었다면, kubectl은 일반적인 k8s 클러스터를 제어하기 위한 CLI 툴이다.

 

kubectl은 이미 알고있다 가정하고 자세한 설명은 하지 않겠다.

 

짱짱 brew로 설치하자.

 

brew install kubectl

AWS CLI

AWS CLI는 또 뭘까? AWS 콘솔을 대체할 수 있는 CLI 툴이다.

 

각종 명령어를 통해 API 호출을 지원해준다.

 

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html

최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface

AWS CLI도 설치해주도록 하자.

 

 

배포를 어떻게 할것인가

CLI 툴을 설치해서 결국에는 무엇을 하려는지 정리해보자.

 

클러스터를 외부에 노출시킬 수 있는 방법은 대표적으로 2가지가 있다.

 

1. LoadBalancer 타입의 Service
2. ClusterIP 타입의 Service & Ingress

 

 

2가지 방법중에 우리가 구성한 파이프라인은 몇번에 해당될까?

 

우리는 ingress를 사용하지 않고 클라우드 플랫폼의 LoadBalancer를 사용하므로 1번에 해당된다.

 

• Load Balancer 와 Ingress 차이
  • Load Balancer
    • Cloud Provider가 제공
    • 클러스터 밖에 존재
    • single service로만 라우팅 가능
  • Ingress
    • k8s native object
    • 클러스터 안에 존재
    • multple service로 라우팅 가능

 

 

각자의 애플리케이션 요구사항에 맞게 둘 중에 선택하면 된다.

 

따라서 우리가 할일은

 

1. 애플리케이션을 배포할 Pod를 생성한다.
2. 해당 Pod를 외부에 노출시킬 수 있는 LoadBalancer 타입의 Service를 생성한다.
3. AWS CLB를 Service에 연결한다.

가 되겠다.

 

AWS CLI Configure

이전에 AWS CLI를 미리 설치했다. 

 

AWS CLI 사용을 위해 configure 명령어를 통해 사용자 자격증명을 하자.

 

aws configure

 

Access Key, Secret Access Key, Region을 입력하라고 나오는데, 

 

이는 AWS Console 창에서 확인할 수 있다.

 

 

보안 자격 증명 탭을 누르면 된다. 만약 액세스 키가 없다면, 새로 만들면 된다.

 

kubectl config 변경

kubectl은 kubeconfig 파일의 구성 정보를 이용해 클러스터 API 서버와 통신한다.

 

바로 이전에 설정한 정보로 update 해주자.

 

aws eks update-kubeconfig --region region-code --name my-cluster

 

region-code는 ap-northeast-2를 넣었다.

 

 

Pod 생성 & Service 생성

1,2번 과정을 동시에 진행해보자.

 

## test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mario
  labels:
    app: mario
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mario
  template:
    metadata:
      labels:
        app: mario
    spec:
      containers:
      - name: mario
        image: pengbai/docker-supermario
---
apiVersion: v1
kind: Service
metadata:
   name: mario
spec:
  selector:
    app: mario
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  type: LoadBalancer

 

다음과 같이 yaml 파일을 생성하고 apply 해보자.

 

슈퍼마리오를 Dockerize한 이미지이다.

 

 

depoyment와 service가 생성된것을 볼 수 있다.

 

service를 살펴보자.

 

External IP가 생겼다. 

 

한번 브라우저에서 접속해보자.

 

마리오가 잘 보인다.

 

오잉 이상하다,,, CLB를 서비스에 아직 연결 안했는데 ...?

CLB(Classic Load Balancer) 확인

 

좀 더 자세한 정보를 보자.

두 개의 AZ에 잘 연결되어 있다.

 

80 -> 31379로 설정 된 모습

 

우리가 연결을 해주지도, CLB를 생성해주지도 않았는데 자동으로 생성과 연결까지 되어있다.

 

어떻게 된 일일까?

 

kubectl에서 apply를 하는 순간, kubectl에 지정한 내 자격 증명으로

 

AWS에 동적으로 로드밸런서를 만들라는 요청을 보내고, 이를 서비스와 연결하게 된다.

 

우리의 CLB는 보면 알겠지만 기능이 굉장히 빈약하다... 따라서 잘 사용되지 않고

 

보통은 CLB 말고 NLB(L4), ALB(L7)등을 사용한다.

 

각각의 차이와 배포 방법은 추후 다른 포스팅에서 다루겠다!