DEVOCEAN

EKS 는 쿠버네티스 업스트림 릴리즈에 맞춰 연 3~4회 정도의 신규 버전이 출시됩니다.

1개 버전씩 업그레이드가 가능하며, 다운그레이드는 불가합니다.

게다가 EKS 버전 업그레이드를 위해서 전체 Workder Node의 재실행, 쿠버네티스 기능 변경에 대한 Application 영향도 검토 등이 필요하기 때문에 간단한 작업은 아닙니다.

이번 글에서는 이처럼 영향도가 크지만 빈번하게 작업이 필요한 EKS 업그레이드를 위한 내용을 정리해 보았습니다.

TANGO에서는 수천개의 Pod가 동작하는 EKS Cluster 를 운영하고 있는데, 아래와 같은 방식으로 이미 7~8 차례 정도 서비스 중단없이 성공적으로 업그레이드를 진행하였습니다.

EKS 버전정책

링크 는 EKS 버전 정책에 대한 내용입니다. 내용을 요약하자면 아래와 같습니다.

• EKS 신규버전 출시는 쿠버네티스 업스트림 릴리즈 주기(4개월)을 따름.

• 신규버전 출시후 14개월간 표준지원 (무료)

• 표준지원 종료후 12개월간 추가지원 (유료 - Cluster 당 0.6$/h)

• 추가버전 종료까지 업그레이드를 하지 않을경우 가장 마지막 버전으로 강제 업그레이드

• 평균적으로 업스트림 릴리즈 이후 약 2~6개월 이후 EKS 지원

추가로, EKS는 1개 버전씩만 업그레이드가 가능하며, 다운그레이드는 불가합니다. (링크 참고)

짧은 릴리즈 주기(4개월), 짧은 AWS 지원기간 (14개월+12개월), 1개 버전 업그레이드 가능 등을 고려했을때,

EKS 업그레이드 작업은 상당히 자주 필요함을 알수 있습니다.

EKS 업그레이드를 위해서 해야 할 일

EKS 업그레이드를 위해서는 다음과 같은 일이 필요합니다.

1. K8S 변경사항 사전검토

2. EKS Cluster 및 Nodegroup 업그레이드

3. Add-on 업그레이드

4. (CA 업그레이드)

5. 각종 Package 업그레이드

아래에서 각 단계에 대해서 좀더 자세히 설명하겠습니다.

1. K8S 변경사항 사전검토 (feat. EKS Upgrade Insight)

새로운 쿠버네티스 버전이 릴리즈 될때마다 다양한 기능변경이 있습니다.

거의 매 버전마다 각종 Alpha, Beta API 가 추가되거나 삭제됩니다.

내부 로직변경 등 비교적 간단한 변경부터, container-run-time 변경(1.24) 등 영향도가 큰 변경사항이 있고, topology-aware-hint (1.25) 등 새로운 기능도 추가됩니다.

이러한 변경사항이 Application 에 미치는 영향도에 대해서 사전 검토가 필요합니다.

AWS에서는 23년 12월부터 EKS 업그레이드를 위해서 아래와 같은 Upgrade Insight 라는 기능을 제공합니다.

• 사용자의 클러스터를 스캔해 업그레이드시 문제가 될만한 항목을 사전에 검출

• 해결 권장사항 제공

추가로 링크와 같이, EKS 버전에 따른 중요 변경사항이나 점검 방법 등에 대해서 정리된 document도 제공합니다.

쿠버네티스 공식 문서를 살펴보는게 가장 좋지만, 일반적인 환경을 사용중이라면, 해당 내용 정도만 검토해도 충분하지 않을까 합니다.

TANGO 의 경우, 삭제된 Beta API 를 사용하는 오픈소스가 있어서 업그레이드 후 정상적으로 동작하지 않은 경우가 있었고, 그 외에는 대부분 사전에 점검 및 조치가 가능했습니다.

그리고 신규 버전의 change log를 검토하면서 비용절감이나 서비스 고도화 등에 대한 아이디어를 얻을수 있으니, 신규 기능에 대해서도 가급적 살펴보시기를 권장합니다.

2. EKS Cluster 및 Nodegroup 업그레이드

실제 Cluster와 Nodegroup 업그레이드 작업을 진행합니다.

EKS는 AWS Console 에서 클릭으로 진행이 가능하기 때문에 작업 자체는 간단합니다.

아래처럼 "Cluster Update" 클릭후 실행합니다.

Nodegroup 에서 AMI release version 의 "Update now"를 클릭합니다

(아래 사진에서는 현재 최신버전이 적용되어 있어서 관련 버튼이 보이질 않습니다)

AWS 는 아래처럼 Cluster 업그레이드가 안전하게 진행된다고 설명합니다. 링크)

업데이트 프로세스는 Amazon EKS에서 업데이트된 Kubernetes 버전으로 새 API 서버 노드를 시작해 기존 노드를 대체합니다.

Amazon EKS는 이러한 새 노드에서 네트워크 트래픽의 표준 인프라 및 준비 상태 검사를 수행하여 예상대로 작동하고 있는지 확인합니다.

하지만 클러스터 업그레이드를 시작한 후에는 일시 중지하거나 중지할 수 없습니다.

이러한 검사 중 하나라도 실패하면 Amazon EKS는 인프라 배포를 되돌리고, 클러스터는 이전 Kubernetes 버전으로 남아 있게 됩니다.

실행 중인 애플리케이션은 영향을 받지 않으며, 클러스터가 불확정적 또는 복구 불가능 상태로 남아 있는 일은 없습니다.

하지만, 콘솔이나 UI 에서 업그레이드 절차가 따로 표시되지 않기 때문에 아무래도 불안한건 어쩔수 없습니다.

CloudWatch Logs(사전에 로그 수집 설정 필요) 나 kubectl 등으로 로그 확인이 가능합니다.

주의할점은, 전체 Node의 재실행이 필요하기 때문에, Pod의 종료에 대한 영향도 검토가 필요합니다.

만일 모든 Pod가 Stateless 하고 HA가 잘 구성되어 있다면 문제가 없지만, 동시에 종료될 경우, 비즈니스적으로 문제가 되는 Pod 들이 있거나,

statefule 하거나, 단독으로 동작하는 Pod 등이 있다면 이를 고려하여 Nodegroup 업그레이드를 진행해야 합니다.

경험적으로, Cluster 는 10분 이내, Node는 3분/대 (Forced 옵션 기준) 정도 소요가 됩니다.

다만, Node 업그레이드는 옵션(Forced/Rolling), instance type, Pod 설정 등에 따라 차이가 많이 날수 있습니다.

3. Add-on 업그레이드

EKS 에서는 coredns, kube-proxy, CNI 및 각종 CSI 등 주요 Workload 이 Add-on 으로 제공됩니다.

업그레이드한 EKS 버전에 알맞게 Add-on 업그레이드가 필요합니다. (Add-on 에 대한 설명은 링크를 참고하세요)

가급적 각 Add-on 의 가이드 문서를 참고해서 권장하는 버전으로 업그레이드를 하되, 일부 명확한 가이드가 없는 Add-on 의 경우는 최신 버전으로 업그레이드 합니다.

각 Add-on 별 가이드는 링크 를 참고하세요

참고로, TANGO 에서는 업그레이드나 버전관리의 부담을 최소화 하기 위해서 Add-on 으로 제공되는 Package 에 대해서는 가급적 직접설치하지 않고 Add-on 을 우선 사용합니다.

4. CA 업그레이드

CA(Cluster AutoScaler) 를 사용중이라면, EKS Cluster 버전과 일치하는 버전으로 업그레이드를 합니다.

만일 Karpenter 나 다른 Scaling Package 를 사용한다면, 가이드를 참고해서 적절한 버전으로 업그레이드를 합니다.

TANGO 는 현재 CA 를 사용하고 있습니다.

Karpenter 의 여러 장점이 있어 Migration 을 고려중이긴 하지만, 사용상에 특별한 문제가 없어서, 당장은 유지중입니다.

(Karpenter v1.0 이 Release 되면, 다시 고려해볼 예정입니다)

5. 각종 운용 Package 업그레이드

필수는 아니지만, 그 외에 각종 운용 Package 를 업그레이드 합니다.

어느 정도 기간은 업그레이드 없이 사용은 가능합니다.

다만, 쿠버네티스의 생태계의 특성상, 업그레이드 속도가 상당히 빠르고,

EKS 정책상, 특정 버전을 계속해서 유지할수 없기 때문에, 운용 Package들도 최신 버전을 따라가지 않는다면, 2~3년 내에는 문제가 발생할 수 있습니다.

기본적으로 kubectl 는 쿠버네티스와 동일 버전으로 업그레이드 합니다. (+1 버전의 호환성은 보장)

그 외에 alb-controller, argocd, sealed-secret, kubecost 등 사용하는 운용 Package 업그레이드를 합니다.

쿠버네티스 버전에 의존성이 없는것들이 대다수 이지만, 영향이 있을수 있습니다.

가급적 Package별 최신 버전을 확인하고, 업그레이드를 검토하시기를 권장합니다.

개인적으로 이 부분이 상당히 까다로운 부분인것 같습니다.

모든 오픈소스의 변경사항을 F/U 하고, 쿠버네티스 버전의 의존성을 파악한다는 것이 현실적으로 쉽지 않습니다.

alb-controller, argocd 등 일부 Tool들은 오류가 발생했을때 서비스 영향도가 크기 때문에 업그레이드 부담도 상당합니다.

TANGO 에서도 개발환경에서 업그레이드 진행시 몇 차례 문제가 발생했고, 조치하는데 상당히 애를 먹은 기억이 있습니다.

상용환경에서 문제를 최소화 하기 위해서는, Package 설치/업그레이드 작업시 수동작업을 제거(가급적 최소화) 하고 모든 파라미터 및 설치 커맨드를 코드화 시키는 것이 중요합니다.

이를 위해 개발환경에서 검증된 구성을 동일하게 운영환경에 설치할수 있는 CI/CD 등의 환경이 꼭 필요합니다.

정리하며

쿠버네티스를 사용한다면 빈번한 업그레이드는 선택이 아닌 필수입니다.

EKS 사용하더라도, 절차가 조금 간편하다는것일 뿐, 업그레이드를 자주 필요한 것은 어쩔수 없습니다.

이를 위해 쿠버네티스 도입부터 안정적인 업그레이드를 위한 방안을 함께 설계하는것이 중요합니다.