Blog

Amazon EKS에서 Amazon Linux 지원 종료 대응하기

Tags: , , ,

Amazon EKS는 Kubernetes 버전과 함께 노드 운영체제(AMI)에 대한 지원 주기를 지속적으로 업데이트합니다.
그 과정에서 Amazon Linux 1(AMZL1) 은 더 이상 최신 EKS 버전에서 사용이 어려워졌고, 기존 AL1 기반 노드그룹을 유지한 상태에서는 안정적인 운영이 어렵다는 점이 명확해졌습니다.

이 글에서는 Amazon Linux 지원 종료 상황에서 어떤 방식으로 대응할 수 있는지,
그리고 실무 관점에서 노드그룹 교체 방식이 왜 더 자연스러운 기본 전략이 되는지를 설명합니다.
(단, 신규 클러스터 생성이 더 적합한 환경도 분명 존재함을 함께 다룹니다.)

1. Amazon Linux 지원 종료란?

Amazon Linux 1 기반 AMI는 Kubernetes 1.30 이후 공식 지원이 종료되었습니다.
이에 따라 다음과 같은 제한이 발생합니다:

  • AL1 기반 NodeGroup 신규 생성 불가
  • 보안 업데이트 제공 중단
  • Auto Scaling 시 교체 노드 생성 실패
  • kubelet / CNI 등 주요 컴포넌트와 버전 충돌 가능성
  • CIS Benchmark, 보안 점검 등에서 경고 발생

결론적으로, 기존 AL1 노드그룹을 Amazon Linux 2 또는 Amazon Linux 2023(AL2023) 기반으로 전환해야 합니다.

2. 지원 종료 대응 전략: 두 가지 선택지

Amazon Linux 지원 종료에 대응하는 실질적인 방법은 두 가지입니다.

① 기존 클러스터에 새로운 NodeGroup을 생성하고 파드를 마이그레이션

→ 운영 환경의 구조를 유지하면서 OS만 교체하는 방식

② 아예 새로운 클러스터를 생성하고 전체 워크로드를 이전

→ 네트워크 설계나 보안 정책을 새롭게 가져가야 하는 경우에 유효한 선택

두 방식 모두 사용할 수 있으며, “정답은 상황에 따라 다르다”는 점이 중요합니다.
다만, 일반적으로 운영 중인 클러스터에서는 노드그룹 교체가 더 적은 변경 범위로 대응할 수 있어 기본적인 선택지가 되는 경우가 많습니다.

3. 왜 대부분의 운영 환경에서는 NodeGroup 교체 방식이 자연스러운 선택일까?

아래 내용은 “신규 클러스터 생성보다 우월하다”는 의미가 아니라,
운영 부담과 서비스 영향도를 최소화해야 하는 일반적인 EKS 환경에서는 NodeGroup 교체가 더 실용적으로 작동한다는 관점에서 정리한 것입니다.

3.1 기존 운영 구조를 유지할 수 있다

EKS 클러스터는 단순히 파드를 실행하는 공간이 아니라, 기업의 운영 체계와 연결되는 핵심 “컨트롤 플레인”입니다.

  • 네임스페이스 구조
  • RBAC 정책
  • OIDC Provider(IRSA)
  • Addon(CoreDNS, CNI, kube-proxy)
  • 모니터링/로깅 스택(CloudWatch, Prometheus, Grafana)
  • CI/CD 시스템(ArgoCD, Jenkins, GitHub Actions)

이러한 공통 구성들은 대부분 클러스터 단위로 관리되기 때문에,
노드그룹을 교체하면 전체 구조는 그대로 유지되면서 노드 OS만 자연스럽게 최신화됩니다.

반면 클러스터를 새로 만들면 모든 구성 요소를 다시 구축해야 하므로
수정해야 하는 범위가 훨씬 넓어집니다.

3.2 DNS, ALB, 서비스 엔드포인트의 변경이 최소화된다

NodeGroup만 교체할 경우:

  • ALB/NLB 기존 엔드포인트 유지
  • Internal/External DNS 레코드 그대로 사용
  • 서비스 도메인(api.example.com 등) 변경 없음
  • Ingress Controller 재배포 필요 없음
  • API Server Endpoint도 동일

즉, 트래픽 라우팅 구조가 그대로 유지되므로 전환 부담이 적다는 장점이 있습니다.

반대로 새 클러스터로 이동하면:

  • 새 API 서버 엔드포인트
  • 새 ALB 엔드포인트
  • Route53 레코드 수정
  • ExternalDNS 다시 구성
  • 서비스 간 내부 통신 주소 변경 가능

특별한 이유가 없다면 DNS/네트워크 변경은 서비스 영향도를 높이는 요인이 됩니다.

3.3 다운타임 없이 순차적 마이그레이션이 가능하다

NodeGroup 교체 → cordon → drain 방식은 기존 Kubernetes 운영 모델과 자연스럽게 맞아떨어집니다.

  • PodDisruptionBudget 준수
  • Graceful termination
  • Rolling 방식으로 파드 이동
  • 하나씩 drain하며 안정적으로 이전 가능

즉, 서비스 중단 없이 점진적이고 통제된 전환이 가능합니다.

신규 클러스터 방식도 “Blue-Green Cluster” 패턴으로 무중단 전환이 가능하지만,
구조가 더 복잡하며 변경 범위가 더 커집니다.

3.4 비용, 운영 리스크, 변경 범위가 상대적으로 작다

NodeGroup 교체는 “OS 레벨 교체”에 해당하므로 변경 범위가 제한적입니다.

반면 신규 클러스터 생성 방식은:

  • 새로운 VPC/Subnet 구성 필요할 수 있음
  • OIDC Provider 및 IAM Role IRSA 모두 재생성
  • Addon 재설치 및 버전 동기화
  • 네트워크 정책 재정의
  • CI/CD, 파이프라인 credential 수정
  • 모니터링/로깅 시스템 재연동

규모가 큰 서비스에서는
변경이 많을수록 리스크도 증가합니다.

4. 그렇다면 “신규 클러스터 생성”이 필요한 상황은 언제일까?

NodeGroup 교체가 기본 전략처럼 보이지만, 아래와 같은 경우에는 신규 클러스터가 오히려 적합합니다.

  • VPC를 새로 설계해야 하는 경우
  • 기존 클러스터의 네트워크 구조가 잘못되어 리팩터링이 필요한 경우
  • kube-system 의존성 충돌로 클러스터 복구가 어려운 상태
  • 규제·보안 정책으로 인해 새로운 격리 환경이 필요한 경우
  • 멀티 클러스터 아키텍처(Blue/Green, Active/Standby)로 가려는 경우
  • 기존 클러스터가 너무 많은 기술적 부채를 가지고 있는 경우

즉, 클러스터 레벨에서 해결해야 하는 문제가 있을 때는 새로운 클러스터 전략이 효과적입니다.

5. 결론: 운영 환경의 특성에 따라 가장 적합한 방식을 선택해야 한다

Amazon Linux 지원 종료는 EKS 운영에서 반드시 해결해야 하는 중요한 이슈이지만,
대응 방식은 환경의 규모, 네트워크 구성, 조직의 운영 방식에 따라 달라질 수 있습니다.

  • 운영 구조를 유지하면서 빠르게 대응해야 한다면 → NodeGroup 교체
  • 아키텍처 자체를 재설계하거나 격리 환경이 필요하다면 → 신규 클러스터 생성

대부분의 일반적인 EKS 운영 환경에서는
노드그룹 교체가 더 자연스럽고 안정적인 전환 방법이 되며,
클러스터 기반 구조를 그대로 유지하면서 OS만 현대화할 수 있다는 점에서
운영 리스크와 변경 비용을 최소화할 수 있습니다.

Post Views: 25