企业官网建设流程全解析

Volcano 与 Kubernetes 版本兼容矩阵：从 v1.6 到 HEAD 的完整版本适配指南

【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano

Volcano 作为运行在 Kubernetes 之上的云原生批处理系统，其各版本对底层 Kubernetes 集群版本的支持范围有明确的边界。本文以仓库中docs/user-guide/version-compatibility-archive.md这份兼容性历史档案为主体，完整收录 Volcano v1.6 至 HEAD（master 分支）对 Kubernetes 1.17–1.34 的完整兼容矩阵，并结合仓库源码与 CI 配置（如go.mod中的 K8s API 依赖版本、e2e 测试集群镜像），讲解如何读懂兼容矩阵符号、为集群选择正确的 Volcano 版本，以及理解版本窗口演进背后的工程原因。

一、这份兼容矩阵档案的定位

Volcano 仓库中有两处维护版本兼容信息，二者分工明确：

• 主 README 中的 "Kubernetes compatibility" 章节，展示最近若干版本（当前覆盖 Volcano v1.10 至 HEAD 对 Kubernetes 1.21–1.36）的兼容矩阵，是日常选型的首选参考；
• 本文主体 docs/user-guide/version-compatibility-archive.md 则是完整的历史兼容档案，覆盖 Volcano v1.6 至 HEAD 对 Kubernetes 1.17–1.34 的全部兼容记录。

原档案文档开头的说明即点明了二者关系：

This page contains the complete compatibility history for all Volcano versions. For the latest versions, see the main README.

因此，当你面对的是一个较老的存量集群（例如仍运行 Kubernetes 1.19–1.22 的存量业务集群），需要确认多年前的某个 Volcano 发布版（如 v1.8、v1.9）是否支持时，这份档案就是唯一权威依据。

二、完整兼容矩阵（全量继承）

以下为档案文档中的 Complete Compatibility Matrix，横轴为 Kubernetes 版本（1.34 → 1.17），纵轴为 Volcano 版本（HEAD → v1.6），完整保留原文：

符号图例（Key）

原档案对每个符号的定义如下，选型时必须准确理解三者的语义差别：

• ✓—完全兼容（exactly compatible）：该 Volcano 版本与该 Kubernetes 版本经过验证、完全匹配，是推荐组合；
• +—有条件兼容：Volcano 存在某些特性或 API 对象，可能在对应 Kubernetes 版本中不存在（即新版本 Volcano 的某些能力依赖较新 K8s 才引入的 API，在旧集群上这部分功能会不可用）；
• -—不兼容：该 Kubernetes 版本存在 Volcano 无法使用的特性或 API 对象，或者说版本差距超出支持窗口，该组合不被支持。

三、从矩阵读出的版本适配规律

把上表与 README 中的最新矩阵放在一起对比，可以归纳出几条稳定的适配规律，这些规律比单点查表更有实战价值。

1. 每个 Volcano 版本支持一个约 6～8 个 K8s 次版本滑动窗口

从矩阵中可以读出各版本的实际支持跨度：

早期版本窗口约为 8 个 K8s 次版本；v1.13 之后窗口明显放宽（v1.14 支持跨度达 12 个次版本），说明新版本客户端对旧 API Server 的容忍度在提升。

2. 窗口整体上移：老 K8s 逐渐退出支持

每一代 Volcano 发布，窗口下限都会抬升 1～2 个 K8s 次版本：v1.7 放弃 K8s 1.17，v1.8 放弃 1.18，v1.9 放弃 1.19……到 HEAD，K8s 1.22 及以下已从矩阵中消失。这意味着：Kubernetes 1.19–1.22 的存量集群最多只能停留在 v1.9 / v1.10 / v1.11 / v1.12 等对应时代的 Volcano 版本，无法直接升级到最新 Volcano。

3. 上限约束：Volcano 不会领先 K8s 太多

矩阵中所有版本的左上角都是-（例如 v1.14 不支持 K8s 1.34 之前发布的更新版本）。从规律看，每个 Volcano 版本最多支持到其发布时点附近的 K8s 最新次版本——K8s 新版本引入的 API 变化（如 Admission API、PodSecurity 策略、动态资源分配等）需要 Volcano 侧显式适配。因此集群升级到 K8s 新版本后，应同步升级 Volcano 以获得✓级兼容。

4. 档案与 README 的衔接：v1.15 出现在最新矩阵中

README 最新矩阵中出现了 v1.15（支持 K8s 1.24–1.35），而历史档案中尚未收录 v1.15 行。二者在重叠区间（如 Volcano v1.14 对 K8s 1.23–1.34 的✓）完全一致，印证了档案的定位——只增不删的历史快照，最新状态以 README 为准。

四、仓库中的工程证据：兼容性是如何被保证的

版本兼容矩阵不是纯声明文档，仓库中有三类机制在持续验证和维护它。

1. 客户端库版本锁定兼容基线

go.mod显示当前代码统一依赖k8s.io/api、k8s.io/apimachinery、k8s.io/client-go、k8s.io/component-base以及被替换（replace）到的k8s.io/kube-scheduler均为v0.36.1（对应 Kubernetes 1.36 API 库），Go 语言版本为 1.26。以 1.36 的 API 客户端为基础构建，是矩阵中 HEAD 行能覆盖 K8s 1.23–1.36 宽窗口的基础：K8s API 遵循"高版本客户端访问低版本 API Server 需落在支持窗口内"的跨版本兼容规则，Volcano 的兼容矩阵下限（1.23）即对应 client-go 的跨版本兼容能力边界。

2. e2e 测试集群锚定最新 K8s 版本

hack/e2e-kind-config.yaml 是 Volcano 端到端测试所用 kind 集群配置，当前锚定kindest/node:v1.36.1（1 个 control-plane + 4 个 worker），并开启了MutatingAdmissionPolicyfeature gate 与 containerd CDI 配置。这说明 CI 始终在最新的 K8s 次版本上跑全量 e2e 套件（对应.github/workflows/下e2e.yaml、e2e_admission.yaml、e2e_cronjob.yaml等十余个 e2e 工作流），保证矩阵右上角的最新 K8s 列始终处于"最近验证"状态。

3. 版本标识与发布流程

pkg/version/version.go定义了 Volcano 构建时的Version、GitSHA、Built注入机制（默认值 "Not provided."，构建时由 ldflags 注入），各组件通过--version输出可核验的 API Version / Git SHA / 构建时间。而.github/workflows/release.yaml定义了发布节奏：master 分支每日 0:00 与 12:00（UTC）产出latest镜像，v*.*.*tag 推送则触发正式版本镜像与 vcctl CLI 多平台构建。这解释了矩阵中 "Volcano HEAD (master)" 一行的含义——它不是某个固定快照，而是每日更新的滚动版本，其兼容区间随 master 上的 K8s 依赖升级而动态演进。

五、实战选型建议

基于以上矩阵与仓库证据，给出一套可操作的选型方法：

1. 先查集群版本：kubectl version --short确认 Kubernetes 次版本，如为 1.26，则从档案矩阵中找所有覆盖 1.26 列的 Volcano 行：HEAD、v1.14、v1.13、v1.12、v1.11、v1.10、v1.9、v1.8、v1.7 均标✓。
2. 新集群直接选 HEAD / 最新 release：K8s 1.25 及以上的集群，直接采用 README 最新矩阵中支持当前 K8s 版本的最近 Volcano release（当前为 v1.15 或 master 每日构建），可获得✓级完全兼容与全部最新调度能力。
3. 老集群升级前先查矩阵：K8s 1.19–1.22 集群若运行 v1.6–v1.9 时代的老 Volcano，升级到最新 Volcano 前必须先升级 K8s 至矩阵下限（当前 HEAD 为 1.23，README 口径）以上，否则落在-区，属于不受支持组合。
4. 遇到+标记要核对特性依赖：+表示 Volcano 部分特性依赖较新 K8s 才有的 API 对象。启用如 DRA、scheduling gates、admission 新 API 等特性前，应核对目标 K8s 版本是否具备对应 API（可通过kubectl api-versions查看）。
5. 不要假设矩阵外组合可用：-是明确的"不受支持"声明，即使实际部署时组件能启动，也不在 Volcano 的兼容承诺范围内。

六、适用前提与限制说明

• 本文所有矩阵数据以当前仓库中 docs/user-guide/version-compatibility-archive.md 与 README.md 的实际内容为准；随着 Volcano 发布新版本，README 矩阵会滚动更新，而档案页补充历史记录。
• 兼容矩阵描述的是 Volcano 核心组件（scheduler、controller-manager、webhook-manager 等）与 Kubernetes 版本的关系，不涵盖 CNI、GPU 设备插件、存储插件等第三方组件的兼容性——这些需要各自另行验证。
• "Volcano HEAD (master)" 行是滚动目标，具体某日的 master 构建对应哪次提交，可通过pkg/version/version.go输出的 Git SHA 核对。
• K8s API 库（go.mod 中 v0.36.1）与矩阵上限（1.36/1.37）的对应关系表明：Volcano 每次跟进 K8s 新版，本质上是升级 k8s.io 客户端依赖并通过全量 e2e（hack/e2e-kind-config.yaml锚定版本）验证后的结果，因此矩阵更新节奏与 K8s 次版本发布节奏强相关。

总结：Volcano 的版本兼容矩阵采用"滑动窗口"模型——每个发布版覆盖一段连续的 K8s 次版本区间，窗口随版本整体上移。历史档案页提供了 v1.6 以来的完整回溯能力，README 提供最新状态；配合 go.mod 依赖版本与 e2e kind 集群配置这两处工程证据，可以完整回答"我的 K8s 集群该配哪个 Volcano"这一选型问题。

【免费下载链接】volcanoA Cloud Native Batch System (Project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/vol/volcano