EKS 처음 설치한다면 - 테라폼, Scheduler

Jerry·2025년 3월 24일
0

가시다님 EKS 스터디 참여하고 내용을 정리합니다.

내가 운영하는 시스템이 Best Practice에 가까웠으면 하고 평소에 작업합니다. 처음 설치하는 사람들에게 조금은 참고가 되었으면 하고 공유합니다.

테라폼 사용 현황과 관리 방식

1. EKS와 Addon 설치 관리

테라폼으로 EKS 클러스터와 필수 애드온(Addon)을 설치합니다. 추가로 신규 애드온이 생길 경우, 테라폼이 아닌 AWS 콘솔에서 작업하는 경우도 많습니다. 테라폼으로 모두 관리하는 것이 이상적이지만, 빠른 대응(+ 귀찮아서)을 위해 콘솔에서 바로 처리하기도 합니다. 개별 테라폼 자원을 분리해서 tfstate - key 파일로 관리하여 테라폼 코드와 현재 운영중인 상태가 맞지 않아도 큰 어려움이 없습니다.

2. 테라폼 코드와 AWS 콘솔 병행 사용

테라폼을 사용하여 AWS 리소스를 생성합니다. 하지만 위와 동일하게 RDS 성능 옵션 설정 변경이나 IAM Role 수정 같은 소규모 변경은 AWS 콘솔에서 바로 처리하는 경우도 많습니다. 물론 테라폼으로 관리하면 일관성과 버전 관리 측면에서 좋지만, 작업 효율성을 고려하면 때로는 콘솔이 더 빠르고 쉬울 수 있습니다.

3. 테라폼 State 파일 분리 관리

테라폼의 상태(state) 파일은 S3 버킷에 저장하는데, 각 테라폼 리소스마다 별도의 키(key)를 부여해 관리합니다. 예시는 다음과 같습니다.

terraform {
  backend "s3" {
    bucket         = "dev-xxx-s3-tfstate"
    key            = "iam/devsecops-role/terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "TerraformStateLock"
    profile        = "xxx-dev"
  }
}

이렇게 하면 리소스 변경 시 다른 리소스에 영향을 주지 않고 개별로 관리가 가능해 매우 편리했습니다.

4. 테라폼 디렉토리 구조를 리소스별로 분리

테라폼 디렉토리를 아래와 같이 리소스 별로 나누어 관리합니다.

tf/
├── eks
├── iam
├── s3 /
├──────── es-snapshot
├──────── ssm-log
└──────── loki-log

파게이트와 카펜터의 활용

카펜터(Karpenter)를 사용해 노드 스케줄링 합니다. 카펜터 자체 파드는 기본 노드 그룹 대신 파게이트(Fargate)에 이중화하여 실행합니다. 기본 노드 그룹을 제거해서 카펜터 자체 파드를 제외한 모든 노드는 카펜터가 관리합니다.

EKS Auto Mode에 대한 의견

EKS Auto Mode는 관리가 간편해 보이지만, 실제 운영 노드 접근 불가능, 모든 노드 21일 제한적인 사용, 추가 비용 등을 고려하면 그리 매력적으로 다가오지 않았습니다. 당분간 고려하지 않을 듯 합니다. 현재는 EKS 운영이 그리 크게 어렵거나 복잡하지 않습니다.

네트워크 및 스토리지 관련하여 시스템 데몬 형태의 실행 방식은 흥미롭네요. 온프렘(On-premise)에서도 시스템 데몬 형태로 관리하는 것이 안정성 면에서 쿠버네티스 파드로 실행하는 것보다 쿠버네티스 종속성을 제거하니 좀 더 안정적일 것 같습니다.

쿠버네티스 Scheduler 전략

쿠버네티스 기본 스케줄러를 사용합니다. 특정 노드에만 파드를 배포하기 위해 nodeSelector, tolerations, taints를 활용 중입니다.

예시 - 파드 설정

nodeSelector:
  priority: high-arm
tolerations:
  - effect: NoSchedule
    operator: Equal
    key: high-priority-arm
    value: "true"

예시 - 노드 설정

taints:
  - key: high-priority-arm
    effect: NoSchedule
    value: "true"

배포 시 파드 분산 전략

배포 시 신규 버전의 파드가 새로운 노드에 생성되지 않고 기존 노드에만 스케줄링되도록 하기 위해 topologySpreadConstraints - matchLabelKeys 옵션을 사용 중입니다.

topologySpreadConstraints:
  - labelSelector:
      matchLabels:
        app.kubernetes.io/instance: xxx-api-dev
    matchLabelKeys:
      - pod-template-hash
    maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule

이렇게 하면 새로운 버전 파드 배포 시 신규 노드를 실행하고 배포가 완료되면 기존 노드에 실행 중인 파드를 삭제하고 새로운 노드에 실행하는 불필요한 파드 스케쥴링 작업을 어느정도 방지할 수 있습니다. (카펜터 설정에 전체 리소스를 사용하지 않고 자원을 80% 혹은 0.5 Core 정도 남겨두는 Reserved 옵션이 있으면 좋겠다.)

profile
도서 <24단계 실습으로 정복하는 쿠버네티스> 저자. 쿠버네티스/EKS 관련 문의 erdia22@gmail.com.

0개의 댓글