쿠버네티스 이론 STEP14 Resource Management

 

ABTCEFG♪  안녕하세요, 여러분!

BTC_김쿼카입니다.

 

이번 시간에는 쿠버네티스의 리소스 관리에 대해 알아보는 시간을 가질게요.

 

---

 

쿠버네티스에서는 pod를 실행하기 위해 node의 리소스를 사용합니다. 스케줄러는 pod를 자원의 여유가 있는 node에 배포하게 되는데 이때 사용되는 기준은 각 node의 cpu, memory의 사용량 등이 대표적입니다.

리소스 단위
cpu : 1000m(밀리 코어) == cpu : 1 Core
memory : 256Mi == memory : 256Mb

 

apiVersion: v1
kind: Pod
metadata:
  name: resource-limit-pod
  labels:
    name: resource-limit-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    resources:
      limits:
        memory: "256Mi"
        cpu: "1000m"

1. Requests

pod를 실행하기 위한 최소 cpu, memory
node에 requests 보다 더 많은 cpu, memory가 남아있는 경우에만 실행이 가능함

 

2. Limits

pod를 실행할 때 사용할 수 있는 최대 cpu, memory
각 pod는 limits 보다 많은 cpu, memory 값을 사용할 수 없음

 

---

 

그렇다면 이제 여러 개의 컨테이너 환경을 한 번 생각해볼까요? 쿠버네티스의 request는 자원의 오버커밋이 가능합니다.

오버커밋
사용할 수 있는 자원보다 더 많은 양을 컨테이너에 할당하면서 전체 자원의 사용률을 높이는 방법

오버커밋을 적용하여 request보다 많은 자원을 사용할 수 있게 하면 효율적이지만 특정 컨테이너가 자원을 침범하게 될 경우 메모리 사용이 실패하게 됩니다. 이 때 쿠버네티스는 가용 메모리를 확보하기 위해 우선 순위가 낮은 pod를 강제 종료하고, 해당 pod는 다른 노드로 옮겨지게 됩니다.

 

 

CPU는 어떨까요?

memory와 거의 동일하지만 한 가지 차이점이 있습니다. 앞에서 말씀했다시피 memory의 경우에는 자원의 침범이 발생하면 pod를 강제 종료시키지만, CPU 사용량의 침범이 발생할 때는 CPU 스로틀이 발생하여 pod의 강제 종료 없이 지정된 Request만큼 사용이 가능합니다.

CPU 스로틀
Request보다 더 많은 CPU를 사용해 경합이 발생하더라도 컨테이너의 CPU 사용량을 억제하는 것

 

---

 

pod 별로 limit, request를 설정하지 않으면 디폴트는 best-effort 상태입니다. 쿠버네티스는 어드미션 컨트롤러를 제공하는데 이를 사용하면 아무것도 명시하지 않았을 때에는 미리 지정해둔 limit, request가 자동으로 설정됩니다.

3. LimitRange

namespace 별로 default requests, default limit, min/max limits 값을 설정할 수 있음

컨테이너 개별 자원의 사용 가능 범위를 지정함

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # this section defines default limits
      cpu: 500m
    defaultRequest: # this section defines default requests
      cpu: 500m
    max: # max and min define the limit range
      cpu: "1"
    min:
      cpu: 100m

4. ResourceQuota
namespace 별로 사용 가능한 cpu, memory를 제한할 수 있음

네임 스페이스 전체의 리소스 양을 정의함