Pod 자원 제한

[junha-ahn]

Description

현재 컴퓨팅 파워에 대한 컨트롤이 없다.

자원 제한에 대해 학습하고, 구현해야 한다

관련 키워드

• Pod 우선순위

참고 도서

• 쿠버네티스 모범 사례

To do

• [ ] 파드안티어피니티를 사용해 워크로드를 여러 가용 영역으로 분산하여, 애플리케이션 고가용성 보장
• [ ] NodeCondition 테인트를 사용해 노드 실패나 성능 저하를 사전에 방지
• [x] NodeSelector 사용
• [x] 클러스터에 배포된 모든 파드에 대해 메모리와 CPU 제한을 설정한다
• [x] 여러 애플리케이션의 공정한 리소스 할당을 위해 ResourceQuata를 사용한다
• [ ] 기본 제한과 요청을 설정하기 위해 LimitRange를 구현한다

요약:

• Nginx/Backend Pod 메모리와 CPU 제한은 Requests 를 통해 사용하고 Limit을 사용하지 않는다
• 다만 Request는 최소한만 사용 (Blue Green 배포 고려)

ResourceQuata

	CPU	메모리
총량	6	6000Mi
Default	없음	없음
ArgoCD	500m
Monitoring	1000m

Test Checklist

[junha-ahn]

파드안티어피니티를 사용해 워크로드를 여러 가용 영역으로 분산하여, 애플리케이션 고가용성 보장

파드어피니티는 향후 Redis 를 Backend Pod과 가장 근접한 위치에 배포할때 사용한다. 현재 BackendPod은 NodeSelector로도 충분하다.

NodeCondition 테인트를 사용해 노드 실패나 성능 저하를 사전에 방지

테인트 또한 현재 크게 의미 있지는 않다. 만약 ArgoCd, Prometheus, Grafana에 대해 격리가 필요하다면 사용

[junha-ahn]

클러스터에 배포된 모든 파드에 대해 메모리와 CPU 제한을 설정한다

참고

• https://jh-labs.tistory.com/502
• 쿠버네티스 리소스 단위
• Kubernetes의 CPU requests와 limits
• Kubernetes best practices: Resource requests and limits

파드 리소스를 관리한다는 것은 전반적인 CPU와 메모리 사용률을 관리하여 클러스터의 활용도를 최적화하는 것을 의미 (네트워크와 스토리지 리소스를 관리하는 방법은 없다)

❯ kubectl top nodes
error: Metrics API not available

매트릭서버 설치는 더 고민해보자

Pod Resource Requests, Limits

Requests

• Pod을 실행하기 위한 최소 리소스 양을 요청
• 스케줄러가 이를 판단하여 여유 있는 노드로 스케줄링

Limits

• Pod이 사용할 수 있는 최대 리소스양을 제한한다
• 메모리 Limit을 초과해서 사용하는 Pod은 OOM Kill,
• CPU는 Limit을 초과하지는 못한다.

노드의 리소스와 같은 양으로 컨테이너에 리소스를 할당하면 해당 컨테이너는 스케줄링되지 않는다. 해당 노드에서 기본적으로 사용 중인 kubelet과 같은 컨테이너가 이미 있기 때문이다. 이렇게 할당할 경우 Pending 상태로 남게 된다. 만약 requests는 설정하지 않고 limits 만 설정한다면 requests에도 limits과 같은 양으로 설정되기 때문에 requests나 limits 모두 너무 크게 잡으면 안 된다.

Resource 변수 의미

CPU 단위(unit)

CPU 리소스는 CPU 단위로 측정된다. 쿠버네티스에서 1 CPU는, 다음과 같다.

• 1 AWS vCPU
• 1 GCP Core
• 1 Azure vCore
• 1 하이퍼스레드 (베어메탈 서버의 하이퍼스레딩 인텔 프로세서)

분수 값도 가능하다. 0.5 CPU를 요청한 컨테이너는 1 CPU를 요청한 컨테이너 CPU의 절반 가량을 보장받는다. 접미사 m을 사용하여 밀리(milli)를 표현할 수도 있다. 예를 들어서 100m CPU, 100milliCPU, 그리고 0.1 CPU는 모두 같다. 1m보다 정밀한 표현은 허용하지 않는다.

CPU 리소스는 항상 리소스의 절대량으로 표시되며, 상대량으로 표시되지 않는다. 예를 들어, 컨테이너가 싱글 코어, 듀얼 코어, 또는 48 코어 머신 중 어디에서 실행되는지와 상관없이 500m CPU는 거의 같은 양의 컴퓨팅 파워를 가리킨다.

즉 reuqest.cpu는 최소한 보장받아야 하는 CPU를 설정하자

메모리

memory 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, k 와 같은 수량 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.

128974848, 129e6, 129M, 128974848000m, 123Mi

• 400m의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다. 이 사람은 아마도 400 메비바이트(mebibytes) (400Mi) 또는 400 메가바이트 (400M) 를 요청하고 싶었을 것이다.

[junha-ahn]

여러 애플리케이션의 공정한 리소스 할당을 위해 ResourceQuata를 사용한다

참고

• Kubernetes를 배워보자 7일차 - namespace와 pod의 자원 제한, ResourceQuota, LimitRange

ResourceQuota와 Limit를 namespace와 함께쓰면서 pod에서 접근할 수 있는 resource 컴퓨팅 자원에 대해 제한을 걸 수 있다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resourcequota
  namespace: custom-ns
spec:
  hard:
    requests.cpu: "1000m"
    requests.memory: "1Gi"
    limits.cpu: "2000m"
    limits.memory: "2Gi"

해당 네임스페이스에 pod가 배포되면 다음의 룰을 따른다.

1. 모든 pod들을 합쳐 해당 네임스페이스에서 하나의 CPU core 이상으로는 자원을 request하지 못한다.
2. 모든 pod들을 합쳐 해당 네임스페이스에서 1GiB 메모리 이상을 request하지 못한다.
3. 모든 pod들을 합쳐 해당 네임스페이스에서 두 개이상의 CPU core를 사용할 수 없다.
4. 모든 pod들을 합쳐 해당 네임스페이스에서 2GiB 이상의 메모리를 사용할 수 없다.

기본 제한과 요청을 설정하기 위해 LimitRange를 구현한다

LimitRange는 개별 pod, container 단위로 cpu와 memory에 제한을 주거나 default값을 설정하도록 할 수 있다

• LimitRange를 만들면 네임스페이스에서 하나의 pod 또는 container가 너무 많은 자원을 소모하지 못하게 할 수 있다.

apiVersion: v1
kind: LimitRange
metadata:
  name: my-limitrange
  namespace: custom-ns
spec:
  limits:
  - default:
      memory: "256Mi"
      cpu: "500m"
    defaultRequest:
      memory: "128Mi"
      cpu: "250m"
    max:
      memory: "1Gi"
      cpu: "1000Mi"
    min:
      memory: "128Mi"
      cpu: "250m"
    type: Container

• Limit 제한을 해지하고, 기본 Request도 굳이 사용하지 않는다