2025-09-30

1일 1아티클

NHN Cloud

Kubernetes CPU Limit

배경

  • Kubernetes에서 컨테이너 실행 시 Pod 사용
  • Pod 사용 시, 컨테이너의 리소스 할당량은 클러스터의 안정성과 직결되는 문제
  • Pod의 컴퓨팅 리소스는 requests, limits로 설정
  • 컨테이너 메모리 사용량이 한계 도달 시, Pod 재실행
  • CPU 사용량 제한은?

Kubernetes CPU Resource 설정

  1. CPU Requests
    • 컨테이너가 정상 실행하기 위한 최소한의 CPU 양
    • kube-schedulerPod를 노드에 할당하는 스케줄링 작업 시 사용
    • 노드에 Pod의 requests 가용 공간이 있어야 할당
  2. CPU Limits
    • 컨테이너가 사용 가능한 CPU 최댓값, kubelet이 관리
    • Pod 컨테이너가 limits를 초과 사용하려고 시도 시, 인위적으로 낮추는 스로틀링으로 상한선 강제
  3. CPU Unit
    • 1 Kubernetes CPU = 1vCPU or 물리적인 1 CPU 코어의 컴퓨팅 파워
    • Kubernetes는 코어를 밀리코어 단위로 더 나누어 설정 가능
    • 1000m = 1 CPU, 500m = 0.5 CPU
  4. QoS (서비스 품질)
    • Kubernetes는 설정된 requests, limits에 따라 QoS 클래스 자동 할당
    • Guaranteed (보장)
    • Pod 내 모든 컨테이너가 CPU와 메모리에 대한 requests, limits가 모두 설정되어 있고, 값이 서로 동일(requests.cpu == limits.cpu)할 때 할당
    • 가장 높은 우선순위 - Burstable (버스트 가능)
    • Pod 내 최소 1개 이상의 컨테이너가 CPU or 메모리 requests 설정했으나, Guaranteed 조건을 충족하지 못(requests.cpu < limits.cpu)할 때 할당
    • 노드에 여유 리소스가 있을 시, 요창량보다 더 많은 리소스 burst하여 사용 가능 - BestEffort (최선의 노력)
    • Pod 내 어떤 컨테이너도 CPU나 메모리에 대한 requests, limits 설정이 없을 때 할당
    • 가장 낮은 우선순위

Limits 적용 시 발생 가능한 현상

  1. CPU 스로틀링
    • 컨테이너 내 프로세스들이 할당량을 모두 사용 시 발생
    • 할당량이 소진된 프로세스들은 커널 스케줄러에 의해 정지
    • 할당량이 채워지는 다음 주기 시작 전까지 대기
    • 멀티 스레드 애플리케이션에서 크게 발생
  2. 지연 시간 증가
    • 스로틀링은 애플리케이션 요청 처리 시간에 지연을 직접 추가
    • 타임아웃, 연쇄적 장애, 나쁜 사용자 경험
    • 전통적인 CPU 사용률 지표로 확인 어려움
  3. 시끄러운 이웃 오해
    • limits에 의해 하나의 애플리케이션이 리소스가 독점하여, 타 애플리케이션으로의 영향 방지 가능할 것으로 예상 가능
    • 실제는, requests에 의해 경합 상황에서도 적절한 리소스 배분이 가능한 시스템

일반적으로는 requests만 설정하여 노드 가용 자원 사용, 자원 부족 시 비율로 할당받도록 설정 (QoS는 Burstable로 설정)
limits만 설정 시 → requests가 0이 되어 자원 가용량 없는 노드도 스케줄링되며 런타임 시 예측 어려움
CPU request는 Pod가 노드 할당 시 절댓값으로 사용, 할당 후에는 상대적 비율로 사용

오늘 배운 것

  1. DB SELECT 응용 (집계함수, 윈도우함수)
  2. 바이브 프로젝트 회의

내일 할 일

  1. DML, DDL

참고자료

results matching ""

    No results matching ""