24년 3분기 세일기간이 일주일동안 있었고, 얼마 전에 끝났습니다. 대외 서비스 파트는 아니지만, 담당하고 있는 인프라를 모니터링하며 수면시간도 그리 길게 가지지 못했던것 같습니다. 이번 글에서는 이번 세일기간에 관리형 쿠버네티스를 운영하며 겪은 일을 공유해 보고자 합니다.
증상 발현
세일 첫날이 시작되는 시간인 00:00시가 다가옴에 따라 긴장을 하고 있었습니다. 그리고 모니터링을 하던 중에 세일이 시작되고, 사용자들은 선착순으로 주어지는 베네핏을 받기 위해서 많은 사용자가 한번에 유입이 되었습니다.
그리고, 문제가 생겼습니다. 그렇게 규모가 크지 않은 클러스터라 POD의 IP대역은 /21 으로 적당히 설정하고 사용하고 있었는데요. 파드가 스케일 아웃이 되며 늘어나야하고, 노드도 늘어야하는데 노드가 늘어나지 못하니 파드도 생성이 되지 못하는 현상이 있었습니다.
문제의 원인이 무었이었나요
분명 IP대역도 여유가 있는데, 노드가 늘지 못한 것을 확인해보니 IP 부족이라고 뜨는것이었습니다. 그래서 여러 문서를 계속해서 찾아봤습니다. 그렇게 찾은 문서는 노드당 최대 포드 수 구성이었습니다. 문서를 읽어보니, 제가 생성할때 설정한 노드당 최대 파드의 수를 크게 신경쓰지 않고 110으로 설정했다는 것을 알았습니다.
그리고 문서를 보며 제가 한가지 놓친것을 알게 되었습니다.
클러스터에 대해 노드당 최대 포드 수를 구성할 때 Kubernetes는 이 값을 사용하여 노드에 대해 CIDR 범위를 할당합니다. 포드에 대한 클러스터의 보조 IP 주소 범위 및 노드에 대한 할당된 CIDR 범위를 기준으로 클러스터의 최대 노드 수를 계산할 수 있습니다.
예를 들어 기본 최대 포드 수를 110으로 설정하고 포드의 보조 IP 주소 범위를 /21로 설정하면 Kubernetes는 /24 CIDR 범위를 클러스터의 노드에 할당합니다. 이렇게 하면 클러스터에서 최대 2(24-21) = 23 = 8개 노드가 허용됩니다.
문서의 내용대로 계산을 해보니 다음과 같이 계산이 됩니다.
최대 파드의 수: 110(기본값)
IP 주소 범위: /21
노드의 수: 2(24-21) = 2의 3승 = 8 개 노드
아, 정말로 구성하면서 제가 간과했던것이 맞다는 것을 깨닫게 되었습니다. 실제 운영중인 쿠버네티스의 노드풀 스펙은 그렇게 고사양을 사용하지는 않습니다. 현재 운영중인 내부서비스, 외부서비스를 포함하여 비용 최적화를 만든 노드이기 때문에 제가 노드당 최대 파드의 수를 110이 아니라, 노드의 스펙에 맞추어서 생성을 했어야 하는 것이었습니다.
어떻게 해결한건가요?
즉시 계산기를 열어서 계산을 했습니다. 현재 운영중인 노드풀의 사양은 유지하면서 더 여유로운 스케일 아웃을 하기 위한 방법을 찾고자 했습니다. 우선, 사용중인 클러스터 타입은 Standard 클러스터입니다. 그리고 Standard 클러스터에 대한 항목을 알아봅니다.
표준 클러스터의 경우 노드당 최대 포드 수는 기본적으로 110개이므로 Kubernetes는 각 노드에 /24 CIDR 블록(256개 주소)을 할당합니다. 사용 가능한 IP 주소 수가 한 노드에서 만들 수 있는 최대 포드 수의 두 배를 넘으므로, Kubernetes는 노드에서 포드를 추가 및 삭제할 때 IP 주소 재사용을 줄일 수 있습니다.
노드당 포드 수 256개가 하드 한도이지만, 노드에서 포드 수를 줄일 수 있습니다. 노드에 할당된 CIDR 블록 크기는 노드당 최대 포드 수에 따라 다릅니다. 블록에 포함되는 주소 수는 항상 노드당 최대 포드 수의 두 배 이상입니다.
| 노드당 최대 파드의 수 | 노드당 CIDR 범위 | IP 수 |
|---|---|---|
| 8 | /28 | 16 |
| 9-16 | /27 | 32 |
| 17-32 | /26 | 64 |
| 33-64 | /25 | 128 |
| 65-128 | /24 | 256 |
| 129-256 | /23 | 512 |
스펙은 기재하지 않지만, 위의 표를 참고해서 노드풀 스펙에 맞추어 계산을 하고, 다음과 같은 방법으로 작업을 진행했습니다.
작업 조건
- 기본 파드용 서비스넷은 현재 사용불가
- 라이브 상태인 클러스터의 영향도의 최소화
머리굴리기
- 신규 파드용 서브넷 생성(/20)
- 신규 노드풀 생성
- 노드당 최대 파드의 수: 64 EA
- 노드 확장 최대의 수: 32 EA
실행
- 신규 노드풀 생성
- Zone 별 최소 2개씩 기본 배치 설정
- Zone은 3개이니, 빠르개 POD 배치가 가능하도록 6개가 바로 생성되도록 설정
- 기존 노드풀 Code-on 처리
- Deployment의 rollout restart 시 스케쥴링 되지 않도록 처리
- Deployment의 Rollout Restart 처리
- 기존 노드풀 제거 처리
노드풀 생성 작업은 한창 부하가 있는 상태에서 작업하기에는 떨렸기에 사용자들이 빠르게 빠져나가기를(원하는거 다 이루시고 주무시러 가시기를) 바랬습니다.
(물론 이미지와 같이 무탈하게 지나가기를 기도하면서 모니터링을 했던건 비밀….) 얼마 시간이 지나고나서 해당 작업을 진행했습니다. 천만 다행으로 기도가 닿았는지(?) 다행히 노드가 적절하게 늘어나지 못하는 상황에서도 오류 없이 요청들을 잘 받아주어서 참으로 다행이라고 생각하며 위의 작업을 진행했습니다.
이후로는요?
매일 밤마다 기본적인 모니터링을 하려고 대기했지만, 다행히 이슈 없이 기간동안 매우 잘 스케일 아웃이 되었고, 저는 피곤하지만 그래도 잠을 청해볼수 있었던것 같습니다. 이번 일로 깨달은 것은 “세세한 옵션 하나하나 잘 뜯어보는 것이 중요하다"는 것을 다시한번 기억했습니다.