📌 Resource Requirements

• 스케줄러는 각 node에 배치될 pod의 요구되는 리소스를, 그리고 노드의 허용 가능한 리소스를 고려한다
• 이후 pod를 설치할 최고의 node를 식별한다.
• 만약 노드의 리소스에 여유가 없다면 해당 노드를 피하여 충분한 리소스 사용이 가능한 노드에 설치한다.
• 만약 노드 리소스가 전혀 없이 꽉 차있다면 스케줄러가 pod를 pending 상태로 둔다.
• pod를 만들때 할당할 cpu와 memory를 지정할 수 있다.
• 이는 컨테이너가 요청하는 최소한의 CPU와 메모리이다.
• 스케줄러가 pod를 만들때 이 값을 이용해 사용가능한 node를 식별한다.

📋 Definition

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
      - containerPort: 8080
    resources:
      requests:
        memory: 4Gi
        cpu: 2

• 스케줄러가 이정도의 리소스가 사용가능한 노드를 찾는다.
• pod가 node에 놓이면 사용 가능한 양의 자원을 보장받게 된다.

⚙️ Meaning

• CPU 1 : 100m(밀리) 👉 1m 까지 사용 가능, 이하는 안됨

• CPU 1 👉 1 vCPU

  • 1 AWS vCPU
  • 1 GCP Core
  • Azure Core
  • 1 Hyperthread

• MEM 256 Mi 👉 mebibyte

  • 1 G(Gigabyte) = 1,000,000,000 bytes

  • 1 M (Megabyte) = 1,000,000 bytes

  • 1 K (Kliobyte) = 1,000 bytes

  • 1 Gi (Gibibyte) = 1,073,741,824 bytes

  • 1 Mi (Mebibyte) = 1,048,576 bytes

  • 1 Ki (kibibyte) = 1,024 bytes

⚖️ Limits

• Pod의 리소스 사용 한도를 지정할 수 있다.
• 결국 Requirements로 최소 요구 사항을 지정하고 Limits로 최대 사용량을 지정하는 것

📋 Limits Definitions

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
      - containerPort: 8080
    resources:
      requests:
        memory: 1Gi
        cpu: 1
      limits:
        memory: 2Gi
        cpu: 2

• limits 가 지정되면 컨테이너는 제한된 리소스 이상의 CPU 사용이 불가하다.
• 하지만 메모리는 그렇지 않다.
• 컨테이너는 한도보다 많은 메모리 리소스를 쓸 수 있다.
• 하지만 계속해서 한도보다 많은 메모리를 사용하면 이 Pod는 Terminating 된다.
• 그리고 log를 실행하면 OOM(Out Of Memory) 에러로 종료되는걸 볼 수 있다.

🔨 Default Behavior

• 기본적으로 CPU, 메모리의 제한이 없다
• 이말은 어떤 pod든 어떤 node에서 요구되는 만큼의 자원을 소비한다.
• 리소스 노드에서 실행 중인 다른 Pod나 프로세스를 질식(?) 시킬 수 있다. (종료인듯)

🧠 Behavior - CPU

• No Request, No Limits - 하나의 Pod가 다른 Pod의 리소스 침범 👉 이상적인 상황 X
• No Request, Limits - requests = limits 자동으로 설정됨
• Request, Limits - 가장 이상적인 시나리오로 보일 수 있음
  • 만약 pod가 총 5cpu 중 3cpu의 limit과 1cpu의 request를 받았다
  • 하지만 2번 pod는 1cpu 만을 사용하고 1번 pod는 그 이상의 cpu가 필요하다.
  • 이 경우 불필요하게 1번 pod가 제한되는 상황이라 이상적이지 않을 수 있다.
• Request, No Limits - 요청이 정해져 있어 각 pod마다 보장받는 cpu가 있으며 한계가 설정되지 않기 때문에 pod 마다 제한 없이 CPU 사용 가능
  • 가장 이상적인 환경
  • 물론 추가적으로 limits을 설정 하여 리소스 사용을 제한할 수 있다.
  • 원하지 않는 리소스의 남용을 막는다 (해커들의 비트코인 채굴 등)
  • 모든 Pod에 Request 설정이 들어가 있어야 최소한의 CPU를 보장 받을 수 있다.

📀 Behavior - Memory

• No Requests, No Limits - 2개의 pod가 경쟁한다고 가정할때 1번 pod가 노드의 메모리 리소스를 모두 사용하면 2번 pod의 메모리 사용을 막을 수 있다.
  • 때문에 이상적인 상황은 아님
• No Requests, Limits - requsets = limits 자동으로 설정함
• Requests, Limits - 각 pod마다 메모리가 보장되고 limits가 설정됨
• Requests, No Limits - 요청이 정해져 각 pod에 메모리를 보장 받고 사용가능한 메모리를 사용할 수 있음
  • 2번 pod 입장에서 1번 pod가 메모리를 더 요청하면 죽이는 수 밖에 없다 (Terminating)
  • CPU와 달리 메모리를 조절 할 수 없기 때문에 메모리를 확보하는 유일한 방법은 노드에서 pod를 죽이고 사용되는 메모리를 줄이는것

📊 LimitRange

# limit-range-cpu.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
        cpu: 500m
     defaultRequest:
        cpu: 500m
     max:
        cpu: “1”
     min:
        cpu: 100m
     type: Container

# limit-range-memory.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: memory-resource-constraint
spec:
  limits:
  - default:
        cpu: 1Gi
     defaultRequest:
        cpu: 1Gi
     max:
        cpu: 1Gi
     min:
        cpu: 500Mi
     type: Container

`
``
- 이것은 독립적인 개체(오브젝트) 이다.
- namespace 단위에서 생성할 수있다.
- 기본한도를 500m 로 설정하고 최대 CPU는 1로 지정하고 최소는 100m
- 사용할 애플리케이션에 적합한 리소스를 설정해야한다.
- 메모리도 명시한대로이다.
- `pod`가 만들어질 때 이런 제한이 적용된다는 뜻
- 때문에 기존 `pod`는 영향을 받지 않는다.

> 💡 쿠버네티스 클러스터에 배포된 앱이 사용할 전체 리소스를 제한할 방법이 있을까?

👉 **네임스페이스 레벨에서 quota로 설정할 수 있음**

resource-quota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
name: my-resource-quota
spec:
hard:
requests.cpu: 4
requests.memory: 4Gi
limits.cpu: 10
limits.memory: 10Gi

- `namespace` 하나에 할당된 총 리소스 할당량