내 클러스터 지키는 파수꾼: 쿠버네티스 리소스 요청(Request)과 제한(Limit) 완벽 가이드

쿠버네티스 환경에서는 하나의 노드(물리적 또는 가상 머신) 위에 수많은 컨테이너가 함께 실행됩니다. 마치 한 아파트 건물에 여러 세대가 함께 사는 것과 같죠. 만약 아무런 규칙 없이 한 세대가 전기를 있는 대로 끌어다 쓴다면 어떻게 될까요? 건물 전체가 정전될 수도 있을 겁니다.

쿠버네티스 클러스터도 마찬가지입니다. 리소스 관리 규칙이 없다면, 특정 컨테이너 하나가 CPU나 메모리를 독차지하는 '시끄러운 이웃(Noisy Neighbor)' 문제가 발생하여 같은 노드에 있는 다른 컨테or이너들의 성능을 저하시키고, 결국 전체 서비스의 안정성을 위협하게 됩니다.

이러한 혼란을 막기 위해 쿠버네티스는 '요청(Requests)'과 '제한(Limits)'이라는 강력한 자원 관리 도구를 제공합니다.

---

1. 핵심 개념: 요청(Requests) vs. 제한(Limits)

요청과 제한은 컨테이너가 사용할 수 있는 시스템 리소스의 양을 정의하는 규칙입니다. 주로 CPU와 메모리에 대해 설정합니다.

요청 (Requests): "이만큼은 꼭 보장해주세요!" 🙋

• 의미: 컨테이너가 정상적으로 동작하기 위해 필요한 최소한의 리소스 양을 의미합니다.
• 역할: 스케줄링에 결정적인 영향을 줍니다. 쿠버네티스 스케줄러는 파드(Pod)의 모든 컨테이너가 요청한 리소스의 총합을 보고, 해당 자원을 할당해 줄 수 있는 충분한 여유 공간이 있는 노드에만 파드를 배치합니다. 만약 모든 노드가 꽉 차서 요청을 만족시킬 수 없다면, 해당 파드는 Pending 상태로 대기하게 됩니다.
• 비유: 호텔을 예약할 때 '싱글베드 1개'를 예약하는 것과 같습니다. 호텔은 최소한 이 침대 하나만큼의 공간은 반드시 고객에게 보장해줘야 합니다.

제한 (Limits): "이 이상은 절대 안 돼요!" 🙅

• 의미: 컨테이너가 사용할 수 있는 최대 리소스 양을 의미합니다. 컨테이너는 이 값을 절대 초과하여 리소스를 사용할 수 없습니다.
• 역할: 런타임에 컨테이너의 리소스 사용을 강제로 제어합니다.
  • CPU 제한: 컨테이너가 CPU 사용량을 제한 값 이상으로 사용하려고 하면, 커널은 해당 컨테이너의 CPU 사용을 강제로 억제(Throttling)합니다. 즉, 애플리케이션이 느려집니다.
  • 메모리 제한: 컨테이너가 메모리 사용량을 제한 값 이상으로 사용하려고 하면, 컨테이너는 경고 없이 즉시 종료(OOMKilled, Out of Memory)됩니다.
• 비유: 호텔 방의 '최대 수용 인원' 규칙과 같습니다. 방이 아무리 넓어 보여도, 규칙으로 정해진 최대 인원을 넘어서 손님을 받을 수는 없습니다.

---

2. 관리할 수 있는 리소스의 종류

CPU

• 단위: m (밀리코어, millicores) 단위를 사용합니다. 1000m는 1개의 CPU 코어와 같습니다. 500m는 CPU 코어의 절반을 의미합니다.
• 특징: 압축 가능한(Compressible) 리소스입니다. 사용량이 제한을 초과해도 컨테이너가 바로 죽지 않고 성능이 저하(throttling)되는 방식으로 제어됩니다.

메모리 (Memory)

• 단위: Ki, Mi, Gi (키비바이트, 메비바이트, 기비바이트)와 같은 단위를 사용합니다.
• 특징: 압축 불가능한(Incompressible) 리소스입니다. 메모리는 CPU처럼 사용량을 줄일 수 없으므로, 제한을 초과하면 프로세스를 강제로 종료(OOMKilled)하는 방법 외에는 없습니다. 따라서 메모리 제한 설정은 매우 중요합니다.

임시 스토리지 (Ephemeral Storage)

• 컨테이너의 쓰기 가능한 레이어, 로그 디렉토리, emptyDir 볼륨 등이 사용하는 로컬 디스크 공간을 의미합니다. 이 리소스에 제한을 걸어 특정 컨테이너가 노드의 디스크를 가득 채우는 것을 방지할 수 있습니다.

---

3. 왜 이렇게 중요할까? 서비스 품질(QoS)의 결정

요청과 제한 설정은 단순히 리소스를 할당하는 것을 넘어, 쿠버네티스가 해당 파드를 얼마나 중요하게 취급할지를 결정하는 서비스 품질(Quality of Service, QoS) 등급을 부여합니다.

노드의 리소스가 부족해지는 비상 상황(메모리 부족 등)이 발생하면, 쿠버네티스는 이 QoS 등급이 낮은 파드부터 순서대로 종료시켜 리소스를 확보합니다.

1. Guaranteed (최고 등급 ⭐⭐⭐)
   • 조건: 모든 컨테이너의 요청(requests) == 제한(limits) (CPU, 메모리 모두).
   • 특징: 가장 높은 우선순위를 가지며, 시스템 리소스가 부족할 때 가장 마지막까지 살아남습니다. 예측 가능한 성능이 필수적인 DB나 중요한 상태 저장 애플리케이션에 적합합니다.
2. Burstable (중간 등급 ⭐⭐)
   • 조건: 요청과 제한 값이 설정되어 있으나, 서로 같지 않은 경우 (요청 < 제한).
   • 특징: 평소에는 요청한 만큼의 리소스를 보장받고, 노드에 여유가 있을 때는 제한 값까지 리소스를 더 사용할 수 있습니다. 일반적인 웹 서버나 대부분의 애플리케이션에 적합합니다. Guaranteed 등급의 파드보다는 먼저 종료될 수 있습니다.
3. BestEffort (최저 등급 ⭐)
   • 조건: 요청(requests)과 제한(limits)이 모두 설정되지 않은 경우.
   • 특징: 가장 낮은 우선순위를 가지며, 리소스가 부족할 때 가장 먼저 종료 대상이 됩니다. 중요도가 낮은 배치 작업이나 개발용 테스트에 사용할 수 있습니다.

https://k21academy.com/docker-kubernetes/quality-of-service-qos-in-kubernetes-ensuring-reliable-application-performance/

---

4. 실전! 리소스 설정 방법

리소스 설정은 파드의 YAML 명세 파일에서 각 컨테이너별로 지정합니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app-container
    image: my-app-image:latest
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

네임스페이스 단위의 리소스 관리

관리자는 개별 파드뿐만 아니라 네임스페이스 전체에 대한 리소스 정책을 설정하여 일관성을 유지할 수 있습니다.

• LimitRange: 네임스페이스 내에서 생성되는 컨테이너에 기본 요청/제한 값을 자동으로 설정하거나, 설정할 수 있는 최소/최대 크기를 강제할 수 있습니다.
• ResourceQuota: 네임스페이스가 사용할 수 있는 리소스의 총량(예산)을 할당합니다. "A팀의 네임스페이스는 총 10 CPU, 20Gi 메모리 이상을 사용할 수 없다"와 같은 규칙을 설정하여 멀티테넌트 환경에서 자원을 공평하게 분배할 수 있습니다.

---

결론

쿠버네티스에서 리소스 요청과 제한을 설정하는 것은 '하면 좋은 일'이 아니라 '반드시 해야 하는 일' 입니다. 이는 클러스터의 안정성을 지키고, 자원을 효율적으로 사용하며, 각 애플리케이션의 서비스 품질을 보장하는 가장 기본적인 약속이자 규칙입니다. 지금 바로 여러분의 클러스터에서 실행 중인 컨테이너들의 리소스 설정을 점검해보세요!