EKS 버전 롤백, 왜 지금 중요한가
Kubernetes 클러스터 업그레이드는 항상 부담스러운 작업이다. 컨트롤 플레인의 API 변경, Deprecated API 제거, 애드온 호환성 문제 등이 한꺼번에 맞물리면서 업그레이드 후 예상치 못한 장애가 발생하는 경우가 적지 않다. 특히 프로덕션 EKS 클러스터에서 인플레이스 업그레이드를 진행할 때, 문제 발생 시 되돌릴 방법이 사실상 없다는 점이 오랜 고민거리였다. Amazon EKS가 업그레이드 후 7일 이내에 컨트롤 플레인을 이전 Kubernetes 버전으로 롤백할 수 있는 기능을 새롭게 도입하면서, 이 고민을 상당 부분 해소할 수 있게 됐다.
기능의 핵심 동작 방식
이 기능은 EKS 클러스터의 컨트롤 플레인을 대상으로 한다. 업그레이드 완료 시점부터 7일간의 롤백 윈도우가 열리며, 해당 기간 내에 문제가 감지되면 이전 버전으로 되돌릴 수 있다. 예를 들어 1.29에서 1.30으로 업그레이드한 뒤 API 호환성 문제가 발생했다면, 7일 이내에 컨트롤 플레인을 1.29로 복구하는 것이 가능하다.
# 예시: AWS CLI를 통한 EKS 컨트롤 플레인 롤백 (개념적 흐름)
aws eks update-cluster-version \
--name my-cluster \
--kubernetes-version 1.29 \
--rollback
다만 몇 가지 중요한 전제를 이해해야 한다. 롤백 대상은 컨트롤 플레인에 한정되며, 워커 노드 그룹(Node Group)이나 Fargate 프로파일은 별도로 관리해야 한다. 또한 롤백 후 데이터 플레인과 컨트롤 플레인 버전 간 호환성을 직접 검증하는 것이 여전히 필요하다.
실무 운영에서의 활용 전략
이 기능이 진가를 발휘하는 시나리오는 크게 두 가지다.
- 신속한 장애 복구: 업그레이드 직후 특정 워크로드에서 CrashLoopBackOff나 API 에러가 쏟아질 때, 블루/그린 클러스터 전환 없이 컨트롤 플레인만 빠르게 되돌려 영향 범위를 최소화할 수 있다.
- 안전한 점진적 검증: 업그레이드 후 7일 동안 카나리 배포나 스테이징 트래픽을 먼저 흘리며 문제를 탐지하고, 이상이 없으면 롤백 윈도우가 닫힌 후 전체 전환을 확정하는 방식으로 운영 리스크를 분산할 수 있다.
기존에는 프로덕션 업그레이드 전에 별도의 테스트 클러스터를 구성하거나, 블루/그린 전략으로 신규 클러스터를 병행 운영하는 방식이 사실상 유일한 안전망이었다. 이 기능은 그 비용과 복잡도를 낮춰준다는 점에서 실질적인 가치가 있다.
정리
- Amazon EKS는 Kubernetes 업그레이드 후 7일 이내 컨트롤 플레인을 이전 버전으로 롤백하는 기능을 제공한다.
- 롤백 범위는 컨트롤 플레인에 한정되므로, 노드 그룹 및 애드온 호환성은 별도로 검토해야 한다.
- 인플레이스 업그레이드 시의 위험 부담을 줄여, 블루/그린 없이도 점진적 검증 전략을 적용할 수 있게 된다.