Hashicorp Nomad란? 기능 설명과 설치 가이드

Hashicorp Nomad란?

Nomad는 Hashicorp 사에서 개발한 고가용성, 분산형, 클러스터 및 어플리케이션 스케쥴러로 서비스, 배치 작업 등을 지원하는

간소화된 Kubernetes라 볼 수 있다.

Nomad vs Kubernetes

Kubernetes와 Nomad는 애플리케이션 배포 및 관리를 위한 유사한 핵심 사용 사례를 지원하지만 몇 가지 주요 방식에서 차이가 있다. Kubernetes는 클러스터 관리, 스케줄링, 서비스 검색, 모니터링, 시크릿 관리 등 Linux 컨테이너 기반 애플리케이션을 실행하는 데 필요한 모든 기능을 제공하는 것을 목표로 한다.

Nomad는 클러스터 관리 및 스케줄링에만 집중하는 것을 목표로 하며, 서비스 검색/서비스 메시를 위한 Consul 및 비밀 관리를 위한 Vault와 같은 도구로 구성하면서 작은 범위를 갖는다는 유닉스 철학에 따라 설계

Nomad 구성

• Cluster(Region) - Region 단위로서 단일 Nomad 바이너리로 실행된 서버와 client
• DC(datacenter) - AZ와 같은 개념으로 복수개로 구성 가능
• Agent - 서버 또는 client 모드에서 실행되는 Nomad 프로세스
• Client - 서버에 자신을 등록하고 할당할 작업이 있는지 모니터링하고 자신에게 할당된 작업을 실행할 책임을 가짐. Agent를 실행할때 node를 client라고 할 수 있음
• Server - 모든 job과 client를 관리하고, task를 모니터링하며 어떤 작업이 어떤 client node에 배치되는지 제어, 서버는 HA를 보장하기 위해 서로 간의 데이터를 복제

Nomad 운영

Kubernetes의 yaml 파일 작성구조와 유사하지만 Nomad에서 제공하는 hcl 문법 사용

• task - Nomad에서 가장 작은 작업 단위로 task는 docker or exec와 같은 task drivers에 의해 실행되며 Nomad는 지원하는 task의 유형을 유연하게 조정 가능 task는 필요한 task drivers, driver 구성, 제약 조건 및 필요한 리소스를 지정
• group - 동일한 Nomad client에서 실행되는 task의 모음
• job_specification - 작업 사양 or 작업 스펙은 Nomad task에 대한 스키마를 정의한다. type of job, job 실행에 필요한 task와 리소스, 실행가능한 client 등의 job 정보를 설명
• allocation - job의 task group과 client node 사이의 매핑, job이 실행되면 Nomad는 해당 task를 실행할 수 있는 client를 선택하고 job에 정의된 task group의 task에 대해 리소스를 할당

Nomad servers Requirements

Nomad server는 Kubernetes의 컨트롤플레인 역할

https://developer.hashicorp.com/nomad/docs/install/production/requirements

• RAFT 알고리즘을 사용하기에 홀수개 권장 -> 1,3,5,7 but, cluster당 7개 이상은 권장하지 않음
• CPU 4-8cores
• MEM 16-32GB
• DISK 40-80GB (AWS에서 실행할 때는 데이터 디렉터리로 NVME 또는 프로비저닝된 IOPS SSD 스토리지를 선호합니다.)
  ![[Pasted image 20240610121234.png]]

추천은 서버 3~5개 클라이언트는 1이상

Nomad는 consul과 함께 사용하지 않으면 client 추가 시
config를 등록해주어야함 -> consul은 token을 이용해 등록

Nomad 사용 사례

• 간단한 컨테이너 오케스트레이터 : 프로덕션 환경에서 컨테이너를 쉽게 배포, 관리, 확장
• 비-컨테이너 앱을 오케스트레이션 : 재작성 없이 컨테이너화되지않은 APP 배포
• 배치 워크로드 지원과 클러스터 관리 : 배치 서비스를 실행하고 ML, AI, Data Science 같은 GPU 지원 제공

주요 기능

Open Source
일반 애플리케이션, 컨테이너, 배치 워크로드 오케스트레이션

• Service & Batch Scheduling
• Task Drivers
• Device Plugins
• Multi-Upgrade Strategies
• Federation
• Autoscaling
• CSI Plugin
• CNI Plugin
• Access Control System
• Web UI
• Consul Integration
• Vault Integration
• Namespaces

Enterprise Platform
Nomad의 구성과 운영에 도움이 되는 기능과 퍼포먼스 증가

• 모든OSS기능+
• Automated Upgrades
• Automates Backup
• Enhanced Read Scalability
• Redundancy Zones
• Multi-Vault Namespaces
• Consul Namespaces

Governance & Policy
다수의 팀/조직에 대한 Nomad 배포의 정책 설정

• Resource Quotas
• Cross-Namespace Queries
• Audit Logging
• Sentinel Policies

Multi-Cluster & Efficiency
향상된 효율성과 배포 효용성을 위한 배포 기능 향상

• Multi-Cluster Deployments
• Dynamic Application Sizing

리전간 운영

• 여러개의 Nomad Region(Cluster)를 하나로 Federation 구성 가능
• Job은 특정 Region에서 제출되지만 대상은 여러 Region일 수 있음
• ACL, Policy, Sentinel은 Region간 공유
• 애플리케이션, 상태에 대한 데이터는 공유되지 않음

특정 Region의 서버에 문제가 생기면 클라이언트는 Federation 구성된 다른 Region에 접근

• RPC, Serf 통신 필요

Bin-packing / spread scheduling

스케쥴링 설정

• Server의 config에서 정책 지정 가능하고, Job에서 개별적으로도 선언 가능
• scheduler_algorithm = "binpack" or "spread"로 선언

Preemption (선점)
우선순위가 낮은 워크로드를 제거하여 우선순위가 높은 워크로드를 위한 용량을 확보

• “job_priority” 를 기반으로 선점을 결정하는 반복 알고리즘 입니다.
• Allocation API로 선점의 세부정보에 대한 상세 내용을 제공합니다.
• 스케줄러를 테스트하기위한 Plan 동작과 통합되어있습니다.

Affinity & anti-affinity

• 관리자가 특정 유형의 노드에서 Job에 대한 배치 기본설정을 선언 가능합니다.

Spread로 향상되는 내결함성 Fault Tolerance
관리자가 데이터 센터, 가용 영역, 물리적 데이터 센터 랙 전반에 걸쳐 맞춤형 방식으로 워크로드를 배포할 수 있습니다.

• 유연한 강제성 (Soft Constraint)의 성격을 갖습니다.
• Job과 Group 수준에서 정의 가능합니다.
• 다중 Spread 선호도에 대해 상대적 선호도를 표현하기 위한 가중치로 표현합니다.

Scheduler Operations 35p

![[Pasted image 20240611145705.png]]

Nomad Autoscaler 아키텍처

Nomad Autoscaler는 내부의 Scaling Policy API와 상호작용하는 에이전트입니다.

• ▪ APM plugins : 다양한 애플리케이션 성능 메트릭 시스템과 인터페이스하여 필요한 메트릭을 가져옵니다. (Nomad 내장 APM, Prometheus, Datadog)
• ▪ Target plugins : Scaling 작업을 수행하기위한 대상의 인터페이스를 제공합니다. (Task 개수, Dynamic Application Sizing, 클라우드 기반 노드)
• ▪ Strategy plugins : 현재의 조정된 내용, 제공되는 조정 전략, 메트릭을 기반으로 특정 대상을 조정하는 시기와 방법을 지시하는 논리를 구현합니다. (Avg, Max, Fixed, Pass-Through, Target, Threshold)

Nomad demo 설치

아래의 Hashicorp에서 제공하는 Nomad demo repo를 통해 설치

git clone https://github.com/hashicorp/learn-nomad-cluster-setup
cd learn-nomad-cluster-setup
cd aws

Nomad 클러스터 만들기

클러스터를 생성하는 두 가지 주요 단계는 Packer를 사용하여
Amazon 머신 이미지(AMI)를 구축하고
Terraform을 사용하여 클러스터 인프라를 프로비저닝.
Packer와 Terraform 모두 실행하기 전에 일부 구성을 설정해야 하며
이러한 구성 변수는 variables.hcl.example 파일에 정의

Packer용 변수 파일 업데이트

mv variables.hcl.example variables.hcl

variables.hcl.example이름 을 바꾸고 variables.hcl IDE에서 실행
Packer를 실행하기 위해서는 Region 값만 필요함

# Packer variables (all are required)  
region                    = "ap-northeast-2"

AMI 구축
Packer init이 성공적으로 완료되면 출력을 반환하지 않음

packer init imasge.pkr.hcl

init으로 생성된 images.pkr.hcl 파일을 이용해 AMI 빌드

packer build -var-file=variables.hcl image.pkr.hcl

ami idPacker는 이미지 빌드가 완료되면 ami id를 출력

variables.hcl텍스트 편집기에서 열고 amiPacker 빌드의 출력 값으로 값을 업데이트합니다

나머지 필요에 따라 추가 variables 편집

• allowlist_ip포트의 Consul 및 Nomad UI 8500와 4646포트의 SSH에 액세스할 수 있는 IP 주소를 지정하는 CIDR 범위 22.
• 기본값은 0.0.0.0/0모든 곳의 트래픽을 허용
• nameAWS 리소스 이름을 지정하기 위한 Prifix
• server_instance_type및 client_instance_type각각 클러스터 서버 및 클라이언트 노드에 대한 가상 머신 인스턴스 유형
• server_count는 client_count각각 서버와 클라이언트에 대해 생성할 노드 수

Deploy Nomad Cluster

terraform init
terraform plan
terraform apply -var-file=variables.hcl

'''

Plan: 18 to add, 0 to change, 0 to destroy.

'''

Apply complete! Resources: 18 added, 0 changed, 0 destroyed.

Apply가 완료되면 출력된 Ouput 값으로 나온 Consul Token으로 Consul 접속

Nomad에 대한 액세스 설정

디렉토리 내에 아래의 스크립트 실행

./post-setup.sh

실행이 완료되면 Nomad 클러스터 연결

export NOMAD_ADDR=$(terraform output -raw lb_address_consul_nomad):4646 && \
  export NOMAD_TOKEN=$(cat nomad.token)

클러스터 연결 확인

nomad node status
ID        Node Pool  DC   Name              Class   Drain  Eligibility  Status
06320436  default    dc1  ip-172-31-18-200  <none>  false  eligible     ready
6f5076b1  default    dc1  ip-172-31-16-246  <none>  false  eligible     ready
5fc1e22c  default    dc1  ip-172-31-17-43   <none>  false  eligible     ready