노드 자동 프로비저닝 노드 풀 구성

이 문서에서는 SKU 선택기, 리소스 제한 및 우선 순위 가중치를 포함하여 AKS(Azure Kubernetes Service) NAP(노드 자동 프로비저닝)에 대한 노드 풀을 구성하는 방법을 설명합니다.

노드 풀 개요

NodePools는 노드 자동 프로비저닝이 만드는 노드 및 해당 노드에서 실행되는 Pod에 대한 제약 조건을 설정합니다. 노드 자동 프로비전을 처음 설치하면 기본 NodePool이 만들어집니다. 이 NodePool을 수정하거나 NodePools를 더 추가할 수 있습니다.

NodePools의 주요 동작:

• 노드 자동 프로비저닝을 수행하려면 하나 이상의 NodePool이 작동해야 합니다.
• 노드 자동 프로비저닝은 구성된 각 NodePool을 평가합니다.
• 노드 자동 프로비저닝은 Pod에서 허용되지 않는 taints를 사용하여 NodePools를 건너뜁니다.
• 노드 자동 프로비저닝은 프로비전된 노드에 시작 taints를 적용하지만 Pod 플러러레이션이 필요하지 않습니다.
• 노드 자동 프로비저닝은 상호 배타적인 NodePools에서 가장 적합합니다. 여러 NodePools가 일치하면 가중치가 가장 높은 노드가 사용됩니다.

노드 자동 프로비전은 VM(가상 머신) SKU(Stock Keeping Unit) 요구 사항을 사용하여 보류 중인 워크로드에 가장 적합한 가상 머신을 선택합니다. SKU 제품군, VM 유형, 스폿 또는 주문형 인스턴스, 아키텍처 및 리소스 제한을 구성합니다.

기본 노드 풀 구성

기본 NodePools 이해

AKS는 사용자 지정할 수 있는 기본 노드 풀 구성을 만듭니다.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default

      # Requirements that constrain the parameters of provisioned nodes.
      # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
      # Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
      # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      - key: karpenter.azure.com/sku-family
        operator: In
        values:
        - D

system-surge 또한 노드 풀은 시스템 풀 노드를 자동 크기 조정하기 위해 만들어집니다.

기본 NodePool 만들기 제어

플래그는 --node-provisioning-default-pools 생성된 기본 노드 자동 프로비저닝 NodePools를 제어합니다.

• Auto (기본값): 즉시 사용할 수 있는 두 개의 표준 NodePools를 만듭니다.
• None: 기본 NodePools가 만들어지지 않음 - 사용자 고유의 노드를 정의해야 합니다.

포괄적인 NodePool 예제

다음 예제에서는 자세한 설명이 포함된 사용 가능한 모든 NodePool 구성 옵션을 보여 줍니다.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  # Template section that describes how to template out NodeClaim resources that Karpenter will provision
  # Karpenter will consider this template to be the minimum requirements needed to provision a Node using this NodePool
  # It will overlay this NodePool with Pods that need to schedule to further constrain the NodeClaims
  # Karpenter will provision to launch new Nodes for the cluster
  template:
    metadata:
      # Labels are arbitrary key-values that are applied to all nodes
      labels:
        billing-team: my-team

      # Annotations are arbitrary key-values that are applied to all nodes
      annotations:
        example.com/owner: "my-team"
    spec:
      nodeClassRef:
        apiVersion: karpenter.azure.com/v1beta1
        kind: AKSNodeClass
        name: default

      # Provisioned nodes will have these taints
      # Taints may prevent pods from scheduling if they are not tolerated by the pod.
      taints:
        - key: example.com/special-taint
          effect: NoSchedule

      # Provisioned nodes will have these taints, but pods do not need to tolerate these taints to be provisioned by this
      # NodePool. These taints are expected to be temporary and some other entity (e.g. a DaemonSet) is responsible for
      # removing the taint after it has finished initializing the node.
      startupTaints:
        - key: example.com/another-taint
          effect: NoSchedule

      # Requirements that constrain the parameters of provisioned nodes.
      # These requirements are combined with pod.spec.topologySpreadConstraints, pod.spec.affinity.nodeAffinity, pod.spec.affinity.podAffinity, and pod.spec.nodeSelector rules.
      # Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
      # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
      requirements:
        - key: "karpenter.azure.com/sku-family"
          operator: In
          values: ["D", "E", "F"]
          # minValues here enforces the scheduler to consider at least that number of unique sku-family to schedule the pods.
          # This field is ALPHA and can be dropped or replaced at any time 
          minValues: 2
        - key: "karpenter.azure.com/sku-name"
          operator: In
          values: ["Standard_D2s_v3","Standard_D4s_v3","Standard_E2s_v3","Standard_E4s_v3","Standard_F2s_v2","Standard_F4s_v2"]
          minValues: 5
        - key: "karpenter.azure.com/sku-cpu"
          operator: In
          values: ["2", "4", "8", "16"]
        - key: "karpenter.azure.com/sku-version"
          operator: Gt
          values: ["2"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["eastus-1", "eastus-2"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["arm64", "amd64"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]

      # ExpireAfter is the duration the controller will wait
      # before terminating a node, measured from when the node is created. This
      # is useful to implement features like eventually consistent node upgrade,
      # memory leak protection, and disruption testing.
      expireAfter: 720h

      # TerminationGracePeriod is the maximum duration the controller will wait before forcefully deleting the pods on a node, measured from when deletion is first initiated.
      # 
      # Warning: this feature takes precedence over a Pod's terminationGracePeriodSeconds value, and bypasses any blocked PDBs or the karpenter.sh/do-not-disrupt annotation.
      # 
      # This field is intended to be used by cluster administrators to enforce that nodes can be cycled within a given time period.
      # When set, drifted nodes will begin draining even if there are pods blocking eviction. Draining will respect PDBs and the do-not-disrupt annotation until the TGP is reached.
      # 
      # Karpenter will preemptively delete pods so their terminationGracePeriodSeconds align with the node's terminationGracePeriod.
      # If a pod would be terminated without being granted its full terminationGracePeriodSeconds prior to the node timeout,
      # that pod will be deleted at T = node timeout - pod terminationGracePeriodSeconds.
      # 
      # The feature can also be used to allow maximum time limits for long-running jobs which can delay node termination with preStop hooks.
      # If left undefined, the controller will wait indefinitely for pods to be drained.
      terminationGracePeriod: 30s

  # Disruption section which describes the ways in which Karpenter can disrupt and replace Nodes
  # Configuration in this section constrains how aggressive Karpenter can be with performing operations
  # like rolling Nodes due to them hitting their maximum lifetime (expiry) or scaling down nodes to reduce cluster cost
  disruption:
    # Describes which types of Nodes Karpenter should consider for consolidation
    # If using 'WhenEmptyOrUnderutilized', Karpenter will consider all nodes for consolidation and attempt to remove or replace Nodes when it discovers that the Node is underutilized and could be changed to reduce cost
    # If using `WhenEmpty`, Karpenter will only consider nodes for consolidation that contain no workload pods
    consolidationPolicy: WhenEmptyOrUnderutilized | WhenEmpty

    # The amount of time Karpenter should wait after discovering a consolidation decision
    # This value can currently only be set when the consolidationPolicy is 'WhenEmpty'
    # You can choose to disable consolidation entirely by setting the string value 'Never' here
    consolidateAfter: 30s

    # Budgets control the speed Karpenter can scale down nodes.
    # Karpenter will respect the minimum of the currently active budgets, and will round up
    # when considering percentages. Duration and Schedule must be set together.
    budgets:
    - nodes: 10%
    # On Weekdays during business hours, don't do any deprovisioning.
    - schedule: "0 9 * * mon-fri"
      duration: 8h
      nodes: "0"

  # Resource limits constrain the total size of the pool.
  # Limits prevent Karpenter from creating new instances once the limit is exceeded.
  limits:
    cpu: "1000"
    memory: 1000Gi

  # Priority given to the NodePool when the scheduler considers which NodePool
  # to select. Higher weights indicate higher priority when comparing NodePools.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 10

지원되는 노드 프로비전 도구 요구 사항

Kubernetes는 Azure에서 구현하는 Well-Known 레이블을 정의합니다. NodePool API의 "spec.requirements" 섹션에서 이러한 레이블을 정의합니다.

노드 자동 프로비저닝은 Kubernetes의 잘 알려진 레이블 외에도 고급 일정 예약을 위해 Azure 특정 레이블을 지원합니다.

잘 알려진 레이블이 있는 SKU 선택기

잘 알려진 레이블

인스턴스 유형

• 키: node.kubernetes.io/instance-type
• 키: karpenter.azure.com/sku-family
• 키: karpenter.azure.com/sku-name
• 키: karpenter.azure.com/sku-version

일반적으로 인스턴스 형식은 단일 값이 아닌 목록이어야 합니다. Pod를 효율적으로 배치하기 위한 선택을 최대화하므로 이러한 요구 사항을 정의되지 않은 상태로 두는 것이 좋습니다.

대부분의 Azure VM 크기는 AKS를 지원하지 않는 특수 크기를 제외하여 지원됩니다.

SKU 제품군 예제

karpenter.azure.com/sku-family 선택기를 사용하면 특정 VM 패밀리를 대상으로 지정할 수 있습니다.

• D 시리즈: CPU 대 메모리 비율이 분산된 범용 VM
• F 시리즈: CPU 대 메모리 비율이 높은 컴퓨팅 최적화 VM
• E 시리즈: 메모리 집약적 애플리케이션을 위한 메모리 최적화 VM
• L 시리즈: 디스크 처리량이 높은 스토리지 최적화 VM
• N 시리즈: 계산 집약적 워크로드에 대한 GPU 지원 VM

예제 구성:

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - D
  - F

SKU 이름 예제

karpenter.azure.com/sku-name 선택기를 사용하면 정확한 VM 인스턴스 유형을 지정할 수 있습니다.

requirements:
- key: karpenter.azure.com/sku-name
  operator: In
  values:
  - Standard_D4s_v3
  - Standard_F8s_v2

SKU 버전 예제

karpenter.azure.com/sku-version 선택기는 특정 세대를 대상으로 합니다.

requirements:
- key: karpenter.azure.com/sku-version
  operator: In
  values:
  - "3"  # v3 generation
  - "5"  # v5 generation

가용성 영역

• 키: topology.kubernetes.io/zone
• 값 예제: eastus-1
• 값 목록: 사용 가능한 영역을 확인하는 데 사용 az account list-locations --output table

노드 자동 프로비저닝은 특정 영역에 노드를 만들도록 구성할 수 있습니다. Azure 구독의 가용성 영역 eastus-1 은 다른 Azure 구독과 실제 위치가 eastus-1 동일하지 않을 수 있습니다.

건축학

• 키: kubernetes.io/arch
• 값:
  • amd64
  • arm64

노드 자동 프로비전은 노드와 arm64 노드를 모두 amd64 지원합니다.

운영 체제

• 키: kubernetes.io/os
• 값:
  • linux

노드 자동 프로비저닝은 linux 운영 체제(Ubuntu + AzureLinux)를 지원합니다. Windows 지원은 곧 제공될 예정입니다.

용량 유형

• 키: karpenter.sh/capacity-type
• 값:
  • spot
  • on-demand

NodePool에서 스폿 및 주문형 인스턴스를 허용하는 경우 노드 자동 프로비저닝은 스폿 제품의 우선 순위를 지정합니다.

노드 풀 한도

기본적으로 노드 자동 프로비전은 사용 가능한 Azure 할당량 내에서 워크로드를 예약하려고 시도합니다. 노드 풀 사양 내에서 한도를 지정하여 노드 풀에서 사용하는 리소스의 상한을 지정할 수도 있습니다.

spec:
  # Resource limits constrain the total size of the cluster.
  # Limits prevent Node Auto Provisioning from creating new instances once the limit is exceeded.
  limits:
    cpu: "1000"
    memory: 1000Gi

노드 풀 가중치

여러 노드 풀을 정의한 경우 워크로드를 예약해야 하는 위치에 대한 기본 설정을 지정할 수 있습니다. 노드 풀 정의에 대한 상대적 가중치를 정의합니다.

spec:
  # Priority given to the node pool when the scheduler considers which to select. 
  # Higher weights indicate higher priority when comparing node pools.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 10

노드 풀 구성 예제

GPU 사용 노드 풀

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-pool
spec:
  weight: 20
  limits:
    cpu: "500"
    memory: 500Gi
  template:
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: karpenter.azure.com/sku-gpu-manufacturer
        operator: In
        values:
        - nvidia
      - key: karpenter.azure.com/sku-gpu-count
        operator: Gt
        values:
        - "0"

스폿 인스턴스 노드 풀

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-pool
spec:
  weight: 5
  template:
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - spot
        - on-demand # Spot nodepools with on-demand configured will fallback to on-demand capacity
      - key: karpenter.azure.com/sku-family
        operator: In
        values:
        - D
        - F

다음 단계

• 노드 중단 정책 구성
• 네트워킹 구성에 대해 알아보기
• AKSNodeClass 설정 구성