빠르면 몇 달만에 새로운 업데이트 버전이 나오는 k8s cluster에 대처해 프로젝트 역시 업데이트를 주기적으로 진행해줘야 한다.
하지만 메뉴얼 방식으로 직접 cluster를 구성하고 업데이트하는 전략은 클라우드 엔지니어 내지는 Devops 엔지니어의 역할이라고 생각했다.
Amazon EKS를 사용하기에 콘솔에서 업데이트하기엔 너무 편리하고.. 추가적으로 kubeadm를 이용한 방법에 대해서 자료를 찾으면서 k8s 아키텍처에 대해서도 다시금 공부하는 기회가 되었다.
이를 공부하면서 배포중인 애플리케이션에 영향을 주지 않는 업데이트 전략도 마찬가지로 중요함을 이해했고, 어떻게 사용자에게 지장을 주지 않으면서 cluster를 업데이트하는지 배울 수 있었다.
Kubernetes 최신 버전 확인(release)
https://kubernetes.io/releases/
Releases
The Kubernetes project maintains release branches for the most recent three minor releases (1.32, 1.31, 1.30). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch suppo
kubernetes.io
업데이트 날짜 2024-8-13인 1.31 버전이 가장 최신 버전이다.
쿠버네티스는 몇 달에 한번씩 소규모 릴리스를 통해 새로운 피쳐와 기능을 MINOR 버전으로 발표한다.
PATCH 버전은 더 작은 단위로 업데이트되며, 보통 운영중인 클러스터 환경에서는 MAJOR 버전을 따른다.
기본적으로 k8s은 업데이트시 가장 최근의 3개 minor 버전까지만 지원한다.
예를 들어 v1.33 를 출시하면 v1.32, v1.31, v1.30까지만 지원한다는 의미이다. 반대로 현재 버전이 v1.30이라면 v1.33까지 업그레이드할 수 있다.
실제 AWS에서 버전 업그레이드시 한번에 1.33까지 업그레이드하지 못하고 단 하나의 마이너 버전만을 업그레이드하게 제한한다.
그 이유는, kube-apiserver는 controller plane의 주요 구성요소로 다른 컴포넌트들과 통신하기에 가장 높은 버전을 유지해야한다.
Kubernetes 업데이트 전략
kuberctl get nodes 명령어를 통해 현재 클러스터의 버전을 확인할 수 있다.
선행적으로, kubernetes의 구조에 대해 이해해야 업데이트하는 방식을 이해할 수 있으므로 이전 게시글을 참고하기 바람
https://blog.naver.com/downfa11/223552885855
kubernetes 아키텍처 요약
쉽게 생겼는데 사실 화물선으로 예시드는게 더 이해안된다. 그림이 이뻐서.. Kubernetes가 무엇인가에 대...
blog.naver.com
그림으로 설명하면 이해가 쉬울텐데 준비하지 못한게 아쉬움.
master node, worker node 순차대로 진행하되, 사용자에게 지장을 주지 않기 위해 컨테이너화된 애플리케이션이 배포중인 Pod를 이동시키는 방법에 대해 소개했다.
Master Node 업그레이드
-
- 이때, 컨트롤 플레인의 컴포넌트(kube-apiserver, kube-scheduler, kube-controller-manager 등)이 잠시 다운된다.
- 새 앱을 배포하거나 기존 앱을 삭제, 수정할 수는 없지만 Worker Node와 앱에 영향을 주진 않는다.
- 업그레이드가 완료되면 클러스터가 백업되고 이후 정상 작동
Worker Node 업그레이드
-
- Upgrade All of Them At Once : 한번에 모두 업그레이드(잠시 사용자가 앱에 접속할 수 없음)
- Upgrade One Node At a Time : 한번에 노드 하나씩 업그레이드하는데, 이때 Pod들은 정상 노드들로 이동한다.
- Add New Nodes to the Cluster : 업데이트 버전의 노드를 추가하고, Pod들을 새 노드로 옮긴다.
특히 Worker Node를 업그레이드하는 3번째 전략인 'Add New Nodes to the Cluster'는 클라우드 환경에서 편리하고 한번에 이뤄진다는 장점이 있다.
가용성에 문제가 생기는 1번, 노드 개수에 따라 번거로운 작업이 이뤄지는 2번에 비해 매력적인 선택지라고 생각한다.
어떻게 Kubernetes를 설치했는가?에 따라서 업그레이드 방법이 나뉜다.
방법1 - Cloud Service Provider
GKE, EKS, AKS 같은 클라우드 서비스는 업그레이드를 자체적으로 지원한다.
우선 클러스터의 컨트롤 플레인 영역의 k8s 버전과 사용자 노드의 k8s 버전이 동일한지 확인합니다.
- 클러스터 컨트롤 플레인의 k8s 버전 확인
- 사용자 노드의 k8s 버전 확인
kubectl version
kubectl get nodes
노드의 버전이 더 낮은 경우, 컨트롤 플레인의 버전을 업데이트하기전에 노드부터 업데이트해줘야한다.
나는 AWS에서 프로젝트를 진행하기에 맞춰서 3가지 방법을 소개하겠다.
1. AWS Console : 그냥 EKS 들어가서 버튼 딸깍 한번에 업데이트를 진행(...)
2. eksctl : 0.184.0버전 이상부터 적용
eksctl upgrade cluster --name my-cluster --version 1.31.x --approve
3. AWS CLI : 다음 명령어로 Amazon EKS 클러스터를 업데이트
aws eks update-cluster-version --region region-code --name my-cluster --kubernetes-version 1.31.x
aws eks describe-update --region region-code --name my-cluster --update-id b5f0ba18...
// describe-update : 클러스터의 업데이트 상태를 모니터링
방법2 - kubeadm
간편하게 클러스터를 설치, 업데이트하는 툴
2-1. upgrade kubeadm(controll plain node)
upgrade kubeadm(controll plain node)
apt-get upgrade -y kubeadm=1.31.x
sudo kubeadm upgrade apply v1.31.x
cluster를 업그레이드하는 명령어(controll plain 영역의 구성 요소 변경)
각 노드들의 kubelet 버전을 보여주기 때문에, 아직 kubectl get nodes로 보면 아직 기존 버전으로 이뤄진다.
2-2. upgrade kubelet(master node)
apt-get upgrade -y kubelet=1.31.x
sudo systemctl restart kubelet
sudo kubectl get nodes
보통 마스터 노드 안에 kubelet이 있고 컨트롤 플레인 컴포넌트를 실행하는데 쓰인다.
2-3. upgrade worker nodes
kubectl drain 명령어로 모든 Pod를 안전하게 종료한 뒤 재조정하기
worker node에서 kubeadm, kubelet 패키지를 업데이트
apt-get upgrade -y kubeadm=1.31.x
apt-get upgrade -y kubelet=1.31.x
sudo kubeadm upgrade node config --kubelet-version v1.31.x
sudo systemctl daemon-reload
sudo systemctl restart kubelet
방법3 - Manual Installation
직접 하나씩 설치하는건 devops 엔지니어가 하자...ㅎㅎㅎ
사실 더 중요하게 다뤄야할건 k8s cluster 업그레이드가 아니라, 그 과정에서 데이터 마이그레이션이라고 생각한다. 좀 더 여유가 생긴다면 고민해보겠다.
출처 및 인용.
kubernetes 공식문서 - Kubeadm cluster 업그레이드
https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/update-cluster.html
https://kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
'kubernetes' 카테고리의 다른 글
Service Mesh - Kubernetes가 있는데 왜 Istio가 필요한가요? (0) | 2025.03.12 |
---|---|
minikube로 로컬 환경을 구축해보자 (feat. Kubernetes Java Client 도입) (0) | 2025.02.11 |
구글 현직자분께 물어본 Kubernetes와 보그(Vogue) 비교 (0) | 2024.11.19 |
ArgoCD를 이용한 무중단 배포하기(Canary 방식, argo-rollout) (0) | 2024.11.19 |
Spring Boot Actuator를 이용한 Kubernetes Pod의 Health check (0) | 2024.11.19 |