WEB BE Repository/kubernetes, k8s

[쿠버네티스 튜토리얼] 7. 쿠버네티스의 리소스 조절

조금씩 차근차근 2025. 12. 21. 23:40
본 글은 GPT 정리를 참고하였습니다.

 

쿠버네티스(Kubernetes)에서 “리소스 조절”은 크게 2가지 의미로 쓰인다.

  1. 한 컨테이너/파드(Pod)가 쓰는 CPU·메모리 양을 정하는 것
  2. 부하에 따라 파드/노드 개수를 자동으로 늘리고 줄이는 것

1) 가장 기본: requests / limits (리퀘스트 / 리밋)

파드 안의 컨테이너마다 CPU, 메모리 사용량을 어느 정도로 잡을지를 선언한다.

  • requests (요청량): “최소 이 정도는 필요”
    쿠버네티스 스케줄러(Kubernetes Scheduler)가 파드를 어느 노드(Node)에 올릴지 결정할 때 참고한다.
  • limits (제한량): “최대 이 이상은 못 씀”
    실행 중 제한을 넘으면 제어가 들어가게 된다.
    • CPU는 보통 쓰로틀링(throttling, 속도 제한)이 걸린다.
    • 메모리는 제한을 넘으면 OOM Kill(Out Of Memory Kill, 메모리 부족 강제 종료)이 날 수 있다.

예시(YAML):

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"
  • m는 밀리코어(millicore)라서 250m = 0.25 코어이다.
  • Mi는 메비바이트(mebibyte) 단위이다.

2) 네임스페이스(Namespace) 전체를 제한: ResourceQuota / LimitRange

팀/서비스 단위로 “이 네임스페이스는 총량을 어느 정도까지” 같은 규칙을 걸고 싶을 때 쓴다.

  • ResourceQuota (리소스쿼터, 리소스 할당량 제한)
    • 네임스페이스 전체에 대해 “CPU/메모리 총합”, “파드 개수”, “서비스 개수” 같은 상한을 둔다.
  • LimitRange (리밋레인지, 기본값·최소·최대 강제)
    • 컨테이너 단위의 requests/limits에 대해 “최소/최대”를 강제하거나, 아예 기본값을 자동으로 넣게 할 수 있다.

운영에서는 보통

  • 개인/팀 네임스페이스에 ResourceQuota로 과소비 방지
  • LimitRange로 “requests/limits 반드시 넣기” 문화 정착

이 조합을 많이 쓴다.

3) 자동으로 늘리고 줄이기: 오토스케일링(autoscaling)

여기부터는 “리소스 조절”을 자동화하는 영역입니다. 목적에 따라 3가지가 자주 나오게 된다.

3-1) HPA (Horizontal Pod Autoscaler, 수평 파드 자동 확장)

  • 의미: 파드 개수를 자동으로 늘리고 줄인다.
  • 기준: 보통 CPU 사용률, 메모리 사용률, 또는 커스텀 지표(예: 요청 수).

예: 트래픽이 늘면 파드 2개 → 10개로 증가.

3-2) VPA (Vertical Pod Autoscaler, 수직 파드 자동 확장)

  • 의미: 파드 1개가 쓰는 리소스(requests 중심) 값을 자동으로 올리거나 내린다.
  • 특징: 요청량(requests)을 바꾸려면 재시작이 필요한 경우가 많아서, 운영에서는 “추천 모드(자동 적용은 안 하고 권장값만 제시)”로 먼저 쓰는 경우가 많다.

3-3) Cluster Autoscaler (클러스터 오토스케일러, 노드 자동 확장)

  • 의미: 파드가 들어갈 자리가 부족하면 노드(Node) 개수를 늘리고, 한가하면 줄인다.
  • 전제: 클라우드(예: AWS, GCP)나 노드 풀(Node Pool)과 연동되어 있어야 한다.

4) “누가 먼저 살아남나”도 중요: QoS / PriorityClass

노드가 꽉 차거나 메모리가 부족하면 파드가 축출(eviction)될 수 있는데, 이때 우선순위가 영향을 준다.

  • QoS (Quality of Service, 서비스 품질 등급)
    requests/limits 설정 상태에 따라 파드 등급이 달라진다. 일반적으로 설정이 탄탄할수록 안정적이다.
  • PriorityClass (프라이오리티클래스, 우선순위 클래스)
    중요한 워크로드를 더 우선 배치하거나, 축출 상황에서 덜 밀리게 설정할 수 있다.

어떻게 세팅을 시작하는게 좋을까?

  1. 먼저 모든 컨테이너에 requests/limits를 넣는다.
  2. 팀/네임스페이스에는 ResourceQuota / LimitRange로 가드레일을 둔다.
  3. 트래픽 변동 대응이 필요하면 HPA를 붙인다.
  4. 노드가 자주 부족하면 Cluster Autoscaler를 고려한다.
  5. requests를 잘 잡기 어렵다면 VPA(추천 모드)로 관측하면서 조정한다.