노마드 거버넌스와 정책
노마드 거버넌스와 정책 (Governance and policy on Nomad)
노마드 엔터프라이즈는 팀과 조직을 대상으로 하며, 협업과 거버넌스 기능으로 멀티 팀·멀티 클러스터 배포의 조직적 복잡성을 해결해요.
이 섹션은 리소스 쿼터, 노드 풀, Sentinel 정책 같은 기능을 통해 멀티 팀 환경에서 노마드를 안전하게 운영하기 위한 모범 사례와 지침을 제공해요.
출처: 문서
본문
리소스 쿼터
엔터프라이즈
많은 팀이나 사용자가 노마드 클러스터를 공유할 때, 단일 사용자가 공정한 몫보다 더 많은 리소스를 사용할 수 있다는 우려가 있어요. 리소스 쿼터는 클러스터 관리자가 네임스페이스 내의 리소스를 제한하는 메커니즘을 제공해요.
쿼터 명세(quota specification)는 노마드에서 일급 객체예요. 쿼터 명세는 고유한 이름, 선택적 사람이 읽을 수 있는 설명, 그리고 쿼터 한도 집합을 가져요. 쿼터 한도는 리전 내 허용되는 리소스 사용량을 정의해요.
쿼터 객체는 네임스페이스 간 공유할 수 있어요. 이를 통해 운영자는 prod-api 쿼터 같은 더 높은 수준의 쿼터 명세를 정의할 수 있고, 여러 네임스페이스가 prod-api 쿼터 명세를 적용할 수 있어요.
Sentinel
엔터프라이즈
- Sentinel 정책 (Sentinel Policies) — 정책은 요청 인자를 검사(introspect)하고 복잡한 로직을 사용해 요청이 정책 요구사항을 충족하는지 판단할 수 있어요. 예를 들어 Sentinel 정책은 노마드 작업이 "docker" 드라이버만 사용하도록 제한하거나 업무 시간 외에는 작업을 수정하지 못하도록 할 수 있어요.
- 정책 범위 (Policy Scope) — Sentinel 정책은 "scope"(범위)를 선언하며, 이는 정책이 적용되는 시점을 결정해요. 현재 지원되는 유일한 범위는 "submit-job"으로, 새로 제출되는 새 작업이나 업데이트되는 기존 작업에 적용돼요.
- 시행 수준 (Enforcement Level) — Sentinel 정책은 여러 시행 수준을 지원해요. advisory 수준은 정책이 실패할 때 경고를 내보내는 반면, soft-mandatory와 hard-mandatory는 작업을 방지해요. soft-mandatory 정책은 사용자에게 필요한 권한이 있으면 재정의(override)할 수 있어요.
Sentinel 정책
각 Sentinel 정책은 고유한 이름, 선택적 설명, 적용 범위, 시행 수준, Sentinel 규칙 정의를 가져요. 같은 범위에 여러 정책이 설치되면 모두 시행되며 모두 통과해야 해요.
Sentinel 정책은 ACL 시스템이 활성화되지 않으면 사용할 수 없어요.
정책 범위
Sentinel 정책은 적용 범위를 지정하며, 이는 정책이 시행되는 시점을 제한해요. 이를 통해 정책이 시스템의 다양한 측면을 관리할 수 있어요.
Sentinel 정책에 사용 가능한 범위를 요약한 표는 다음과 같아요:
| Scope | Description | |
|---|---|---|
| submit-job | 등록되는 모든 작업(새 작업 또는 업데이트)에 적용 |
시행 수준
Sentinel 정책은 시행 수준을 지정하며, 이는 정책이 시행되는 방식을 바꿔요. 이를 통해 정책 시행에 더 많은 유연성을 제공해요.
사용 가능한 시행 수준을 요약한 표는 다음과 같아요:
| Enforcement Level | Description | |
|---|---|---|
| advisory | 정책이 실패할 때 경고를 발행 | |
| soft-mandatory | 정책이 실패할 때 작업을 방지하고, 재정의되면 경고를 발행 | |
| hard-mandatory | 정책이 실패할 때 작업을 방지 |
soft-mandatory 정책을 재정의하려면 sentinel-override 기능이 필요해요. 이를 통해 필요한 경우 제한된 사용자 집합이 재정의 능력을 가질 수 있게 해요.
멀티 리전 구성
노마드는 멀티 데이터센터와 멀티 리전 구성을 지원해요. 단일 리전은 여러 데이터센터를 서비스할 수 있고, 리전의 모든 서버는 서로 상태를 복제해요. 멀티 리전 구성에서는 리전마다 서버 집합이 있어요. 각 리전은 독립적으로 운영되며 느슨하게 결합되어 어떤 리전에서든 작업이 스케줄링될 수 있고 요청이 올바른 리전으로 투명하게 흐를 수 있게 해요.
ACL이 활성화되면 노마드는 ACL 정책, 전역 ACL 토큰, Sentinel 정책에 대한 단일 진실의 원천으로 작동하는 "authoritative region"(권위 있는 리전)에 의존해요. 권위 있는 리전은 에이전트의 server 스탠자에서 구성되며, 모든 리전이 단일 권위 소스를 공유해야 해요. Sentinel 정책은 먼저 권위 있는 리전에서 생성돼요. 다른 모든 리전은 Sentinel 정책, ACL 정책, 전역 ACL 토큰을 복제해 로컬 미러로 작동해요. 이렇게 하면 정책을 중앙에서 관리하고, 낮은 지연 시간을 위해 각 리전에서 로컬로 시행할 수 있어요.