노드 풀 만들고 사용하기

노드 풀 만들고 사용하기 (Create and use node pools)

노드 풀(node pools)을 사용해 클라이언트를 그룹화하고 인프라를 논리 단위로 분리해서, 작업이 할당 배치를 제어할 수 있게 해요. 멀티 리전 클러스터에서의 노드 풀 복제, 내장 노드 풀, 노드 풀 패턴, 그리고 스케줄러 구성, 노드 풀 거버넌스, 멀티 리전 작업 같은 엔터프라이즈 기능을 검토해요.

노드 풀이 없으면 작업의 할당은 클러스터의 자격 있는 클라이언트 어디에나 배치될 수 있어요. 어피니티(affinity)와 제약(constraints)은 특정 노드에 대한 선호를 표현하는 데 도움이 되지만, 다른 작업이 특정 노드 집합에 할당을 배치하는 것을 쉽게 막지는 못해요.

nomad node pool apply 명령에 노드 풀 명세 파일을 전달해 노드 풀을 만들어요.

# dev-pool.nomad.hcl
node_pool "dev" {
  description = "Nodes for the development environment."

  meta {
    environment = "dev"
    owner       = "sre"
  }
}

$ nomad node pool apply dev-pool.nomad.hcl
Successfully applied node pool "dev"!

그런 다음 클라이언트의 구성 파일에서 node_pool 속성을 설정하거나, 동등한 -node-pool 명령줄 플래그를 사용해 이 노드 풀에 클라이언트를 추가할 수 있어요.

client {
  # ...
  node_pool = "dev"
  # ...
}

이 과정을 간소화하기 위해 노드는 요청 시 노드 풀을 만들 수 있어요. 클라이언트 구성이 아직 존재하지 않는 노드 풀을 참조하면, 노마드는 클라이언트 등록 시 노드 풀을 자동으로 만들어요.

참고: 이 동작은 비권위(non-authoritative) 리전의 클라이언트에는 적용되지 않아요. 자세한 내용은 Multi-region Clusters를 참고해 주세요.

작업은 node_pool 속성으로 노드 풀을 참조할 수 있어요.

job "app-dev" {
  # ...
  node_pool = "dev"
  # ...
}

namespace 속성과 마찬가지로 노드 풀은 미리 존재해야 하며, 그렇지 않으면 작업 등록에서 오류가 발생해요. 주어진 노드 풀의 노드만 배치 대상으로 고려돼요. 사용 가능한 노드가 없으면 클라이언트가 노드 풀에 추가될 때까지 배포는 pending으로 유지돼요.

출처: 문서

본문

멀티 리전 클러스터

연합된 멀티 리전 클러스터에서 노드 풀은 권위 있는(authoritative) 리전에서 모든 비권위 리전으로 자동 복제되며, 새 노드 풀 생성·수정 요청은 비권위 리전에서 권위 있는 리전으로 전달돼요.

복제 데이터는 한 방향으로만 흐르므로 비권위 리전의 클라이언트는 요청 시 노드 풀을 만들 수 없어요.

아직 존재하지 않는 노드 풀을 참조하는 비권위 리전의 클라이언트는 노드 풀이 만들어져 모든 리전에 복제될 때까지 initializing 상태로 유지돼요.

내장 노드 풀

사용자가 생성한 노드 풀 외에도 노마드는 삭제하거나 수정할 수 없는 두 개의 내장 노드 풀을 자동으로 만들어요.

  • default: 노드 풀은 노마드의 선택 기능이에요. 클라이언트 구성과 job file 모두에서 node_pool 속성은 선택 사항이에요. 지정하지 않으면 이 값들은 기본 내장 노드 풀을 사용하도록 설정돼요.
  • all: 어떤 상황에서는 노드 풀 구성과 관계없이 클러스터의 모든 클라이언트에 걸쳐 작업을 실행하는 것이 유용해요. 이런 시나리오에서는 클러스터에 등록된 모든 클라이언트를 항상 포함하는 내장 all 노드 풀을 작업이 사용할 수 있어요. 다른 노드 풀과 달리 all 노드 풀은 작업에서만 사용할 수 있고 클라이언트 구성에서는 사용할 수 없어요.

노마드 엔터프라이즈

엔터프라이즈

노마드 엔터프라이즈는 노드 풀을 더 강력하고 관리하기 쉽게 만드는 추가 기능을 제공해요.

스케줄러 구성 (Scheduler Configuration)

노마드 엔터프라이즈의 노드 풀은 노마드 스케줄러의 일부 측면을 사용자 정의하고 노드 풀별로 특정 전역 구성을 재정의할 수 있어요.

이를 통해 메모리 초과 할당(oversubscription) 같은 기능을 격리하여 실험하거나, 주어진 클라이언트 집합에 배포되는 워크로드 유형에 따라 스케줄러 알고리즘을 spread 또는 binpacking 사이에서 조정할 수 있어요.

내장 all 노드 풀을 사용하면 전역 스케줄러 구성이 적용돼요.

자세한 내용은 노드 풀 명세의 scheduler_config 파라미터를 참고해 주세요.

노드 풀 거버넌스 (Node Pool Governance)

노드 풀과 네임스페이스는 몇 가지 유사점을 공유하며, 둘 다 리소스를 격리된 논리 단위로 그룹화하는 방법을 제공해요. 작업은 네임스페이스로, 클라이언트는 노드 풀로 그룹화돼요.

노드 풀 거버넌스는 네임스페이스에 기본 노드 풀을 할당하며, 이는 네임스페이스에 등록된 모든 작업이 자동으로 사용해요. 이 기능은 모든 작업에 지정할 필요 없이 네임스페이스 구성에서 노드 풀을 유추하므로 작업 관리를 간소화해요.

이 연결은 네임스페이스 node_pool_config 블록의 default 속성으로 이루어져요.

namespace "dev" {
  description = "Jobs for the development environment."

  node_pool_config {
    default = "dev"
  }
}

이제 dev 네임스페이스의 모든 작업은 dev 노드 풀의 노드에만 할당을 배치하므로, 작업 명세에서 node_pool 속성을 생략할 수 있어요.

job "app-dev" {
  # The "dev" node pool will be used because it is the
  # namespace's default node pool.
  namespace = "dev"
  # ...
}

작업은 다른 node_pool 값을 지정해 네임스페이스 기본 노드 풀을 재정의할 수 있어요.

네임스페이스는 allowed와 denied 파라미터로 이 동작을 허용할지 시행하거나 어떤 노드 풀을 사용할 수 있고 없을지 제한할 수 있어요.

namespace "dev" {
  description = "Jobs for the development environment."

  node_pool_config {
    default = "dev"
    denied  = ["prod", "qa"]
  }
}

job "app-dev" {
  namespace = "dev"

  # Jobs in the "dev" namespace are not allowed to use the
  # "prod" node pool and so this job will fail to register.
  node_pool = "prod"
  # ...
}

멀티 리전 작업 (Multi-region Jobs)

멀티 리전 작업은 각 리전 블록에서 최상위 node_pool 작업 값이나 네임스페이스 기본 노드 풀을 재정의해 리전별로 다른 노드 풀을 지정할 수 있어요.

job "multiregion" {
  node_pool = "dev"

  multiregion {
    # This region will use the top-level "dev" node pool.
    region "north" {}

    # While the regions bellow will use their own specific node pool.
    region "east" {
      node_pool = "dev-east"
    }

    region "west" {
      node_pool = "dev-west"
    }
  }
  # ...
}

노드 풀 패턴

아래 섹션들은 특정 목표를 달성하는 데 사용할 수 있는 노드 풀 패턴을 설명해요.

인프라 및 시스템 작업 (Infrastructure and System Jobs)

이 패턴은 비즈니스 중심 애플리케이션의 기본 인프라를 제공하는 데 초점을 둔 특정 작업 집합을 위해 노드를 예약하면서, 시스템 작업이 노드 풀 경계를 넘을 수 있게 하는 예시를 보여줘요.

노마드 클러스터에는 더 비즈니스 중심적인 애플리케이션의 기본 인프라를 제공하는 데 초점을 둔 특정 작업이 있는 것이 일반적이에요. 예시로는 트래픽 인그레스용 리버스 프록시, CSI 플러그인, 주기 유지보수 작업이 있어요.

이 작업들은 자체 네임스페이스로 격리할 수 있지만 스케줄링 요구사항이 다를 수 있어요.

리버스 프록시(그리고 오직 리버스 프록시만)는 공개 트래픽에 노출된 클라이언트에서 실행해야 할 수 있고, CSI 컨트롤러 플러그인은 클라우드 리소스와 API에 대한 높은 권한 접근이 있는 클라이언트가 필요할 수 있어요.

CSI 노드 플러그인과 주기 유지보수 작업 같은 다른 작업은 클러스터의 모든 클라이언트에서 시스템 작업으로 실행해야 할 수 있어요.

노드 풀은 첫 번째 작업 집합에 필요한 격리를 달성하는 데 사용할 수 있고, 모든 클라이언트에서 실행해야 하는 작업에는 내장 all 노드 풀을 사용할 수 있어요. 정리를 위해 모든 작업이 같은 infra 네임스페이스에 등록돼요.

job "ingress-proxy" {
  namespace = "infra"
  node_pool = "ingress"
  # ...
}

job "csi-controller" {
  namespace = "infra"
  node_pool = "csi-controllers"
  # ...
}

job "csi-nodes" {
  namespace = "infra"
  node_pool = "all"
  # ...
}

job "maintenance" {
  type      = "batch"
  namespace = "infra"
  node_pool = "all"

  periodic { /* ... */ }
  # ...
}

내장 all 노드 풀을 대상으로 할 때는 양성·음성 제약을 사용해 배치를 세밀하게 조정해요.

job "maintenance-linux" {
  type      = "batch"
  namespace = "infra"
  node_pool = "all"

  constraint {
    attribute = "${attr.kernel.name}"
    value     = "linux"
  }

  constraint {
    attribute = "${node.pool}"
    operator  = "!="
    value     = "ingress"
  }

  periodic { /* ... */ }
  # ...
}

노마드 엔터프라이즈와 노드 풀 거버넌스를 사용하면 infra 네임스페이스가 기본적으로 특정 네임스페이스를 사용하고 필요한 특정 노드 풀만 허용하도록 구성할 수 있어요.

namespace "infra" {
  description = "Infrastructure jobs."

  node_pool_config {
    default = "infra"
    allowed = ["ingress", "csi-controllers", "all"]
  }
}

혼합 스케줄링 알고리즘 (Mixed Scheduling Algorithms)

이 패턴은 서로 다른 스케줄링 알고리즘을 노드 풀별로 사용하는 예시를 보여줘요.

노마드가 제공하는 각 스케줄링 알고리즘은 서로 다른 유형의 환경과 워크로드에 가장 적합해요.

binpack 알고리즘은 리소스 사용을 최대화하고 주어진 클라이언트 집합에 가능한 한 많은 워크로드를 채우는 것을 목표로 해요. 이는 인프라가 시간당 과금되고 빠르게 확장·축소될 수 있는 클라우드 환경에 이상적이에요. 워크로드 밀도를 최대화함으로써 클라우드 인스턴스에서 실행되는 클러스터는 필요한 모든 것을 실행하는 데 필요한 클라이언트 수를 줄일 수 있어요.

spread 알고리즘은 반대 방향으로 동작하며, 사용 가능한 모든 클라이언트를 사용해 밀도와 잠재적인 noisy neighbor·리소스 경합을 줄여요. 이는 클라이언트가 미리 프로비저닝되고 더 천천히 확장되는 환경(예: 온프레미스 배포)에 이상적이에요.

혼합 환경의 클러스터는 노드 풀을 사용해 노드 유형별로 스케줄러 알고리즘을 조정할 수 있어요. 클라우드 인스턴스는 binpack 알고리즘을 사용하는 노드 풀에, 베어메탈 노드는 spread를 사용하도록 구성된 노드 풀에 배치될 수 있어요.

node_pool "cloud" {
  # ...
  scheduler_config {
    scheduler_algorithm = "binpack"
  }
}

node_pool "on-prem" {
  # ...
  scheduler_config {
    scheduler_algorithm = "spread"
  }
}

알고리즘을 혼합하는 것이 유용한 또 다른 시나리오는 noisy neighbor에 더 민감한 워크로드(따라서 spread 알고리즘 사용)를 더 빡빡하게 채울 수 있는 워크로드(binpack)에서 분리하는 거예요.

더 알아보기 (Learn more)