Volcano is a Kubernetes-native batch scheduling system, not a general-purpose orchestrator. It extends the standard kube-scheduler with gang scheduling, job queues, fair-share, preemption, and reservation features aimed at AI/ML, big data, and HPC jobs that need to run as a group. The project sits under the Cloud Native Computing Foundation as an incubating project, and the README says it draws on over fifteen years of experience running high-performance workloads. At review time, this is a Go codebase with 5,932 GitHub stars, Apache-2.0 license, and release v1.15.2 from August 29, 2026.
What happened when we ran it
We cloned the repo at commit 606c628 and ran it in a sandbox with 3 CPUs, 8 GB of RAM, and Go 1.24 on 2026-09-09. Install succeeded in 71 seconds and installed 460 packages. Build succeeded in 280 seconds. The full test run failed with exit code 1 after 313 seconds: 194 tests passed and 33 failed out of 227. The failing log lines are all end-to-end suites (jobseq, schedulersharding, schedulingaction, schedulingbase, schedulinggates, shardingcontroller, stress, vcctl), not unit tests. Those e2e suites need a live Kubernetes cluster, and our fresh Debian container had none. That failure is not a code bug in itself, but it does mean a contributor cannot validate the repo end to end from the README alone.
Volcano's biggest selling point is its integration surface. The README lists Spark Operator, native Spark, Flink, KubeRay, PyTorch, TensorFlow, kubeflow/trainer v2, kubeflow/training-operator v1, kubeflow/arena, MPI, Horovod, PaddlePaddle, Cromwell, MindSpore, MXNet, Argo, and KubeGene. That is a remarkable breadth, and it means most batch or AI operators on Kubernetes can point at Volcano as a scheduler with only a schedulerName change. The project also has an active talk list at KubeCon events from 2019 through 2026, including sessions on LLM training and topology-aware scheduling. It has hundreds of contributors and regular releases, with v1.15.2 arriving less than two weeks before our review.
Rough edges start with the test experience. Our run produced 33 failed tests in e2e suites, and the README does not clearly tell new contributors that they need a live cluster to run those tests. The repository is also large: 1,932 files and roughly 266,275 lines of source. The issue tracker has 823 open issues, which suggests a busy project but also a backlog that may hide stale problems. The repo has no Dockerfile among the measured files, so local development depends on your Kubernetes setup or make targets that are not covered in the README snippet we reviewed. None of this blocks adoption, but it raises the effort for first-time contributors.
Activity is strong. The last push to the default branch was September 8, 2026, one day before our review. The latest release v1.15.2 was cut on August 29, 2026. There are 25 CI workflow files, a tests directory, and OpenSSF Scorecard plus CII Best Practices badges in the README. The project is CNCF incubating, which means it has passed a minimum bar for governance and security practices. The 823 open issues are high, but for a repo of this size and adoption, that is not unusual. Contributors appear to be reviewing and merging regularly.
Volcano fits behind an existing Kubernetes API server, not in front of one. You run its controllers and scheduler alongside kube-scheduler, then set schedulerName: volcano on Jobs, PodGroups, or other batch CRDs. In a real stack, you would use Volcano with Spark Operator for large ETL, KubeRay for distributed training, or Kubeflow for ML pipelines. It is not a replacement for your container orchestrator or your workload manager; it is the scheduling brain that decides where and when batch pods run. Our sandbox install needed 460 packages and a 280-second build, so you will want a proper Kubernetes cluster and CI pipeline rather than ad hoc local runs.