👮‍♂️ 우리 클러스터의 교통경찰! LimitRange와 ResourceQuota로 질서 잡기

안녕하세요, 쿠버네티스 클러스터를 운영하는 여러분! 🚀

여러 팀이 함께 사용하는 멀티테넌트(Multi-tenant) 클러스터를 운영하다 보면 이런 걱정을 하게 됩니다.

"한 팀이 실수로 리소스를 너무 많이 사용하는 Pod를 배포해서 다른 팀의 서비스까지 장애가 나면 어떡하지?" "특정 네임스페이스가 클러스터의 모든 자원을 독차지하지 않도록 막을 방법은 없을까?"

 

마치 공용 아파트에서 한 집이 전기와 물을 너무 많이 써서 다른 집이 피해를 보는 상황과 비슷하죠. 😅

오늘은 이런 '리소스 무질서'를 바로잡고, 클러스터에 공정하고 안정적인 규칙을 부여하는 두 명의 교통경찰, LimitRange와 ResourceQuota에 대해 자세히 알아보겠습니다!

 

 

---

📏 LimitRange: 개별 Pod를 위한 '최소/최대 사용량 가이드라인'

LimitRange는 네임스페이스 안에서 개별 Pod나 컨테이너가 사용할 수 있는 리소스의 범위를 지정하고, 기본값을 설정해주는 규칙입니다.

• 역할: 컨테이너 하나하나에 대한 세밀한 리소스 규칙(Micro-control)을 적용합니다.
• 핵심 기능:
  1. 최소/최대 리소스 강제: 컨테이너가 요청(request)하거나 제한(limit)할 수 있는 CPU, 메모리의 최솟값과 최댓값을 정합니다.
  2. 기본값 자동 할당: 개발자가 Pod를 배포할 때 requests나 limits를 명시하지 않으면, 여기에 설정된 기본값을 자동으로 주입해줍니다.

비유하자면...

공용 주방의 '가전제품 사용 규칙'과 같아요.

🍳 "이 주방의 모든 가전제품은 최소 50W, 최대 1000W의 전력만 사용할 수 있습니다. 만약 전력량이 표시되지 않은 제품을 가져오면, 자동으로 100W로 간주합니다."

 

YAML 예시로 살펴보기

apiVersion: v1
kind: LimitRange
metadata:
  name: my-limit-range
spec:
  limits:
  - type: Container # 컨테이너 타입에 적용
    max:
      cpu: "1"      # 컨테이너는 최대 1 CPU 코어까지만 제한(limit) 가능
      memory: "1Gi" # 최대 1Gi 메모리까지만 제한(limit) 가능
    min:
      cpu: "100m"   # 최소 100m (0.1 코어) 이상은 요청(request)해야 함
      memory: "10Mi" # 최소 10Mi 메모리 이상은 요청(request)해야 함
    default:
      cpu: "300m"   # limit을 명시 안하면 자동으로 300m
      memory: "200Mi" # limit을 명시 안하면 자동으로 200Mi
    defaultRequest:
      cpu: "200m"   # request를 명시 안하면 자동으로 200m
      memory: "100Mi" # request를 명시 안하면 자동으로 100Mi

 

이 LimitRange가 적용된 네임스페이스에서는?

• requests나 limits 없이 Pod를 배포하면 defaultRequest와 default 값이 자동으로 설정됩니다.
• 만약 requests.cpu를 50m로 설정한 Pod를 배포하면, min 값인 100m보다 작기 때문에 생성이 거부됩니다. 🙅‍♀️
• 만약 limits.memory를 2Gi로 설정한 Pod를 배포하면, max 값인 1Gi보다 크기 때문에 생성이 거부됩니다. 🙅‍♂️

---

🏦 ResourceQuota: 네임스페이스의 '총 예산 한도'

ResourceQuota는 네임스페이스 전체가 사용할 수 있는 리소스의 총량을 제한하는 규칙입니다. 개별 Pod가 아니라, 네임스페이스의 '총합'을 관리합니다.

• 역할: 네임스페이스 단위의 거시적인 리소스 할당량(Macro-control)을 관리합니다.
• 핵심 기능:
  1. 리소스 총량 제한: 네임스페이스 내 모든 Pod의 requests, limits의 총합을 제한합니다.
  2. 오브젝트 개수 제한: 생성할 수 있는 Pod, Service, ConfigMap, PVC 등의 개수도 제한할 수 있습니다.

비유하자면...

한 가족에게 주어지는 '한 달 공과금 예산'과 같아요. 💰 "우리 가족은 이번 달에 전기 300kWh, 수도 20톤, 가스 50m³ 안에서만 사용해야 합니다. 이 예산을 넘을 수는 없습니다."

YAML 예시로 살펴보기

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    # 리소스 총량 제한
    requests.cpu: "2"       # 네임스페이스 내 모든 Pod의 CPU request 총합은 2 코어를 넘을 수 없음
    requests.memory: "2Gi"  # 메모리 request 총합은 2Gi를 넘을 수 없음
    limits.cpu: "4"         # CPU limit 총합은 4 코어를 넘을 수 없음
    limits.memory: "4Gi"    # 메모리 limit 총합은 4Gi를 넘을 수 없음
    
    # 오브젝트 개수 제한
    pods: "10"                # Pod는 최대 10개까지만 생성 가능
    services: "5"             # Service는 최대 5개까지만 생성 가능
    persistentvolumeclaims: "4" # PVC는 최대 4개까지만 생성 가능

 

이 ResourceQuota가 적용된 네임스페이스에서는?

• 현재 네임스페이스의 Pod들이 requests.cpu를 총 1.8 코어 사용 중일 때, requests.cpu: "300m"인 새로운 Pod를 배포하면 총합이 2.1 코어가 되어 할당량(2)을 초과하므로 생성이 거부됩니다.
• Pod를 10개까지 생성한 후 11번째 Pod를 배포하려고 하면 생성이 거부됩니다.
• 중요! ResourceQuota가 CPU/메모리 총량을 제한하는 경우, 해당 네임스페이스에 생성되는 모든 Pod는 반드시 requests와 limits 값을 명시해야만 합니다.

---

✨ LimitRange + ResourceQuota = 환상의 콤비!

이 두 가지는 함께 사용될 때 진정한 시너지를 발휘합니다.

구분	LimitRange (개별 규칙)	ResourceQuota (총량 규칙)
대상	개별 컨테이너/Pod	네임스페이스 전체
역할	최소/최대 범위, 기본값 설정	리소스/오브젝트의 총량 제한
목표	개별 Pod의 비정상적인 리소스 사용 방지	네임스페이스의 리소스 독점 방지

 

ResourceQuota는 모든 Pod에 requests/limits 설정을 강제하는데, 개발자가 이를 매번 기억하고 입력하기는 번거롭습니다. 이때 LimitRange가 있으면? 개발자가 깜빡해도 자동으로 기본값을 설정해주니 ResourceQuota의 요구사항을 자연스럽게 만족시키며 Pod가 성공적으로 배포됩니다.

 

LimitRange가 ResourceQuota의 훌륭한 조력자가 되어주는 셈이죠!

---

결론

LimitRange와 ResourceQuota는 공유 클러스터 환경에서 공정성과 안정성을 보장하는 필수적인 도구입니다.

• LimitRange로 개별 컨테이너가 지켜야 할 최소한의 규칙을 만들어주고,
• ResourceQuota로 각 팀(네임스페이스)이 사용할 수 있는 자원의 파이를 명확히 나누어 주세요.

이 두 교통경찰과 함께라면, 리소스 충돌 걱정 없는 평화롭고 안정적인 쿠버네티스 클러스터를 운영할 수 있을 겁니다!

---

태그: 쿠버네티스, Kubernetes, LimitRange, ResourceQuota, 리소스관리, DevOps, CKA, CKAD, 멀티테넌시, 네임스페이스