Workload & Pod management

워크로드 배치

워크로드를 여러 노드에 고르게 분산시켜야 애플리케이션의 가용성을 높일 수 있다.
스케줄러가 새로운 파드를 어느 노드에서 실행할 지 결정하는데, 서버의 총 컴퓨팅 파워, 기존 파드의 사용량, 사용자가 파드 실행 위치를 제어하고자 정의한 policy 등에 의해 결정된다.

워크로드 배치 상태

새로 생성된 파드는 실행될 노드가 지정될 때 까지 pending 상태이다.
스케줄러는 파드에 적합한 노드를 지정하기 위해 부적격한 노드를 후보에서 제거하는 filtering 과정과 남은 노드 중 가장 적합한 노드를 선택하기 위한 scoring 과정을 수행한다.

taint

필터링 과정에서는 taint라는 특별한 타입의 레이블이 사용된다. key-value 형태이며 스케줄러가 노드를 분류하는 기준이 된다.
컨트롤플레인 노드의 경우 master taint가 부여되어 필터링 과정에서 바로 제외된다.
다음 명령들을 이용해 각 노드에 적용된 테인트를 확인하고, 모든 노드에 테인트를 하나 추가하고 제거할 수 있다.

kubectl get nodes -o jsonpath='{range.items[*]}{.metadata.name} {.spec.taints[*].key}{end}'

# 모든 노드에 taint 추가
kubectl taint nodes --all kiamol-diskk=hdd:Noschedule

# 모든 노드에 해당 taint 제거 (- 기호를 사용)
kubectl taint nodes --all kiamol-diskk=hdd:Noschedule-

테인트를 추가하더라도 기존 워크로드에는 영향을 미치지 않는다.
파드 정의에 toleration을 추가하면 특정 테인트를 가진 노드에도 파드가 배정될 수 있도록 명시할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep2
  labels:
    kiamol: ch19
spec:
  selector:
    matchLabels:
      app: sleep2
  template:
    metadata:
      labels:
        app: sleep2
    spec:
      containers:
      - name: sleep
        image: kiamol/ch03-sleep      
      tolerations:
      - key: "kiamol-disk"
        operator: "Equal"
        value: "hdd"
        effect: "NoSchedule"

NoSchedule taint가 부여된 노드는 스케줄러의 필터링 과정에서 제외되기 때문에 파드가 배치되지 못한다.
파드가 배치되지 못해 pending 상태에 있다면 스케줄러는 계속해서 노드 배정을 시도한다.

effect 종류

NoSchedule
- 파드 정의에 toleration이 없는 한 스케줄러의 filtering 단계에서 노드가 배제된다.
PreferNoSchedule
- 파드 정의에 toleration이 있고 다른 적합한 노드가 남아있지 않을 경우에만 이 노드에서 파드를 실행하게 된다.
- 스케줄러의 scoring에서 낮은 점수를 받는다.

노드셀렉터

파드가 특정 레이블을 가진 노드에서만 배치되도록 정의할 수 있다.
다음은 노드의 CPU 아키텍처가 ZX 스펙트럼이어야 파드가 배치되도록 노드셀렉터를 이용해 강제한 예시이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep2
  labels:
    kiamol: ch19
spec:
  selector:
    matchLabels:
      app: sleep2
  template:
    metadata:
      labels:
        app: sleep2
    spec:
      containers:
      - name: sleep
        image: kiamol/ch03-sleep
      nodeSelector:        
        kubernetes.io/arch: zxSpectrum

어피니티

노드 어피니티

스케줄러에 원하는 우선 조건 또는 필요 조건을 상세히 정의할 수 있다.
이를 통해 특정 노드에 파드가 실행되도록 강제할 수 있다.
requiredDuringSchedulingIgnoredDuringExecution 키워드를 통해 반드시 충족되어야 하는 조건을 지정할 수 있다.
preferredDuringSchedulingIgnoredDuringExecution 키워드를 통해 더 선호하는 조건을 지정할 수 있다.
여러 matchExpressions를 지정하여 원하는 레이블 조건을 명시할 수 있으며, 각 조건은 OR 조건으로 연결된다.
아래는 requiredDuringSchedulingIgnoredDuringExecution 키워드를 이용해 파드가 배치될 노드가 운영체제가 linux 혹은 windows여야만 하고, preferredDuringSchedulingIgnoredDuringExecution 키워드를 이용해 리눅스 노드를 좀 더 선호하도록 어피니티를 지정한 예제이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep2
  labels:
    kiamol: ch19
spec:
  selector:
    matchLabels:
      app: sleep2
  template:
    metadata:
      labels:
        app: sleep2
    spec:
      containers:
      - name: sleep
        image: kiamol/ch03-sleep      
      tolerations:
      - key: "kiamol-disk"
        operator: "Equal"
        value: "hdd"
        effect: "NoSchedule"
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/arch
                  operator: In
                  values:
                  - amd64
                - key: kubernetes.io/os
                  operator: In
                  values:
                  - linux
                  - windows
              - matchExpressions:
                - key: beta.kubernetes.io/arch
                  operator: In
                  values:
                  - amd64
                - key: beta.kubernetes.io/os
                  operator: In
                  values:
                  - linux
                  - windows
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values:
                - linux
          - weight: 1
            preference:
              matchExpressions:
              - key: beta.kubernetes.io/os
                operator: In
                values:
                - linux

파드 어피니티

파드 간 노드 배정 시, 다른 파드와 같은 노드에 배정해야 할 때는 어피니티를 작성하고 다른 노드에 배정해야할 때는 안티어피니티를 작성한다.
서로 통신하는 컴포넌트들은 같은 노드에 두어 네트워크 부하를 줄일 수 있으며, 같은 컴포넌트들은 서로 다른 노드에 두어 고가용성을 확보할 수 있다.
스케줄러가 파드 어피니티 조건에 맞는 노드를 찾아 배정하지 못하면 파드는 pending 상태가 된다.
topologykey를 이용해 어피니티의 적용 단위를 결정한다. hostname일 경우 파드를 같은 노드에 실행하라는 의미이고, region, zone일 경우 지역이 같은 노드끼리 실행하라는 의미가 된다.
아래는 새로 배치할 파드가 app=numbers 레이블이 부여된 파드가 실행중인 노드에 배정하도록 강제하는 예시이다.

apiVersion: apps/v1
kind: Deployment  
metadata:
  name: numbers-web
  labels:
    kiamol: ch19
    app: numbers
spec:
  selector:
    matchLabels:
      app: numbers
      component: web
  template:
    metadata:
      labels:
        app: numbers
        component: web
    spec:
      containers:
        - name: web
          image: kiamol/ch03-numbers-web
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - numbers
              - key: component
                operator: In
                values:
                - api
            topologyKey: "kubernetes.io/hostname"

파드 어피니티는 노드 어피니티와 같은 규칙을 사용하므로 두 가지를 섞어 사용하면 혼동될 수 있다.
디플로이먼트 혹은 레플리카셋 등 컨트롤러에서 파드 안티어피니티를 지정했을 때 조건에 맞는 노드가 더이상 없는 경우 레플리카수를 늘리긴 하지만 늘어난 파드들의 상태는 pending으로 남아있게 된다.

자동 스케일링

애플리케이션의 부하에 맞춰 레플리카 수를 조절하는 기능이다.
기존 파드의 부하를 확인하기 위해 metrics-server 컴포넌트가 제공하는 kubectl top nodes 명령을 사용해 리소스 사용량을 확인할 수 있다.
쿠버네티스에서는 자동 스케일링을 위해 클러스터 측정값을 수집해야 하므로 metrics-server 컴포넌트가 반드시 설치되어 있어야 한다.

HPA

HorizontalPodAutoscaler의 약자로, 자동 스케일링을 위한 리소스를 의미한다.
디플로이먼트나 스테이트풀셋 같은 컨트롤러를 스케일링 대상으로 삼으며, CPU 사용량에 따라 조절할 레플리카 수의 범위를 지정할 수 있다.
실행중인 모든 파드의 평균 CPU 사용량이 증가하면 15초에 하나씩 파드 개수를 늘리고, 감소하면 5분 이상 CPU 사용량 기준 이하를 유지하는지 확인한 후 파드 개수를 줄인다.
측정값이 수집되어 HPA에 전달 되는 데에 최대 수십초의 시간이 걸릴 수 있다.
하나의 대상만 지정할 수 있으므로 각 애플리케이션마다 적합한 스케일링 규칙 및 속도를 지정할 수 있다.
아래는 기준 CPU 사용량을 75%로 두고 해당 사용량을 기준으로 파드 개수를 1~5개 사이에서 자동으로 조절하도록 정의한 HPA 예시이다.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: pi-cpu
  labels:
    kiamol: ch19
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: pi-web
  minReplicas: 1
  maxReplicas: 5
  targetCPUUtilizationPercentage: 75

HPA 버전 2에서는 측정 값이 기준 이상 혹은 이하임이 일정 시간동안 지속될 때 까지 대기한 후 스케일링하도록 할 수 있다. 그리고 CPU 사용량 외에 HTTP 요청 수나 큐에 쌓인 메시지 개수 등의 기준을 사용할 수도 있다.
다음은 CPU 사용률을 기준으로 하며 파드를 감소시킬 때 기준치 이하로 내려오고 30초동안 유지되면 현재 파드 수를 50% 감소시키는 예시이다.

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler
metadata:
  name: pi-cpu
  labels:
    kiamol: ch19
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: pi-web
  minReplicas: 1
  maxReplicas: 5  
  metrics:
  - type: Resource
    resource:
      name: cpu      
      target: 
        type: Utilization
        averageUtilization: 75
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 50
        periodSeconds: 15

아래 명령을 통해 현재 HPA의 상태를 확인할 수 있다.

kubectl get hpa <hpa name>

파드 축출

노드의 컴퓨팅 리소스가 고갈된 경우 서버 상태를 안정화시키기 위해 파드를 제거한다.
선점이란 리소스 정의나 리소스쿼터, 배치 및 스케일링 중에 문제가 생겨 메모리, 디스크 용량 등이 고갈된 상태가 발생했을 때 일어난다.
- CPU 리소스의 경우 다른 컴퓨팅 리소스와 달리 스로틀링만으로 리소스 회수가 가능하므로 선점을 일으키지 않는다.
선점이 발생하면 쿠버네티스는 해당 노드가 과부하 상태라고 간주하고 파드를 축출(eviction)한다.
축출된 파드는 나중에 문제 원인 파악을 위해 노드에 남겨두지만 파드 컨테이너는 종료 및 삭제된다.
축출된 파드가 컨트롤러 관리 하에 있었다면, 다른 노드에 다시 배정된다.
파드가 축출되면서 대량의 메모리가 회수되고 메모리 고갈 상태가 사라지면, 이를 대체하는 새 파드가 생성되고 다시 이 파드로 인해 메모리 고갈 상태에 빠지게 되어 계속 새로 생성되고 축출되는 상황이 반복될 수 있다.

우선순위

축출 대상이 될 수 있는 모든 파드의 우선 순위가 같다면, 초과 점유하고 있는 리소스양이 많은 순서대로 파드를 축출한다. 따라서 파드 정의에 지정하는 기준 리소스 사용량을 신중하게 정해야 한다.
파드의 우선순위에 따라 축출될 파드가 결정된다. 파드의 우선순위는 파드에 정의된 리소스 사용량 대비 실제 리소스 사용량과 priority class에 의해 결정된다.
priority class는 다음과 같이 정의할 수 있으며 값이 클수록 우선순위가 높은 것이다. 메모리 고갈 상태가 발생하면 우선순위가 낮은 파드가 먼저 축출된다.
다음은 PriorityClass 리소스를 정의하고 이를 파드 정의에 연결시켜 파드의 우선순위를 높이는 예시이다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: kiamol-high
  labels:
    kiamol: ch19
value: 10000
globalDefault: false
description: "High priority - may evict low priority"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stress-high
  labels:
    kiamol: ch19
spec:
  replicas: 2
  selector:
    matchLabels:
      app: stress
      level: high
  template:
    metadata:
      labels:
        app: stress
        level: high
    spec:
      priorityClassName: kiamol-low
      # ...

PreviousMulti Node/Architecture Cluster NextCRD & Operator

Last updated 6 months ago