[Kubernetes Best Practice] 8. 리소스 관리

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다. 모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다. 

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

쿠버네티스 스케줄러

Kubernetes Master Node에 존재하는 스케줄러는 클러스터와 사용자의 리소스 제약에 최적화 되도록 Pod을 배치하는 역할을 담당합니다. 이 때 논리 조건 및 우선 순위 기반의 스코어 알고리즘을 사용합니다.

• 논리 조건
  스케줄링 시 사용하는 첫 번째 기능은 참/거짓을 반환하는 논리 조건 함수입니다. 논리조건에 대해 거짓을 반환하면 해당 노드는 스케줄링 후보에서 제거되는 방식으로 동작합니다. 문서에서는 이를 Filtering이라고 표현하고 있습니다.
• 우선순위
  논리 조건으로 참에 해당하는 노드는 우선 순위 스코어 알고리즘을 통해 순위가 정해집니다. 이 중 가장 순위가 높은 노드에 Pod이 스케줄링됩니다. 만약 같은 우선순위를 반환한다면 Round Robin Tournament 방식으로 배치할 노드를 선택합니다.

---

대부분의 경우 쿠버네티스 스케줄러를 통해 최적화된 스케줄링 성능을 보여주지만 사용자가 원하는 경우 더욱 세밀한 스케줄링이 가능합니다. 이를 위해 다음과 같은 기능들이 존재합니다.

• PodAffinity / PodAntiAffinity
  Pod의 간의 배치 규칙을 설정할 수 있는 기능입니다. PodAffinity는 조건을 만족하는 Pod이 있는 노드에 배포를 하라는 의미이며 PodAntiAffinity는 조건을 만족하는 Pod이 있는 도느에 배포를 하지 말라는 것을 의미합니다. 자세한 예제는 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
spec:
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      containers:
        - name: server
          image: sphong.com/server:v1.1.0
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - server
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - redis
            topologyKey: "kubernetes.io/hostname"

 

위의 예제는 server 애플리케이션을 배포할 때, PodAffinity를 통해 redis pod이 배포된 노드에 배포를 해야하며, server pod이 이미 존재한다면 해당 노드에는 배포할 수 없음을 의미합니다. 이를 통해 하나의 노드가 실패하더라도 Pod을 다른 노드에 분산하여 배치함으로써 장애에 대응할 수 있습니다.

 

• NodeSelector / NodeAffinity
  NodeSelector는 Node Label을 통해 특정 노드에 Pod을 스케줄링하는 방법입니다. NodeAffinity는 Pod Affinity와 유사하게 Node Label을 통해 어떤 노드에 스케줄링할 지 결정하는 방법입니다. 예전에 작성했던 Elasticsearch Helm Chart를 예시로 들면 다음과 같습니다.

// Node Selector
nodeSelector:
  cloud.google.com/gke-nodepool: ssd-node-pool
---
// NodeAffinity
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
      	- key: cloud.google.com/gke-nodepool
     	  operator: In
      	  values:
      	  - ssd-node-pool

 

• Taint / Toleration
  Taint는 Pod가 스케줄링 되지 못하도록 하는 기능을 담당합니다. AntiAffinity와 동일한 기능을 수행하지만 다른 방식 및 용도로 사용됩니다. Taints는 특수한 하드웨어를 가진 장비나, 전용 노드 리소스를 선택해야 하는 경우 특정 노드를 가진 Pod만 스케줄링하고 그 외의 다른 pod은 스케줄링 하지 않으려는 상황에 사용됩니다. 만약 Taint된 노드에 스케줄링 하려면 Toleration을 통해서만 가능합니다. Taint 타입은 NoScehule, PreferNoSchedule, NoExecute, NodeCondition 타입이 존재하며 각 타입이 수행하는 기능은 문서에서 확인할 수 있습니다.
  
  Node의 Taint 설정은 kubectl taint nodes node1 key1=value1:NoSchedule의 CLI를 통해 설정할 수 있고 이 노드에 스케줄링 하기 위한 toleration은 다음과 같습니다.
  
  

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

NoSchedule과 NoExecute의 차이를 조금 더 자세히 살펴보면, NoSchedule 타입의 테인트가 추가되더라도 기존에 스케줄링 된 Pod은 그대로 실행됩니다. 하지만 NoExecute 타입의 테인트가 추가되면 기존에 스케줄링 된 Pod은 축출되는 방식으로 동작하게 됩니다.

---

Pod 리소스 관리

클러스터의 리소스 활용을 최적화하기 위해서는 Pod의 리소스 관리를 고려할 필요가 있습니다. 리소스 관리에 대해 알기 위해서는 먼저 Request와 Limit에 대해 알아야 합니다.

Request는 클러스터가 스케줄링 할 때 필요한 리소스의 양으로 CPU와 Memory를 통해 정의가 가능합니다. 만약 Request 만큼의 리소스를 만족하는 노드가 없다면 Pod은 스케줄링 되지 않습니다.

Limit은 Pod이 실행 중에 도달할 수 있는 최대 리소스 양을 의미합니다. Request와 동일하게 CPU와 Memory를 통해 정의가 가능합니다. 

---

OverCommitted

request에 맞게 리소스를 할당하여 컨테이너를 생성, 운영하던 도중 리소스가 더 필요하게 되면 limit까지 리소스를 요청할 수 있습니다. 하지만 모든 컨테이너의 limit 총합이 실제 시스템이 가용가능한 reousrce의 양보다 많아지는 현상 (=Overcommitted)이 발생할 수 있습니다.

Overcommitted 상태가 되었을 경우 CPU와 Memory는 각자 다른 작업을 수행합니다.

• CPU Overcommitted
  실제 CPU 사용량을 request에 정의된 상태까지 낮춥니다(Throttling). 이후에 Overcommitted 상태가 해결되지 않는다면 우선 순위에 따라 운영 중인 컨테이너를 강제 종료시킵니다.

• Memory Overcommitted
  사용중인 메모리의 크기를 줄일 수 없기 때문에 우선 순위에 따라 컨테이너를 강제 종료 시킵니다. 이후 초기 request에 맞게 컨테이너가 재할당됩니다.

---

Qos Class

Pod이 생성되면 Guaranteed, Burstable, Best-Effort 중 하나의 QoS 클래스가 할당됩니다. request와 limit이 같은 경우에는 Guranteed, limit > request인 경우에는 Burstable, request나 limit을 설정하지 않으면 Best-Effort가 할당됩니다. 이는 Pod 자원이 없는 경우 축출되는 Pod을 선택할 때 우선순위에 영향을 주게 됩니다. 리소스에 대한 세밀한 조정을 하지 못하면 Overcommitted 현상이 발생할 가능성이 있기 때문에 일반적으로 Guaranteed 클래스로 생성하는 것을 권장한다고 합니다. 

더 자세한 내용은 공식 문서에서 확일할 수 있습니다.

---

PodDisruptionBudget

Pod이 축출되는 유형은 2가지가 존재합니다. 하드웨어 장애, 리로스 부족으로 인한 비자발적 중단과 클러스터 오토스케일링 해제, PodTemplate 업데이트로 인한 자발적 축출입니다. PodDisruptionBudget은 Pod이 축출될 때 최소 가용 Pod과 최대 불가용 Pod에 대한 정책을 설정함으로써 어플리케이션의 가동 시간을 보장하기 위한 기능입니다. 다음의 예시는 server 어플리케이션이 항상 최소 5개가 가용해야 함을 의미합니다.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: server-pdb
spec:
  minAvailable: 5
  selector:
    matchLabels:
      app: server

---

ResourceQuota

단일 클러스터를 여러 사용자가 공유할 경우 네임스페이스에 ResourceQuota를 설정해 클러스터를 논리적으로 분할해야 합니다. 이 때 정의할 수 있는 리소스는 cpu, memory, storage, pvc, storageClass, service/deployment/replicaSet의 개수 등이 존재합니다. 다음의 예시는 sphong이라는 namespace에 cpu 및 memory, pvc 개수를 제한하는 역할을 담당합니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-rq
  namespace: sphong
spec:
  hard:
    request.cpu: "1"
    request.memory: 2Gi
    limits.cpu: "3"
    limits.memory: 2Gi
    persistentvolumeclaims: "5"

---

LimitRange

ResourceQuota를 사용할 경우 request와 limit이 명시되지 않으면 스케줄링이 거절됩니다. 하지만 리소스에 대해 잘 알지 못하는 사용자가 이를 설정하기에 어려움이 존재하고 실수로 빼먹을 수도 있습니다. 이런 상황을 위하 LimitRange라는 Admission Controller를 제공합니다. 다음 예시는 memory에 대한 defaultRequest를 설정하는 LimitRange 입니다.

apiVersion: v1
kind: LimitRange
metadata:
  name: sphong-lr
spec:
  limits:
  - default: 
      memory: 256Mi
    defaultRequest:
      memory: 128Mi
    type: Container

---

HPA

워크로드의 증가가 예상되는 경우 수동 확장을 통해 대응할 수 있지만 그렇지 않은 경우에는 자동으로 워크로드를 확장할 수 있어야 합니다. 이를 위해 쿠버네티스는 HPA를 제공합니다. HPA는 addon으로 제공되는 metrics-server로 부터 메트릭을 조회해 수평 확장을 진행할 수 있습니다. 이 때 다음과 같은 기본값을 가지고 동작합니다.

• horizontal-pod-autoscaler-sync-period(메트릭 동기화 주기) : 30s

• horizontal-pod-autoscaler-upscale-delay(확장 지연 시간) : 3m

• horizontal-pod-autoscaler-downscale-delay(축소 지연 시간) : 5m

HPA를 설정할 경우 무한 확장/축소를 방지하기 위해 최소/최대 확장 개수를 설정해야 하며, 확장을 진행할 리소스 기준을 설정해야 합니다. 다음 CLI는 cpu를 60% 사용하는 경우 최소 1개에서 최대 5개의 레플리카를 생성하는 HPA를 설정하게 됩니다.

> kubectl autoscale deployment server --cpu-percent=60 --min=1 --max=5

 

metrics-server에서 제공하는 메트릭 이외에도 사용자 정의 메트릭을 사용하여 HPA를 설정할 수도 있습니다. 이를 위해서는 API Apapter를 통해 custom metric을 API로 노출시켜야 합니다. 이와 관련된 자세한 내용은 alice_k106님의 블로그에서 쉽게 설명되어 있어 링크를 남겨두도록 하겠습니다.