LimitRange

LimitRange

기본적으로 컨테이너는 쿠버네티스 클러스터에서 제한 없는 컴퓨트 리소스로 실행돼요. 쿠버네티스 리소스 쿼터를 사용하면 관리자(또는 클러스터 운영자)가 지정된 네임스페이스 안에서 클러스터 리소스(예: CPU 시간, 메모리, 영속 스토리지)의 소비와 생성을 제한할 수 있습니다. 네임스페이스 안에서 Pod이나 컨테이너는 그 네임스페이스에 적용되는 ResourceQuota가 허용하는 만큼 CPU와 메모리를 소비할 수 있어요. 클러스터 운영자로서, 또는 네임스페이스 레벨 관리자로서 단일 오브젝트가 네임스페이스 안의 모든 사용 가능한 리소스를 독점하지 못하게 하는 것에도 관심이 있을 수 있습니다.

LimitRange는 네임스페이스에서 각 적용 대상 오브젝트 종류(Pod이나 PersistentVolumeClaim 등)에 지정할 수 있는 리소스 할당(limit과 request)을 제한하는 정책이에요.

출처: 문서

본문

_LimitRange_는 다음을 할 수 있는 제약을 제공합니다:

  • 네임스페이스에서 Pod·컨테이너당 최소·최대 컴퓨트 리소스 사용량을 강제한다.
  • 네임스페이스에서 PersistentVolumeClaim당 최소·최대 스토리지 request를 강제한다.
  • 네임스페이스에서 리소스의 request·limit 비율을 강제한다.
  • 네임스페이스의 컴퓨트 리소스에 대한 기본 request/limit을 설정하고 런타임에 컨테이너에 자동으로 주입한다.

쿠버네티스는 특정 네임스페이스에 LimitRange 오브젝트가 하나 이상 있을 때마다 그 네임스페이스의 파드에 대한 리소스 할당을 제한해요.

LimitRange 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 해요.

리소스 limit·request에 대한 제약

  • 관리자가 네임스페이스에 LimitRange를 만든다.
  • 사용자가 그 네임스페이스에서 Pod이나 PersistentVolumeClaim 같은 오브젝트를 만들거나(만들려고 하거나) 한다.
  • 먼저 LimitRange 어드미션 컨트롤러가 컴퓨트 리소스 요구 사항을 설정하지 않은 모든 파드(및 컨테이너)에 기본 request·limit 값을 적용한다.
  • 그리고 LimitRange는 사용량을 추적해 네임스페이스에 있는 어떤 LimitRange에 정의된 리소스 최소·최대·비율을 초과하지 않도록 보장한다.
  • LimitRange 제약을 위반하는 오브젝트(Pod이나 PersistentVolumeClaim)를 만들거나 업데이트하려 하면 API 서버에 대한 요청이 HTTP 상태 코드 403 Forbidden과 위반된 제약을 설명하는 메시지로 실패한다.
  • cpu, memory 같은 컴퓨트 관련 리소스에 적용되는 LimitRange를 네임스페이스에 추가하면 그 값들에 대한 request나 limit을 지정해야 한다. 그렇지 않으면 시스템이 파드 생성을 거부할 수 있다.
  • LimitRange 검증은 Pod 어드미션 단계에서만 일어나며, 실행 중인 파드에는 적용되지 않는다. LimitRange를 추가하거나 수정해도 그 네임스페이스에 이미 존재하는 파드는 변경 없이 계속된다.
  • 네임스페이스에 LimitRange 오브젝트가 둘 이상 있으면 어떤 기본값이 적용될지 결정적(deterministic)이지 않다.

파드에 대한 LimitRange와 어드미션 검사

LimitRange는 적용하는 기본값의 일관성을 확인하지 않아요. 즉 LimitRange가 설정한 limit 기본값이 클라이언트가 API 서버에 제출하는 스펙의 컨테이너에 지정된 request 값보다 작을 수 있습니다. 이 경우 최종 파드는 스케줄 가능하지 않습니다.

예를 들어 아래 매니페스트로 LimitRange를 정의한다고 해요:

다음 예시들은 namespace 파라미터가 정의되지 않고 LimitRange 범위가 네임스페이스 레벨로 제한되므로, 클러스터의 default 네임스페이스 안에서 동작해요. 이는 이 예시들의 어떤 참조나 연산도 클러스터의 default 네임스페이스 요소와 상호작용함을 의미합니다. metadata.namespace 필드에서 namespace를 구성해 운영 네임스페이스를 덮어쓸 수 있습니다.

CPU 리소스 request가 700m이지만 limit은 없는 파드와 함께라면:

그 파드는 스케줄되지 않고 다음과 비슷한 오류로 실패합니다:

Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit

request와 limit을 모두 설정하면, 같은 LimitRange가 있어도 그 새 파드는 성공적으로 스케줄됩니다:

리소스 제약 예시

LimitRange로 만들 수 있는 정책 예시는 다음과 같아요:

  • 8 GiB RAM·16 core 용량의 2노드 클러스터에서 네임스페이스의 Pod이 CPU 100m를 request하고 CPU 최대 limit 500m, 메모리 200Mi를 request하고 메모리 최대 limit 600Mi를 갖도록 제한한다.
  • 스펙에 cpu·memory request가 없는 상태로 시작된 컨테이너에 대해 기본 CPU limit과 request를 150m, 메모리 기본 request를 300Mi로 정의한다.

네임스페이스의 총 limit이 Pod·Container의 limit 합계보다 작으면 리소스 경합이 발생할 수 있어요. 이 경우 Container나 Pod은 생성되지 않습니다.

경합이나 LimitRange 변경 모두 이미 생성된 리소스에는 영향을 주지 않아요.

더 알아보기 (Learn more)

limit 사용 예시는 다음을 참고하세요:

맥락과 역사적 정보는 LimitRanger 설계 문서를 참고하세요.