search

sungsu9022 / study-kubernetes-in-action

study-kubernetes
12 stars 8 forks source link

14. 파드의 컴퓨팅 리소스 관리 #14

Open sungsu9022 opened 4 years ago

sungsu9022 commented 4 years ago

14. 파드의 컴퓨팅 리소스 관리

파드의 예상 소비량과 최대 소비량을 설정하는 것은 파드 정의에서 매우 중요하다. 이는 리소스를 공평하게 공유하고, 클러스터 전체에서 파드가 스케줄링되는 방식에도 영향을 미친다.

14.1 파드 컨테이너의 리소스 요청

14.1.1 리소스 요청을 갖는 파드 생성

apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      requests:              # 컨테이너 리소스 요청
        cpu: 200m         # cpu 200밀리코어 (1 core : 1000m 또는 1, 200밀리코어는 1/5 core 시간을 의미)
        memory: 10Mi   # 10Mi 메모리를 요청
# 리소스 요청을 명시한 파드 생성
kubectl create -f requests-pod.yaml 

# 컨테이너 내부 CPI와 메모리 사용량 확인
kubectl exec -it requests-pod top
스크린샷 2020-09-15 오후 2 21 25

14.1.2 리소스 요청이 스케줄링에 미치는 영향

파드가 특정 노드에 실행할 수 있는지 스케줄러가 결정하는 방법

스크린샷 2020-09-15 오후 2 25 11

스케줄러가 파드를 위해 최적의 노드를 선택할 때 파드의 요청을 사용하는 방법

스케줄러의 우선순위 함수(요청된 리소스 양에 기반해 노드의 순위를 정한다.)
MostRequestedPriority의 필요성

노드의 용량 검사

# 노드 정보 조회
kubectl describe nodes

# 파드 생성
kubectl run requests-pod-2 --image=busybox --restart Never --requests='cpu=800m,memory=20Mi' -- dd if=//dev/zero of=/dev/null
스크린샷 2020-09-15 오후 2 30 12

어느 노드에도 실행할 수 없는 파드 생성

# cpu 1core를 사용하는 파드 생성
kubectl run requests-pod-3 --image=busybox --restart Never --requests='cpu=1,memory=20Mi' -- dd if=//dev/zero of=/dev/null
스크린샷 2020-09-15 오후 3 03 33 스크린샷 2020-09-15 오후 3 04 30

파드가 스케줄링되지 않은 이유 확인

# 노드 정보 확인
kubectl describe node
스크린샷 2020-09-15 오후 3 06 38

파드가 스케줄링될 수 있도록 리소스 해제

# 두번쨰 파드 삭제
kubectl delete po requests-pod-2

# 파드 확인
kubectl get po
스크린샷 2020-09-15 오후 3 10 15

14.1.3 CPU 요청이 CPU 시간 공유에 미치는 영향

스크린샷 2020-09-15 오후 3 11 40

14.1.4 사용자 정의 리소스의 정의와 요청

14.2 컨테이너에 사용 가능한 리소스 제한

14.2.1 컨테이너가 사용 가능한 리소스 양을 엄격한 제한으로 설정

리소스 제한은 갖는 파드 생성

apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      limits:                    # 컨테이너의 리소스 제한
        cpu: 1                  # 최대 CPU 1코어를 사용할 수 있다.
        memory: 20Mi    # 최대 20Mi 메모리를 사용할 수 있다.

리소스 제한 오버커밋

스크린샷 2020-09-15 오후 4 07 32

14.2.2 리소스 제한 초과

CrashLoopBackOff

스크린샷 2020-09-15 오후 4 59 38

14.2.3 컨테이너의 애플리케이션이 제한을 바라보는 방법

컨테이너느 항상 컨테이너 메모리가 아닌 노드의 메모리를 본다.

컨테이너는 노드의 모든 CPU 코어를 본다.

14.3 파드 Qos 클래스 이해

리소스 제한은 오버커밋될 수 있으므로 노드가 모든 파드의 리소스 제한에 지정된 양의 리소스를 반드시 제공할 수는 없다. 그러면 파드들 중에서 더 많은 메모리 사용을 요구하게 되면서 노드가 필요한 만큼의 메모리르 제공할 수 없을때는 결국 어떤 컨테이너는 종료시키고 메모리를 확보해야 한다. 이 경우 어떤 기준으로 종료될 파드를 결정할까? 이는 상황에 따라 다르며, 쿠버네티스 스스로 결정할 수 없기 때문에 쿠버네티스에서는 이 우선순위를 지정하는 방법을 제공한다.

파드를 분류하는 세가지 서비스 품질(QoS, Quality of Service) 클래스

14.3.1 파드의 QoS 클래스 정의

1) BestEffort 클래스

2) Guaranteed 클래스

Guaranteed의 조건

3) Burstable 클래스

리소스 요청과 제한 사이의 관계가 QoS 클래스를 정의하는 방법

스크린샷 2020-09-15 오후 5 58 26

참고 : 컨테이너에 제한만 설정된 경우, 요청은 기본으로 제한과 동일한 값으로 설정되므로 Guaranteed QoS 클래스를 갖게 되낟.

다중 컨테이너 파드의 QoS 클래스 파악

컨테이너1 QoS 클래스 컨테이너2 QoS 클래스 컨테이너3 QoS 클래스 파드 QoS 클래스
BestEffort BestEffort BestEffort BestEffort
BestEffort Burstable Guaranteed Burstable
... ... ... NONE
Guaranteed Guaranteed Guaranteed Guaranteed

14.3.2 메모리가 부족할 때 어떤 프로세스가 종료되는지 이해

QoS 클래스가 우선순위를 정하는 방법

스크린샷 2020-09-15 오후 6 04 05

동일 Qos 클래스를 갖는 컨테이너 중 우선순위

OOM score 계산 방식

14.4 네임스페이스별 파드에 대한 기본 요청과 제한 설정

컨테이너 리소스 요청과 제한을 설정하지 않으면 컨테이너는 이를 설정한 다른 컨테이너에 의해 좌지우지된다. 그래서 모든 컨테이에 리소스 요청과 제한을 설정하는 것이 좋다.

14.4.1 LimitRange 리소스

스크린샷 2020-09-15 오후 6 21 45

14.4.2 LimitRange 오브젝트 생성

apiVersion: v1
kind: LimitRange
metadata:
  name: example
spec:
  limits:
  - type: Pod              # 파드 전체에 리소스 제한 지정
    min: 
      cpu: 50m 
      memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
  - type: Container    # 컨테이너 전체에 요청 기본 지정
    defaultRequest:
      cpu: 100m
      memory: 10Mi
    default:                      # 리소스 제한을 지정하지 않은 컨테이너의 기본 제한(limit)
      cpu: 200m
      memory: 100Mi
    min:
      cpu: 50m
      memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
    maxLimitRequestRatio:     # 각 리소스요청/제한간의 최대 비율
      cpu: 4
      memory: 10
  - type: PersistentVolumeClaim    # PVC에 대한 min/max
    min:
      storage: 1Gi
    max:
      storage: 10Gi

14.4.3 강제 리소스 제한

# LimitRange 리소스 생성
kubectl create -f limits.yaml

# 요청이 큰 파드 생성
kubectl create -f limits-pod-too-big.yaml

The Pod "too-big" is invalid: spec.containers[0].resources.requests: Invalid value: "2": must be less than or equal to cpu limit
스크린샷 2020-09-15 오후 6 30 29

14.4.4 기본 리소스 요청과 제한 적용

# 예전에 실습한 파드 생성
kubectl create -f ../Chapter03/kubia-manual.yaml

# 파드 상태 확인(limit, request가 정상적으로 반영된 것을 볼 수 있다.)
kubectl describe po kubia-manual
스크린샷 2020-09-15 오후 6 33 21

14.5 네임스페이스의 사용 가능한 총 리소스 제한하기

14.5.1 리소스쿼터 오브젝트

CPU 및 메모리에 관한 리소스쿼터 생성

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cpu-and-mem
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi
스크린샷 2020-09-15 오후 6 44 52

쿼터와 쿼터 사용량 검사

# 리소스쿼터 생성
kubectl create -f quota-cpu-memory.yaml

# 리소스쿼터 조회
kubectl describe quota

리소스쿼터와 함께 LimitRange 생성

14.5.2 퍼시스턴트 스토리지에 관한 쿼터 지정하기

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage
spec:
  hard:
    requests.storage: 500Gi
    ssd.storageclass.storage.k8s.io/requests.storage: 300Gi
    standard.storageclass.storage.k8s.io/requests.storage: 1Ti

14.5.3 생성 가능한 오브젝트 수 제한

apiVersion: v1
kind: ResourceQuota
metadata:
  name: objects
spec:
  hard:
    pods : 10
    replicationcontrollers: 5
    secrets: 10
    configmaps: 10
    services: 5
    services.loadbalancers: 10
    services.nodeports: 10
    standard.storageclass.storage.k8s.io/persistentvolumeclaims: 2

14.5.4 특정 파드 상태나 QoS 클래스에 대한 쿼터 지정

QoS 클래스 기준 쿼터 범위(quota scope)

Terminating 관련 참고사항

Qos 클래스 쿼터 뻠위를 지정한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort-notterminating-pods
spec:
  scopes:
  - BestEffort               # BestEffort Qos를 갖고 유효 데드라인이 없는 파드에만 적용
  - NotTerminating
  hard:
    pods: 4                   # 저 스코프에 해당하는 파드는 4개까지만 존재할수 있다.

14.6 파드 리소스 사용량 모니터링

쿠버네티스 클러스터를 최대한 활용하기 위해 리소스 요청과 제한을 적절하게 설정하는 것은 매우 중요한 일이다. 하지만 적정 값을 찾으려면 모니터링이 필요하다. 애예상되는 부하 수준에서 컨테이너의 실제 리소스 사용량을 모니터링하고, 필요한 경우 리소스 요청과 제한을 조정해야 한다.

14.6.1 실제 리소스 사용량 수집과 검색

14.6.2 기간별 리소스 사용량 통계 저장 및 분석

인플럭스 DB와 그라파나

클러스터에서 인플럭스DB와 그라파나 실행

# metrics-server 활성화
minikube addons enable metrics-server

# 쿠버네티스 클러스터 정보 조회
kubectl cluster-info

# 미니쿠베 모니터링 서비스 가동
minikube service monitoring-grafana -n kube-system

그라파나로 리소스 사용량 분석하기

Referrence