쿠버네티스 리소스 계산기

밀리코어와 메모리 접미사를 변환하고, 레플리카 수만큼 곱하고, kubelet이 매길 QoS 클래스를 보여줍니다. 접미사 비교표는 Mi와 M의 차이를 눈으로 보여주는데, 조용한 과금과 갑작스러운 OOMKill이 바로 여기서 나옵니다.

예시 워크로드

레플리카

CPU request

CPU limit

메모리 request

메모리 limit

QoS 클래스: BurstableCPU limit이 request의 5.0배메모리 limit이 request의 2.0배

	파드당	× 레플리카 3개
CPU request	0.1	0.3
CPU limit	0.5	1.5
메모리 request	128Mi	384Mi
메모리 limit	256Mi	768Mi

매니페스트 조각

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

# 3 replicas require
#   cpu    0.3 cores requested, 1.5 at the limit
#   memory 384Mi requested, 768Mi at the limit

Mi는 M이 아닙니다

쿠버네티스는 2진 접미사와 10진 접미사를 모두 받는데, 크기가 다릅니다.

접미사	바이트	접미사	바이트	차이
1Ki	1,024	1k	1,000	+2.4%
1Mi	1,048,576	1M	1,000,000	+4.9%
1Gi	1,073,741,824	1G	1,000,000,000	+7.4%

그래서 1G는 1G, 1Gi는 1Gi 로 약 7% 차이가 납니다.

전부 브라우저 안에서 처리됩니다. 이 페이지는 정적 파일입니다. 입력한 내용은 탭 안에만 머물고 서버로 전송되지 않으며 창을 닫으면 사라집니다. 실제 토큰이나 설정을 붙여넣어도 안전합니다.

이럴 때 씁니다

Deployment 크기를 정하면서 레플리카 수가 클러스터 용량을 얼마나 차지할지 계산할 때.
Guaranteed로 만들려고 했는데 왜 Burstable이 됐는지 확인할 때.
docker-compose의 메모리 제한을 매니페스트가 기대하는 단위로 옮길 때.

실제 예제

밀리코어

입력: 500m
결과: 0.5 코어

1000m이 1코어입니다. request가 100m이면 스케줄러가 코어의 10분의 1을 예약합니다.

돈이 새는 접미사

입력: 1000M vs 1Gi
결과: 1,000,000,000 vs 1,073,741,824 바이트

Mi를 쓰려다 M을 쓰면 의도보다 약 7% 적은 메모리를 받습니다.

Guaranteed QoS

입력: requests == limits
결과: Guaranteed

CPU와 메모리 모두 request가 limit과 정확히 같을 때만입니다. 그 외에는 Burstable이고 자원이 부족할 때 더 먼저 쫓겨납니다.

자주 틀리는 부분

Mi를 쓸 자리에 M을 쓰는 것

512M은 512,000,000바이트, 512Mi는 536,870,912바이트입니다. 둘 다 유효한 매니페스트라 아무 경고도 없고, 파드만 숫자가 시사하는 것보다 적은 메모리를 받습니다.

CPU limit을 request보다 훨씬 크게 잡는 것

limit이 request의 몇 배면 파드가 잠깐 치솟았다가 노드가 바빠지는 순간 심하게 throttle됩니다. 애플리케이션 버그처럼 보이는 지연 스파이크가 사실 CFS throttling인 경우가 많습니다.

request를 아예 안 쓰는 것

request가 없는 파드는 BestEffort라 노드가 부족해지면 가장 먼저 쫓겨납니다. 스케줄러에게 판단 근거도 주지 않아 노드가 고르지 않게 채워집니다.

자주 묻는 질문

request와 limit은 어떻게 다른가요?

request는 파드를 배치할 때 스케줄러가 예약하는 양이고, limit은 런타임에 커널이 강제하는 상한입니다. request는 어디에 뜰지를, limit은 언제 throttle되거나 OOMKill될지를 결정합니다.

QoS 클래스는 어떻게 정해지나요?

모든 컨테이너의 CPU·메모리 request가 limit과 같으면 Guaranteed, request도 limit도 없으면 BestEffort, 그 사이는 전부 Burstable입니다. 축출이 이 순서로 일어나기 때문에 중요합니다.

CPU limit을 꼭 걸어야 하나요?

메모리 limit만 걸고 CPU는 열어두는 팀이 많습니다. 메모리 limit 초과는 컨테이너를 죽이지만 CPU limit 초과는 throttle에 그치는데, 놀고 있는 용량을 쓰게 두는 것보다 지연 측면에서 더 손해인 경우가 많기 때문입니다.