Scheduling-Resource Requirements and Limits

1. 리소스 요청과 제한의 개념

• 리소스 요청 (Resource Requests):
  • Pod이 실행되기 위해 필요한 최소한의 CPU와 메모리 양을 지정합니다.
  • Kubernetes 스케줄러는 이 값을 기준으로 Pod을 배치할 노드를 결정합니다.
  • 요청된 리소스는 Pod에 보장됩니다.
• 리소스 제한 (Resource Limits):
  • Pod이 사용할 수 있는 최대 CPU와 메모리 양을 지정합니다.
  • Pod이 제한을 초과하려고 하면, CPU는 쓰로틀링(Throttling) 되고, 메모리는 초과 시 **Pod이 종료(OOM Kill)**됩니다.

2. 리소스 요청 및 제한 설정 방법

Pod 정의 파일에 resources 섹션을 추가하여 설정

resources:
  requests:
    memory: "1Gi"     # 최소 1GiB 메모리 요청
    cpu: "500m"       # 최소 0.5 vCPU 요청
  limits:
    memory: "2Gi"     # 최대 2GiB 메모리 제한
    cpu: "1"          # 최대 1 vCPU 제한

단위

• CPU:
  • 1 = 1 vCPU (AWS), 1 코어(GCP/Azure).
  • 100m = 0.1 vCPU (m은 milli 단위).
• 메모리:
  • Mi = Mebibyte (1024 KiB).
  • Gi = Gibibyte (1024 MiB).
  • M, G는 Megabyte(1000 KiB), Gigabyte(1000 MB)로 다릅니다.

리소스 요청 및 제한 동작

CPU

1. 요청(Requests)만 설정:
   • Pod은 요청된 CPU를 보장받습니다.
   • 사용 가능한 추가 CPU가 있다면, 다른 Pod이 사용하지 않는 한 자유롭게 사용할 수 있습니다.
2. 제한(Limits)만 설정:
   • Kubernetes는 요청 값을 제한 값으로 자동 설정합니다.
   • Pod은 지정된 한도까지만 CPU를 사용할 수 있습니다.
3. 요청과 제한 모두 설정:
   • Pod은 요청된 CPU는 보장받으며, 지정된 한도까지만 사용할 수 있습니다.
4. 요청도 제한도 설정하지 않음:
   • 어떤 Pod도 노드의 모든 CPU를 사용할 수 있어 다른 Pod을 굶주리게 할 위험 존재

메모리

• 메모리는 CPU와 유사하지만, 중요한 차이가 있습니다:
  • 메모리는 쓰로틀링되지 않습니다.
  • Pod이 제한을 초과하면 OOM(Out of Memory) 오류로 종료됩니다

기본값 및 LimitRange

Kubernetes는 기본적으로 리소스 요청이나 제한을 설정하지 않습니다. 이를 방지하기 위해 다음을 사용할 수 있습니다:

LimitRange

• 네임스페이스 수준에서 기본값, 최소 및 최대 값을 설정할 수 있습니다.
• 예시 YAML:↑

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:
      cpu: "200m"
      memory: "128Mi"
    max:
      cpu: "2"
      memory: "1Gi"
    min:
      cpu: "100m"
      memory: "64Mi"

Resource Quota

• 네임스페이스 전체에서 사용 가능한 총 리소스를 제한합니다.
• 예시 YAML:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "4Gi"
    limits.cpu: "10"
    limits.memory: "10Gi"

---

Behavior - CPU

1. CPU 리소스 요청과 제한

• 요청(Requests):
  • Pod이 실행되기 위해 필요한 최소 CPU를 지정.
  • Kubernetes 스케줄러는 요청 값을 기준으로 Pod을 배치할 노드를 선택.
  • 요청된 리소스는 보장됩니다.
• 제한(Limits):
  • Pod이 사용할 수 있는 최대 CPU를 지정.
  • Pod이 제한을 초과하려고 하면, CPU 사용량은 쓰로틀링(Throttling) 됩니다.

2. CPU 동작 방식

1) 요청(Requests)만 설정

• Pod은 요청된 만큼의 CPU를 보장받습니다.
• 추가로 사용 가능한 CPU가 있다면, 다른 Pod이 사용하지 않는 한 자유롭게 사용할 수 있습니다.

2) 제한(Limits)만 설정

• Kubernetes는 요청 값을 제한 값과 동일하게 자동 설정합니다.
• Pod은 지정된 최대 한도까지만 CPU를 사용할 수 있습니다.

3) 요청과 제한 모두 설정

• Pod은 최소한의 CPU 사용량(Requests)을 보장받으며, 지정된 한도(Limits)까지만 사용할 수 있습니다.
• 예:
  • 요청: 1 vCPU
  • 제한: 3 vCPU
  • -> 최소 1 vCPU는 보장되며, 최대 3 vCPU까지 사용 가능.

4) 요청도 제한도 설정하지 않음

• Pod은 노드의 모든 CPU를 사용할 수 있어 다른 Pod을 굶주리게 할 위험이 있습니다.

3. 이상적인 설정

요청(Requests)을 설정하고, 제한(Limits)을 생략

• 각 Pod은 최소한의 리소스를 보장받으면서, 시스템에 여유가 있을 경우 추가 리소스를 자유롭게 사용할 수 있습니다.
• 예:
  • 요청: 1 vCPU
  • 제한: 없음
  • -> 여유가 있을 경우 더 많은 CPU를 사용 가능.

제한(Limits)을 사용하는 경우

• 공용 환경에서 악용 방지(예: 비트코인 채굴 방지).
• 특정 애플리케이션에 자원 소비를 강하게 제어해야 할 때.

4. 기본값 및 LimitRange

기본값(Default Behavior)

• Kubernetes는 기본적으로 리소스 요청이나 제한을 설정하지 않습니다.
• 이로 인해 특정 Pod이 모든 리소스를 독점할 위험이 있습니다.

LimitRange 사용

• 네임스페이스 수준에서 기본값, 최소 및 최대 값을 설정할 수 있습니다.

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
      cpu: "500m"
    defaultRequest:
      cpu: "200m"
    max:
      cpu: "2"
    min:
      cpu: "100m"

---

Behavior - Memory

1. 메모리 요청(Requests)과 제한(Limits)의 개념

• 메모리 요청(Requests):
  • Pod이 실행되기 위해 필요한 최소 메모리를 지정합니다.
  • Kubernetes 스케줄러는 이 값을 기준으로 Pod을 배치할 노드를 선택합니다.
  • 요청된 메모리는 Pod에 보장됩니다.
• 메모리 제한(Limits):
  • Pod이 사용할 수 있는 최대 메모리를 지정합니다.
  • Pod이 제한을 초과하려고 하면, OOM(Out of Memory) 오류로 인해 종료됩니다.

2. 메모리 동작 방식

1) 요청(Requests)만 설정

• Pod은 요청된 만큼의 메모리를 보장받습니다.
• 추가로 사용 가능한 메모리가 있다면, 다른 Pod이 사용하지 않는 한 자유롭게 사용할 수 있습니다.
• 그러나 제한(Limits)이 없으므로, Pod이 너무 많은 메모리를 사용할 경우 다른 Pod에 영향을 줄 수 있습니다.

2) 제한(Limits)만 설정

• Kubernetes는 요청 값을 제한 값과 동일하게 자동 설정합니다.
• Pod은 지정된 최대 한도까지만 메모리를 사용할 수 있습니다.
• 제한을 초과하려는 경우, OOM 오류로 인해 Pod이 종료됩니다.

3) 요청과 제한 모두 설정

• Pod은 최소한의 메모리(Requests)를 보장받으며, 지정된 한도(Limits)를 초과하지 않습니다.
• 예:
  • 요청: 1Gi
  • 제한: 3Gi
  • -> 최소 1Gi는 보장되며, 최대 3Gi까지 사용 가능.

4) 요청도 제한도 설정하지 않음

• 어떤 Pod도 노드의 모든 메모리를 사용할 수 있어 다른 Pod을 굶주리게 할 위험이 있습니다.
• 이는 BestEffort QoS 클래스에 해당하며, 리소스 압박 상황에서 가장 먼저 퇴출(Eviction) 대상이 됩니다.

3. OOM(Out of Memory) 동작

• CPU와 달리, 메모리는 비압축성 자원입니다. 즉, 부족한 경우 쓰로틀링(Throttling)이 불가능합니다.
• Pod이 제한(Limits)을 초과하여 메모리를 소비하려고 하면:
  1. 커널의 OOM 서브시스템이 작동하여 컨테이너를 종료시킵니다.
  2. 종료된 컨테이너는 재시작 정책에 따라 kubelet에 의해 재시작될 수 있습니다.
  3. 로그 또는 kubectl describe pod 명령어를 통해 OOM 오류를 확인할 수 있습니다.

4. QoS 클래스와 메모리 동작

Kubernetes는 리소스 요청 및 제한 설정 여부에 따라 QoS(Quality of Service) 클래스를 할당합니다:

1. Guaranteed:
   • 모든 컨테이너가 동일한 요청(Requests)과 제한(Limits)을 설정한 경우.
   • 가장 높은 우선 순위를 가지며, 리소스 압박 시 퇴출되지 않습니다.
2. Burstable:
   • 일부 컨테이너만 요청(Requests)을 설정하거나, 요청과 제한 값이 다른 경우.
   • 유연하게 리소스를 사용할 수 있지만, Guaranteed보다 낮은 우선 순위를 가집니다.
3. BestEffort:
   • 요청(Requests)이나 제한(Limits)이 전혀 설정되지 않은 경우.
   • 가장 낮은 우선 순위를 가지며, 리소스 압박 시 가장 먼저 퇴출됩니다.

5. 이상적인 설정

요청(Requests)을 설정하고, 제한(Limits)을 생략

• 각 Pod은 최소한의 리소스를 보장받으면서, 시스템에 여유가 있을 경우 추가 리소스를 자유롭게 사용할 수 있습니다.
• 예:
  • 요청: 1Gi
  • 제한: 없음
  • -> 여유가 있을 경우 더 많은 메모리를 사용 가능.

제한(Limits)을 사용하는 경우

• 공용 환경에서 악용 방지(예: 비트코인 채굴 방지).
• 특정 애플리케이션에 자원 소비를 강하게 제어해야 할 때.

6. LimitRange와 ResourceQuota 활용

LimitRange

• 네임스페이스 수준에서 기본값(Default), 최소(Min), 최대(Max)를 정의하여 컨테이너별 리소스 사용을 제어합니다.

apiVersion: v1
kind: LimitRange
metadata:
  name: memory-limits
spec:
  limits:
  - default:
      memory: "512Mi"
    defaultRequest:
      memory: "256Mi"
    max:
      memory: "1Gi"
    min:
      memory: "128Mi"

ResourceQuota

• 네임스페이스 전체에서 사용 가능한 총 리소스를 제한합니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-quota
spec:
  hard:
    requests.memory: "4Gi"
    limits.memory: "8Gi"

---

단어정리

1. 쓰로틀링 (Throttling)

• 정의: CPU 사용량이 Pod의 **리소스 제한(Limits)**을 초과하려고 할 때, Kubernetes가 CPU 사용량을 제한하는 동작.
• 작동 방식:
  • CPU는 압축 가능한 자원으로, 사용량을 동적으로 조정할 수 있습니다.
  • Pod이 제한된 CPU 이상을 사용하려고 하면, Kubernetes는 해당 Pod의 CPU 사용량을 강제로 줄입니다.
  • 이 과정에서 애플리케이션 성능이 저하될 수 있지만, Pod은 종료되지 않습니다.
• 예시:
  • Pod의 CPU 제한(Limits)이 2 vCPU로 설정된 경우, 해당 Pod은 최대 2 vCPU까지만 사용할 수 있으며, 이를 초과하면 쓰로틀링됩니다.

2. OOM 오류 (Out of Memory Error)

• 정의: Pod이 메모리 제한(Limits)을 초과하여 더 많은 메모리를 사용하려고 할 때 발생하는 오류.
• 작동 방식:
  • 메모리는 비압축성 자원으로, 부족할 경우 동적으로 조정할 수 없습니다.
  • Pod이 제한된 메모리 이상을 사용하려고 하면, 커널의 OOM(Out of Memory) 킬러가 작동하여 해당 컨테이너를 종료합니다.
  • 종료된 컨테이너는 Kubernetes의 재시작 정책에 따라 다시 시작될 수 있습니다.
• 확인 방법:
  • kubectl describe pod <pod-name> 명령어를 통해 OOM 오류 로그를 확인할 수 있습니다.
• 예시:
  • Pod의 메모리 제한(Limits)이 512Mi로 설정된 경우, 해당 Pod이 512Mi를 초과하면 OOM 오류가 발생하고 종료됩니다.

3. QoS 클래스 (Quality of Service Class)

• 정의: Kubernetes가 Pod에 할당된 리소스 요청(Requests) 및 제한(Limits)에 따라 Pod의 우선순위를 결정하는 분류 시스템.
• QoS 클래스는 리소스 압박 상황에서 어떤 Pod이 먼저 퇴출(Eviction)될지를 결정합니다.

QoS 클래스 유형

Guaranteed:

• 모든 컨테이너가 동일한 요청(Requests)과 제한(Limits)을 설정한 경우.
• 가장 높은 우선순위를 가지며, 리소스 압박 상황에서 퇴출되지 않습니다.
• 예시:

resources:
  requests:
    memory: "1Gi"
    cpu: "1"
  limits:
    memory: "1Gi"
    cpu: "1"

 

Burstable:

• 일부 컨테이너만 요청(Requests)을 설정하거나, 요청과 제한 값이 다른 경우.
• 유연성을 제공하지만, Guaranteed보다 낮은 우선순위를 가집니다.
• 예시:

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "1"

 

BestEffort:

• 요청(Requests)이나 제한(Limits)이 전혀 설정되지 않은 경우.
• 가장 낮은 우선순위를 가지며, 리소스 압박 상황에서 가장 먼저 퇴출됩니다.
• 예시:

resources: {}

---

The elephant pod runs a process that consumes 15Mi of memory. Increase the limit of the elephant pod to 20Mi.

kubectl edit pod elephant
error: pods "elephant" is invalid
A copy of your changes has been stored to "/tmp/kubectl-edit-386529057.yaml"
error: Edit cancelled, no valid changes were saved.


kubectl replace --force -f /tmp/kubectl-edit-386529057.yaml 
###
pod "elephant" deleted
pod/elephant replaced
###

kubectl get pod
NAME       READY   STATUS    RESTARTS   AGE
elephant   1/1     Running   0          13s