쿠버네티스 스케줄링과 자원 관리, 오토스케일링

스케줄러가 필터링과 점수 매기기로 노드를 고르는 과정은 쿠버네티스 구조와 핵심 개념에 있다. 이 노트는 그 판단에 쓰이는 조건(어디에 둘까) 과 자원 선언(얼마나 쓸까), 그리고 수요에 따라 파드와 노드를 늘리고 줄이는 오토스케일러를 다룬다.

노드 고르기: 라벨로 끌어당기기

nodeSelector

spec:
  nodeSelector:
    disktype: ssd
    topology.kubernetes.io/zone: ap-northeast-2a

라벨이 모두 정확히 일치하는 노드에만 둔다. 가장 단순하지만 「a 또는 b」, 「x가 아닌」 같은 조건과 「되도록이면」 같은 선호를 표현하지 못한다.

노드 어피니티

노드 어피니티는 nodeSelector의 표현력 부족을 채운다. 연산자 In, NotIn, Exists, DoesNotExist, Gt, Lt를 쓰고, 강제 조건과 선호 조건을 나눈다.

이름 끝의 IgnoredDuringExecution은 이미 실행 중인 파드에는 다시 적용하지 않는다는 뜻이다. 배치 뒤에 노드 라벨이 바뀌어도 파드는 쫓겨나지 않는다.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:                     # 항목끼리는 OR
        - matchExpressions:                  # 항목 안 조건끼리는 AND
            - { key: kubernetes.io/arch, operator: In, values: [amd64, arm64] }
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80
        preference:
          matchExpressions:
            - { key: node.kubernetes.io/instance-type, operator: In, values: [m7g.large] }

파드 어피니티와 안티어피니티

노드 라벨이 아니라 이미 떠 있는 다른 파드의 라벨을 기준으로, 「그 파드와 같은 영역에」(어피니티) 또는 「그 파드와 다른 영역에」(안티어피니티) 둔다.

여기서 「같은 영역」의 범위를 정하는 것이 topologyKey다. topologyKey는 노드 라벨 이름이고, 그 라벨 값이 같은 노드들을 한 도메인으로 본다. kubernetes.io/hostname이면 노드 단위, topology.kubernetes.io/zone이면 가용 영역 단위다.

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector: { matchLabels: { app: api } }
        topologyKey: kubernetes.io/hostname    # 한 노드에 api 파드 하나만

강제 안티어피니티는 레플리카 수가 노드 수보다 많으면 남는 파드가 Pending이 된다. 파드 어피니티 계산은 클러스터가 크면 스케줄링을 느리게 한다.

토폴로지 분산 제약

「도메인마다 최대 하나」가 아니라 도메인 사이에 고르게 흩으려면 topologySpreadConstraints를 쓴다.

topologySpreadConstraints:
  - maxSkew: 1                              # 도메인 간 파드 수 차이 상한
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule        # ScheduleAnyway면 선호 조건
    labelSelector: { matchLabels: { app: api } }

레플리카 6개, 영역 3개면 2·2·2로, 7개면 3·2·2로 놓인다. 영역 장애에 대비해 레플리카를 흩는 표준 방법이다.

노드가 밀어내기: 테인트와 톨러레이션

어피니티가 파드를 노드로 끌어당긴다면, 테인트(taint)는 노드가 파드를 밀어낸다. 노드에 key=value:effect 테인트를 붙이면, 그것을 견디는 톨러레이션(toleration)이 있는 파드만 놓인다.

kubectl taint nodes gpu-1 dedicated=gpu:NoSchedule        # 붙이기
kubectl taint nodes gpu-1 dedicated=gpu:NoSchedule-       # 떼기(끝의 -)

tolerations:
  - { key: dedicated, operator: Equal, value: gpu, effect: NoSchedule }

톨러레이션은 「들어갈 수 있다」는 허가일 뿐 그 노드로 가라는 뜻이 아니다. GPU 노드를 GPU 작업 전용으로 쓰려면 테인트(다른 파드 차단) + 톨러레이션 + 노드 어피니티(이 파드를 그리로 끌기) 를 함께 쓴다.

컨트롤 플레인 노드와 자동 테인트

컨트롤 플레인 노드에는 node-role.kubernetes.io/control-plane:NoSchedule 테인트가 붙어 있어 일반 파드가 놓이지 않는다. API 서버·etcd의 자원과 안정성을 지키기 위해서다. 노드가 한 대뿐인 실습 클러스터에서는 이 테인트를 떼거나(kubectl taint nodes --all node-role.kubernetes.io/control-plane-), 필요한 파드에만 톨러레이션을 준다.

노드 상태가 나빠지면 노드 컨트롤러·kubelet이 테인트를 자동으로 붙인다.

파드에는 not-ready·unreachable에 대한 300초 톨러레이션이 기본으로 붙는다. 그래서 노드가 죽어도 약 5분 뒤에야 다른 노드로 옮겨진다. 빨리 옮겨야 하는 서비스는 tolerationSeconds를 줄인다.

자원 선언: requests와 limits

CPU는 압축 가능한 자원이라 넘쳐도 느려질 뿐이고, 메모리는 압축 불가능한 자원이라 넘치면 죽는다.

단위

m과 M을 혼동하면 사고가 난다. 메모리에 500m이라고 쓰면 0.5바이트다.

한쪽만 설정했을 때

메모리는 requests와 limits를 같게(OOM 예측 가능), CPU는 requests만 두고 limits는 생략하거나 넉넉히(스로틀링 회피) 두는 운영이 흔하다.

QoS 클래스

쿠버네티스는 requests·limits 설정으로 파드의 QoS 클래스를 정한다. 노드 메모리가 부족할 때 누구를 먼저 축출하고 OOM에서 먼저 죽일지의 기준이다.

네임스페이스 단위 통제

LimitRange

LimitRange는 네임스페이스 안 컨테이너·파드 하나의 자원 값을 정하거나 막는다. 파드가 만들어질 때 어드미션 단계에서 적용된다.

apiVersion: v1
kind: LimitRange
metadata: { name: defaults, namespace: team-a }
spec:
  limits:
    - type: Container
      default:        { cpu: 500m, memory: 512Mi }   # limits를 안 쓰면 넣을 값
      defaultRequest: { cpu: 100m, memory: 256Mi }   # requests를 안 쓰면 넣을 값
      min:            { cpu: 50m,  memory: 64Mi }    # 이보다 작으면 거부
      max:            { cpu: "2",  memory: 2Gi }     # 이보다 크면 거부

ResourceQuota

ResourceQuota는 네임스페이스 전체의 합계를 제한한다. 팀·환경마다 클러스터를 나눠 쓸 때 한쪽이 자원을 독차지하지 못하게 한다.

apiVersion: v1
kind: ResourceQuota
metadata: { name: team-a, namespace: team-a }
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.memory: 60Gi
    pods: "100"
    persistentvolumeclaims: "20"
    count/deployments.apps: "30"

• 한도를 넘는 생성 요청은 거부된다(Pending이 아니다). Deployment라면 ReplicaSet이 파드를 만들지 못한 채 이벤트에 exceeded quota가 남는다.
• CPU·메모리 쿼터가 걸린 네임스페이스에서는 requests·limits가 없는 파드도 거부된다. 그래서 LimitRange로 기본값을 함께 둔다.

PriorityClass와 선점

PriorityClass는 파드에 정수 우선순위를 준다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata: { name: critical-api }
value: 100000
globalDefault: false
preemptionPolicy: PreemptLowerPriority     # Never면 선점하지 않고 대기열 앞에만 선다

• 스케줄링 대기열에서 높은 우선순위 파드가 먼저 처리된다.
• 놓을 노드가 없으면 스케줄러가 낮은 우선순위 파드를 축출(선점, preemption) 해 자리를 만든다. PodDisruptionBudget은 되도록 지키지만 보장하지는 않는다.
• 노드 자원 압박 시 축출 순서에도 쓰인다. system-cluster-critical, system-node-critical은 CoreDNS·CNI 같은 시스템 구성 요소용으로 미리 있다.
• 우선순위가 낮은 「자리 맡기」 파드를 띄워 두고, 급히 필요할 때 선점되게 해서 노드 증설 시간을 숨기는 기법(오버프로비저닝)에도 쓴다.

오토스케일링

HPA

HPA 컨트롤러는 기본 15초마다 지표를 읽어 원하는 레플리카 수를 계산한다.

원하는 레플리카 = ceil( 현재 레플리카 × 현재 지표값 / 목표 지표값 )
예: 파드 4개, 평균 CPU 사용률 90%, 목표 60% → ceil(4 × 90/60) = 6

• 비율이 1에서 허용 오차(기본 10%) 안이면 바꾸지 않는다.
• 지표가 여러 개면 각각 계산한 값 중 가장 큰 값을 쓴다.
• CPU 「사용률」은 requests 대비 비율이다. requests가 없으면 HPA가 계산하지 못한다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: api }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 60 } }
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300      # 기본값. 지난 5분의 권고치 중 가장 큰 값으로만 줄인다
      policies: [{ type: Percent, value: 50, periodSeconds: 60 }]
    scaleUp:
      stabilizationWindowSeconds: 0        # 기본값. 늘릴 때는 바로

stabilizationWindowSeconds는 지표가 출렁일 때 레플리카가 늘었다 줄었다를 반복하는 플래핑(flapping)을 막는다. 줄일 때는 창 안의 권고치 중 최댓값을, 늘릴 때는 최솟값을 따른다. policies는 한 주기에 바꿀 수 있는 양(비율·개수)을 제한한다.

CPU는 부하와 사용률이 비례하는 CPU 집약 서비스에 맞다. I/O 대기가 많은 서비스, 큐 소비자는 요청 수·큐 길이 같은 커스텀 지표가 수요를 더 잘 나타낸다. 이벤트 기반 확장과 0개까지 줄이기는 KEDA가 HPA를 만들어 관리하는 방식으로 한다.

VPA

VPA는 쿠버네티스 본체가 아닌 별도 애드온이다. Recommender가 사용량 기록으로 적정 requests를 계산하고, Updater가 적용하고, 어드미션 컨트롤러가 새 파드에 값을 넣는다. limits는 원래의 requests:limits 비율을 유지하며 함께 바뀐다.

Cluster Autoscaler

줄이기를 막는 것: PodDisruptionBudget을 어기게 되는 파드, 컨트롤러 없이 직접 만든 파드, 로컬 저장소(emptyDir)를 쓰는 파드(설정에 따라), cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 어노테이션.

AWS 등에서 쓰는 Karpenter는 미리 정한 노드 그룹 대신 Pending 파드의 요구에 맞는 인스턴스 유형을 골라 노드를 바로 만들고, 파드를 더 적은·싼 노드로 모으는 통합(consolidation)도 한다.

셋을 함께 쓸 때

flowchart TB
  a["부하 증가"] --> b["HPA가 파드를 늘림"]
  b --> c["자리가 없어 Pending"]
  c --> d["Cluster Autoscaler가 노드 추가"]
  d --> e["노드 준비(수 분)"]
  e --> f["파드 배치"]
  f --> g["Ready"]
  g --> h["부하 분산"]

• HPA와 VPA를 같은 CPU·메모리 지표에 함께 걸지 않는다. VPA가 requests를 키우면 사용률이 낮아져 HPA가 파드를 줄이고, 그러면 사용량이 다시 올라 서로 싸운다. HPA를 커스텀 지표로 걸거나, VPA는 Off로 권고치만 본다.
• 스케줄러와 Cluster Autoscaler는 실제 사용량이 아니라 requests만 본다. requests가 부풀면 노드가 낭비되고, 작으면 노드가 과밀해진다. VPA 권고치로 requests를 맞추는 것이 출발점이다.
• 확장 지연이 누적된다(지표 수집 + HPA 주기 + 노드 생성 + 이미지 다운로드 + 앱 시작). 오버프로비저닝 파드, 작은 이미지, 미리 받아 둔 이미지로 줄인다.

파드를 늘려도 지연이 줄지 않을 때

수평 확장은 병목이 파드 안에 있을 때만 효과가 있다.

지연은 평균이 아니라 p95·p99로 보고, 구간별(게이트웨이·앱·DB) 트레이스로 어디서 시간이 쓰이는지 먼저 찾는다(관측 가능성, 서버 장애 진단 패턴).

정리

• nodeSelector는 정확 일치, 노드 어피니티는 연산자와 선호 조건, 파드 (안티)어피니티는 다른 파드 기준, topologyKey가 「같은 곳」의 범위를 정한다. 고르게 흩을 때는 토폴로지 분산 제약을 쓴다.
• 테인트는 노드가 밀어내고 톨러레이션은 허가할 뿐이다. 전용 노드는 테인트 + 톨러레이션 + 어피니티로 만든다.
• requests는 스케줄링과 보장, limits는 상한이다. CPU를 넘으면 스로틀링, 메모리를 넘으면 OOMKilled다.
• QoS는 requests·limits로 정해지고 압박 시 BestEffort부터 축출된다. LimitRange는 하나의 기본값과 범위, ResourceQuota는 네임스페이스 합계를 막는다.
• HPA는 비율 공식으로 파드 수를, VPA는 크기를, Cluster Autoscaler는 Pending 파드를 보고 노드를 조절한다. 셋 모두 정확한 requests에 기댄다.

관련 노트: 쿠버네티스 구조와 핵심 개념, 쿠버네티스 워크로드와 파드 생명주기, 쿠버네티스 운영, Docker 컨테이너 운영, 관측 가능성: 로그, 트레이스, 메트릭, 클라우드 비용 최적화와 숨은 비용