EKS #1 - 개념, eksctl, cluster

이전에 Kubernetes의 구성 요소에 대해서 간단히 알아보았다. 이번 글 부터 Kubernetes의 배포에 자주 사용되는 EKS에 대해서 공부한 내용을 하나씩 정리해볼까 한다.

먼저 EKS란 단순히 말하면 AWS에서 관리하는 컨트롤 플레인이다. 컨트롤 플레인은 쿠버네티스 클러스터의 전반적인 상태, 동작을 관리하는 하나의 노드이다.

이 컨트롤 플레인은 여러개의 워커 노드에서 각 노드의 파드의 레플리카가 몇 개여야 하는지 충족되지 않을 경우의 새로운 파드를 실행하는 명령등을 실행해줘야 한다.

이 뿐만이 아니라 보안, 각 파드의 업데이트 확장성까지 고려하면 컨트롤 플레인을 관리해줘야하는 복잡성이 엄청나게 증가한다.

EKS는 이러한 복잡성을 줄여준다. AWS가 다양한 AWS 리소스를 관리 자동으로 생성하고 관리하여 개발자가 서버의 운영에만 집중할 수 있도록 도와준다.

또 EKS를 사용하면 자동으로 VPC, SG, ASG, EC2 등을 자동으로 생성해주는데 이러한 AWS 요소를 사용하므로 다른 AWS 리소스와의 통합이 자연스럽다. 이외에도 AWS가 계속해서 EKS에 대한 보안도 관리해주며 쿠버네티스의 최신 버전으로 업그레이드 하는 부분도 관리해주므로 쌩으로 쿠버네티스를 운영하는 것 보다 훨씬 쉽고 효과적이라고 할 수 있다.

Node Groups

먼저 EKS에 Node Group에 대해서 간단히 이해할 필요가 있다. Kubernetes에는 없지만 EKS에 있는 개념이다.

일반적으로 EKS 클러스터의 노드는 하나의 EC2이다.(Fargate를 사용하면 다르지만 일단 EC2 기준으로 설명한다)

이러한 노드들 즉 EC2를 하나로 묶는 개념인데, 실제로 서버를 실행할 때 필요한 노드들 즉 EC2를 하나로 묶는 개념이다.

이게 필요한 이유는 EC2는 각각 AMI라는 스펙을 가지는데, 이러한 스펙을 관리하는 단위가 필요하다. 특정 노드 그룹의 EC2의 AMI를 업데이트하면 EKS가 이 노드 그룹의 단위로 스펙을 업데이트 해준다.

또 스케일링을 관리할 때도 효율적이다. 각 노드 그룹이 자체적인 Auto Scaling Group을 가짐으로서 이 노드 그룹 단위로 독립적으로 확장하거나 축소한다.

즉 노드 그룹은 비슷한 성격의 워커 노드들을 관리하기 위한 논리적인 집합이라고 할 수 있다.

여기서도 노드그룹은 2가지 성격으로 나뉘는데, 일반 노드그룹(Self-Managed)와 매니지드 노드그룹으로 나뉜다.

일반 노드그룹은 각 노드그룹에 대해서 직접 관리를 해야한다. 오토 스케일링 그룹이나 AMI 등 많은 것들을 직접 생성해서 연결해줘야 한다. 매니지드 노드그룹은 이러한 노드그룹에 필요한 리소스들을 자동으로 생성하고 관리해준다. 하지만 자세한 커스텀이 불가능하다는 단점이 있는데, 가장 큰 부분이 AMI에 해당한다. 매니지드 노드그룹을 사용하면 무조건 Amazon Linux를 사용해야만 한다.

하지만 그럼에도 불구하고 매니지드 노드그룹이 가져다주는 이점이 커서 대부분 이걸 선택하며, 노드그룹을 생성할 때 디폴트도 매니지드 노드그룹으로 생성이 된다.

eksctl

kubernetes를 사용하면 kubectl 이라는 명령어를 계속해서 사용하게 된다. kubectl은 Kubernetes에 명령을 보내기 위해 API Server 인터페이스를 호출하는 명령어라고 할 수 있다.

EKS에도 EKS 클러스터를 관리하기 위한 명령어가 따로 존재하고 이를 eksctl이라고 한다.

이제 eksctl을 설치하고 사용하는 방법에 대해서 간단히 알아보자.

먼저 aws-cli를 설치해야 한다. 이 글은 eksctl에 대해서 설명하므로 aws cli는 공식문서 를 통해서 설치해보자.

그리고 aws iam을 통해서 aws 리소스를 사용할 수 있도록 인증을 해야한다. 먼저 iam에 유저를 만들고 AdminAceess 권한을 준 후, Access Key와 Secret Key를 aws configure 명령을 통해서 입력해준다.

$ aws configure
AWS Access Key ID [None] : [Access Key ID]
AWS Secret Access Key [None] : [Secret Access Key]
Default region name [None] : ap-northeast-2
Default output format [None] : [아무것도 입력하지 않아도 된다]

이렇게 하면 aws cli 설정이 마무리 된다.

이제 eksctl을 설치하면 되는데, 설치도 사실 아주 간단한 딸깍이다.

이 링크에 자세히 설명이 되어 있는데, Mac OS 기준으로 터미널에 아래 명령어를 실행해주면 간단히 설치가 된다.

# for ARM systems, set ARCH to: `arm64`, `armv6` or `armv7`
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"

# (Optional) Verify checksum
curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check

tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz

sudo mv /tmp/eksctl /usr/local/bin

윈도우의 경우 위 링크에 들어가면 명령어 없이 바로 다운받을 수 있는 설치 파일의 링크가 있다. 맥의 경우 brew로도 설치할 수 있는데, 왜 인지 추천하지 않는 방법이라고 하여, 위 명령어를 통해 설치했다.

설치가 완료되면

eksctl version

이라는 명령어를 통해 버전을 확인하여 설치가 정상적으로 완료되었는지 확인할 수 있다.

eksctl을 통한 클러스터 생성, 삭제

이제 실제로 eksctl을 사용해보자. eks로 클러스터를 관리할 때는 웹 콘솔보다 eksctl을 사용하는 것이 압도적으로 편한데, 이유는 VPC 설정부터 이후에 노드 그룹의 오토 스케일링 설정까지 전부 eksctl이 자동으로 해주기 때문이다.

회사에서 일을 할 때는 거의 다 웹 콘솔을 이용해서 업무를 봐서 이렇게 하는게 직관적이고 편하다고 생각했지만, 웹 콘솔은 정말 자주 UI가 업데이트되어 뭔가 익숙해진다는 느낌이 덜 든다.

또 대부분의 리소스를 생성할 때 VPC와 서브넷을 지정하게 되는데, 매번 드롭다운 내려서 서브넷 아이디 찾고 이런 과정을 많이 줄일 수 있다. 웹 콘솔로 AWS 리소스 관리하는건 드롭다운 내려서 맞는 보안 그룹과 서브넷을 찾는 일이다

먼저 eksctl을 통해 cluster를 생성하려면

eksctl create cluster \
--name eksctl-test

이렇게 하면 된다. 이름이 지정된 클러스터를 생성해준다. 클러스터를 생성한 후엔 노드그룹을 생성해주어야 하는데, 이제 같은 종류의 워커 노드들을 붙여준다고 생각하면 된다. 이 create cluster 명령어는 기본적으로 VPC, Subnet, IGW, NAT, SG 등 EKS 클러스터 관리에 필요한 다양한 AWS 리소스를 생성하므로 보통 5-10분 정도의 시간이 걸린다.

노드 그룹을 추가하려면

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: eksctl-test
  region: ap-northeast-2

nodeGroups:
  - name: ng1-public
    instanceType: t3.micro
    desiredCapacity: 2
  
managedNodeGroups:
  - name: ng2-managed
    instanceType: t3.micro
    minSize: 1
    maxSize: 3
    desiredCapacity: 2  

위 파일을 작성해서 eksctl-create-ng.yaml이라는 이름으로 저장해주고

eksctl create nodegroup --config-file=eksctl-create-ng.yaml

이런 명령어를 실행해주면 된다. 노드그룹은 다양한 설정값을 가지고 있어, 이렇게 매니페스트 파일로 관리하는게 좋다. 파일을 살펴보면 일반 노드그룹과 매니지드 노드그룹이 있으며 desiredCapacity를 통해 EC2의 개수를 설정하고 instaceType을 통해 EC2의 스펙을 정해줄 수 있다.

또한 매니지드 노드그룹은 오토 스케일링 그룹도 자동으로 만들어주므로 추가로 minSize, maxSize를 통해 오토 스케일링 그룹의 스케일링 범위도 설정해줄 수 있다.

이렇게 따로 노드그룹을 생성하는 방법 말고 클러스터와 동시에도 생성할 수 가 있는데,

eksctl create cluster \
--name eksctl-test \
--node group-name ng-default \
--node-type m5.large \
--nodes 2

이렇게 클러스터와 한번에 노드그룹 이름, 타입, 개수를 설정해서 생성해 줄 수도 있다. 이렇게 생성하면 매니지드 노드그룹으로 노드그룹이 생성되는데, ASG의 min, maxSizes는 nodes에 설정된 2로 생성이 된다.

이제 간단히 pod를 생성해보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    environment: test # labels를 기준으로 Deployments는 replicaSet을 replicaSet은 pod을 관리하게 된다.
  name: testdeploy # pod의 이름 prefix가 된다
spec:
  replicas: 3 # 3개의 pod 유지
  selector:
    matchLabels:
      environment: test
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1 # update시 몇 개의 새로운 pod를 추가할지
      maxUnavailable: 0 # 몇 개의 pod이 unavailable해야 update를 완료 처리하는지
    type: RollingUpdate
  template:
    metadata:
      labels:
        environment: test
    spec:
      containers:
      - image: nginx:1.17
        name: nginx

이렇게 nginx를 만드는 파드를 생성하고, kubectl apply -f [filename] 을 실행하면 파드가 정상적으로 EC2에 배포가 된다. 다시 kubectl get pod 으로 파드 목록을 가져오면 nginx 파드가 3개 배포되어 있는걸 확인할 수 있을 것이다.

이제 클러스터를 정리해보자. 클러스터를 삭제하려면

eksctl delete cluster --name=eksctl-test

이 명령어를 입력해주면 된다. 이러면 이 클러스터와 관련된 모든 AWS 리소스를 삭제해준다. create cluster로 생성되지 않고 따로 연결한 AWS 리소스는 남아있게 된다. 다만 노드그룹은 cluster에 종속적으로만 작동하므로 같이 삭제가 된다.

만약 노드그룹만 삭제하고 싶다면

eksctl delete nodegroup --cluster eksctl-test --name ng1-public

이렇게 —cluster, —name에 각각 클러스터이름, 노드그룹이름을 넣어서 노드그룹만 따로 삭제해줄 수도 있다.

kubectl context

그런데 eksctl로 생성된 클러스터에 kubectl get pod 같은 명령어를 사용하게 되면 자동으로 eks cluster에 있는 파드 정보를 가져오게 된다. 따로 설정한 적도 없는데 말이다.

이건 kubectl의 컨텍스트와 관련이 있다.

kubectl config get-contexts

이 명령어를 실행해보면 두 개의 컨텍스트가 나온다. 하나는 docker-desktop을 설치할 때 딸려온 로컬 쿠버네티스 환경, 하나는 aws로 시작하는 eks cluster와 관련이 있다.

kubectl config current-context

이 명령어를 통해서 현재 어떤 클러스터를 가리키고 있는지 알 수도 있다.

아마 eks cluster를 생성하고 삭제하면 kubectl이 먹통이 될건데, 이건 kubectl의 컨텍스트가 삭제된 클러스터를 가리키고 있기 때문이다. 만약 로컬 클러스터를 사용할 것이라면,

kubectl config use-context docker-desktop

이렇게 도커 데스크톱의 쿠버네티스 클러스터를 가리키도록 설정해주면 되고, 또 새로운 클러스터를 가리키고 싶다면

aws eks update-kubeconfig --name [EKS-Cluster-Name] --region ap-northeast-2

이렇게 aws 커맨드를 사용해서 외부에 존재하는 EKS 클러스터를 돌려서 우리 kubectl의 컨텍스트를 바꿔주면 된다.

Billing

이제 요금이다. 아마 AWS를 처음 사용한다면 이 요금 폭탄에 대한 글들을 많이 보았을 것이다. 나름 개발자들 사이에서 알려진 정보로는 EKS가 그렇게 저렴하지만은 않다는 점이다.

필자도 EKS를 프로덕션 환경에서 운영해본 경험이 없어, 실제로 어느정도의 요금이 나오는지는 모르겠지만 일단 EKS로 이것저것 실습해보는데 필요한 요금은 조금 알아둬야겠다는 생각이 들었다.

먼저 create cluster 명령어에 nodegroup을 붙여서 클러스터를 생성하면 함께 생성되는 AWS Resource는 아래와 같다.

• EKS 컨트롤 플레인
• EC2 인스턴스
• EBS 볼륨
• VPC
• 서브넷
• 라우팅 테이블
• 인터넷 게이트웨이
• NAT 게이트웨이
• Auto Scaling Group

대략 이정도이다. 이 중에서 요금이 드는 요소는

• EKS 컨트롤 플레인 - 시간 당 0.1$, 1달에 약 74$
• EC2 인스턴스(t3.medium 기준 시간당 0.0416$)
• EBS (EC2의 스토리지) 월 0.114$
• NAT Gateway 시간당 0.045$

정도이다. 이 외에도 인터넷 게이트웨이를 통해서, 데이터를 전송하면 추가로 요금이 발생한다. Auto Scaling Group은 EC2 인스턴스의 추가적인 확장에만 요금이 추가될 수 있으며 VPC, Subnet, Routing Table 등 기본적인 네트워크 세팅을 무료이다.

이외에 이 후에 ALB를 연결해준다면 ALB에 관련된 요금이 조금 나올 것이다.

전반적으로 살펴봤을 때 실습 후 클러스터만 잘 삭제해준다면 월에 1만원~3만원 정도로 실습이 가능하지 않을까 싶다. 만약 AWS 프리티어가 사용가능한 계정이고 실습에서 t3.micro와 같이 프리티어를 지원한다면 더 저렴하게 이용이 가능할 것이다.