AEWS 4기 7주차(1) - EKS Upgrade

본 글은 공식 문서 및 서종호(가시다)님의 AWS EKS 워크샵 내용을 기반으로 참고하여 학습 목적으로 작성하였습니다.
주관적인 해석이 포함되어 있어 사실과 다르거나 오류가 있을 수 있으니 참고용으로만 읽어주시기 바랍니다.

본 글은 Amazon EKS Upgrades: Strategies and Best Practices에 대한 AWS Workshop 실습을 통해 작성한 내용입니다.

EKS Upgrade

쿠버네티스는 연간 3회(약 4개월 주기)의 릴리즈가 발생하며, Amazon EKS(Elastic Kubernetes Service) 업그레이드는 클러스터의 안정성, 보안, 그리고 최신 기능 활용을 위해 필수적으로 수행해야 하는 핵심 운영 작업입니다.

 

EKS Upgrade 고려해야 하는 이유

고려 사항

 

표준 지원 및 연장 지원

 

EKS 업그레이드 지연 시 위험도

 

EKS 업그레이드 과정

컨트롤 플레인 업그레이드

준비 항목 (Checklist)	상세 내용 및 요구사항
릴리즈 노트 검토	버전별 변경 사항 및 제거된 API 확인 (v1.22 주의)
네트워크 IP 확보	서브넷당 최소 5개의 여유 IP 주소 필요
마스터 및 노드 버전 확인	현재 노드와 타겟 버전 간의 호환성 검증
보안 그룹 유지	초기 Pod Security Policy, SG 및 서브넷 구성 유지 여부 확

업그레이드는 기존 버전에서 1단계씩만 업그레이드 가능(v.1.30 > v1.32로 바로 업그레이드 불가능)

 

업그레이드 방법( 업그레이드 버전은 기존 버전에서 1단계씩 순차적으로 업그레이드가 가능)

• AWS Console, AWS CLI, eksctl, CloudFormation, Terraform

 

EKS Managed Node Group 업그레이드

- 업데이트 시기 : EKS 컨트롤 플레인이 새로운 버전의 쿠버네티르 업데이트됨, 새로운 AMI 릴리스 버전이 사용 가능함, 구성 변경

 

업그레이드 과정

프로세스 요약

단계	핵심 액션	상태 변화	비고
1. 구성 생성	Launch Template 업데이트	Ver.1.30 → Ver.1.31	신규 AMI 지정
2. 용량 확장	ASG Desired +1	Nodes: 3 → 4	신규 노드 부팅
3. 이주(Migration)	kubectl drain & cordon	Pod Eviction	서비스 영향 최소화
4. 인스턴스 종료	구버전 EC2 Termination	Nodes: 4 → 3	AWS 자동 처리
5. 정리	ASG 원복 및 완료	Final Steady State	순차 반복 (Rolling)

 

Karpenter Node 업그레이드

Karpenter Drift를 통한 제로 터치 관리방식을 권장합니다.

 

Karpenter Drift란?

클러스터의 실제 노드 상태가 정의된 EC2NodeClass 또는 최신 AMI 설정과 불일치하는 현상을 의미합니다.

 

Karpenter Drift 동작 방식

1. 모니터링: Karpenter가 AWS SSM Parameter Store를 지속적으로 감시하여 새로운 EKS 최적화 AMI 릴리즈를 감지합니다.

2. 드리프트 감지: 현재 실행 중인 노드의 AMI ID가 최신 권장 ID와 다를 경우 해당 노드를 'Drifted' 상태로 표시합니다.

3. 노드 교체: 신규 AMI가 적용된 새 노드를 프로비저닝하고, 기존 노드의 파드를 새로운 노드로 안전하게 이주(Cordon & Drain)시킵니다.

 

Managed vs Karpenter 업그레이드 비교

비교 항목	Managed Node Group (MNG)	Karpenter (Drift)
트리거 방식	사용자/API 호출 (수동/예약)	이벤트 기반 (자동 감지)
AMI 업데이트	Launch Template 버전 수동 변경 필요	SSM Parameter 감시를 통한 자동화
유연성	ASG 기반의 정적 구성	워크로드 요구사항에 따른 동적 크기 조정
운영 오버헤드	보통 (버전 관리 필요)	매우 낮음 (Zero-Touch)

 

Fargate 업그레이드

Fargate 노드에서 업그레이드는 항상 기존 파드 삭제 후 신규 파드 생성을 통해 이루어집니다.

방법 1. 클러스터 업그레이드 방식

- Kubelet 버전 일치: EKS 컨트롤 플레인을 업그레이드하더라도 기존 실행 중인 Fargate 파드는 이전 버전을 유지합니다.

- 재배포 필수: 최신 클러스터 버전과 일치하는 Kubelet을 적용하려면 파드를 삭제하고 다시 배포해야 합니다.

- 롤링 업데이트: Deployment 객체를 사용 중이라면 kubectl rollout restart 명령으로 무중단 버전 교체가 가능합니다.

 

방법 2. AWS 정기 유지 보수

- 보안 위협 대응: AWS는 인프라 수준의 CVE 수정을 위해 Fargate 파드를 주기적으로 패치하고 노드를 리사이클링합니다.

- Task Retirement: 특정 보안 기준에 미달하는 오래된 인프라 Revision은 AWS에 의해 'Retirement' 통보를 받게 됩니다.

- Eviction API: AWS는 Kubernetes Eviction API를 호출하여 파드를 안전하게 Drain하며, 실패 시 강제 삭제 후 재생성합니다.

 

EKS MNG vs EKS Fargate 비교

비교 항목	EKS Managed Node (EC2)	EKS Fargate
패치 주체	고객 (AMI 업데이트)	AWS (완전 관리형)
버전 업데이트 방식	인스턴스 롤링 교체	파드 재시작 (Recycle)
운영 복잡도	높음 (ASG, LT 관리 필요)	매우 낮음 (Node-less)
유지보수 영향	수동 제어 가능	AWS 일정에 따라 자동 발생
가용성 전략	Node Drain & ASG 확장	PDB (Pod Disruption Budget)

 

Fargate 업그레이드 전략

EKS 애드온 업그레이드

Add-on 구성

Add-ons의 고급 구성

 

업데이트 중 add-on 구성 변경 사항 보존

--resolve-conflicts PRESERVE 동작 원리

설정 보존 파라미터(--resolve-conflicts PRESERVE)를 사용하면 업데이트 중 발생할 수 있는 의도치 않은 설정 초기화를 방지합니다.

 

업데이트 관련 호환성 및 규칙

구분	동작 방식 및 상세 규칙
최신 버전 업데이트	EKS 클러스터 버전과 호환되는 최신 애드온 버전으로 즉시 업데이트가 가능합니다.
고급 구성 승계	새로운 고급 구성 설정이 제공되지 않는 경우, API는 기존의 구성 설정을 그대로 적용하려고 시도합니다.
충돌 해결 전략	OVERWRITE(기본값) 또는 PRESERVE를 선택하여 사용자 지정 설정 유지 여부를 결정합니다.
순차적 업데이트	애드온은 일반적으로 컨트롤 플레인 버전과 1단계 차이 내에서 업데이트를 진행하는 것이 권장됩니다.