Pod 수를 늘리는 방식과 실제 동작 구조
Kubernetes에서 Scale Out은 단순히 서버를 늘리는 개념이 아니다. Kubernetes는 Pod 단위로 애플리케이션을 확장하며, 이를 자동화하기 위한 여러 메커니즘을 제공한다. 이 글에서는 Kubernetes에서 Scale Out이 실제로 어떻게 이루어지는지, 어떤 구성 요소들이 관여하는지를 개념 중심으로 정리한다.
Kubernetes에서 Scale Out의 기본 단위
Kubernetes에서 확장의 최소 단위는 서버가 아니라 Pod다.
- 서버 확장 아님
- 컨테이너 확장 아님
- Pod 개수 증가
즉, Kubernetes의 Scale Out은 “Pod를 더 많이 실행하는 것”을 의미한다.
Scale Out의 출발점: Deployment
Kubernetes에서 Scale Out은 대부분 Deployment를 통해 이루어진다.
Deployment는 다음을 정의한다.
- 어떤 Pod를 실행할 것인지
- Pod를 몇 개 유지할 것인지
Pod 개수를 변경하면 Kubernetes는 자동으로 Pod를 생성하거나 제거한다.
가장 단순한 Scale Out 방식: 수동 확장
가장 기본적인 Scale Out은 Pod 개수를 직접 늘리는 방식이다.
- replicas 값을 증가
- 새로운 Pod 생성
- Service를 통해 자동으로 트래픽 분산
이 방식은 구조를 이해하기 쉽지만, 트래픽 변화에 실시간으로 대응하기 어렵다.
Service가 Scale Out을 가능하게 하는 이유
Pod가 여러 개로 늘어나도 클라이언트는 이를 인지하지 않는다.
그 이유는 Service가 Pod 앞단에서 트래픽을 분산하기 때문이다.
- Pod 증가 → Service 엔드포인트 자동 추가
- Pod 감소 → Service 엔드포인트 자동 제거
Service 덕분에 Scale Out이 자연스럽게 동작한다.
Kubernetes에서 자동 Scale Out: HPA
실제 운영 환경에서는 수동 확장보다 HPA(Horizontal Pod Autoscaler) 가 사용된다.
HPA는 다음 기준으로 Pod 수를 자동 조절한다.
- CPU 사용률
- 메모리 사용량
- 사용자 정의 메트릭
HPA는 Scale Out 결정을 자동으로 내려주는 역할을 한다.
HPA가 Scale Out을 결정하는 방식
HPA는 주기적으로 메트릭을 수집하고 판단한다.
- 현재 Pod 사용률 확인
- 목표 값과 비교
- 필요 시 Pod 수 증가
이 판단 결과는 Deployment에 반영되고, Kubernetes는 즉시 Pod를 추가 생성한다.
Pod가 늘어나면 실제로 일어나는 일
Pod 수가 증가하면 Kubernetes 내부에서는 다음 흐름이 발생한다.
- Deployment의 replicas 증가
- ReplicaSet이 새 Pod 생성
- Scheduler가 Pod를 노드에 배치
- 노드의 Kubelet이 컨테이너 실행
- Readiness Probe 통과
- Service 엔드포인트에 등록
이 과정을 거쳐 Scale Out이 완료된다.
Scale Out이 잘 되기 위한 필수 조건
Kubernetes에서 Scale Out이 제대로 동작하려면 몇 가지 전제가 필요하다.
- 애플리케이션이 무상태 구조일 것
- 세션과 상태를 외부로 분리
- Readiness Probe 설정
- requests / limits 설정
이 조건이 충족되지 않으면 Pod를 늘려도 효과가 제한적이다.
Scale Out과 Load Balancer의 관계
Pod 수가 늘어나면 트래픽은 다음 순서로 분산된다.
- 외부 요청 → Load Balancer / Ingress
- Service
- 여러 Pod
Scale Out은 Load Balancer와 Service가 함께 동작할 때 완성된다.
Pod는 늘었는데 성능이 안 좋아지는 이유
Scale Out을 했음에도 성능이 개선되지 않는 경우가 있다.
- DB가 병목인 경우
- 캐시 미사용
- 외부 API 의존
- 초기화 시간이 긴 애플리케이션
Scale Out은 전체 시스템 중 확장 가능한 부분에만 효과가 있다.
Node가 부족하면 어떻게 될까
Pod를 늘렸는데 실행되지 않는 경우도 있다.
- 노드 리소스 부족
- Pod가 Pending 상태
이 경우에는 Pod가 아니라 노드 자체를 확장해야 한다.
이 역할을 하는 것이 Cluster Autoscaler다.
Pod Scale Out과 Node Scale Out의 차이
- Pod Scale Out
- 애플리케이션 확장
- HPA 담당
- Node Scale Out
- 인프라 확장
- Cluster Autoscaler 담당
두 가지가 함께 동작해야 진짜 자동 확장이 완성된다.
Kubernetes Scale Out의 한계
Kubernetes의 Scale Out도 한계가 있다.
- 상태를 가진 애플리케이션
- DB, 파일 시스템
- 초기 기동 비용이 큰 서비스
이런 경우에는 구조 개선이 선행되어야 한다.
실무에서의 일반적인 Scale Out 흐름
대부분의 서비스는 다음 흐름을 따른다.
- 무상태 애플리케이션 설계
- Service + Ingress 구성
- HPA 적용
- 캐시와 DB 병목 제거
- 필요 시 Cluster Autoscaler 도입
이 순서가 안정적인 확장의 기본 패턴이다.
정리
Kubernetes에서 Scale Out은 Pod 개수를 늘리는 방식으로 이루어진다. Deployment, Service, HPA가 함께 동작해 트래픽 증가에 자동으로 대응한다. 하지만 Scale Out은 모든 문제의 해답은 아니며, 무상태 설계와 캐시, DB 구조까지 함께 고려해야 효과를 낼 수 있다. Kubernetes의 Scale Out을 이해하면 대규모 트래픽 대응 전략을 더 명확하게 설계할 수 있다.