쿠버네티스 CPU·메모리 request와 limit 설정 기준

쿠버네티스의 CPU·메모리 request(요청량)는 파드를 어느 노드에 배치할지 판단하는 기준이고, limit(제한값)은 컨테이너가 사용할 수 있는 상한입니다. request가 실제 사용량의 상한이 되는 것은 아닙니다. CPU limit에 닿으면 스로틀링으로 처리량이나 응답 시간이 영향을 받을 수 있고, 메모리 limit을 넘는 할당은 OOM(메모리 부족) 종료로 이어질 수 있습니다. 따라서 일률적인 비율보다 실제 사용량과 장애 허용 범위를 보고 정해야 합니다.

request와 limit이 실제로 하는 일

request는 파드 배치 기준

스케줄러는 파드의 리소스 request와 노드의 할당 가능 자원(allocatable)을 바탕으로 배치할 수 있는 노드를 판단합니다. 요청을 충족할 노드가 없으면 실제 사용량이 낮더라도 파드는 Pending 상태로 남을 수 있습니다. 실행 중에는 노드에 여유 자원이 있을 때 컨테이너가 request보다 더 사용할 수 있지만, request가 사용량을 보장하거나 경합 시 특정 파드의 우선순위를 정하는 설정은 아닙니다. 경합 시 동작에는 CPU 자원 배분, QoS 클래스, 파드 우선순위 등 여러 요소가 관여합니다.

limit은 CPU와 메모리에서 다르게 작동

Linux 노드에서 CPU limit은 컨테이너가 사용할 CPU 시간을 제한합니다. 한도에 도달한 컨테이너는 종료되는 대신 스로틀링(throttling, 실행 시간이 제한되는 현상)을 겪을 수 있어 응답 지연이나 처리량 저하로 이어질 수 있습니다. 메모리 limit은 메모리 사용량 상한으로 작동하며, 이를 초과하는 메모리 할당을 시도하면 커널이 프로세스를 종료할 수 있습니다. 메모리는 CPU처럼 실행 시간을 나눠 제한하는 방식이 아니므로 OOMKilled와 재시작 여부를 함께 살펴야 합니다.

기억할 기준: request는 배치 기준이고 limit은 상한입니다. CPU limit 초과는 스로틀링, 메모리 limit 초과는 OOM 종료 위험으로 나타날 수 있습니다.

CPU·메모리 단위와 값 읽는 법

CPU는 코어 단위 또는 millicpu

쿠버네티스에서 CPU 1은 노드가 물리 호스트인지 가상 머신인지에 따라 물리 코어 하나 또는 가상 코어 하나에 해당합니다. 1000m는 CPU 1, 500m는 CPU 0.5입니다. CPU 값은 노드 성능 대비 비율이 아니라 절대량으로 표현됩니다. 최소 표기 단위는 1m이므로 이보다 작은 정밀도는 사용할 수 없습니다. 작은 값을 적을 때는 소수보다 100m처럼 millicpu 표기를 쓰면 착오를 줄일 수 있습니다.

메모리는 바이트와 Mi·Gi 단위

메모리는 바이트 기준이며 Mi와 Gi는 2진 단위, M과 G는 10진 단위입니다. 예를 들어 512Mi와 512M은 정확히 같은 양이 아닙니다. 메모리 값에 CPU에서 쓰는 m을 붙이면 의도와 크게 달라질 수 있습니다. 400m 메모리는 400Mi가 아니라 0.4바이트를 뜻하므로 단위를 확인하세요.

표기	뜻	실무 점검
cpu: 500m	CPU 0.5	파드 내 컨테이너 request도 확인
memory: 512Mi	메모리 512MiB	피크 사용량과 종료 위험을 함께 고려
requests만 설정	스케줄링 기준 설정	limit 기본값이 적용되는지 확인
limits만 설정	기본 request가 없으면 limit이 request로 복사될 수 있음	LimitRange 등 admission 기본값 적용 여부 확인

초기 설정값은 어떻게 정할까

사용량 자료로 request 후보를 잡기

테스트나 운영 지표에서 평상시와 피크 시간대의 CPU·메모리 사용량을 구분하세요. 평균만으로 request를 정하면 피크 때 요청량에 비해 과밀한 노드에 배치될 수 있고, 짧은 최고치를 그대로 쓰면 스케줄링 가능한 공간을 불필요하게 줄일 수 있습니다. 컨테이너별 메트릭을 확인하고 배포 직후의 초기화 작업, 캐시 적재, 트래픽 급증처럼 평소와 다른 구간도 살펴 request 후보를 정합니다.

limit은 장애 영향과 버스트 특성으로 판단

메모리 limit은 컨테이너의 메모리 사용을 제한하지만, 너무 낮으면 정상적인 피크에도 OOM 종료와 재시작이 반복될 수 있습니다. CPU limit은 CPU 사용을 제한하는 대신 스로틀링과 지연을 만들 수 있으므로 지연 민감 서비스인지, 클러스터 격리가 필요한지 함께 판단합니다. CPU limit을 설정하지 않는 선택도 가능하지만, 이 경우 네임스페이스 정책과 노드 자원 경합을 고려해야 합니다. 하나의 정답 비율이나 모든 워크로드에 적용할 고정값은 없습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: app
          image: example/app:stable
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1000m"
              memory: "512Mi"

위 숫자는 설정 형식을 보여주는 예시일 뿐 권장 고정값이 아닙니다. 일반 컨테이너 기준 파드의 총 request와 limit은 각 컨테이너 값의 합으로 생각할 수 있습니다. 다만 초기화 컨테이너와 사이드카 등 파드 구성에 따라 유효 자원 계산 방식이 달라질 수 있으므로 해당 구성을 함께 확인하세요. 적용 후에는 실제 파드 스펙과 관측된 사용량을 비교합니다.

실무에서 적용하고 검토하는 순서

1. 워크로드를 구분합니다. 온라인 API, 배치, 캐시처럼 트래픽과 메모리 사용 패턴이 다른 구성요소를 나눕니다.
2. 관측 구간을 확보합니다. 정상 시간대뿐 아니라 피크, 배포, 재시작 전후의 CPU·메모리 지표를 봅니다.
3. request부터 설정합니다. 스케줄링 실패와 노드 과밀을 고려해 컨테이너별 값을 정하고, 파드 내 사이드카도 포함합니다.
4. limit을 위험에 맞춰 정합니다. 메모리 OOM과 CPU 스로틀링이 서비스에 미치는 영향을 검토하고, 필요한 경우 단계적으로 조정합니다.
5. 배포 후 결과를 확인합니다. Pending, OOMKilled, 재시작 횟수, CPU throttling, 지연 시간과 처리량을 함께 살핍니다.

HPA와 네임스페이스 정책도 연결해서 확인

HPA(Horizontal Pod Autoscaler, 파드 수 자동 조절)가 CPU 사용률을 기준으로 동작한다면 CPU request 설정이 중요합니다. 사용률은 현재 사용량을 request와 비교한 값이므로 request가 없으면 해당 사용률 기반 지표를 계산하기 어렵습니다. 네임스페이스의 LimitRange는 기본 request·limit이나 최소·최대값을 적용하고 검증할 수 있으며, ResourceQuota는 네임스페이스 전체 자원 사용량을 제한할 수 있습니다. 매니페스트에 값이 빠졌더라도 정책이 값을 주입했을 수 있으니 실제 생성된 파드 스펙을 확인하세요.

자주 하는 실수와 확인 방법

• 모든 컨테이너에 같은 값을 복사: 앱과 로그 수집 사이드카의 자원 패턴은 다를 수 있습니다.
• request를 실제 사용량 상한으로 오해: request보다 더 쓸 수 있지만, 노드 여유와 경합 상황에 따라 달라집니다.
• limit만 적고 request를 놓침: 기본 요청값이 적용되지 않으면 limit 값이 request로 복사될 수 있어 스케줄링 판단에 영향을 줍니다.
• OOM을 메모리 limit만의 문제로 단정: 노드 메모리 압박과 종료 사유, 재시작 기록도 함께 확인해야 원인을 좁힐 수 있습니다.
• 노드 총량만으로 계산: 파드에 쓸 수 있는 할당 가능 자원은 노드 총 용량보다 적을 수 있습니다. 노드의 Allocatable과 이미 예약된 request를 봅니다.

확인에는 kubectl describe pod로 이벤트와 종료 사유를 보고, kubectl describe node에서 Allocatable 및 할당 현황을 살펴볼 수 있습니다. kubectl top pod와 kubectl top node는 현재 사용량을 파악하는 데 도움을 주지만 짧은 피크나 과거 추세를 대신하지는 않습니다. 장기 관측 자료와 애플리케이션 지표를 함께 사용하세요.

운영 점검: YAML에 적은 값만 보지 말고 admission 정책을 거쳐 생성된 파드의 실제 request·limit, 노드 Allocatable, OOM·스로틀링 지표를 확인하세요.

세부 동작과 단위는 쿠버네티스 공식 리소스 관리 문서, 네임스페이스 기본값과 제한은 LimitRange 문서, 네임스페이스 총량 제한은 ResourceQuota 문서, HPA의 request 대비 사용률 계산은 Horizontal Pod Autoscaling 공식 문서에서 확인할 수 있습니다.

자주 묻는 질문

Q. request보다 CPU를 더 사용할 수 있나요?

가능합니다. 노드에 여유 자원이 있으면 request 초과 사용이 허용될 수 있습니다. 다만 노드 경합 시 request는 자원 할당과 스케줄링 판단에 쓰이는 기준이며, limit을 설정했다면 그 상한에서 스로틀링될 수 있습니다.

Q. CPU limit을 꼭 설정해야 하나요?

항상 필수인 것은 아닙니다. limit은 CPU 사용을 제한하지만 지연을 유발할 수 있어 워크로드 특성과 격리 정책에 따라 판단해야 합니다. limit이 없을 때는 다른 파드와의 경합 및 네임스페이스 정책도 확인하세요.

Q. 메모리 limit을 초과하면 즉시 종료되나요?

항상 즉시 종료된다고 단정할 수는 없습니다. 메모리 할당을 제한하는 동작은 구현과 상황에 따라 다를 수 있고, 커널이 메모리 부족 상태를 처리하면서 프로세스를 종료할 수 있습니다. 컨테이너의 종료 사유와 재시작 여부를 확인하세요.

Q. limit만 설정하면 request는 어떻게 되나요?

별도의 기본 요청값이 적용되지 않는 경우, 쿠버네티스는 해당 limit 값을 request로 복사해 사용할 수 있습니다. LimitRange 같은 admission 정책이 기본값을 적용하는지도 확인하고 최종 생성된 파드 스펙을 살펴보세요.

참고자료

• Resource Management for Pods and Containers – Kubernetes
• Limit Ranges – Kubernetes
• Resource Quotas – Kubernetes
• Horizontal Pod Autoscaling – Kubernetes