EKS 노드의 메모리를 늘리는 일은 서버에 메모리를 꽂는 작업이 아니라 더 큰 인스턴스 타입의 노드 그룹으로 워크로드를 옮기는 작업이다. 노드 이미지를 새 AMI 로 바꾸는 작업도 절차가 같다. 두 작업 모두 파드를 재스케줄링하는 것일 뿐이므로 클러스터 위에 올라간 애플리케이션을 다시 설치할 필요는 없다.
aws eks update-nodegroup-config 로는 인스턴스 타입을 바꿀 수 없다. 스케일 설정과 레이블·테인트·업데이트 설정만 바꿀 수 있고, 타입과 디스크 크기는 노드 그룹 생성 시 결정된다. 따라서 선택지는 두 가지다.
시작 템플릿(Launch Template) 을 쓰는 노드 그룹이면 새 템플릿 버전을 만들고 update-nodegroup-version --launch-template version=<n> 으로 롤링 교체할 수 있다. AMI 교체도 같은 경로다.
시작 템플릿 없이 만든 노드 그룹이면 새 노드 그룹을 추가하고 기존 노드 그룹을 비운 뒤 삭제한다. 이 방식이 롤백도 쉽다.
aws eks list-nodegroups --cluster-name <cluster>
aws eks describe-nodegroup --cluster-name <cluster> --nodegroup-name <ng> \
--query 'nodegroup.{type:instanceTypes,ami:amiType,subnets:subnets,lt:launchTemplate}'
새 노드 그룹은 기존과 같은 서브넷·가용영역을 포함해야 한다. EBS 로 만든 PV 는 만들어진 가용영역의 노드에만 붙으므로, 새 노드 그룹이 다른 AZ 에만 있으면 상태 저장 파드가 Pending 에서 멈춘다. EFS 는 AZ 제약이 없는 대신 보안 그룹에서 2049/TCP 가 열려 있어야 한다.
# 1. 새 노드 그룹이 Ready 가 된 것을 확인한 뒤
kubectl get nodes -L eks.amazonaws.com/nodegroup
# 2. 기존 노드에 새 파드가 뜨지 않게 막고
kubectl cordon <old-node>
# 3. 파드를 비운다
kubectl drain <old-node> --ignore-daemonsets --delete-emptydir-data --timeout=600s
# 4. 모든 노드를 비운 뒤 노드 그룹 삭제
aws eks delete-nodegroup --cluster-name <cluster> --nodegroup-name <old-ng>
--delete-emptydir-data 는 emptyDir 볼륨의 내용을 버린다는 뜻이므로, 그 볼륨에 의미 있는 데이터를 두는 파드가 없는지 먼저 확인한다.
레이블·테인트·노드 셀렉터가 새 노드 그룹에도 똑같이 적용되는지 본다. GPU 전용 테인트나 nodeSelector 로 특정 노드 그룹을 지정한 파드는 새 노드에 같은 레이블이 없으면 스케줄링되지 않는다.
PodDisruptionBudget 을 확인한다. 복제본이 1개인데 minAvailable: 1 이면 drain 이 영원히 멈춘다. 상태 저장 컴포넌트(데이터베이스, 메시지 브로커, 합의 기반 구성요소)는 한 번에 한 파드씩만 빠지도록 PDB 를 잡아 두고 노드도 하나씩 비운다.
AMI 를 직접 만들어 쓴다면 이미지 안에 컨테이너 런타임 버전, nfs-utils · amazon-efs-utils 같은 스토리지 클라이언트, 시각 동기화 데몬, IMDSv2 설정이 기존 노드와 같게 들어 있어야 한다. 하나라도 빠지면 새 노드에서만 마운트나 인증이 실패한다.
EBS CSI · EFS CSI 드라이버의 버전이 새 Kubernetes 버전과 맞는지도 확인한다. AMI 교체와 클러스터 버전 업그레이드를 동시에 하지 않는 편이 문제를 가른다.