kubernetes 버전업 1.24 에서 1.26까지
쿠버네티스 버전을 1.24 에서 1.26으로 업그레이드한 과정을 공유합니다. (EKS)
버전 업을 해야하는 상황
EKS를 사용하고 있다 보면 AWS에 어느 순간 메일이 전달됩니다.
안녕하세요,
Amazon EKS의 Kubernetes 버전 1.24에 대한 표준 지원이 2024년 1월 31일에 종료됩니다. 2024년 2월 1일부터는 이 버전에서 실행되는 모든 Amazon EKS 클러스터에 확장 지원(extended support)이 적용됩니다. Kubernetes 버전 1.24는 2025년 1월 31일까지 확장 지원 상태로 유지되며, 그 이후에는 이 버전이 Amazon EKS에서 더 이상 지원되지 않습니다.2025년 1월 31일 이후에는 더 이상 새로운 Kubernetes 버전 1.24 클러스터를 생성할 수 없으며, 이 버전을 실행하는 모든 EKS 클러스터는 점진적인 배포 프로세스를 통해 Kubernetes 버전 1.25로 업데이트됩니다.
현재 고객님께서는 Kubernetes 버전 1.24로 실행 중인 EKS 클러스터가 1개 이상 있고 해당 리소스가 AWS 상태 대시보드의 ‘영향을 받는 리소스’ 탭에 나열되어 있기 때문에 이 메시지가 표시되었습니다.
확장 지원은 현재 평가판을 제공하고 있으며 모든 고객이 무료로 이용할 수 있습니다. 2024년 초에 확장 지원이 일반적으로 제공되면 확장 지원 버전을 실행하는 모든 클러스터에 대해 시간당 클러스터당 추가 요금이 부과됩니다. 비용 정보는 해당 기능이 정식 출시되면 발표될 예정입니다.
확장 지원을 사용하지 않으려면 표준 지원 종료일인 2024년 1월 31일 이전에 1.24 클러스터를 Kubernetes 버전 1.25 이상으로 업데이트하는 것이 좋습니다. Kubernetes 버전에 대한 지원 확대에 대해 자세히 알아보려면 출시 발표 [1] 를 참조하세요. 클러스터를 업데이트하는 방법에 대한 지침은 Amazon EKS 서비스 설명서 [2] 를 참조하십시오.
Kubernetes 버전 지원에 대한 자세한 내용은 Amazon EKS 서비스 설명서 [3] 를 참조하시기 바랍니다.
질문이나 우려 사항이 있는 경우 AWS 지원 [4] 에 문의주시기 바랍니다.
이 메일을 요약하자면 현재 사용하고 있는 1.24버전에 대한 표준 지원이 종료되니, 1.25 또는 그 이상의 버전으로 업데이트 하라는 것입니다. 만약 업데이트하지 않고 있는다면 메일의 내용처럼 25년 1월 31일 이후에 자동으로 1.25로 업데이트가 될 것입니다. 만약 k8s 안에 있는 애플리케이션들이 이에 대한 대비가 되어 있지 않는다면 장애로 이어질 수 있을 것 입니다. 따라서 메일이 전달된 이후 k8s 버전 업에 대한 계획을 세우기 시작했습니다.
EKS 버전 업 계획
EKS 버전 업은 1.21에서 1.24로 이미 경험을 한 적이 있었습니다. 당시에 업데이트 하면서 굉장히 오랜시간이 걸렸기 때문에 애플리케이션 다운타임이 상당해서 골치 아팠던 경험이었습니다. 다행히 운영쪽에 사용되는 애플리케이션은 없었고 대부분 개발계 airflow나 mlflow 정도였기 때문에 운영 상의 피해는 거의 없었습니다. 여기서 경험한 바로는 EKS 클러스터의 플러그인 버전을 해당 클러스터 버전에 맞게 맞춰줄 것, 특히 ebs-csi controller log를 확인하면서 ebs 볼륨이 detach, attach 잘 되고 있는지 확인하는 것이 중요했습니다. 또한 AWS 콘솔 상에서 클러스터 버전 업은 금방 처리 되지만 이후에 노드 그룹을 업그레이드를 콘솔에서 하게 되면 상당히 시간이 지체되곤 했습니다. Rancher를 통해 노드 그룹 업데이트를 하는 것도 가능했습니만 이 역시 시간이 상당히 지체되거나 행이 걸리는 경우가 발생했습니다. 그래서 버전 업한 노드그룹을 새로 만들고 기존 노드에 있던 앱들을 옮기는 방식으로 진행했습니다.
*참고로 이 방식은 권장되는 방식이 아닙니다. 이 클러스터는 MLOps용 클러스터였고 특히나 개발계에서 사용되는 클러스터였기 때문에 잠시 순단이 일어나도 용인 가능한 상황이었습니다. 운영에서 버전 업을 할 때는 순단이 최소한으로 일어날 수 있도록 더 많은 조치가 필요합니다.
버전 업을 할 때 주로 참고했던 문서는 AWS에서 제공한 이 문서였습니다. 여기서 기본적인 정보를 파악하고 큰 틀의 계획을 잡았습니다.
- 플러그인 업데이트 (1.25 기준)
- CoreDNS — v1.9.3-eksbuild.2
- 현재 coredns:v1.8.4-eksbuild.1 사용 중
- Kube-proxy — 1.25.6-eksbuild.1
- 현재 v1.21.2-eksbuild.2 사용 중
- VPC CNI — 1.12.2-eksbuild.1
- 현재 v1.10.1-eksbuild.1 사용 중
- aws-ebs-csi-driver- v1.16.0-eksbuild.1
- 현재 v1.14.0-eksbuild.1 사용 중
- CoreDNS — v1.9.3-eksbuild.2
- 클러스터 버전 업 (AWS 콘솔)
- 버전 업된 노드그룹 생성
- 기존 노드 Drain
버전 업 진행
버전 업을 진행하면서 가장 힘들었던 부분은 플러그인 업데이트에 관한 것이었습니다. 플러그인 업데이트만 딱 하면 끝인 줄 알았더니, 업데이트를 위한 Role이나 IAM조정 등이 필요했습니다. 그 중에서 VPC CNI를 설치하면서 나왔었던 Retrying waiting for IPAM-D 가 대표적이었습니다. VPN-CNI 에 대한 설치는 기존에 AWS 콘솔에 있는 애드 온을 이용했었는데, 이를 이용해 업데이트를 하니 발생했던 에러였습니다. VPN-CNI는 k8s클러스터 내에 노드마다 설치가 되며 이는 aws-node-xxxx 와 같이 나타납니다. 이 파드들이 제대로 running되지 못하고 있었고 이에 따라 노드가 정상적으로 실행되지 못하고 있었습니다. 이에 관해서 이 블로그 글을 참조했습니다만 저는 AWS의 EKS 문서에서 Add-ons 부분을 보고 IAM Role을 override하는 방식으로 진행했습니다. Add-ons 부분에서는 VPC-CNI, Core-DNS, Kube-Proxy에 대해서 설정이 가능하고, ebs-csi의 경우에는 Storage 부분에서 해당 내용을 확인할 수 있습니다. 그 외에 참고할 만한 내용들이 있으니 문서를 보시면 버전 업 외에도 클러스터 운영에 관한 도움을 받을 수 있을 것으로 보입니다.
설치 중에 ebs-csi에서도 에러가 발생했습니다. 다음과 같은 에러였습니다.
Conflicts found when trying to apply. Will not continue due to resolve conflicts mode. Conflicts: DaemonSet.apps ebs-csi-node - .metadata.labels.app.kubernetes.io/managed-by DaemonSet.apps ebs-csi-node - .metadata.labels.app.kubernetes.io/version DaemonSet.apps ebs-csi-node - .spec.selector DaemonSet.apps ebs-csi-node - .spec.template.metadata.labels.app.kubernetes.io/managed-by DaemonSet.apps ebs-csi-node - .spec.template.metadata.labels.app.kubernetes.io/version DaemonSet.apps ebs-csi-node - .spec.template.spec.containers[name=”ebs-plugin”].env DaemonSet.apps ebs-csi-node - .spec.template.spec.containers[name=”ebs-plugin”].env[name=”CSI_NODE_NAME”]
…
충돌이 발생했다는 에러메세지였습니다. 아마 AWS 콘솔에서 모든 add-on을 다 설치했다면 이런 에러는 볼 수 없을지도 모릅니다. 왜냐하면 이 에러는 클러스터에 따로 helm으로 ebs-csi를 설치하고, 콘솔을 통해 add-on을 업데이트 하려고 하면 발생하는 에러이기 때문입니다. 클러스터에 설치된 ebs-csi를 제거했고 AWS 콘솔의 add-on으로 설치하니 해당 에러는 발생하지 않았고 정상적으로 설치가 완료 되었습니다.
플러그인 설치 이후에는 모든 작업이 순조로웠습니다. 클러스터 버전 업도 잘되었고 1.25 노드그룹으로의 이전, 그리고 1.26클러스터 업데이트, 1.26 노드그룹 이전 까지 순차적으로 작업이 완료되었습니다.
버전업 이후에는 Airflow나 Kubeflow, mlflow 등 클러스터 안에 설치된 애플리케이션의 기능과 실행에 대해서 확인을 했고 정상적으로 실행이 되었습니다.
주의 점
앞에서 잠깐 나왔지만, 운영 클러스터에는 이 방법을 적용하기는 어려울 것 같았습니다. 노드그룹을 옮기면서 순단이 발생할 수 있고 애플리케이션에 graceful shutdown이 적용되어 있지 않다면 순단이 매우 길어질 수 있기 때문입니다. 특히 실제 애플리케이션에 노출되는 API의 경우에 순단이 발생한다면 연관 백엔드 API에 장애전파가 일어날 수 있어 서킷 브레이커가 적용되어있는지, 만약 API가 동작하지 않는다면 백업 로직은 어떻게 되어있는지를 면밀히 파악하고, 사전에 stg쪽에서 비슷한 상황으로 시뮬레이션하여 백업로직이 정확히 어떻게 동작하는지를 알아놓는 것이 좋습니다.
또한 클러스터 내에서 배치작업 등이 실행된다면 순단이 얼마나 발생하는지 예측하여 해당 시간대에 어떤 배치가 동작해야하는지 알고 있어야 합니다. 따라서 배치 담당자들과 사전에 협의를 해놓는 것이 필요하고 실패시에 어떤 방식으로 복구가 가능한지 계획해놓아야 합니다. 그리고 현재 클러스터에는 Karpenter가 적용이 되어 있습니다. Karpenter에 관한 글은 Kurly의 기술블로그 내용을 참조하면 좋을 것 같습니다. k8s를 업데이트 하면서 deprecated된 API 들이 발생하기 때문에 이를 참고해서 Karpenter의 업그레이드도 버전을 신경써줘야 합니다. 예를 들어 Karpenter v0.28.0 버전은 Kubernetes version 1.26 이상 버전과 호환되지 않습니다. 따라서 1.27이나 1.28을 사용한다면 Karpenter버전을 더 올려주는 것이 좋겠습니다.
Reference
kubernetes 버전업 1.24 에서 1.26까지