nixpkgs 中 k3s 包维护指南:版本化升级、补丁发布与生命周期管理

发布时间:2026/10/5 12:41:05
nixpkgs 中 k3s 包维护指南:版本化升级、补丁发布与生命周期管理 包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载本指南以 K3s 包维护文档 为核心骨架系统讲解在 nixpkgs 仓库中维护 k3s 包的完整流程包括 NixOS 发布周期内的版本策略、patch 升级脚本用法、包移除流程与变更审查清单。读者读完可以掌握update-script.sh的调用方式与内部原理、版本化包如k3s_1_36的增删流程以及维护者审查 k3s PR 时的关键检查点。为什么 k3s 需要专门的维护流程与 bash 这类可以随nixos-rebuild switch原子升级的普通软件不同k3s/Kubernetes 通常跨多台 NixOS 机器运行且每台机器独立更新。新旧版本在集群中会短暂共存version skew因此 nixpkgs 必须维持一条不违背上游 Kubernetes 版本偏差政策的升级路径upgrade path。这一背景在 VERSIONING.md 中有详细论述是理解本维护文档一切流程的前提。k3s 基于 Kubernetes 构建通常沿用与上游 K8s 相近的发布节奏与支持窗口大约每 4 个月发布一个新版本每个版本支持略超过 1 年。nixpkgs 据此在nixos-unstable分支上同时维护两类包标准k3s包随上游新版本发布即时更新版本化包如k3s_1_34、k3s_1_35遵循补丁发布支持生命周期在上游 EOL 或早于nixos-stable中当前k3s版本时从nixos-unstable移除。从 pkgs/top-level/all-packages.nix 可以看到当前的实际结构仓库同时暴露k3s_1_34至k3s_1_37四个版本化包且k3s k3s_1_36;——标准别名指向当前最新版本化包。NixOS 发布周期内的维护节奏发布前Pre-Release在下一个 NixOS 版本的 breaking change 窗口关闭之前维护者需要在nixos-unstable上完成三件事确保k3s指向最新版本化发布确保发布说明release notes最新提前移除将在下一个 NixOS 稳定版生命周期结束前上游 EOL 的 k3s 版本并附带恰当的弃用通知即下文包移除流程。这样做的目的是让即将冻结的 NixOS 稳定版只包含一个仍受支持的 k3s 版本避免在稳定版支持周期内出现已弃用软件。发布后Post-Release对于 k3s 的major/minor 新版本nixos-unstable创建新的版本化包目录如1_37/nixos-unstable更新k3s别名指向新版本化包nixos-unstable新增 NixOS 发布说明注明被移除的已弃用 k3s 包、以及来自 Kubernetes/k3s 项目的迁移信息nixos-stable回移backport该版本化包。对于已有版本的patch 发布nixos-unstable按Patch 升级流程更新包版本nixos-stable回移在nixos-unstable上完成的更新。稳定版之间的版本跨越策略按 VERSIONING.md 的规划每个 NixOS 稳定版发布时只应含一个 k3s 版本如 24.05 为 1.30.x。为了不强迫用户在升级 NixOS 稳定版时做违反版本偏差政策的大版本跳跃维护者会把后续版本化包回移到当前稳定版。文档给出的三版本示例为NixOS 23.11k3s/k3s_1_27发布版本patch 回移k3s_1_28、k3s_1_29、k3s_1_30回移NixOS 24.05k3s/k3s_1_30发布版本k3s_1_31、k3s_1_32回移NixOS 24.11k3s/k3s_1_32发布版本。用户升级到新稳定版前可先在旧稳定版上通过services.k3s.package依次指向k3s_1_31、k3s_1_32完成集群内小版本滚动从而平滑跨过稳定版边界。Patch 升级流程update-script.sh 实操基本用法patch 升级可直接使用包根目录下的 update-script.sh。在 nixpkgs git 仓库根目录运行例如升级 k3s 1.30.x./pkgs/applications/networking/cluster/k3s/update-script.sh 30只需把30替换为对应的 minor 版本号即可当前仓库中可用34、35、36、37。脚本会在执行结束时输出符合passthru.updateScript约定的 commit 描述 JSONattrPath、oldVersion、newVersion、files供 nixpkgs 的自动更新机制实现提交。脚本内部流程结合脚本源码一次 patch 升级会依次完成以下工作update-script.sh参数校验MINOR_VERSION${1:?Must provide a minor version number...}强制要求传入 minor 版本号获取当前版本通过nix-instantiate --eval读取k3s_1_X.version作为 OLD_VERSION 基线查询上游最新 tag调用 GitHub Releases API过滤prerelease、排除rc/engine后缀按版本号倒序筛选出v1.X.*的最新稳定 tag定位 commit 与源码 hash解析 tag 对应的 commit SHA并用nix-prefetch-url --unpack计算 k3s 源码 tarball 的 store 路径与 sha256推导依赖版本在 store 内source scripts/version.sh预置TAG、GITHUB_SHA等环境变量得到 k3s-root、CNI plugins、containerd 等所有捆绑组件的版本与 hash。随后脚本更新三个版本描述文件update-script.shchart-versions.nix从k3s.io/k3s-charts/assets下载 traefik/traefik-crd chart计算 sha256 后写入脚本会校验 chart 数量恰好为 2否则提示New manifest charts added, the packaging scripts will need to be updated并退出images-versions.json从该版本 Release 资产中筛选k3s-airgap-images-*.tar.*结合官方sha256sum-{amd64,arm64,arm}.txt生成各架构 airgap 镜像归档的 url 与 sha256versions.nix写入k3sVersion、k3sCommit、k3sRepoSha256及所有组件版本其中k3sVendorHash先用占位符FAKE_HASH最后用nurl计算真实的 Go modules vendor hash 后sed替换。失败处理与自动化文档明确规定脚本失败时第一目标是修复脚本本身若无法修复则用确切的命令和观察到的失败现象开 issue 报告。同时RyanTM bot 可以自动执行 patch 升级更新日志位于按版本组织的页面例如 1.30.x 的日志页面。这些日志可供维护者核对 bot 每次升级前后的版本变化。包移除流程版本化包的移除时间线遵循 VERSIONING.md 中的补丁发布支持生命周期。移除某个版本化包如k3s_1_30时需要提交一个 PR 完成四件事删除版本化目录移除包含 chart 与包版本文件的目录如./1_30/即 1_34/、1_35/、1_36/、1_37/ 这类目录下的versions.nix、chart-versions.nix、images-versions.json删除 default.nix 中的包块如k3s_1_30 ...删除 pkgs/top-level/all-packages.nix 中的包引用在 pkgs/top-level/aliases.nix 中添加弃用通知例如文档给出的模板k3s_1_26 throw k3s_1_26 has been removed from nixpkgs as it has reached end of life; # Added 2024-05-20当前仓库中已有实践范例pkgs/top-level/aliases.nix 中保留了k3s_1_30至k3s_1_33的 throw 别名均注明 has been removed from nixpkgs as it has reached end of life 及添加日期。这样既能让引用旧包的用户得到明确报错又能通过别名保留迁移线索。变更请求PR审查清单文档为 k3s 包的审查者提供了快速检查清单Go 编译器版本是否按该 release 的 go.mod 文件锁定注意update script 不会锁定也不会更改 Go 版本因此 PR 中任何 Go 版本调整都需要人工核对 go.modK3s 的passthru.tests是否在所有受支持架构上通过x86_64-linux、aarch64-linuxGitHub CI 上可用 OfBorg 测试所有平台本地测试可在 nixpkgs 根目录、升级分支上运行nix build .#k3s_1_29.passthru.tests.{etcd,single-node,multi-node}将29替换为被测版本nix 构建日志或测试日志中是否有异常测试与构建器机制补充从 builder.nix 的源码可以看到passthru.tests的生成逻辑是按k3s_ 主次版本号1.36→k3s_1_36映射到nixosTests.k3s下的同名测试etcd、single-node、multi-node等排除all也就是说nix build .#k3s_1_36.passthru.tests.etcd实际会构建对应的 NixOS 集成测试。k3s 的构建本身分为两个阶段builder.nix 注释有完整说明第一阶段用buildGoModule构建将被打包进厚 k3s 二进制的所有组件CNI plugins、containerd-shim、k3s bundle让它们都经过 nixpkgs 的自动 strip/patchelf 处理第二阶段再把这些组件连同 k3s-root 的etc配置、traefik chart 一起通过go generate嵌入最终的单二进制k3s并生成kubectl、crictl、ctr等多调用符号链接builder.nix。同时builder 还通过k3sRuntimeDepskmod、socat、iptables、nftables、iproute2、ipset、bridge-utils、ethtool、util-linuxMinimal、conntrack-tools、runc、bash、shadow 等builder.nix在wrapProgram中注入 PATH保证 kubelet 运行所需的宿主机工具可用。审查者若在日志中发现异常可据此定位是捆绑组件问题还是运行时依赖缺失。版本化包目录结构速览当前每个版本目录如 1_36/固定包含三个文件供维护者日常核对versions.nix核心版本清单含k3sVersion、k3sCommit、k3sRepoSha256、k3sVendorHash以及 k3s-root、CNI、containerd、cri-tools、flannel、kube-router、cri-dockerd、helm-controller 等全部捆绑组件的版本与 sha256chart-versions.nixtraefik 与 traefik-crd 两个内置 chart 的 URL 与 sha256images-versions.json各架构 airgap 镜像归档amd64/arm64/arm的 URL 与 sha256对应k3s.airgap-images-amd64-tar-zst等 passthru 属性。版本化包的装配入口是 default.nix它通过import ./builder.nix lib得到构造器再对每个versions.nix调用callPackage并把调用方all-packages.nix传入的额外参数向下透传从而支持对 builder 的三处可覆写点overrideBundleAttrs、overrideCniPluginsAttrs、overrideContainerdAttrs。适用前提与限制上述流程面向 nixpkgs 的 k3s 维护者与审查者普通用户通常只需通过services.k3s.package选用合适的k3s或k3s_X_Y版本update-script.sh依赖curl、git、go、jq、nurl、yq-go等工具见脚本开头的 nix-shell shebang并假设在 nixpkgs git 仓库根目录执行文档给出的版本示例如 1.26、1.29、1.30为历史策略示例当前仓库实际维护的版本以 default.nix 中列出的k3s_1_34~k3s_1_37为准nixos-unstable与各nixos-stable分支的具体情况可能随时间推移变化请以各分支当前内容为准。赞分享包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载相关推荐QMK 固件 Shisaku 键盘完全指南THT 焊接、Solenoid 触觉反馈与烧录配置QMK 固件 Shisaku 键盘完全指南THT 焊接、Solenoid 触觉反馈与烧录配置 导读 Shisaku 是 QMK 固件仓库中由 Arturo A包管理器操作系统OpenZiti 发布策略与 LTS 支持生命周期版本兼容、升级路径与补丁发布全解析OpenZiti 发布策略与 LTS 支持生命周期版本兼容、升级路径与补丁发布全解析 OpenZiti 是一套零信任、可编程网络的实现其中控制器Contr零信任网络后端认证鉴权Firecracker 发布策略深度解读版本规划、API 支持周期与维护生命周期管理Firecracker 发布策略深度解读版本规划、API 支持周期与维护生命周期管理 导读 本文以 Firecracker 官方 docs/RELEASE_P虚拟化云原生创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考