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¶
- π Nomad Documentation - Complete Nomad reference
- π Nomad Tutorials - Hands-on learning paths
- π» Nomad GitHub - Source code and issues
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
Related Capabilities¶
Within Operate:
- Infrastructure as Code - Provision the infrastructure Nomad runs on with Terraform
- Configure & Automate - Configure Nomad nodes and cluster settings with Ansible
Other Building Blocks:
- Non-human Identity - Inject secrets into Nomad workloads via Vault
- Full-Stack Application Observability - Monitor workloads running on Nomad
- Application Performance - Optimize resource allocation for scheduled workloads