EKS 1.29 to 1.31 업그레이드

EKS 1.29 to 1.31 업그레이드 작업 경험을 공유합니다.

이번에 과감하게 처음으로 업무 시간에 작업을 했고 무중단으로 무사히 문제없이 작업을 완료하였다.

이슈 사항으로 Release Note에도 나왔는데, ebs-csi-controller도 같이 업그레이드 하는 정도. 일부 eks에서 add-on이 아닌 helm으로 설치되었는데, 업그레이드 후 문제가 발생하여 add-on으로 변경하였다.

add-on 변경 시 기존 IAM Role에 연결된 SA를 아래처럼 add-on의 SA로 교체해야 한다.

"oidc.eks.ap-northeast-2.amazonaws.com/id/8B8501B08402D1591A69785B69A8447B:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"

업그레이드 작업 자체는 사실 어렵지 않다. 다만, 평소에 준비가 필요하다. EKS 업그레이드 작업은 그냥 기존 노드가 새로운 버전의 노드로 교체되는 작업이다. 노드 교체 자체는 사실 카펜터를 사용한다면 수시로 일어나는 일이다. 즉, 평소에 노드 교체 작업 시 서비스에 문제가 없었다면 EKS 업그레이드 작업에도 문제가 없어야 한다. 이게 어려운 일이기는 하다. ㅎㅎ

그럼 안전하게 노드가 교체되기 위한 전제 조건을 알아보자.

• 같은 파드가 여러 종류에 파드에 분산되어 실행되도록 podAntiAffinity, topologySpreadConstraints 설정이 필요하다. 필자는 topologySpreadConstraints + matchLabelKeys 설정을 사용한다.

• PDB 설정
  노드가 재시작되어도 서비스에 이상없도록 PDB 설정이 필요하다. min or max 설정을 하여 서비스 보장되도록 한다. (필자는 사용하지 않지만….)

• 그리고 readiness/liveness probe, preStop, terminationGracePeriodSeconds, do-not-evict 등의 설정이 필요하다.

위와 같은 설정이 잘되어있으면 업그레이드 작업해도 서비스에 문제가 없다. 업그레이드 작업 시 문제가 발생하면 업그레이드 작업 자체의 문제보다는 평소에 고가용성 구성이 잘 안되어 있는 것이다.

업그레이드 작업 순서는 아래와 같다.

• 사전 release note 검토
• AWS 엔지니어 대기 요청
• 사전 서비스 확인
• k9s, 데이터독 등 모니터링 준비
• upgrade insights 권고 사항 f/u
• 콘솔 이용 eks upgrade
• add-on upgrade
• Karpenter 파드 upgrade
• 이전 버전 전체 노드 Cordon
• 전체 노드 순차적으로 drain
• ebs add-on 설치
• 상세 서비스 확인 요청

공식 문서를 참고하여 Release Note를 검토한다. eks 버전에 따라 같이 업그레이드 해야 할 구성 요소들이 있다.

가능하면 AWS 엔지니어 대기 요청을 한다. 문제가 발생하면 빠르게 지원을 받을 수 있다.

작업 전 먼저 간단히 서비스, 파드 정상 실행 여부 확인한다. 업그레이드 작업과 무관하게 이미 문제가 있을 수 있다.

작업 중 모니터링 준비
k9s로 업그레이드 작업 시 전체 파드의 정상 실행 여부를 한번에 확인할 수 있다. 추가로 데이터독 등 모니터링 시스템에서 업그레이드 작업 중 TPS 변화 내역 등을 실시간으로 추적한다.

필요에 따라 uptime-kuma, k6s 등으로도 서비스 Ping 이상 여부를 확인할 수 있다.

upgrade insights
AWS는 친절하게 업그레이드 전 API 버전 호환, Add-on 지원 여부를 사전에 알려준다. 해당 권고 사항을 참조하여 사전에 작업한다. 필자는 Add-on ebs-csi-controller, kube-proxy 업그레이드 작업을 진행하였다.

컨트롤 플레인 업그레이드
어드민 웹콘솔에서 작업해도 되고 테라폼 코드로 관리하면 테라폼을 사용할 수도 있다. 이전에는 테라폼으로 업그레이드 작업을 하였는데, 이번은 콘솔로 작업했다. 이전 테라폼 코드에 문제가 있었다. (굳이 테라폼 소스 코드를 수정하는 수고를 들이지 않았다.)

테라폼 코드로 업그레이드 작업하는 것이 물론 좋다.

1.29 to 1.31 2가지 버전을 업그레이드 했는데, 하나씩 순차로 컨트롤 플레인 업그레이드 했다. 버전 당 8,9분 소요된다. 반면 워커 노드는 1.29 to 1.31 한번에 업그레이드했다.

Add-on 업그레이드
새로운 EKS 버전은 새로운 add-on 버전을 지원하니 add-on도 컨트롤 플레인 작업 후 업그레이드 하였다. add-on 버전은 latest가 아닌 default를 따랐다. add-on은 1,2분 내에 완료된다.

카펜터 업그레이드
카펜터는 파게이트를 사용한다. 카펜터 파드부터 교체하였다.

이전 버전 전체 노드 Cordon
파드 재배포 시 이전 버전 노드에 배포되지 않도록 기존 버전의 전체 노드를 Cordon 한다.

이제 전체 노드를 한대씩 순차적으로 drain 한다. drain 하면 새로운 노드에 파드가 배치되어야 하는데, 이전 버전 노드는 Cordon 되어 있으니 카펜터가 새로운 노드를 실행하는데, 새로운 노드는 업그레이드 된 컨트롤 플레인 버전을 따라서 새로운 버전이 스케줄된다. drain 된 전체 파드가 새로운 노드에서 정상 Running 상태로 변경되면 다음 노드를 drain 한다. 이렇게 순차적으로 전체 노드를 drain 하여 새로운 노드로 하나씩 완전히 교체한다.
(k rollout restart deploy --all, k rollout restart sts --all를 이용해도 된다.)

파드가 이전되면 기존 노드는 카펜터가 자동으로 delete 한다.

노드 교체 완료하고 일부 eks의 ebs-csi-controller를 add-on으로 교체하는 작업을 진행했다.

여기까지 무사히 작업 완료하면 QA, 백엔드 팀에 전체 서비스 확인 요청을 한다. 문제 없다면 작업이 무사히 완료된 것이다.

EKS 업그레이드 작업도 이제 자주해서 대작업임에도 이젠 그냥 그러려니 한다. 물론 쫄리기는 하지만 ㅎㅎ