[AWS] EKS Kubernetes 버전 업그레이드 1.29 -> 1.30

배경

운영팀 메일함으로부터 Amazon EKS Kubernetes 1.29 버전의 표준 지원 종료 안내가 도착하였다.
이는 클러스터 버전을 최신으로 유지하라는 AWS 측의 조치 요청이다.

 

대응 절차

2-1. 사전 정보 확인

먼저 메일 내용의 정확한 세부 사항을 확인하기 위해 AWS Health Dashboard에 접속한다.
이벤트 탭의 "예정된 변경 사항" 항목에서 해당 알림을 찾고 클릭하면,
적용 대상 리소스, 강제 갱신 예정일, 자동 업그레이드 시점 등을 확인할 수 있다.

 

2-2. 클러스터 업그레이드 시작

AWS EKS 콘솔에 접속해 대상 클러스터를 선택한 뒤, “지금 업그레이드” 버튼을 클릭한다.

 

2-3. 목표 버전 선택 및 실행

업데이트할 Kubernetes 버전(예: 1.30) 을 선택한 후 업그레이드 작업을 진행한다.

 

2-4. 새로고침 후 진행 바가 사라져도 업그레이드는 계속될 수 있다.

업데이트가 완료되었는지는 클러스터 정보 화면에서 상태 항목에 '활성' 표시가 나타나는지를 통해 판단할 수 있다.
해당 상태가 ‘활성’으로 전환되면, Kubernetes 버전이 제대로 반영되었는지 확인하여 업그레이드가 성공적으로 완료되었는지 검토한다.

 

 

업데이트가 다 되면 아래와 같이 상태가 변경됩니다. 

 

2-5. 상태 확인 

업그레이드 진행 중 콘솔에서 파란 상태바가 사라지더라도 실제 처리는 백그라운드에서 계속된다.
업그레이드가 완료되면 클러스터 상세 정보에서 상태 → 활성으로 변경된다.
이후 kubectl version 명령어를 통해 실제 반영된 버전을 확인할 수 있다.

kubectl version

 

리소스 확인 및 대기

클러스터 리소스 상태는 통상 하루에 한 번 정도 새로 반영되기 때문에,
정상 반영 여부는 24시간이 지난 후 확인하는 것이 확실하다.
업데이트가 완료되면 AWS Health Dashboard의 해당 항목도 자동으로 사라진다.

 

Add-on 업데이트 및 오류 처리

업데이트 후 약 24시간이 지나면 EKS 콘솔에 오류 알림(빨간 배지) 이 나타날 수 있다.
이는 대부분 EKS Add-on 버전이 새 Kubernetes 버전과 호환되지 않음을 의미한다.

• 경로: EKS > 클러스터 > 추가 기능 탭
• 조치: 각각의 Add-on을 클릭하여 권장 버전으로 수동 업그레이드

⚠️ Add-on 문제 해결 후에도 오류 배지는 최대 24시간 후에 반영됨

 

궁금증: 업그레이드했는데도 왜 파드가 재시작되지 않았을까? 

클러스터의 Kubernetes 버전을 올리는 작업은 Control Plane(제어 플레인) 컴포넌트(API Server, Scheduler 등)를 새 버전으로 교체하는 작업이다.
Node나 Pod에 직접적인 영향을 주지 않기 때문에 Pod는 재시작되지 않는다.
이 점은 EKS 구조 상 의도된 동작이며, 안정적인 운영을 위한 설계이다.

 

참고: Kubernetes 버전 수명주기 요약 (Amazon EKS 기준)

버전릴리스일표준 지원 종료확장 지원 종료

 

버전	릴리스일	표준 지원 종료	확정 지원 종료
1.30	2024.05.23	2025.07.23	2026.07.23
1.29	2024.01.23	2025.03.23	2026.03.23
1.28	2023.09.26	2024.11.26	2025.11.26

• 표준 지원: 14개월
• 확장 지원: 12개월 추가 (기본 적용 / 시간당 과금 발생)
• CLI로 확인:
   

aws eks describe-cluster-versions

 

AWS 공식 가이드 기반 요약 참고

 

• 표준 지원 종료 후 12개월 동안은 자동 확장 지원으로 유지되며 요금 부과
• 컨트롤 플레인은 자동 업그레이드되지만 노드는 수동 처리 필요
• Fargate 및 하이브리드 노드는 직접 롤링 업데이트 필요
• 확장 지원이 종료되면 해당 버전은 더 이상 클러스터 생성 불가

 

Amazon EKS 클러스터의 안정적인 운영을 위해서는 주기적인 Kubernetes 버전 업그레이드가 필수적이다.
단순히 제어 플레인 업그레이드만으로 끝나지 않고, Add-on 및 노드 그룹에 대한 후속 조치까지 포함해야 실제 운영 장애를 방지할 수 있다.
AWS의 정책 변경이나 자동 업그레이드 이전에 선제적으로 관리하는 것이 비용과 장애 리스크를 줄이는 가장 좋은 방법이다.
지속적인 모니터링과 반복적인 업그레이드 경험을 통해, 점점 더 효율적인 운영 체계를 만들어갈 수 있을 것이다.