ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

KubeVirtCI K8S Provider 自动化更新机制解析:从 Kubernetes 发版到 KubeVirt 测试矩阵的完整流水线

KubeVirtCI K8S Provider 自动化更新机制解析:从 Kubernetes 发版到 KubeVirt 测试矩阵的完整流水线 云原生【免费下载链接】kubevirtKubernetes Virtualization API and runtime in order to define and manage virtual machines.项目地址https://gitcode.com/gh_mirrors/ku/kubevirt点击查看免费下载KubeVirtCI 是 KubeVirt 项目用于在容器中快速拉起预置 Kubernetes 集群的开发与测试基础设施其中每个 K8s 版本对应一个 provider预置集群容器镜像及其启动脚本。本文以仓库文档 K8S_AUTOMATION.md 为骨架系统梳理 KubeVirtCI 在 Kubernetes 新版本发布、补丁版本更新等场景下如何通过一系列自动化任务Prow Job完成 provider 的创建、更新与集成并对照仓库内源码与脚本说明这些自动化步骤在 KubeVirt 主仓库中的实际落地方式。读完本文你将掌握 KubeVirtCI provider 自动化生命周期中每个任务的角色、触发时机与产出物以及手动兜底流程和相关的版本同步脚本原理。KubeVirtCI Provider 自动化更新的背景KubeVirtCI 的核心目标是以容器镜像形式提供预置好的 Kubernetes 集群一次完成集群的下载、安装与编译固化之后可在离线环境下快速启动且结果与宿主机的 OS 与已装软件包无关详见 K8S_DEV_GUIDE.md。Kubernetes 社区持续发布新的 minor 版本与 patch 版本KubeVirtCI 必须持续跟进为每个新版本创建对应的 provider并把它接入 KubeVirt 的测试矩阵。这些创建、更新与集成步骤全部以 Prow Job 的形式定义在project-infra仓库中形成了一条自动化的流水线。从当前仓库的实际目录可以看到 provider 的组织方式kubevirtci/cluster-up/cluster/下按版本号划分目录如k8s-1.34/、k8s-1.35/、k8s-1.36/、k8s-1.37/每个目录内含provider.sh等启动脚本另有kind-1.35/、kind-1.36/、kind-1.37/、kind-dra/、kind-ovn/等基于 kind 的变体 provider。自动化任务的目标就是让这些目录及其背后的容器镜像始终跟上 Kubernetes 的发布节奏。自动化任务总览一张表看懂六个 Prow JobK8S_AUTOMATION.md 的核心内容是一张任务映射表完整列举了六个自动化任务及其触发时机与产出结果全部内容如下触发时机任务Job结果Kubernetes 新 minor 版本发布periodic-kubevirtci-cluster-minorversion-updater为新版本创建新的 providerKubernetes 新 minor 版本发布periodic-kubevirtci-provider-presubmit-creator创建 PR添加新的 check-provision 任务以开启对新 provider 的测试Kubernetes 新 minor 版本发布periodic-kubevirt-job-copier创建 PR添加一组新的 KubeVirt sig 测试任务开启 KubeVirt 对新 provider 的测试Kubernetes 新 patch 版本发布periodic-kubevirtci-cluster-patchversion-updater创建 PR为每个 KubeVirtCI k8s provider 更新 patch 版本合并到 kubevirt/kubevirtci 的 main 分支periodic-kubevirtci-bump-kubevirt创建 PR将 KubeVirtCI 更新到 kubevirt/kubevirt主仓库每月月初periodic-kubevirt-presubmit-requirer检查最新 KubeVirt sig 测试任务的always_run与optional状态这些任务共同构成一个闭环新版本进来 → 创建 provider → 接通 provisioning 测试 → 接通 KubeVirt sig 测试 → 更新主仓库依赖 → 周期性复核测试任务的运行策略。下面按触发时机逐类拆解。Kubernetes minor 版本发布三步接力创建并接入新 ProviderKubernetes 每发布一个新的 minor 版本例如从 1.36 升到 1.37会依次触发三个任务形成创建—验证—接入的三步接力periodic-kubevirtci-cluster-minorversion-updater负责在新版本发布后创建对应的 provider。从 K8S_DEV_GUIDE.md 可知一个完整的 provider 包含两部分cluster-provision/k8s/${KUBEVIRT_PROVIDER_VERSION}用于预置集群镜像与cluster-up/cluster/k8s-${KUBEVIRT_PROVIDER_VERSION}用于启动预置集群。新 provider 落地后仓库中会出现对应的provider.sh、README.md等文件例如当前仓库中kubevirtci/cluster-up/cluster/k8s-1.37/目录即包含provider.sh、config_sriov_cluster.sh、config_vfio_cluster.sh以及 sriov 组件清单。periodic-kubevirtci-provider-presubmit-creator在 KubeVirtCI 仓库创建 PR添加一个针对新 provider 的check-provisionpresubmit 任务。该任务的作用是在合入前先验证新 provider 的 provisioning 流程能否成功确保镜像可被正常构建与启动。periodic-kubevirt-job-copier在 KubeVirt 主仓库当前仓库即为其镜像创建 PR复制出一组新的 KubeVirt sig 测试任务。这样新 provider 就正式进入 KubeVirt 的 e2e 测试矩阵KubeVirt 的各个 sig如 sig-compute、sig-network、sig-storage都会针对新 Kubernetes 版本运行测试。三个任务全部由 Kubernetes minor 版本发布这一事件驱动将原本需要人工完成的新建目录、编写脚本、提交 PR、配置 CI工作全部自动化。Kubernetes patch 版本发布批量升级所有 ProviderKubernetes 的 minor 版本生命周期内会持续发布 patch 版本如 1.37.0 → 1.37.1。此时触发的periodic-kubevirtci-cluster-patchversion-updater会一次性更新所有 KubeVirtCI k8s provider 的 patch 版本并创建 PR。从 K8S_DEV_GUIDE.md 描述的 provider 结构可以推断patch 版本信息被固化在 provider 的版本声明中任务通过批量改写这些版本号让所有 provider 镜像统一跟随最新的补丁版本从而保证测试环境始终运行在修复了已知问题的 Kubernetes 版本之上。kubevirtci main 分支合并自动回灌主仓库KubeVirtCI 是独立于 KubeVirt 主仓库的组件主仓库通过固定 hash 引用特定版本的 KubeVirtCI。当任意改动合并到 kubevirt/kubevirtci 的 main 分支后periodic-kubevirtci-bump-kubevirt会创建 PR把 KubeVirtCI 的新版本同步到 kubevirt/kubevirt 主仓库。这一回灌动作在主仓库的脚本中有直接落地证据hack/config-default.sh 中维护kubevirtci_git_hash2609300856-4bec1cc7即主仓库当前引用的 KubeVirtCI 版本 hashhack/bump-kubevirtci.sh 通过 curl 读取kubevirt-prow存储的kubevirtci/latest最新 hash用sed改写hack/config-default.sh中的kubevirtci_git_hash然后调用hack/sync-kubevirtci.sh完成同步hack/sync-kubevirtci.sh 是比较与下载的核心它先对kubevirtci/cluster-up与kubevirtci/hack下所有文件做sha1sum汇总与kubevirtci/cluster-up-sha.txt记录的哈希比对若 hash 或文件哈希任一发生变化就下载对应 tag 的 tarball 覆盖cluster-up与hack目录并更新kubevirtci/cluster-up/version.txt与kubevirtci/cluster-up-sha.txt。也就是说自动化任务负责发起 PR而 PR 合并后主仓库的hack/sync-kubevirtci.sh这类脚本负责真正把新版本 KubeVirtCI 的脚本与配置落到仓库里。每月例行体检presubmit 任务的运行策略复核periodic-kubevirt-presubmit-requirer在每月月初运行检查最新一批 KubeVirt sig 测试任务的always_run与optional状态。其目的在于持续审视测试矩阵的健康度always_run表示该任务在每次 PR 提交时都必须运行optional表示允许失败不阻塞合入。定期复核可以避免新接入的测试任务因配置不当而被跳过例如被错误标记为 optional 而失去把关作用保证 KubeVirt 的持续集成对关键路径始终保持足够的覆盖。自动化之外手动创建与发布 Provider 的兜底流程自动化流程覆盖了常规场景但 K8S_DEV_GUIDE.md 同时保留了手动创建与发布 provider 的完整步骤作为自动化任务的兜底与补充创建一个新的 K8s provider手动步骤克隆现有 k8s provider 目录目录名遵循k8s-${KUBEVIRT_PROVIDER_VERSION}.0的命名规则补齐四个关键文件cluster-provision/k8s/${KUBEVIRT_PROVIDER_VERSION}/provision.sh用于创建新 providercluster-provision/k8s/${KUBEVIRT_PROVIDER_VERSION}/publish.sh用于发布新 providercluster-up/cluster/k8s-${KUBEVIRT_PROVIDER_VERSION}/provider.sh供 cluster-up 启动集群时使用cluster-up/cluster/k8s-${KUBEVIRT_PROVIDER_VERSION}/README.md使用说明。向集群添加新 manifest 的示例手动步骤将 manifest 文件放入cluster-provision/manifests该目录会在 provisioning 时被cluster-provision/cli/cli复制到容器内的/tmp在cluster-provision/k8s/scripts/provision.sh中、Wait at least for 7 pods 之前插入如下片段custom_manifest/tmp/custom_manifest.yaml kubectl --kubeconfig/etc/kubernetes/admin.conf create -f $custom_manifest运行./cluster-provision/k8s/${KUBEVIRT_PROVIDER_VERSION}/provision.sh它会创建新的 provision 并执行测试。发布新 provider 的手动步骤运行./cluster-provision/k8s/${KUBEVIRT_PROVIDER_DIR}/publish.sh将新镜像发布到 quay.io提交一个 PR包含以下文件新增的 manifest、更新后的cluster-provision/k8s/scripts/provision.sh、更新后的cluster-up/cluster/images.sh。文档明确说明创建、测试和集成新 KubeVirtCI provider 的步骤大多已自动化指向 K8S_AUTOMATION.md上述手动流程是异常场景下的备选路径。自动化流程验证与回归保障自动化任务产出新 provider 后还需要配套的验证机制确保集群可正常启动。从 up.sh 可以看到 cluster-up 启动链路中的校验逻辑启动时按KUBEVIRT_PROVIDER选择kubevirtci/cluster-up/cluster/$KUBEVIRT_PROVIDER/provider.sh并调用up函数若设置了GLOBAL_KUBECONFIG会将生成的 kubeconfig 复制到全局路径若KUBEVIRT_SINGLE_STACK为 true则执行validate_single_stack_ipv6等待 kube-system 命名空间下的 kube-dns pod Ready校验其podIP是否以 IPv6 的fd前缀开头并确认不存在第二个 pod IP否则直接exit 1失败。此外主仓库与 KubeVirtCI 的同步有双重校验hack/sync-kubevirtci.sh通过kubevirtci/cluster-up/version.txt记录 git hash与kubevirtci/cluster-up-sha.txt记录文件内容哈希判断是否需要重新下载同时 hack/sync-kubevirtci-stable-provider.sh 会依据新 hash 从远端读取各 k8s provider 的版本并更新kubevirtci/stable_provider.txt保证稳定 provider 列表与 KubeVirtCI 版本一致。结语一条从 Kubernetes 发版到 KubeVirt 测试矩阵的自动化闭环KubeVirtCI 的 K8s provider 自动化更新体系可以概括为一条清晰的闭环Kubernetes 发布 minor 版本时periodic-kubevirtci-cluster-minorversion-updater创建 providerperiodic-kubevirtci-provider-presubmit-creator接通 provisioning 验证periodic-kubevirt-job-copier把新 provider 接入 KubeVirt 各 sig 测试发布 patch 版本时由periodic-kubevirtci-cluster-patchversion-updater统一升级KubeVirtCI 自身有更新时由periodic-kubevirtci-bump-kubevirt回灌主仓库配合 hack/bump-kubevirtci.sh 与 hack/sync-kubevirtci.sh 完成实际同步最后periodic-kubevirt-presubmit-requirer每月复核测试任务的运行策略。配合 K8S_DEV_GUIDE.md 中的手动兜底流程这一体系保证了 KubeVirt 始终能在最新的 Kubernetes 版本上进行充分的集成测试。赞分享云原生【免费下载链接】kubevirtKubernetes Virtualization API and runtime in order to define and manage virtual machines.项目地址https://gitcode.com/gh_mirrors/ku/kubevirt点击查看免费下载相关推荐LMDeploy Autotest 模型测试矩阵配置指南从 YAML 到自动化测试流水线LMDeploy Autotest 模型测试矩阵配置指南从 YAML 到自动化测试流水线 本指南围绕 LMDeploy 仓库中 autotest/config人工智能大模型模型推理服务推理引擎本地部署模型量化Fleet 中 Windows EXE 安装脚本EXE install scripts实战指南机器级与用户级静默部署Fleet 中 Windows EXE 安装脚本EXE install scripts实战指南机器级与用户级静默部署 本指南以 Fleet 的 EXE 安云原生Cap 开源录屏工具教程从录制到分享链接只需 3 步Cap 开源录屏工具教程从录制到分享链接只需 3 步 为什么发一条 1 分钟的视频而不是开 30 分钟会 给同事讲一个 bug 或演示一个功能时截图讲不动屏幕录制音视频桌面应用后端前端视频处理AI 应用移动开发上一篇OmX 0.20.3 版本深度解析按 Agent 推理强度上限、tmux 面板精确权威与 Ralplan 评审完整性加固下一篇NautilusTrader Lighter 适配器测试数据解析REST、WebSocket 与 L2 签名向量的工程实践创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表