Skip to content

Workload Orchestration & Scheduling

Overview

Workload Orchestration & Scheduling delivers flexible, multi-runtime workload scheduling across hybrid infrastructure using HashiCorp Nomadβ€”enabling organizations to run containers, VMs, binaries, and batch jobs under a single, lightweight control plane without the operational complexity of full Kubernetes deployments.

What is Workload Orchestration & Scheduling?

Modern applications are composed of diverse workload types: long-running containerized services, periodic batch jobs, legacy binary processes, and Java applicationsβ€”often spread across cloud and on-premises environments. Managing each with a different scheduler creates operational silos and increases complexity.

HashiCorp Nomad solves this by providing a single, ergonomic scheduler that handles all workload types through a unified job specification. Unlike Kubernetes, Nomad is designed for operational simplicityβ€”a single binary that supports clusters of 10,000+ nodes, integrates natively with HashiCorp Vault for secrets and Consul for service discovery, and requires no separate etcd, controllers, or complex networking overlays to get started.

This building block is designed for platform engineers and DevOps teams who need workload scheduling flexibility beyond what a pure Kubernetes environment providesβ€”especially in mixed-workload, edge, or resource-constrained environments.

Why Workload Orchestration & Scheduling?

  • πŸ”€ Multi-Runtime Scheduling: Run Docker containers, Java JARs, raw binaries, and VMs under a single scheduler
  • πŸͺΆ Operational Simplicity: Single binary, no etcd dependency, operational overhead far below Kubernetes
  • 🌐 Hybrid Infrastructure Support: Schedule workloads across cloud, on-premises, and edge nodes in a single cluster
  • πŸ”— Native HashiCorp Integration: Deep integration with Vault (secrets) and Consul (service discovery/mesh)
  • πŸ“¦ Batch & Service Jobs: First-class support for both long-running services and periodic/parameterized batch jobs
  • πŸ”„ Zero-Downtime Deployments: Built-in rolling updates, blue/green, and canary deployment strategies

Key Features

Core Capabilities

🎯 Multi-Runtime Job Scheduling

Unified Scheduling Across Workload Types: Nomad's task driver model supports any workload type through a pluggable driver system.

  • Docker Driver: Schedule containerized workloads with full image lifecycle management
  • Exec / Raw Fork Driver: Run native binaries and scripts directly on host OS without containers
  • Java Driver: Launch JVM-based applications with configurable heap and classpath settings
  • Podman Driver: Rootless container execution for security-hardened environments
  • QEMU Driver: Schedule lightweight VMs alongside container workloads

Use Case: A platform team runs a mixed estate of legacy Java services, containerized microservices, and batch processing scriptsβ€”all scheduled and monitored through a single Nomad cluster.

πŸ“… Batch & Parameterized Jobs

First-Class Batch Workload Support: Nomad treats batch and periodic jobs as first-class citizens, with built-in scheduling, retry logic, and dispatch capabilities.

  • Periodic Jobs: Cron-style scheduling for recurring batch workloads (nightly ETL, reports, backups)
  • Parameterized Dispatch: Define a job template and dispatch instances with different parameters at runtime
  • Retry Policies: Configurable restart and reschedule policies with exponential backoff
  • Resource Isolation: CPU and memory limits per task prevent noisy-neighbor problems in shared clusters

Use Case: A data engineering team uses Nomad periodic jobs to run nightly data pipeline tasks across a distributed cluster, with automatic retry on transient failures.

πŸ”„ Advanced Deployment Strategies

Safe, Gradual Workload Updates: Nomad provides built-in deployment strategies that minimize risk when rolling out new versions.

  • Rolling Updates: Incrementally replace task group allocations with configurable batch sizes and health check gates
  • Blue/Green Deployments: Run two versions simultaneously, switch traffic via Consul, then decommission old version
  • Canary Deployments: Deploy a canary allocation and promote to full rollout only after validation
  • Automatic Rollback: Revert to the previous job version if the deployment health check fails

Use Case: A SaaS provider uses Nomad canary deployments to validate new service versions under real production traffic before committing to a full rollout.


Architecture

High-Level Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    Nomad Control Plane                       β”‚
β”‚   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”‚
β”‚   β”‚              Nomad Servers (3 or 5)                 β”‚   β”‚
β”‚   β”‚   Raft Consensus Β· Job Scheduler Β· State Store      β”‚   β”‚
β”‚   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                           β”‚ RPC / mTLS
          β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
          ↓                ↓                ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  Nomad Clientβ”‚  β”‚  Nomad Clientβ”‚  β”‚  Nomad Clientβ”‚
β”‚  (Cloud)     β”‚  β”‚  (On-Prem)   β”‚  β”‚  (Edge)      β”‚
β”‚  Docker/Exec β”‚  β”‚  Java/Exec   β”‚  β”‚  Exec/Podman β”‚
β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜
       β”‚                 β”‚                  β”‚
       ↓                 ↓                  ↓
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚          HashiCorp Ecosystem Integration                     β”‚
β”‚   Vault (Secrets) Β· Consul (Service Discovery / Mesh)       β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

System Components

Component Purpose Technology Scalability
Nomad Servers Cluster state, job scheduling, Raft consensus HashiCorp Nomad 3–5 nodes (HA)
Nomad Clients Execute task allocations on host infrastructure HashiCorp Nomad Horizontal (10K+ nodes)
Task Drivers Runtime adapters (Docker, Exec, Java, Podman) Nomad Plugins Per-client
HashiCorp Vault Secrets injection for workloads at runtime HashiCorp Vault Horizontal
Consul Service discovery, health checking, service mesh HashiCorp Consul Horizontal
Nomad Pack Templated job specifications (like Helm for Nomad) Community / HCP N/A

Data Flow

sequenceDiagram
    participant Operator as Operator / CI/CD
    participant Server as Nomad Server
    participant Vault as HashiCorp Vault
    participant Client as Nomad Client
    participant App as Running Workload

    Operator->>Server: Submit Job Spec (nomad job run)
    Server->>Server: Schedule Allocations
    Server->>Client: Place Allocation on Client
    Client->>Vault: Request Runtime Secrets (Vault Agent)
    Vault-->>Client: Inject Secrets (env vars / files)
    Client->>App: Launch Task (Docker / Exec / Java)
    App-->>Client: Health Check Status
    Client-->>Server: Allocation Health
    Server-->>Operator: Deployment Status

Use Cases

Who Should Use Workload Orchestration & Scheduling?

Target Personas

πŸ‘¨β€πŸ’» Platform Engineers

Platform engineers use Nomad to provide a workload scheduling platform that handles diverse workload types without forcing everything into containers.

Common Tasks:

  • Scheduling mixed workloads (containers, legacy binaries, batch jobs) on shared infrastructure
  • Managing cluster capacity and workload bin-packing across hybrid nodes
  • Integrating Nomad with Vault and Consul for secure service networking
  • Defining resource quotas and namespace isolation for multi-team clusters

Benefits:

  • Single scheduler for all workload types reduces operational complexity
  • 10,000+ node scalability with a 35MB single binary
  • Native Vault integration eliminates custom secrets injection solutions
🏒 DevOps & Application Teams

DevOps teams use Nomad to deploy and manage applications with fine-grained control over placement, resource allocation, and deployment strategies.

Common Tasks:

  • Defining job specifications for services and batch workloads
  • Executing canary and blue/green deployments
  • Parameterizing batch job dispatch for data pipelines
  • Monitoring allocation health and deployment progress

Benefits:

  • Declarative job specs with built-in deployment strategies
  • Self-service job submission without cluster administration privileges
  • Consistent deployment patterns across cloud and on-premises environments

Real-World Scenarios

Scenario 1: Mixed-Workload Migration from Multiple Schedulers

Challenge: An enterprise operates separate schedulers for batch jobs (cron), containerized services (Kubernetes), and legacy Java applications (manual scripts), creating operational silos and inconsistent monitoring.

Solution: Consolidate all workloads onto Nomad, defining each as a job with appropriate task drivers. A single control plane handles scheduling, health checks, and deployment across all workload types.

Results:

  • βœ… Simplification: Reduced from 3 scheduling systems to 1
  • βœ… Visibility: Unified monitoring and alerting for all workload types
  • βœ… Efficiency: Improved cluster utilization through shared resource pooling

Scenario 2: Batch Data Pipeline Orchestration

Challenge: A data engineering team needs to run hundreds of nightly ETL jobs with different parameters, retry on failure, and track execution history without building a custom scheduler.

Solution: Use Nomad parameterized batch jobs dispatched via API from the data pipeline orchestrator. Nomad handles placement, resource limits, retry policies, and execution tracking.

Benefits:

  • Parameterized dispatch eliminates duplicate job definitions
  • Built-in retry with exponential backoff handles transient failures
  • Resource isolation prevents batch jobs from starving service workloads

Products & Services

HashiCorp Nomad

Description: HashiCorp Nomad is a flexible, lightweight workload orchestrator that enables organizations to deploy and manage containerized, non-containerized, and batch workloads across on-premises and cloud environments from a single control plane.

Key Features: - Multi-runtime task drivers: Docker, Exec, Java, Podman, QEMU - First-class batch and periodic job scheduling - Native integration with HashiCorp Vault and Consul - Blue/green, canary, and rolling deployment strategies - Multi-region and federated cluster support

Links: - πŸ“– Documentation - πŸš€ Get Started - πŸ’» GitHub Repository


Core Concepts

Fundamental Concepts

Concept 1: Jobs, Task Groups, and Tasks

The Nomad job specification is the fundamental unit of work. Jobs contain task groups (sets of co-located tasks), and task groups contain individual tasks (processes).

job "web-api" {
  type = "service"

  group "api" {
    count = 3

    task "server" {
      driver = "docker"

      config {
        image = "myorg/web-api:v1.2.0"
        ports = ["http"]
      }

      resources {
        cpu    = 500  # MHz
        memory = 256  # MB
      }
    }
  }
}

Concept 2: Scheduler Types

Nomad supports three scheduler types, each optimized for a different workload pattern:

Scheduler Use Case Behavior
service Long-running services Restart on failure, rolling updates
batch Finite batch jobs Run to completion, parameterizable
system Infrastructure daemons Run one allocation per eligible node

Concept 3: Vault Integration for Runtime Secrets

Nomad's native Vault integration injects secrets directly into task environments without requiring application changes or storing secrets in job specs.

vault {
  policies = ["web-api-policy"]
}

template {
  data        = <<EOF
{{ with secret "database/creds/web-api" }}
DB_USERNAME={{ .Data.username }}
DB_PASSWORD={{ .Data.password }}
{{ end }}
EOF
  destination = "secrets/db.env"
  env         = true
}

Assets

Additional Resources


Call to Action

Ready to Build with Workload Orchestration & Scheduling?

  • Explore the fundamentals in the Overview, Architecture, and Core Concepts sections
  • Review use cases to identify the scheduling patterns that apply to your workloads
  • Get started with Nomad through the official tutorials

Get Started Now: - πŸš€ HashiCorp Nomad Get Started - πŸ“– Nomad Documentation


Within Operate:

Other Building Blocks: