📚 课程目录第2章环境搭建与快速部署

2. 环境搭建与快速部署

Volcano 是构建在 Kubernetes 之上的批处理调度平台，它并不替代 kube-scheduler，而是以独立调度器（volcano-scheduler）与一组控制器（vc-controller-manager）、准入 Webhook（volcano-admission）和命令行工具（vcctl）协同工作的方式接入集群。因此环境搭建的第一步不是装 Volcano，而是确认 Kubernetes 集群本身满足版本、网络、存储与权限前提。本节按“集群准备 → 安装方式选择 → 组件启动验证 → 常见问题排查”的顺序展开，并给出可直接对照执行的示例参数。

一、Kubernetes 集群准备

Volcano 官方对 Kubernetes 版本有最低要求，较新的 Volcano 版本通常要求 Kubernetes 1.20 及以上，并建议使用 containerd 或 Docker 作为容器运行时。准备阶段需要确认四件事：

版本与节点状态：执行 kubectl version --short 与 kubectl get nodes -o wide，确保所有节点处于 Ready，且 kubelet 版本与 API Server 版本偏差不超过一个小版本。
网络与 DNS：CoreDNS 必须正常运行，Pod 之间可跨节点通信。若使用 Calico、Flannel 等 CNI，需确认 kubectl get pods -n kube-system 中网络组件全部 Running。
存储与镜像仓库：Volcano 组件本身不强制依赖持久卷，但后续跑 MPI、TensorFlow 等作业会用到 PVC，建议提前准备 StorageClass。若集群无法访问公网，需要把 Volcano 镜像同步到内网仓库。
权限：安装 Volcano 需要 cluster-admin 权限，用于创建 CRD、ClusterRole 与命名空间。

一个常见的准备检查命令如下，示例输出中节点名与 IP 均为假设值：

$ kubectl get nodes
NAME        STATUS   ROLES           AGE   VERSION
master-01   Ready    control-plane   12d   v1.26.3
worker-01   Ready    <none>          12d   v1.26.3
worker-02   Ready    <none>          12d   v1.26.3

$ kubectl get pods -n kube-system | grep -E 'coredns|calico'
coredns-6d4b75cb6d-abcde        1/1   Running   0   12d
calico-node-xyz12               1/1   Running   0   12d

如果节点处于 NotReady，优先排查 kubelet 日志与 CNI 配置，而不是继续安装 Volcano，否则后续 Pod 会卡在 ContainerCreating。

二、Volcano 安装方式

Volcano 提供三种主流安装方式，选择依据是“是否需要定制”和“是否已有 Helm 管理习惯”。

方式	适用场景	关键命令
YAML 直接部署	快速验证、离线环境	`kubectl apply -f volcano-*.yaml`
Helm Chart	需要参数化、可升级	`helm install volcano volcano-sh/volcano -n volcano-system`
源码编译部署	二次开发、调试	`make images && kubectl apply -f installer/`

以 Helm 方式为例，示例参数如下（版本号与仓库地址为示例，实际以官方发布为准）：

helm repo add volcano-sh https://volcano-sh.github.io/volcano
helm repo update
helm install volcano volcano-sh/volcano \
  --namespace volcano-system \
  --create-namespace \
  --set basic.image_tag_version=v1.9.0 \
  --set custom.scheduler_config_file=volcano-scheduler.conf

安装完成后，Volcano 会在 volcano-system 命名空间下创建 Deployment、Service、ConfigMap 以及若干 CRD（如 queues.scheduling.volcano.sh、podgroups.scheduling.volcano.sh）。这些 CRD 是后续提交作业的基础，必须确认它们已成功注册。

三、核心组件启动验证

Volcano 的核心组件包括：volcano-scheduler（批调度与队列管理）、vc-controller-manager（作业生命周期控制）、volcano-admission（准入校验）、volcano-webhook（部分版本合并到 admission）。验证顺序建议从 Pod 状态 → 日志 → CRD → 调度器配置四层推进。

$ kubectl get pods -n volcano-system
NAME                                   READY   STATUS    RESTARTS
volcano-admission-5b7c8d9f6-abcde      1/1     Running   0
volcano-controllers-6f8d7c5b4-fghij    1/1     Running   0
volcano-scheduler-7d9c8b6a5-klmno      1/1     Running   0

$ kubectl get crd | grep volcano
podgroups.scheduling.volcano.sh        2024-05-01T10:00:00Z
queues.scheduling.volcano.sh           2024-05-01T10:00:00Z

若 Pod 处于 CrashLoopBackOff，用 kubectl logs -n volcano-system <pod-name> --previous 查看上一次崩溃日志。调度器启动失败最常见的原因是 ConfigMap 中 volcano-scheduler.conf 的 actions 或 tiers 配置语法错误，例如插件名拼写错误或缩进不合法。

验证调度器是否真正接管批作业，可以提交一个最小 Volcano Job，观察 Pod 是否由 volcano-scheduler 调度。若 Pod 的 spec.schedulerName 为 volcano，说明调度链路已生效。

四、常见问题排查

下面用一张关系图梳理从“安装后异常”到“定位根因”的排查路径，图中对象均为 Volcano 实际组件与资源。

结合上图，几个高频问题及处理方式如下：

调度器启动即退出：多为 volcano-scheduler.conf 中 actions 引用了不存在的插件，或 tiers 缩进错误。修正 ConfigMap 后 kubectl rollout restart deployment volcano-scheduler -n volcano-system。
Pod 一直 Pending：先确认 Pod 的 schedulerName 是否为 volcano；再检查 Queue 是否存在且未被 closed；最后看节点资源是否满足 PodGroup 的 minMember 要求。
CRD 未注册：kubectl get crd | grep volcano 为空，说明安装时 RBAC 不足或 YAML 未完整应用，需重新执行安装并检查 kubectl apply 的报错。
Webhook 拒绝作业：查看 volcano-admission 日志，常见原因是 PodGroup 的 minMember 大于实际副本数，或 Queue 配额不足。

不要用 kubectl delete pod 反复重启组件来“碰运气”。Volcano 组件异常通常由配置或权限引起，删除 Pod 不会改变根因，应先看日志与事件（kubectl describe pod）。

完成以上验证后，可以用一个最小 Queue 与 Job 做端到端确认：创建名为 test-queue 的 Queue，再提交一个 minAvailable: 1 的 Volcano Job，观察其 Pod 是否被调度到 worker 节点并进入 Running。若成功，说明集群准备、安装、组件启动与调度链路均已打通，可以进入后续的队列管理与作业编排环节。