기존에는 EKS에서 노드 그룹을 관리 위해서는 Cluster-Autoscaler를 이용하여 Autoscaling 그룹을 조정하여 운영해왔습니다. 이럴 경우 몇가지 문제가 발생 됩니다. 1. Autoscaling 그룹은 인스턴스의 생성/삭제가 느리다. 2. Topology 이슈 3. 무조건 1대 이상의 인스턴스가 실행되어 있어야 한다. 1번의 경우 Autoscaling 그룹의 원하는 용량(desire)을 조정하여 스케일링 하므로, 동작이 매우 느린 단점이 있습니다. 2번의 경우 Autoscaling 그룹이 가용영역 별로 인스턴스의 수량을 균등하게 유지하려는 특성이 있기 때문에, PV가 있는 가용영역에 생성되지 않는 불상사(?)가 발생될 수 있습니다. 3번의 경우 빌드 서버로 예를 들면, 빌드 서버는 상시로..

EKS 1.24가 되면서, SA(Service Account 이하 SA로 지칭)의 생성 및 활용하는 방법이 변경되었다. 아래 코드를 입력하여 SA를 생성한다. apiVersion: v1 kind: ServiceAccount metadata: name: account-name namespace: namespace-name 1.24 버전 전까지는 SA 생성 후 토큰까지 자동 생성되었지만… 1.24 이후에는 토큰 및 인증서 생성이 수동으로 변경되었다. 그래서 아래 코드를 입력하여 secret으로 type: service-account-token을 생성한다. apiVersion: v1 kind: Secret metadata: name: secret-sa-name namespace: namespace-name a..

최근 입사한 회사에서 조직마다 클러스터를 따로 쓰고 있다보니 관리에 애로사항이 꽃필 것 같아서 IaC를 하기 위해 조금씩 스터디해서 저장해놓는 글 AWS Provider 사용 시 provider "aws" { region = "ap-northeast-2" #사용 리전 profile = "dev" #aws profile shared_config_files = [ "~/.aws/config" ] #aws configure 후 저장된 config file 사용을 선언 shared_credentials_files = [ "~/.aws/credentials" ] #aws configure 후 저장된 credentials file 사용을 선언 } Access Key를 하드 코딩하면 보안 상 좋지도 않고 EKS 쓰려..