Fargate on EKS : Version Upgrade

1. 개요

Amazon EKS Fargate는 서버리스(Serverless) 방식의 Kubernetes 실행 환경으로, 사용자가 EC2 노드를 직접 관리하지 않아도 컨테이너를 실행할 수 있도록 지원합니다. 기존 EC2 on Fargate환경에서는 데이터 플레인(Data Plane) 즉, 워커 노드 및 Kubelet 구성, AMI 패치, 스케일링 등을 사용자가 직접 관리해야 합니다.반면, Fargate on EKS는 이 데이터 플레인을 AWS 측에서 완전 관리 형태로 운영하기 때문에, 사용자는 Pod 단위로만 리소스를 정의하고 배포하면 됩니다. 이로써 노드 관리 부담이 사라지고, 인프라 운영 리소스 및 보안 위험을 줄일 수 있습니다.

이 글에서는 Fargate on EKS의 버전 업그레이드(Version Upgrade) 방법과, 실제 운영 환경에서 발생할 수 있는 EKS Fargate Pod Evictions 에 대해 설명합니다.

2. EKS EC2 vs EKS Fargate

항목	EKS Fargate	EKS EC2 (Self-managed / Managed Node Group)
Pod 실행 방식	AWS가 자동으로 서버리스 인프라에 Pod 실행	EC2 인스턴스 위에 직접 Pod 실행
서버 관리	불필요 (서버 없음)	필요
보안 격리	Pod 단위로 격리 (강력)	노드 단위 격리
스케일링	Pod 수준의 단순한 스케일링	EC2 오토스케일링 / Pod 수준의 스케일링 필요
커스텀 DaemonSet	지원 안 함	가능
스토리지	EBS 사용 불가 / EFS 사용 가능	EBS 및 EFS 사용 가능
비용	Fargate 단위의 초 단위 과금 (CPU/Mem)	EC2 인스턴스 시간 단위 요금

3. Hands-on : Fargate On EKS 업그레이드(v1.32 → v1.33)

3.1 EKS Cluster 버전 업그레이드 필요 이유

EKS는 AWS에서 제공하는 완전관리형 Kubernetes 서비스로 지속적으로 개선되는 Kubernetes 생태계의 특성상 버전 업그레이드는 운영자에게 매우 중요한 주기적 업무입니다.

Kubernetes는 각 버전이 정식 릴리스된 후 약 1년간 Standard Support가 제공되며, 이후 1년간은 Extended Support로 전환됩니다. Extended Support 기간에는 별도의 추가 과금이 발생하므로, 운영 비용과 안정성을 고려할 때 Standard Support 기간 내에 클러스터 버전을 업그레이드하는 것이 바람직합니다.

3.2 버전 업그레이드

EKS 클러스터에서 Fargate 기반과 EC2 노드 기반의 K8S 버전 업그레이드 방식에는 근본적인 차이가 있습니다.

EKS on EC2는 EC2 내에 설치된 pod들을 축출하여 새로운 버전의 EC2 노드로 옮겨야하는 반면, EKS on Fargate는 각 pod들은 AWS가 관리하는 Node 내에 배포되어 Pod 레벨에서의 재배포만으로 Pod 즉, Node의 전이 업그레이드가 됩니다.

AWS Console에서 ‘Upgrade version’을 클릭하여 버전을 업그레이드 합니다. (v1.32 → v1.33)

업데이트는 보통 약 15~25분 정도 소요됩니다.

아래와 같이 클러스터 버전이 업그레이드되면 이제 Pod들도 Control Plane과 동일한 1.33 버전의 노드에서 실행되도록 업그레이드를 진행합니다.

• 업그레이드 전 Pod 버전

총 6개의 Pod 중 EKS Cluster에서 제공하는 Add on인 coredns와 metrics-server를 먼저 업그레이드해보겠습니다.

먼저 Kubernetes 버전과 호환이 가능한 버전부터 확인합니다. Add on 버전 업그레이드는 AWS 콘솔과 AWS CLI에서 모두 지원됩니다. 이번 실습에서는 AWS CLI로 업그레이드를 진행하겠습니다.

아래 명령어를 통해 1.33버전와 호환가능한 버전으로 업그레이드를 진행합니다.

aws eks describe-addon-versions \
  --addon-name coredns \
  --kubernetes-version 1.33

위 명령어를 사용하면, 현재 EKS 클러스터 버전과 호환 가능한 coredns의 add-on 버전 목록이 반환됩니다.

아래 그림처럼 compatibilities에 defaultVersion이 true인 것이 AWS가 권장하는 버전입니다.

해당 버전으로 업그레이드를 진행해보겠습니다.

아래 명령어를 통해 coredns의 add on 버전을 업그레이드합니다.

aws eks update-addon \
  --cluster-name kyobodts-eks-cluster-1-31 \
  --addon-name coredns \
  --addon-version v1.12.1-eksbuild.2 \
  --resolve-conflicts OVERWRITE

coredns의 버전이 잘 업그레이드 되었는지 확인합니다.

aws eks describe-addon \
  --cluster-name kyobodts-eks-cluster-1-31 \
  --addon-name coredns

이후 Pod의 Node 버전도 1.33 버전으로의 업그레이드가 되었는지 확인합니다.

Coredns의 add on 관련된 pod(node)들의 version이 업그레이드된 것을 확인할 수 있습니다.

다른 Add on들도 위 내용처럼 업그레이드를 진행하실 수 있습니다.

Add on 업그레이드와 비슷한 방법으로 사용자의 애플리케이션 Pod들도 버전 업그레이드를 진행합니다.

무중단 업그레이드를 보장하려면 서비스 특성에 따라 필요한 설정이 조금씩 다르지만, replicas 설정과 readinessProbe 설정을 통해 최소 Pod 하나가 유지되도록하고 새 Pod가 완전히 준비되기 전까지 서비스에 포함되지 않도록 보장하는 설정이 필요합니다.

아래 rollout restart 명령어를 통해 Deployment를 롤아웃시키며, 기존 파드를 순차적으로 종료하고 새로운 파드로 교체합니다.

kubectl rollout restart deployment -n namespace <my-deployment-name>

kubectl rollout restart deployment를 실행하면 새로운 파드를 하나씩 생성하고, 그 새 파드가 준비되면 기존 파드를 하나씩 제거하는 방식으로 순차적으로 교체합니다.

새로운 파드로의 교체가 완료되었습니다.

Fargate 파드들이 Kubernetes 1.33 버전의 노드에서 정상적으로 실행되고 있는 것이 확인되면, EKS 클러스터의 버전 업그레이드는 완료된 것입니다. 이후에는 운영 중인 서비스들도 이상 없이 동작하는지 최종 점검을 수행합니다.

4. EKS Fargate Pod Evictions

EKS Fargate 환경에서는 AWS 측의 정기 유지관리의 일환으로 Fargate 소프트웨어 업데이트 과정에서 Fargate Pod Eviction 이벤트가 발생할 수 있습니다. 보안/성능이 개선된 새로운 OS로 Fargate Node가 교체되면서 기존 Pod가 축출(evict)되고 새로운 OS 버전이 적용된 Fargate Pod가 생성됩니다.
아래는 Eviction 작업 및 OS 패치 관련 주요 작업 내용과 유의사항입니다.

4-1 작업 상세 내용 및 유의사항

해당 작업은 생각보다 주기가 잦아 EKS Fargate Pod 운영 시, 아래 내용을 유의하여 사용하셔야합니다.
작업에 대한 공지는 AWS Health Dashboard를 통해 확인할 수 있으며, 작업 영향 리소스에 대해 안내받을 수 있습니다.

EKS 클러스터에서 노후화된 Fargate 노드(파드)가 존재할 경우, 이와 같은 EKS fargate pod evictions 이벤트가 발생하며, 예정된 시간에 기존 Fargate 노드가 삭제되고, OS 패치가 적용된 신규 Fargate 노드로 교체됩니다. 이 과정에서 파드 역시 삭제 후 재생성되는데 디플로이먼트/레플리카셋의 경우, EKS에 의해 PDB가 자동 적용되어 최소 1개 이상의 파드 실행은 보장하면서 나머지 파드에 대한 교체를 우선 진행하는 무중단 배포(업데이트)가 이루어집니다.

예상 부하에 따라 보다 많은 파드의 실행이 보장되어야 한다면 직접 PDB 리소스를 생성하고, minAvailable을 1보다 큰 N 값으로 설정해서 업데이트 동안 최소 N개의 파드 실행을 보장하실 수도 있습니다. 또한 디플로이먼트/레플리카셋의 Replicas가 1일 경우에는 일시적으로 서비스 중단이 발생하기 때문에 중요한 워크로드에 대해서는 Replicas를 2 이상으로 사전 설정하실 것을 권장합니다.

Fargate OS 패치 예상 시점까지 자동 업데이트를 기다리지 않더라도 Health Event가 공지된 시점 이후로 파드 재생성 또는 kubectl rollout restart를 수행할 경우, 예상 시점보다 앞당겨 수동으로 최신 버전의 Fargate OS 패치를 진행할 수 있습니다.