Nomad开源集群中强制节点分配至指定命名空间的实现方案

一、节点专属元数据标签配置 #

先给node1、node2、node3打上专属元数据标签，用于后续调度约束和ACL过滤：

• 临时修改（节点重启后失效）：

  nomad node meta node1 dedicated_namespace=dev
  nomad node meta node2 dedicated_namespace=dev
  nomad node meta node3 dedicated_namespace=dev
  

• 永久生效（修改节点配置文件nomad.hcl）：

  meta {
    dedicated_namespace = "dev"
  }
  

修改后重启节点服务，确保标签生效。

二、命名空间强制调度约束 #

通过配置Dev命名空间的全局约束，强制该命名空间下所有作业只能调度到带有指定标签的节点，不受作业自身配置影响：

namespace "dev" {
  description = "Development environment namespace"
  # 全局约束：所有Dev命名空间的作业必须匹配节点标签
  constraints {
    attribute = "${node.meta.dedicated_namespace}"
    value     = "dev"
  }
}

将上述配置添加到Nomad服务器的配置文件，或通过nomad namespace apply命令提交。此配置会覆盖作业自身的调度约束，确保所有Dev作业只能运行在目标节点上。

三、节点池+ACL权限限制（双重保障） #

配合节点池和ACL策略，进一步限制用户操作权限，防止绕过约束：

1. 创建Dev专属节点池

   node_pool "dev_pool" {
     description = "Dedicated node pool for Dev namespace"
     # 节点选择器：仅包含带有dev标签的节点
     node_selector {
       attribute = "${node.meta.dedicated_namespace}"
       value     = "dev"
     }
     # 节点池默认约束：所有提交到该池的作业必须匹配节点标签
     default_constraint {
       attribute = "${node.meta.dedicated_namespace}"
       value     = "dev"
     }
   }
   

2. 配置ACL策略限制Dev用户权限
   确保Dev命名空间的用户只能访问dev_pool，无法使用默认节点池，且仅能看到目标节点：

   policy "dev_namespace_policy" {
     name = "dev-namespace-policy"
     rules = <<EOT
   namespace "dev" {
     # 允许操作Dev命名空间的作业
     job { policy = "write" }
     # 仅允许访问dev_pool节点池
     node_pool "dev_pool" { policy = "write" }
     # 禁止访问默认节点池
     node_pool "default" { policy = "deny" }
   }
   # 限制节点可见性：仅能看到带有dev标签的节点
   node {
     selector {
       attribute = "${node.meta.dedicated_namespace}"
       value     = "dev"
     }
     policy = "read"
   }
   # 拒绝访问其他节点
   node {
     policy = "deny"
   }
   EOT
   }
   

将该策略绑定到Dev用户的ACL Token，确保用户无法看到或使用非目标节点。

四、最佳实践 #

• 优先使用命名空间全局约束：这是最直接的强制手段，无需依赖用户作业配置，从命名空间层面确保调度规则生效
• 标签命名规范：使用dedicated_namespace这类明确的标签键，避免与业务标签冲突，便于后续维护
• 最小权限ACL策略：Dev用户仅授予必要的命名空间、作业、节点池权限，禁止访问其他资源
• 定期审计：定期检查节点标签、命名空间约束和ACL策略，防止误配置或权限泄露
• 双重保障：结合命名空间约束+节点池+ACL，形成多层限制，彻底杜绝绕过规则的可能

内容的提问来源于stack exchange，提问作者theasker228