Kubernetes에는 node pool이라는 개념이 있다. 이름에서 알 수 있듯 노드들의 묶음 단위로 보면 된다. 크게는 시스템에서 사용하는 system pool과 user가 사용하는 user 풀로 나눌 수 있다. user pool 또한 워크로드에 따라 또는 vm 스펙에 따라 따로따로 운용할 수 있다.
사용하다보면, 노드풀 스펙의 변경이 필요한 경우가 있다. 나 또한 최근에 platform에 사용되는 서비스만 모아놓는 pool의 메모리가 항상 부족하여 고민에 있던중 바꾸기로 결심하였다. 사실 platform에 올라가는 오픈소스이 개수가 많기도 하였지만 loki가 서비스가 성장할수록 점점 더 많은 메모리를 먹어치우는 바람에 어쩔 수 없이 옮겼어야만 했다. 어느날 출근해서 확인해보니 120회가 넘는 loki 리소스의 eviction 기록이 남아 있더라...
그래서 이번 기회에 노드풀 스펙을 변경하여 메모리를 2배로 늘리기로 결정했다!!
노드풀을 변경할 때, 아래와 같은 포인트들에 대한 고민이 생긴다.
여기서 어느정도 kubernetes를 다뤄본 사람이라면 4번을 제외한 부분은 어느정도 어떻게 해야할지 예상이 될 것이다.
각 항목에 대한 방법을 보자면 아래와 같다.
고민 포인트들에 대해서는 위와 같이 정리 되었다면, 순서를 보자.
'위 방법이 일반적일까?'라는 부분은 판단하기 힘들다. 하지만 현재 이러한 서비스들을 리딩하는 기업들이 사용하는 방법이라고 한다면 조금 더 안심될 것이다.
AKS에서 Cluster를 업그레이드 할 때, 위와 같은 과정을 거쳐 풀들을 업그레이드 한다.
위에서 설명한 cordon과 drain은 아래와 같이 실행하자.
cordon
kubectl cordon <node-names>
drain 명령어
kubectl drain <node-names> --ignore-daemonsets --delete-emptydir-data
조금 더 자세한 내용은 아래 링크를 통해 확인할 수 있다.
https://learn.microsoft.com/en-us/azure/aks/resize-node-pool?tabs=azure-cli&source=docs?wt.mc_id=AZ-MVP-5003065
Microsoft Azure의 AKS는 몇가지 cluster 업그레이드 방법을 제공한다. 그 중, 운영을 담당하는 사람으로서 눈길이 가지 않을 수 없는 아래와 같은 메뉴가 있다.
세상에 Cluter를 자동으로 업그레이드를 해준다구요!?
너무 매력적인 옵션이지만 사용률이 높은지는 모르겠다. 우선 내 주위에는 저 옵션을 사용하는 lion heart는 없다. 사용하고 있는 오픈 소스들의 호환 kubernetes 버전 및 내 yaml 파일들의 deprecation은 없는지 매 업그레이드마다 확인이 필요하다.
자동으로 해놓고 주말이나 밤이나 내가 인지하지 못하는 동안 업그레이드가 진행되어 장애가 발생된다면... 정말 상상하기 싫다.
이번에 노드풀 스펙 업그레이드가 필요해 보여 진행하며, 정리해 보았다. 이번 교훈은 노드풀 교체를 잘하자! 가 아닌 처음부터 노드풀 사이즈 예측을 잘하자.