노드의 리소스 관리

오랜만에 해서 AKS에 연결하는법을 까먹었다

az aks start --name sampleAKS --resource-group sampleAKS

시작만 하면 되는듯. az는 portal에서 로그인하면 자동으로 되는것 같다.

 

 

 

쿠버네티스를 통해 리소스를 노드에 할당되는 리소스를 제어 해보는게 목표다

 

 

노드에서 이용할 수 있는 리소스의 상세정보를 살펴보자.

kubectl describe node [node 명]
만약 노드명을 모르면 kubectl get node 를 통해 확인하자

이런 정보가 나오는데 Capacity는 노드가 사용가능한 리소스, Allocatable은 포드가 이용가능한 리소스의양.

밑에 cpu가 1900m이 나오는데 1000m당 1cpu라고 생각하면 된다.

 

 

Resource Request

어떤 노드에 어떤 포드가 스케줄링 될지는 클러스터에게 맡기지만 스펙이 안좋은 노드에 포드가 배포되면 곤란한 경우가 생긴다.

그래서 포드에 들어가는 컨테이너 애플리케이션에 cpu와 메모리를 할당 할수 가있는데 그기능이 Resource Request이다.

한마디로 포드를 노드에 스케줄링할때 사용된다.

 

다음의 매니페스트로 포드를 만들자

# (1) 기본항목
apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
  
# (2) Pod 스펙
spec:

  # (3) 컨테이너 사양
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      requests:
        cpu: 400m
        memory: 2Gi

생성명령어

kubectl create -f [매니페스트파일]

 

포드가 어떤 노드에 있는지 확인해보자

kubectl get pods -o wide

***0노드에서 생성된것을 볼수있다.

 

그러면 이 노드의 리소스를 확인해보자.

전의 명령어 describe로 확인할 수 있다.

보면 requests-pod에서 cpu 400m(21%), mem2gi(94%)를 사용하고 있는것을 볼수 있다.

(좀이상한게 allocatable이 줄질 않았다?)

 

-  만약 가지고 있는 리소스보다 더 많이 할당하게 된다면 get pod 에서 확인할수 있는 status가 pending 으로 나오며

 describe에서 Node는 None, Condition-Podscheduled 가 False로 되버린다.

 

 

포드를 스케줄링 할때 실제 노드의 리소스 사용량을 체크하지 않는다.

그래서 만일 실제 리소스 사용율이 낮아 여유가 있는 노드가 있어도 정의상 리소스를 확보할 수 없는 노드에는 포드를 배치하지 않는다.

 - 가용용량만보고  실제 사용용량을 보지 않는다는 의미같다.

Resource Requests는 포드에 들어가는 컨테이너 애플리케이션의 총합을 넣어야한다.

 

Resource Limit

이번에는 메모리와 cpu의 상한을 정해보자

 실행할 매니페스트이다.

# (1) 기본항목
apiVersion: v1
kind: Pod
metadata:
  name: limits-pod

# (2) Pod스펙
spec:
  #restartPolicy: OnFailure 
  
  # (3) 컨테이너 사양
  containers:
  - name: main
    image: polinux/stress
    resources:
      limits:
        cpu: 400m
        memory: 1Gi
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "500M", "--vm-hang", "1"]

설명하자면 polinux/stress 이미지로부터 컨테이너를 생성하여 그 컨테이너가 0.5g메모리를 사용하는 애플리케이션이다.

이 컨테이너의 cpu 상한은 400m, 메모리는 1g 상한이다.

 

cpu 400m에 mem 1Gi로 할당 및 제한이 걸려 있는 것을 볼 수 있다.

 

다음은 상한을 넘게 설정해 보았다.

kubectl describe pod limits-pod

위 명령어를 치면 아래 상태가 나온다.

 

- 만약 상한을 넘게 되면 STATUS는 CrashLoopBackOff,(재시작을 마치면 oomkilled가 되는것같다. 두가지가 번갈아가면서 표시된다.)

 desc에서 Node는 정상 출력, State: Reason은 CrashLoopBackOff, Last State - Reason은 OOMKilled라고 나온다.

근데 Podscheduled는 True로 출력된다.

 

오류 발생했을때 포드의 제어

기본적으로 오류가 발생하면 포드는 재시작을 반복한다.

설정방법은 spec 아래에 restartPolicy 값을 정해주면된다.

Always : 항상 재시작(기본값)

OnFailure : 비정상 종료 발생 시 컨테이너를 재시작 합니다. (시작 실패?)

Never : 재시작하지 않는다.

 

 

포드의 우선순위

우선순위(Quality of Service)는

resource Requests와 리소스의 상한을 정하는 Resource Limits 조건을 바탕으로 우선순위가  다음과 같이 정해 진다.

• BestEffort : 포드 안의 어떤 컨테이너에도 RR과 RL가 설정되어 있지 않을 때 설정된다.
• Burstable: BestEffort와 Guaranteed 이외의 경우에 설정된다.
• Guaranteed : CPU와 메모리 둘다에 RR,RL이 설정되어 있는 경우, 포드 안의 각각의 컨테이너에 설정되어 있는경우, 값이 각각 똑같은 경우

기본값을 BestEffort로 설정되어 있으며, besteffort - burstable - guaranteed 순으로 kill 된다.(guaranteed는 시스템이 메모리 필요한경우에만)