Nomad：企业级现代化轻量工作负载编排

Target，美国最大的零售商之一，拥有超过 1,800 家门店，面临着一项复杂的挑战：在多个环境中编排工作负载 - 从公共云到自有数据中心，再到门店的 Edge 位置。尽管 Kubernetes 已经在部分场景中使用，但其复杂性以及较高的运行总成本使其难以推广。最终，Target 选择了 HashiCorp Nomad，这一决策显著加快了开发周期，并简化了基础架构。这个成功案例反映了行业中的一个普遍趋势：企业越来越意识到精简、高效的编排解决方案的价值，这些方案专注于核心需求，而非不必要的复杂性。

 

容器编排（Container Orchestration）正在发展为现代 IT 基础架构的关键组成部分。随着越来越多的企业对其应用架构进行现代化改造，并向云原生（Cloud-Native）架构迁移，他们面临着如何高效管理日益庞大的工作负载的问题。然而，许多组织发现，主流的编排解决方案由于其复杂性、高资源消耗以及陡峭的学习曲线，不仅未能提高运营效率，反而增加了管理负担。这直接导致了更高的运营成本、更长的开发周期，以及 IT 团队的过度负担。

此外，仅仅编排容器还远远不够。对于在服务器（无论是虚拟机还是裸机）上运行的工作负载，例如可执行文件形式的应用程序、批处理作业（Batch Jobs）甚至 Java 服务，仍然需要额外的编排解决方案。这进一步增加了基础架构的复杂性。因此，许多企业开始寻找更精简、更高效的工作负载编排替代方案。

这正是 HashiCorp Nomad 大显身手的地方。

Nomad 已经成为工作负载编排的优雅且高效的替代方案。与 Kubernetes 不同，Nomad 采用了务实的设计理念：单一二进制文件（Single Binary）、简洁的 API 以及直观的架构，使团队能够专注于自身业务，而无需被编排平台本身的管理困扰。而且，无论工作负载是否被容器化，Nomad 都能高效运行。

 

为什么更简单也可能更好：Nomad 方法

在现代企业环境中编排工作负载需要在功能性和复杂性之间找到平衡。Target 的经验清楚地表明了这一点：该公司需要在 Google Cloud、自有数据中心以及 1,800 多家门店内运行应用程序。挑战在于如何高效且集中地编排这些不同环境中的工作负载，同时避免不必要的复杂性。

最终选择 Nomad 是基于多个关键因素，而这些因素在实践中被证明至关重要。

1. 其中一个核心因素是一致性：由于 Target 在门店中已经使用 Kubernetes 运行 Docker 容器，因此能够在其他环境中复用相同的容器价值极大。这避免了创建单独的 RPM 包或其他部署格式的需求。

2. 部署速度 也是一个关键考量因素。Target 的开发团队需要能够快速推出并测试新版本，尤其是在黑色星期五促销季到圣诞节这段高峰期。使用 Nomad，他们可以在几分钟内完成部署，而之前基于 RPM 和 Docker 的流程往往需要 30 分钟甚至更长的时间。

3. 与现有 HashiCorp 生态的无缝集成 也是决定性优势之一。Target 早已在基础设施中使用 Consul 进行服务发现（Service Discovery）和 DNS 解析，并利用 Vault 进行 Secrets 管理。Nomad 与这些组件的无缝集成使团队能够继续使用这些成熟的工具，而无需额外的适配。

4. 多区域（Multi-Region）支持 对于 Target 的分布式基础设施至关重要。Target 在明尼苏达州拥有本地数据中心，同时在 US-Central 和 US-East 地区有云部署，因此团队需要能够在全球和区域范围内独立部署工作负载，同时保持联邦化（Federated）的配置和监控。

5. 最后，与 Terraform 的集成 是一个重要因素。Target 的团队已经建立了一套基于 Terraform 的成熟部署流水线，能够继续沿用这些工具进行 Nomad 部署，使迁移过程变得更加顺畅。

资源优化与混合工作负载

高效的资源利用对于处理各种不同工作负载的企业至关重要。Nomad 提供了一种强大的编排解决方案，能够优化资源使用，并灵活管理混合工作负载。

资源利用最大化

Nomad 采用高效的Bin-Packing 算法，可智能地将较小的任务填充到已有的空闲资源中，以优化服务器资源分配。这不仅减少了未使用的计算资源，还能最大化集群效率。在高性能计算（HPC）环境或工作负载需求变化较大的企业场景下，Nomad 能够确保昂贵的硬件资源得到充分利用。

• 动态资源分配：根据实时需求对工作负载进行调度，以避免资源空闲。
• 效率提升：通过智能作业调度减少硬件需求，从而降低运营成本。
• 负载均衡：工作负载可自动迁移到较空闲的节点，以确保系统负载均衡。

支持混合工作负载

Nomad 的一大优势在于能够并行编排多种类型的工作负载。虽然 Kubernetes 主要针对容器化应用程序设计，但 Nomad 还能管理独立应用（Standalone Applications）、批处理作业（Batch Jobs）、微服务（Microservices，容器）以及系统关键进程（System-Critical Processes）。

• 批处理计算 & HPC 工作负载：适用于研究机构或数据密集型企业，这类工作负载通常需要短时间内高性能计算能力。
• 微服务 & 云原生（Cloud-Native）应用：现代分布式架构可通过 Nomad 的简洁 API 和声明式配置实现高效管理。
• 传统应用 & 系统进程：与 Kubernetes 不同，Nomad 还能高效编排非容器化工作负载。

简化运维

Nomad 采用极简架构，仅依赖单一二进制文件（Single Binary），且无外部依赖，大幅减少了运维开销，使小型 IT 团队也能轻松管理强大的编排解决方案。

凭借高效的资源利用和灵活的工作负载支持，Nomad 成为一款通用平台，既适用于动态的现代云环境，也能满足传统 IT 基础架构的需求。

企业级调度与 Bin Packing

Nomad 的调度引擎在核心理念上与其他编排解决方案截然不同，其方法既务实又高效。Nomad 采用分布式调度器，并基于 Raft 共识协议（Raft-Consensus Protocol），使得调度决策能够快速且可靠地在整个集群中协调。Target 在每个区域部署了由三个节点组成的集群，其中一个服务器作为 Leader，其余两个作为 Follower，在发生故障时可立即接管任务。而在需要更高可用性的场景下，五节点集群是更理想的选择：这五个节点可以分布在不同的故障域（Fault Domains）或数据中心，即使当前的集群 Leader 意外失效，剩余的 Follower 仍可选举出新的 Leader 并保持集群的完整功能 - 而在三节点集群中，由于无法满足法定人数（Quorum）要求，这种情况将无法实现。

Nomad 调度器的独特之处在于其先进的 Bin-Packing 算法，我们在前文中已经提到过。许多编排解决方案采用的是简单的资源分配策略，这往往导致资源利用率低下，而 Nomad 采用了一种多维度的方法，综合考虑 CPU、内存、网络端口以及自定义资源。在 Target 的实践中，这种策略显著提高了资源效率：每个集群仅使用八个节点，就能高效运行大量工作负载，避免了 VMware 或 Kubernetes 等平台常见的硬件和网络基础架构过度配置问题。

Nomad 的调度决策基于一套精细化的约束（Constraints）和亲和性（Affinities）规则。开发人员可以精确定义工作负载的需求，例如硬件要求、网络拓扑或地理位置等。调度器会结合这些约束条件以及集群的实时状态，做出最优的资源分配决策。在 Target 的场景中，这一点对于其跨区域部署尤为重要，帮助管理其位于明尼苏达的数据中心和 Google Cloud 区域的工作负载。

一个具体的 Target 实践案例展示了调度器的强大能力：Target 在 Nomad 上运行完整的 ELK 堆栈（Elasticsearch、Logstash、Kibana），每天处理约 300GB 的日志数据。这体现了调度器在不同类型工作负载间的灵活性 - 无论是无状态（Stateless）应用，还是像 Elasticsearch 这样的复杂有状态（Stateful）系统，调度器都能自动识别其特定需求，并将其最优地部署到可用基础架构上。

值得一提的是，Nomad 调度器还具备处理抢占式实例（Preemptible Instances）的能力。Target 在其 Staging 环境中进行了相关实验，利用这一特性来使用低成本的可中断云实例，而调度器则自动确保服务的持续运行。这一功能不仅提升了 Nomad 调度引擎的技术效率，同时也直接带来了显著的成本节约。

 

企业级功能（Enterprise-Grade Features）

Nomad Enterprise 在开源版本的基础上扩展了额外的功能，专门针对大型企业的需求进行优化。尤其是在复杂和分布式环境中，Nomad Enterprise 展现出其优势，使企业能够实现更高的可扩展性、安全性和治理能力。

治理与多云管理

对于拥有全球分布式基础设施的企业而言，跨多个区域和云供应商高效管理集群是一项重大挑战。Nomad Enterprise 提供了一种强大的联邦化（Federated）集群架构：

• 跨多个区域和云供应商的联邦化集群：企业可以在不同的区域或云环境中运行多个 Nomad 集群，并进行集中管理。例如，一个集群可以在本地（On-premise）运行，另一个分布在 Oracle Cloud Infrastructure（OCI）法兰克福的三个数据中心，还有一个运行在 Amazon Web Services（AWS）。这些集群共同构成一个应用资源池，使得企业能够根据地理位置、应用程序资源需求、延迟要求、软件许可条件或合规要求灵活分配工作负载。
• 独立的区域部署控制：每个区域可以独立运行和管理，确保某一区域的故障或错误不会影响其他集群。同时，全球策略可以通过中央管理。比如，本地运行的 Nomad 集群可以管理和部署 OCI 或 AWS 上的工作负载，并在本地数据中心与云环境之间同步数据 - 但不包括 Token、区域 ACL 策略和执行业务规则的 Sentinel 策略（我们将在后续章节详细介绍）。
• 自动化验证与部署流程：Nomad Enterprise 允许自动验证和部署应用程序到生产环境，减少人为错误，提高发布的可靠性。

高可用性与可扩展性

对于业务关键型应用，高可用性至关重要。Nomad Enterprise 提供额外的功能，以增强 Nomad 集群的容错能力和扩展能力：

• 每个区域支持三节点或五节点集群，确保高可用性：为了保证高可用性，每个区域至少运行一个包含三个节点的 Nomad 服务器集群，即使其中一个或多个服务器出现故障，剩余节点仍能继续运行。而五节点集群提供更强的容错能力，适用于更关键的业务场景。
• 自动化共识机制（Consensus）保障调度决策：Nomad 采用 Raft 共识协议（Raft-Consensus Protocol）来确保调度决策在整个集群中的一致性和高效性。如果 Leader 节点发生故障，系统会自动选举新的 Leader，以保持持续可用性。
• 灵活扩展客户端节点：Nomad 可以根据工作负载需求动态扩展客户端节点，使企业能够更高效地利用资源并降低运营成本。

政策执行与合规要求的落实

在金融、医疗保健和公共行政等受监管行业，严格遵守安全与合规要求至关重要。Nomad Enterprise 通过集成 HashiCorp Sentinel，提供了一种强大的政策执行（Policy Enforcement）解决方案，将规则定义和自动化直接嵌入到编排流程中。这使企业能够高效地执行监管要求和内部安全政策。整体而言，企业可以利用这一自动化、可扩展的策略验证解决方案，将其无缝集成到现有的工作流和合规策略中。此外，Sentinel 不仅与 Nomad 集成，也适用于 Terraform、Vault 和 Consul，使 Policy-as-Code（政策即代码）的实施能够扩展至整个基础架构层面。

Sentinel：Nomad Enterprise 的政策执行框架

Sentinel 是一个基于策略的框架，使管理员能够以代码方式定义精细化的政策，并通过 Nomad 自动执行这些策略。Sentinel 策略构建在 Nomad 现有的访问控制列表（ACL）系统之上，能够对 Job 提交和执行进行精确控制。

Sentinel 在 Nomad Enterprise 中的核心功能：

• 精细化策略控制：Sentinel 策略可规定哪些 Job 可以在何时运行，确保仅使用特定的容器镜像，或执行其他合规性要求。
• 声明式策略结构：策略使用 Sentinel 语言定义，该语言优化了可读性和执行效率。策略的复杂性可灵活调整，但应避免对系统性能产生负面影响。
• 详尽的对象访问：Sentinel 策略可访问 Nomad 生态系统中的多个对象，包括 Job 定义、现有 Job、ACL Token 和 Namespace，使其能够执行差异化的审核与策略执行机制。

Sentinel 策略的管理与执行

Sentinel 策略的管理可通过 Nomad CLI 进行，并支持多种执行级别（Enforcement Levels）：

• Advisory Policies（建议性策略）：当 Job 违反策略时，仅会生成警告，但不会阻止其执行。
• Soft-Mandatory Policies（软强制性策略）：违反策略的 Job 仍可执行，但需要获得明确批准。
• Hard-Mandatory Policies（硬强制性策略）：严格执行策略，不符合策略要求的 Job 将被直接阻止，无法运行。

例如，可以使用以下命令应用策略：

---

nomad sentinel apply -level=soft-mandatory compliance-policy policy.sentinel

---

实践示例：限制 Job 执行方式

一个常见的场景是确保仅允许特定的 Job 驱动（Driver），以降低安全风险。例如，某个 Sentinel 策略可以规定，仅允许使用“exec”驱动（用于可执行文件的编排），而禁止使用“docker”或“raw_exec”驱动：

---

main = rule { all_drivers_exec }

all_drivers_exec = rule {
  all job.task_groups as tg {
    all tg.tasks as task {
      task.driver is "exec"
    }
  }
}

---

 

Terraform 集成 Sentinel 策略

为实现策略管理的自动化，可以使用 Terraform。通过资源类型 nomad_sentinel_policy，可以直接将 Sentinel 策略集成到 Infrastructure-as-Code（IaC）流程中。

---

resource "nomad_sentinel_policy" "enforce_exec_driver" {
  name  = "restrict-to-exec"
  policy = file("restrict-to-exec.sentinel")
  enforcement_level = "hard-mandatory"
}

---

这样可以确保所需策略在整个企业范围内得到一致的应用。

 

Nomad 与 Kubernetes 的对比

Nomad 以其简单性、灵活性和高效性脱颖而出，而 Kubernetes 则在网络、存储和监控功能方面具有更强的扩展能力。企业应根据具体应用场景权衡，选择更适合其基础架构和业务需求的解决方案。虽然 Kubernetes 被广泛认为是容器编排的标准，但越来越多的企业开始采用 HashiCorp Nomad 作为更精简的替代方案，因为它不仅降低了复杂性，还支持更多不同类型的工作负载。

Nomad 的特性与优势

Nomad 具备一系列优势，使其特别适合那些寻求简单、灵活且高效的编排解决方案的企业：

• 简便的部署：与 Kubernetes 相比，Nomad 的安装和配置更为简单快捷。它仅需一个二进制文件（Binary）即可运行客户端和服务器，同时配置复杂度较低。
• 工作负载的灵活性：尽管 Kubernetes 主要专注于容器化应用，但如前文所述，Nomad 还能高效管理非容器化工作负载以及传统系统（Legacy Systems）。
• 简化运维：Nomad 采用精简架构，所需的管理工作较少，团队可以更专注于应用开发，而无需投入大量精力管理编排平台本身。
• 降低组织资源消耗：由于 Nomad 的运维管理更加精简，因此企业对专业人才的需求也相应减少。Kubernetes 需要较高的技术门槛，并且在大规模部署时才真正发挥价值。许多企业不得不雇佣额外的人员来维护 Kubernetes 集群并处理故障，而 Nomad 在组织管理上的挑战要小得多。
• 低系统资源占用：Nomad 比 Kubernetes 消耗更少的系统资源，使其成为边缘计算（Edge Computing）、物联网（IoT）环境以及资源受限系统的理想选择。此外，由于所需的人员和基础架构资源更少，整体基础设施成本也随之降低，从而改善总体拥有成本（TCO）和投资回报率（ROI）。
• 与 HashiCorp 生态系统无缝集成：Nomad 与 HashiCorp Consul（用于服务发现）和 Vault（用于 Secrets 管理）紧密集成，使企业能够充分利用现有的 HashiCorp 技术栈。
• 原生支持多区域（Multi-Region）部署：Nomad 具备内置的多区域和多云支持，而 Kubernetes 需要额外的复杂配置和管理层来实现类似功能。

挑战

尽管 Nomad 具有诸多优势，但在使用过程中仍存在一些挑战，尤其是在与 Kubernetes 的对比中：

• 负载均衡（Load Balancing）：Kubernetes 原生提供了负载均衡功能，例如 kube-proxy 和 Ingress，而 Nomad 需要依赖外部解决方案来实现此功能。常见的方案包括与 Nomad 直接集成的 Traefik，或采用 HashiCorp Consul 以获得一站式支持。
• 网络与策略管理（Network & Policy Management）：Kubernetes 内置强大的网络管理功能，如 Network Policies 可用于流量控制，而 Nomad 需要借助 HashiCorp Consul、第三方工具或 HashiCorp Sentinel 来实现类似功能。然而，Sentinel 仅在企业版（Enterprise Edition）中可用。
• Service Mesh 支持：Kubernetes 可以轻松与 Istio 或 Linkerd 等 Service Mesh 解决方案集成，而 Nomad 虽然可以与 Consul 配合使用，但其本身并不具备 Kubernetes 原生 Service Mesh 方案的全部功能。
• 监控与日志管理（Monitoring & Logging）：Kubernetes 提供了开箱即用的监控与日志管理功能，而 Nomad 主要依赖外部工具进行监控和日志收集。
• 配置管理方式（Configuration Model）：Kubernetes 采用声明式配置模型（Declarative Configuration），适用于大规模环境的集中管理。而 Nomad 采用过程式配置（Procedural Configuration），尽管提供了更精细的控制，但在复杂环境中管理起来可能更具挑战性。
• 持久化存储（Persistent Storage）：Kubernetes 提供多种持久化存储解决方案，包括本地存储、云存储和网络存储，而 Nomad 在存储管理方面的功能相对有限，通常将存储管理交由操作系统或底层容器平台（如 Docker）处理。在复杂或混合环境中，这可能会增加额外的运维工作量。

综合来看，Nomad 以其轻量级架构、简便性、灵活性和高效性著称，而 Kubernetes 则凭借其强大的原生网络、存储和监控功能在复杂环境中占据优势。

开发团队的实际优势

从 Target 及其他 HashiCorp 客户的经验来看，Nomad 不仅简化了基础架构管理，同时也为开发团队带来了显著优势。以下改进在日常运营中被证明尤为有价值：

1. 加速开发周期：借助 Nomad，新的服务可以更快速地从概念验证（PoC）阶段过渡到生产环境。简化的工作负载部署和测试能力大幅缩短了新功能和应用的上市时间（Time-to-Market）。
2. 简化部署流程：使用 Nomad，部署时间可从数小时缩短至几分钟。尤其是在零售行业黑色星期五促销季等高负载时期，企业能够实时推送变更，而不会影响现有业务运行或造成资源瓶颈。
3. 优化资源利用：Nomad 采用高效的 Bin-Packing 算法，使服务器资源利用率最大化，支持不同架构和服务器规格的混合部署，从而大幅减少硬件需求。这种优化直接带来了可观的基础设施成本节约。
4. 灵活的工作负载支持：虽然 Kubernetes 主要针对容器化应用进行优化，但 Nomad 允许编排各种类型的工作负载 - 从传统 Java 应用到现代微服务（Microservices）。这使 Target 能够使用统一的平台管理所有工作负载，而无需额外的编排工具。
5. Blue-Green 部署：为尽量减少更新期间的停机时间，Target 在数据中心级别实施 Blue-Green 部署策略。新版本会与现有版本并行运行，只有在测试成功后才会正式上线。如果出现问题，系统可以立即回滚到之前的版本。

这些功能和改进表明，Nomad Enterprise 是一款功能强大、易于管理的解决方案，适用于需要现代化、高可用性和成本效益优化的企业级编排平台。

与 HashiCorp 生态系统的集成

Nomad 的一大优势在于能够无缝集成其他 HashiCorp 工具。Target 及其他拥有关键基础架构的客户充分利用这些协同能力：

• Consul 用于服务发现（Service Discovery）和动态配置
• Vault 用于 Secrets 管理和动态凭证（Dynamic Credentials）
• Terraform 用于基础设施即代码（Infrastructure as Code）和自动化部署

这种集成支持一个完全自动化的流水线（Pipeline），开发人员可以通过 Git 提交更改，CI/CD 流程随后自动进行验证和部署。

示例：自动化部署流水线

开发人员在基于 Git 的环境中工作，所有应用程序和基础架构代码的更改都被版本化。典型工作流程如下：

1. 代码更改与提交：开发人员向 Git 仓库推送应用的新版本，这可能是一次微服务 API 的更新或是配置调整。
2. 自动化 CI/CD 流程启动：GitHub Actions 或 Jenkins 这样的构建系统检测到更改，并启动流水线执行以下步骤：
   • 构建与测试：应用程序使用最新更改进行编译，并以容器镜像或可执行文件（Binary）形式打包。
   • 安全扫描与 Secrets 获取：Vault 用于提供动态 Secrets，从而避免在代码或流水线中存储静态凭证。
   • 基础设施验证：Terraform 运行检查，确保所有必需的基础设施组件已正确配置。
3. 使用 Nomad 进行部署：
   • 构建成功后，生成或更新新的 Nomad Job 文件。
   • 使用 Nomad CLI 或 Terraform-Nomad 组合工具注册并部署新 Job。
   • Consul 自动进行服务发现，使新实例能立即被其他服务识别。
4. Blue-Green 部署与流量切换：
   • 采用 Nomad 的滚动部署（Rolling Deployment）策略，新版本与现有版本并行运行。
   • 通过 Consul 负载均衡或 Traefik 进行流量切换，确保新版本通过健康检查后接管流量。
   • 如果检测到问题，可自动回滚到之前的版本。
5. 监控与优化：
   • Prometheus 或其他可观测性工具（Observability Tools）收集部署指标，这些数据可以通过 Nomad 的 REST API 访问。
   • 如有必要，可使用 Terraform 与 Nomad 的自动扩展功能（Auto-Scaling）动态调整资源。

此部署流水线的优势

• 完全自动化：消除手动部署，减少人为错误，提高部署速度。
• 高安全性：Vault 确保凭据不会存储在代码库或 CI/CD 流水线中，从而降低安全风险。
• 快速回滚 & 低风险：借助 Blue-Green 部署和基于 Consul 的服务发现，可在不中断业务的情况下回滚错误版本。
• 高效的资源利用：Terraform 优化基础设施资源供应，Nomad 通过 Bin Packing 机制最大化服务器利用率。

该工作流可在几分钟内完成新版本的部署，并根据需求动态调整基础设施——这在高度动态的环境中尤为关键。

展望：工作负载编排的未来

未来的 IT 基础架构将越来越多地受边缘计算（Edge Computing）、多云战略（Multi-Cloud Strategies）和混合工作负载（Hybrid Workloads）驱动。HashiCorp 的 Nomad 发展路线图展示了几项值得关注的技术趋势：

•  支持 NVIDIA 多实例 GPU（Multi-Instance GPU），Golden Job 版本控制，NUMA，设备配额管理（已在 Nomad 1.9 版本中引入）。
•  基础设施生命周期管理（Infrastructure Lifecycle Management, ILM），结合 Terraform、Packer 和 Waypoint，简化基础设施管理。
• 动态节点元数据（Dynamic Node Metadata），增强 Nomad 环境管理的灵活性。
• 工作负载身份管理（Workload Identity Management），通过扩展身份管理（Identity Management），并集成 Vault 和 Consul，进一步提升安全性。

Nomad 提供了一种强大而务实的现代工作负载编排解决方案。企业若能在当下投资高效、可扩展的编排方案，将在降低运营成本、加快开发周期和提升团队生产力方面获得长远优势。

欢迎联系我们获取更多信息！我们可为您分析具体的应用场景和需求，制定合适的使用案例，并帮助您选择最优的编排平台。