리밋 레인지(Limit Range)

기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 컴퓨팅 리소스로 실행된다. 쿠버네티스의 리소스 쿼터를 사용하면 클러스터 관리자(또는 클러스터 오퍼레이터 라고 함)는 네임스페이스별로 리소스(CPU 시간, 메모리 및 퍼시스턴트 스토리지) 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 클러스터 운영자 또는 네임스페이스 수준 관리자는 단일 오브젝트가 네임스페이스 내에서 사용 가능한 모든 리소스를 독점하지 못하도록 하는 것에 대해 우려할 수도 있다.

리밋레인지는 네임스페이스의 각 적용 가능한 오브젝트 종류(예: 파드 또는 퍼시스턴트볼륨클레임)에 대해 지정할 수 있는 리소스 할당(제한 및 요청)을 제한하는 정책이다.

리밋레인지 는 다음과 같은 제약 조건을 제공한다.

네임스페이스에서 파드 또는 컨테이너별 최소 및 최대 컴퓨팅 리소스 사용량을 지정한다.
네임스페이스에서 퍼시스턴트볼륨클레임별 최소 및 최대 스토리지 요청을 지정한다.
네임스페이스에서 리소스에 대한 요청과 제한 사이의 비율을 지정한다.
네임스페이스에서 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임에 있는 컨테이너에 자동으로 설정한다.

해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다.

리밋레인지 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

리소스 제한 및 요청에 대한 제약

관리자는 네임스페이스에 리밋레인지를 생성한다.
사용자는 해당 네임스페이스에서 파드 또는 퍼시스턴트볼륨클레임과 같은 오브젝트를 생성하거나 생성하려고 시도한다.
첫째, LimitRange 어드미션 컨트롤러는 컴퓨팅 리소스 요구사항을 설정하지 않은 모든 파드(및 해당 컨테이너)에 대해 기본 요청 및 제한 값을 적용한다.
둘째, LimitRange는 사용량을 추적하여 네임스페이스에 존재하는 LimitRange에 정의된 리소스 최소, 최대 및 비율을 초과하지 않는지 확인한다.
리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하려고 하는 경우 HTTP 상태 코드 403 FORBIDDEN 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다.
cpu, memory와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지를 추가한 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다.
LimitRange 유효성 검사는 실행 중인 파드가 아닌 파드 어드미션 단계에서만 수행된다. 리밋레인지가 추가되거나 수정되면, 해당 네임스페이스에 이미 존재하는 파드는 변경되지 않고 계속 유지된다.
네임스페이스에 두 개 이상의 LimitRange 오브젝트가 존재하는 경우, 어떤 기본값이 적용될지는 결정적이지 않다.

파드에 대한 리밋레인지 및 어드미션 확인

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

예를 들어, 이 매니페스트에 LimitRange를 정의한다.

concepts/policy/limit-range/problematic-limit-range.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # 이 섹션에서는 기본 한도를 정의한다
      cpu: 500m
    defaultRequest: # 이 섹션에서는 기본 요청을 정의한다
      cpu: 500m
    max: # max와 min은 제한 범위를 정의한다
      cpu: "1"
    min:
      cpu: 100m

이 때 CPU 리소스 요청을 700m로 선언하지만 제한은 선언하지 않는 파드를 포함한다.

concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m

그러면 해당 파드는 스케줄링되지 않고 다음과 유사한 오류와 함께 실패한다.

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가 적용되어 있어도 새 파드는 성공적으로 스케줄링된다.

concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-no-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: registry.k8s.io/pause:2.0
    resources:
      requests:
        cpu: 700m
      limits:
        cpu: 700m

리소스 제약 예시

LimitRange를 사용하여 생성할 수 있는 정책의 예는 다음과 같다.

용량이 8GiB RAM과 16 코어인 2 노드 클러스터에서 네임스페이스의 파드를 제한하여 CPU의 최대 제한이 500m인 CPU 100m를 요청하고 메모리의 최대 제한이 600M인 메모리 200Mi를 요청하라.
스펙에 CPU 및 메모리 요청없이 시작된 컨테이너에 대해 기본 CPU 제한 및 요청을 150m로, 메모리 기본 요청을 300Mi로 정의하라.

네임스페이스의 총 제한이 파드/컨테이너의 제한 합보다 작은 경우 리소스에 대한 경합이 있을 수 있다. 이 경우 컨테이너 또는 파드가 생성되지 않는다.

경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다.

다음 내용

제한의 사용에 대한 예시는 다음을 참조한다.

컨텍스트 및 기록 정보는 LimitRanger 디자인 문서를 참조한다.

최종 수정 June 20, 2024 at 12:44 PM PST: Sync changest from andygol/k8s-website (36d05bc8a1)