包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载K3s 是面向边缘与 IoT 场景精简化的 Kubernetes 发行版将集群核心组件打包进少数几个小型二进制文件中。本文以 Nixpkgs 仓库中的 K3s 包与 NixOS 模块k3s 包目录为蓝本系统讲解如何在 NixOS 上完成单节点、多节点 HA 集群的部署配置、GPU 直通与存储方案落地、集群重置与排障以及 Nixpkgs 侧 K3s 的版本管理与包维护流程读完即可从零搭建一套可实战的 NixOS K3s 集群。K3s 与 Nixpkgs 的集成方式K3s 是一个简化的 Kubernetes 发行版它把 Kubernetes 集群组件捆绑进少量面向边缘和 IoT 设备优化的小型二进制文件中。在 Nixpkgs 中K3s 包位于 pkgs/applications/networking/cluster/k3s/default.nix通过 builder.nix 生成各版本包NixOS 模块则位于 nixos/modules/services/cluster/rancher/k3s.nix。包结构一个“厚”二进制背后的多层派生上游 K3s 以单个大型二进制分发内含多个“身份”k3s server、k3s agent、k3s kubectl等子命令并在运行时把内部 bindata 解包到用户主目录或/var/lib/rancher。Nixpkgs 为了充分利用自身的条带化strip、patchelf、依赖注入等工具链在 builder.nix 中将构建拆成了多个派生k3sBundlepname 为k3s-bin构建cmd/server主程序并通过postInstall创建containerd、crictl、ctr、kubectl、k3s-server、k3s-token等多调用multicall软链接k3sCNIPlugins拉取 rancher 维护的 CNI 插件对上游做补丁后的版本k3sContainerd仅构建containerd-shim-runc-v2因为自 K3s 1.27.2 起 shim 不再随主二进制捆绑最终k3s包通过buildPhase中的go generate./scripts/package-cli将上述产物、k3sRoot中的etc/配置、traefik 等静态 chart 一并嵌入最后用wrapProgram把k3sRuntimeDepskmod、socat、iptables、nftables、iproute2、ipset、bridge-utils、ethtool、util-linuxMinimal、conntrack-tools、runc、bash、shadow等 kubelet 依赖的工具注入PATH。这正是理解后续“Quirks”与“从不同源码构建”章节的关键背景。单节点部署在configuration.nix中加入以下配置即可启用单节点 K3s{ networking.firewall.allowedTCPPorts [ 6443 # k3s必开保证 pod 能访问 API server默认运行在 6443 端口 # 2379 # k3setcd 客户端使用 High Availability Embedded etcd 配置时必开 # 2380 # k3setcd 对等节点使用 High Availability Embedded etcd 配置时必开 ]; networking.firewall.allowedUDPPorts [ # 8472 # k3sflannel多节点时用于节点间组网必开 ]; services.k3s.enable true; services.k3s.role server; services.k3s.extraFlags toString [ # --debug # 可选向 k3s 追加额外参数 ]; }配置生效后可以通过sudo k3s kubectl访问集群例如sudo k3s kubectl cluster-info也可以使用生成的 kubeconfig 文件/etc/rancher/k3s/k3s.yaml。从 NixOS 模块源码 nixos/modules/services/cluster/rancher/k3s.nix 可以看到role的语义当role server时默认同时以 agent 身份承载工作负载默认以独立服务器模式启动数据存储使用内嵌 sqlite配置clusterInit true可切换到内嵌 etcd 数据存储并启用 HA 模式配置serverAddr可加入一个已初始化的 HA 集群当role agent时serverAddr为必填项。此外模块还提供disableAgent仅运行 server默认false、disable禁用默认组件对应上游--disable标志、images启动时导入容器镜像等选项。多节点 HA 集群K3s 可以轻松组成多节点高可用集群——所有节点都位于控制面并参与 etcd 集群。第一个节点配置如下{ services.k3s { enable true; role server; token randomized common secret; clusterInit true; }; }其余后续节点使用略有不同的配置加入{ services.k3s { enable true; role server; # 或 agent表示纯工作节点 token randomized common secret; serverAddr https://ip of first node:6443; }; }几点注意事项需要在防火墙中打开上文提到的 API6443、etcd2379/2380和 flannel8472端口具体端口要求以上游 K3s 官方文档为准etcd 官方建议此类集群使用奇数个节点有利于 etcd 选主与容错如果节点间针对特定应用如 ingress controller出现连通性问题请对照该应用的文档核对防火墙配置。以 ingress controller 为例可能需要按需开放 80 或 443 端口。模块中clusterInit的语义见 k3s.nix在默认使用 sqlite 后端的 server 上启用该选项会迁移到内嵌 etcd若 HA 集群内嵌 etcd已经初始化该选项不再起作用该选项仅对未连接其他 server 的服务器有意义HA 集群的第一个 server 必须设置clusterInit true其余 server 通过serverAddr接入。已知 Quirksprefer-bundled-bin不可用K3s 有一个配置项prefer-bundled-bin对应 CLI 标志--prefer-bundled-bin它让 k3s 优先使用/var/lib/rancher/k3s/data/current/bin/aux/目录中由 k3s 二进制解包出来的工具而不是系统$PATH中的工具。这在官方发行版中可用但Nixpkgs 中的 K3s 包不行它没有把上游k3s-root的二进制内嵌进 k3s 二进制Nixpkgs 选择用包管理器注入这些依赖见 builder.nix 中关于k3sRoot的注释——它只取用其中的etc/配置如 strongswan 配置。因此不能用prefer-bundled-bin来绕开 kubelet 调用/使用二进制时遇到的问题例如 util-linux 的mount回归问题。从不同源码构建fork 或任意 commit由于包被拆分为多个派生且构建流程较复杂从不同源码fork 或任意 commit构建 K3s 并不直观。必须同时使用.override配合overrideBundleAttrs覆盖k3sBundle派生和另一个.overrideAttrs覆盖最终派生{ fetchgit, k3s }: let k3sRepo fetchgit { url https://github.com/k3s-io/k3s; rev 99d91538b1327da933356c318dc8040335fbb66c; hash sha256-vVqZzVp0Tea27s8HDVq4SgqlbHBdZcFzNKmPFi0Yktk; }; vendorHash sha256-jrPVYFVZV9wlbik/I35W8ChcLrHlYbLAwUYU16mJLM; in (k3s.override { overrideBundleAttrs { src k3sRepo; inherit vendorHash; }; }).overrideAttrs { src k3sRepo; inherit vendorHash; }补充说明除了overrideBundleAttrs还有overrideCniPluginsAttrs与overrideContainerdAttrs两个覆盖入口定义见 builder.nixk3s --version仍会打印“基础”包传入builder.nix的k3sCommit的 commit SHA而不是实际使用的rev取决于 fork/commit 的改动范围仅用k3s.override不叠加最终派生的overrideAttrs可能就足够了如果该 commit 对应的是不同版本的 k3s务必选用正确的“基础”包如k3s_1_31.override否则构建会因版本不匹配失败错误形如Tagged version v1.33.1k3s1 does not match expected version v1.31.9[-]*当通过builder.nix添加全新 k3s 版本时注意k3sCommit参数并不用作k3sRepo的rev后者固定使用v${k3sVersion}因此还需要按上面的方式再 override 一次。集群维护与排障更改 K3s Token更换 K3s token 需要重置整个集群。重置前注意仅仅在 NixOS 配置中禁用 K3s 模块并不会停止 containerd、网络等 K3s 相关依赖。要彻底停止可以运行k3s-killall.sh脚本位于$PATH即/run/current-system/sw/bin/k3s-killall.sh该脚本由 builder.nix 从上游安装脚本裁剪生成或直接重启宿主机。多主机同步Nix 会自动将各主机同步到configuration.nix。若要同步configuration.nix的 git 仓库并在多台主机上触发nixos-rebuild switch通常使用ansible它可以自动化集群的配置下发、升级与重置。集群重置由于上游的k3s-uninstall.sh尚未被打包进 NixOS需要手动执行以下步骤重置集群在所有主机上禁用 K3sservices.k3s.enable false;重建 NixOS 配置nixos-rebuild switch。这会移除 K3s 的 service 文件但不会删除 K3s 数据。卸载 kubelet 并删除 K3s 数据KUBELET_PATH$(mount | grep kubelet | cut -d -f3); ${KUBELET_PATH:umount $KUBELET_PATH} rm -rf /etc/rancher/{k3s,node}; rm -rf /var/lib/{rancher/k3s,kubelet,longhorn,etcd,cni}使用 etcd 时还需重置 etcd先确保所有K3s 实例都已停止单个实例可能用旧的加密密钥重新播种 etcd 数据库然后在 NixOS 配置中禁用 etcdservices.etcd.enable false;重建 NixOS删除 etcd 文件并重启主机rm -rf /var/lib/etcd/重启后在 NixOS 配置中先重新启用 etcd重建并用systemctl status etcd验证服务健康再重新启用 K3s重建并用systemctl status k3s验证。etcd 与 K3s 集群将被重新搭建。推荐用 Ansible 把整套重置流程自动化。排障Raspberry Pi 无法启动若k3s.service/k3s server 无法启动并报错FATA[0000] failed to find memory cgroup (v2)可以在configuration.nix中加入以下内核参数boot.kernelParams [ cgroup_enablecpuset cgroup_memory1 cgroup_enablememory ];排障FailedKillPod 网络错误若出现以下错误KillPodSandboxError: failed to get network cbr0 cached result: decoding version from network config: unexpected end of JSON input可参考上游 K3s issue 中提供的 workaround 处理清理损坏的 CNI 网络配置缓存。GPU 直通NVIDIA前提services.k3s.enable true;已设置。启用 NVIDIA 驱动hardware.nvidia { open true; package config.boot.kernelPackages.nvidiaPackages.stable; # 按你的内核修改 nvidiaSettings true; }; # 让 nvidia 驱动被识别的小技巧 services.xserver { enable false; videoDrivers [ nvidia ]; }; nixpkgs.config.allowUnfreePackages [ nvidia-x11 nvidia-settings ];同时启用 NVIDIA 容器工具包hardware.nvidia-container-toolkit.enable true; hardware.nvidia-container-toolkit.mount-nvidia-executables true; environment.systemPackages with pkgs; [ nvidia-container-toolkit ];重建 NixOS 配置。验证 GPU 可访问nvidia-smi如果输出报错可能需要重启让驱动分配到 GPU。也可以用lspci -k确认驱动已绑定# lspci -k | grep -i nvidia 01:00.0 VGA compatible controller: NVIDIA Corporation TU106 [GeForce RTX 2060 Rev. A] (rev a1) Kernel driver in use: nvidia Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia配置 K3s 使用 NVIDIA runtime在/var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl新建文件{{ template base . }} [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.nvidia] privileged_without_host_devices false runtime_engine runtime_root runtime_type io.containerd.runc.v2向集群应用以下 RuntimeClassapiVersion: node.k8s.io/v1 handler: nvidia kind: RuntimeClass metadata: labels: app.kubernetes.io/component: gpu-operator name: nvidia重启 K3ssystemctl restart k3s.service确认 NVIDIA runtime 被 k3s 检测到grep nvidia /var/lib/rancher/k3s/agent/etc/containerd/config.toml应用 generic-cdi-plugin 的 DaemonSet它负责把 NVIDIA CDI 配置写入 kubelet 可见路径从而将 GPU 资源上报给调度器apiVersion: v1 kind: Namespace metadata: name: generic-cdi-plugin --- apiVersion: apps/v1 kind: DaemonSet metadata: name: generic-cdi-plugin-daemonset namespace: generic-cdi-plugin spec: selector: matchLabels: name: generic-cdi-plugin template: metadata: labels: name: generic-cdi-plugin app.kubernetes.io/component: generic-cdi-plugin app.kubernetes.io/name: generic-cdi-plugin spec: containers: - image: ghcr.io/olfillasodikno/generic-cdi-plugin:main name: generic-cdi-plugin command: - /generic-cdi-plugin - /var/run/cdi/nvidia-container-toolkit.json imagePullPolicy: Always securityContext: privileged: true tty: true volumeMounts: - name: kubelet mountPath: /var/lib/kubelet - name: nvidia-container-toolkit mountPath: /var/run/cdi/nvidia-container-toolkit.json volumes: - name: kubelet hostPath: path: /var/lib/kubelet - name: nvidia-container-toolkit hostPath: path: /var/run/cdi/nvidia-container-toolkit.json affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nixos-nvidia-cdi operator: In values: - enabled再给节点打上标签把#CHANGEME替换为你的节点名kind: Node apiVersion: v1 metadata: name: #CHANGEME labels: nixos-nvidia-cdi: enabled现在 GPU 容器可以这样调度spec: runtimeClassName: nvidia containers: resources: requests: nvidia.com/gpu-all: 1 limits: nvidia.com/gpu-all: 1测试 Pod完整参考配置--- apiVersion: v1 kind: Pod metadata: name: gpu-test namespace: default spec: runtimeClassName: nvidia # - 这里启用 GPU containers: - name: gpu-test image: nvidia/cuda:12.6.3-base-ubuntu22.04 command: [ /bin/bash, -c, -- ] args: [ while true; do sleep 30; done; ] env: - name: NVIDIA_VISIBLE_DEVICES value: all - name: NVIDIA_DRIVER_CAPABILITIES value: all resources: # - 这里申请 GPU requests: nvidia.com/gpu-all: 1 limits: nvidia.com/gpu-all: 1Pod 运行后验证 GPU 是否被识别kubectl exec -n default -it pod/gpu-test -- nvidia-smi成功时输出类似Thu Sep 25 04:17:42 2025 ----------------------------------------------------------------------------------------- | NVIDIA-SMI 580.82.09 Driver Version: 580.82.09 CUDA Version: 13.0 | --------------------------------------------------------------------------------------- | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | || | 0 NVIDIA GeForce RTX 2060 Off | 00000000:01:00.0 On | N/A | | 0% 36C P8 10W / 190W | 104MiB / 6144MiB | 0% Default | | | | N/A | --------------------------------------------------------------------------------------- | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | || | No running processes found | -----------------------------------------------------------------------------------------GPU 直通Intel前提services.k3s.enable true内核足够新以开箱支持你的 GPU目标驱动为i915其他驱动按需修改。作者写作时使用 Intel Arc A770 验证本指南多数内容对其他 Kubernetes 发行版同样适用对核显能力大概率同样有效。启用 Intel 驱动在 NixOS 中加入无头部署必需services.xserver.videoDrivers [ i915 ];重建配置后重启主机让驱动分配到 GPU然后用以下命令确认 GPU 使用 i915 内核驱动sudo lspci -k例如 Intel Arc A770 主机的输出❯ sudo lspci -k | grep -A 3 Arc 03:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A770] (rev 08) Subsystem: ASRock Incorporation Device 6010 Kernel driver in use: i915 Kernel modules: i915, xe安装 Node Feature Discovery (NFD)Intel 的 Kubernetes 设备插件提供 NFDNode Feature Discovery可以在节点安装了独立 GPU 且驱动正确绑定后自动发现 GPU 能力。以下命令在集群中安装 NFD假设已安装并配置好curl、jq、kubectl# 使用最新 release export LATEST_RELEASE$(curl -s https://api.github.com/repos/intel/intel-device-plugins-for-kubernetes/releases/latest | jq -r .tag_name) # 用 Kustomize 部署 kubectl apply -k https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/nfd?ref$LATEST_RELEASE kubectl apply -k https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/nfd/overlays/node-feature-rules?ref$LATEST_RELEASE kubectl apply -k https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/gpu_plugin/overlays/nfd_labeled_nodes?ref$LATEST_RELEASENFD 会自动给节点打上相关标签验证kubectl get nodes -o yaml | grep gpu.intel.com | sort -u输出示例❯ kubectl get nodes -o yaml | grep gpu.intel.com | sort -u gpu.intel.com/device-id.0300-56a0.count: 1 gpu.intel.com/device-id.0300-56a0.present: true gpu.intel.com/family: A_Series gpu.intel.com/i915: 1 gpu.intel.com/i915_monitoring: 0 nfd.node.kubernetes.io/feature-labels: gpu.intel.com/device-id.0300-56a0.count,gpu.intel.com/device-id.0300-56a0.present,gpu.intel.com/family,intel.feature.node.kubernetes.io/gpu注意gpu.intel.com/i915: 1表示同一时刻只有一个 pod 可以使用 GPU——下面有解决办法。GPU 容器调度配置spec: containers: resources: requests: gpu.intel.com/i915: 1 limits: gpu.intel.com/i915: 1允许多个 Pod 共享 GPU默认配置下只有一个 pod 能使用 GPU。要让多个 pod 共用可应用如下 Kustomize patchpatches: - target: kind: DaemonSet name: intel-gpu-plugin patch: | - op: add path: /spec/template/spec/containers/0/args value: - -shared-dev-num10或者手动修改intel-gpu-pluginDaemonSet让插件以-shared-dev-num10或你期望的最大 pod 数运行apiVersion: apps/v1 kind: DaemonSet metadata: name: intel-gpu-plugin spec: spec: containers: - args: - -shared-dev-num10验证已生效kubectl get nodes -o yaml | grep gpu.intel.com/i915 | sort -u例如配置为最多 10 个 pod 时输出❯ kubectl get nodes -o yaml | grep gpu.intel.com/i915 | sort -u gpu.intel.com/i915: 10测试 Pod完整参考配置--- apiVersion: v1 kind: Pod metadata: name: intel-gpu-test namespace: default spec: containers: - name: intel-gpu-test image: docker.io/ubuntu:24.04 command: [ /bin/bash, -c, -- ] args: [ while true; do sleep 30; done; ] resources: requests: gpu.intel.com/i915: 1 limits: gpu.intel.com/i915: 1Pod 运行后验证 GPU 是否可用kubectl exec -n default -it pod/intel-gpu-test -- ls /dev/dri可用时输出类似❯ kubectl exec -n default -it pod/intel-gpu-test -- ls /dev/dri by-path card1 renderD128测试完删除 Pod以免占用 GPU 配额kubectl delete -n default pod/intel-gpu-test存储方案示例以下是一些存储机制在 NixOS Kubernetes/k3s 场景下的特殊配置考量。LonghornLonghorn 所需的 NixOS 配置environment.systemPackages [ pkgs.nfs-utils ]; services.openiscsi { enable true; name ${config.networking.hostName}-initiatorhost; };Longhorn 容器对 NixOS 的路径有兼容问题解决方法是覆盖 PATH 环境变量PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin用 Kyverno 策略批量修复 NixOS 上的 Longhorn 容器通过 ConfigMap ClusterPolicy 给longhorn-system命名空间下所有 Pod 注入 PATH--- apiVersion: v1 kind: ConfigMap metadata: name: longhorn-nixos-path namespace: longhorn-system data: PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin --- apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: longhorn-add-nixos-path annotations: policies.kyverno.io/title: Add Environment Variables from ConfigMap policies.kyverno.io/subject: Pod policies.kyverno.io/category: Other policies.kyverno.io/description: - Longhorn invokes executables on the host system, and needs to be aware of the host systems PATH. This modifies all deployments such that the PATH is explicitly set to support NixOS based systems. spec: rules: - name: add-env-vars match: resources: kinds: - Pod namespaces: - longhorn-system mutate: patchStrategicMerge: spec: initContainers: - (name): * envFrom: - configMapRef: name: longhorn-nixos-path containers: - (name): * envFrom: - configMapRef: name: longhorn-nixos-path ---NFSNFS 所需的 NixOS 配置boot.supportedFilesystems [ nfs ]; services.rpcbind.enable true;Rook/Ceph支持 Rook/Ceph 需要在 NixOS 中加入以下内核模块配置boot.kernelModules [ rbd ];ZFS ContainerD 支持可以为 k3s 内嵌的 ContainerD 启用 ZFS snapshotter但需要把一个数据集挂载到 k3s 使用的特定路径/var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.zfs例如$ zfs create -o mountpoint/var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.zfs zpool name/containerd然后通过--snapshotter标志让 k3s 使用 zfsservices.k3s { ... extraFlags [ --snapshotterzfs ]; };使用外部 ContainerdK3s 自带 containerd 二进制但有时需要改用外部 containerd只需几行配置。配置 Containerd{ virtualisation.containerd { enable true; settings.plugins.io.containerd.grpc.v1.cri.cni { bin_dir /var/lib/rancher/k3s/data/current/bin; conf_dir /var/lib/rancher/k3s/agent/etc/cni/net.d; }; # 可选让 containerd 使用 k3s 的 pause 镜像 settings.plugins.io.containerd.grpc.v1.cri { sandbox_image docker.io/rancher/mirrored-pause:3.6; }; }; }配置 K3s{ services.k3s { enable true; extraFlags [ --container-runtime-endpoint unix:///run/containerd/containerd.sock ]; }; }导入容器镜像K3s 提供services.k3s.images选项在启动时导入容器镜像但该选项不适用于外部 containerd。此时可用ctr -nk8s.io image import /var/lib/rancher/k3s/agent/images/*导入注意必须设置k8s.io命名空间镜像才对集群可见。版本管理为什么 Nixpkgs 同时维护多个 K3s 版本K3s、Kubernetes 等集群软件有一个特性无法原子化更新。Nixpkgs 中的大多数软件如 bash可以在nixos-rebuild switch时一次性替换而 K3s/Kubernetes 通常运行在多台 NixOS 机器上每台机器独立更新因此不同版本的包与 NixOS 模块在更新过程中必须通过“临时版本偏移”version skew互相保持兼容。上游 Kubernetes 项目在其版本偏移策略文档中说明了支持的组件升级顺序Nixpkgs 侧的目标是维护一条不违反该策略的合法“升级路径”。Patch 版本支持生命周期K3s 构建于 K8s 之上发布节奏与支持窗口类似通过 cherry-pick K8s 补丁实现因此 Nixpkgs 假定 K3s 的支持生命周期与上游 K8s 一致大约每 4 个月发布一个新 Kubernetes 版本每个版本支持略超过 1 年。Nixpkgs 中的版本布局nixos-unstable在nixos-unstable分支上维护两类包标准k3s包随上游 k3s 新版本发布而更新版本化包如k3s_1_34、k3s_1_35等遵循上述补丁发布支持生命周期在上游 EOL 或早于nixos-stable中的当前k3s包时从nixos-unstable移除。当前仓库 default.nix 中维护的版本包括k3s_1_34、k3s_1_35、k3s_1_36、k3s_1_37每个版本目录如 1_37/内含versions.nix、chart-versions.nix与images-versions.json分别描述版本 git tag、commit hash、内嵌 chart 版本与离线镜像清单。NixOS 发行版中的版本策略NixOS 发行版24.05、24.11 等在其支持生命周期内应尽量避免弃用软件或大版本升级因此每个 NixOS 发行版发布时通常只携带一个k3s 版本。例如 NixOS 24.05 的k3s包在其整个生命周期内指向k3s_1_30。但这与“用户能在两个稳定版之间平滑升级而不违反版本偏移策略”的诉求冲突若 24.05 的 k3s 是 1.30.x、24.11 是 1.32.x用户需要在升级到下一个 NixOS 稳定版之前先把 k3s 升到 1.32.x。为此维护者会把k3s_1_31、k3s_1_32等中间版本从nixos-unstablebackport 到 24.05。这样 24.05 用户可以先本地升级到k3s_1_31再升到k3s_1_32例如把services.k3s.package从k3s指向k3s_1_31升级集群再重复该过程跨版本升级。三个 NixOS 发行版的示例布局NixOS 23.11k3s/k3s_1_27发行版本补丁已 backportk3s_1_28Backportedk3s_1_29Backportedk3s_1_30BackportedNixOS 24.05k3s/k3s_1_30发行版本补丁已 backportk3s_1_31Backportedk3s_1_32BackportedNixOS 24.11k3s/k3s_1_32发行版本补丁已 backport包维护面向维护者的流程NixOS 发行版维护节奏Pre-Release下一个发行版 breaking change 窗口关闭前nixos-unstable确保k3s指向最新的版本化包nixos-unstable确保 release notes 最新nixos-unstable移除在下一个 NixOS 稳定版 EOL 之前就会上游 EOL 的 k3s 版本需按下方流程添加弃用通知。Post-Release对 k3s 的 major/minor 版本nixos-unstable创建新版本化 k3s 包nixos-unstable更新 k3s 别名指向新版本化包nixos-unstable添加 NixOS release note说明被弃用 K3s 包的移除、来自 Kubernetes/K3s 项目的迁移信息nixos-stablebackport 该版本化包对既有包的 patch 版本nixos-unstable更新包版本流程见下nixos-stablebackportnixos-unstable上的更新。Patch 升级流程可以使用包目录根部的 update-script.sh。例如升级 k3s 1.30.x在 nixpkgs git 仓库根目录运行./pkgs/applications/networking/cluster/k3s/update-script.sh 30升级其他版本只需把30替换为对应的 minor 版本号。若脚本失败优先修复脚本无法修复时请提交 issue附上所用命令与观察到的失败信息。RyanTM bot 可自动执行 patch 升级更新日志可在对应版本的 URL 查看。包移除流程包移除策略与时间线遵循版本管理文档中的补丁支持生命周期。移除版本化 k3s 包需提交 PR 完成以下事项删除包含 chart 与包版本文件的版本目录如./1_30/从 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。变更请求评审清单评审 k3s 包的快速检查表Go 编译器版本是否按该版本go.mod文件固定——更新脚本不会固定也不会修改 Go 版本passthru.tests是否在所有支持架构linux-x86_64、aarch64-linux上通过本地可在 nixpkgs 根目录、升级分支上运行nix build .#k3s_1_29.passthru.tests.{etcd,single-node,multi-node}把 29 换成被测版本nix 构建日志或测试日志中是否有异常这些测试在 builder.nix 的passthru.tests中按k3s_major_minor命名自动映射到nixosTests.k3s的对应版本测试etcd、single-node、multi-node 等这也是验证版本偏移兼容性的自动化保障。结语从单节点起步、到内嵌 etcd 的多节点 HA、再到 NVIDIA/Intel GPU 直通与各类存储方案Nixpkgs 为 K3s 提供了完整且可复现的部署路径而多版本并行与严格的升级路径管理则保证了跨主机、跨 NixOS 发行版升级时不会破坏集群兼容性。本文涉及的配置示例、排障步骤与维护流程均来自 pkgs/applications/networking/cluster/k3s/README.md 及其 docs 目录你可以在仓库中继续查阅 USAGE.md、CLUSTER_UPKEEP.md、VERSIONING.md、PKG_UPKEEP.md 及各 GPU/存储示例获取第一手维护与排障细节。赞分享包管理器操作系统【免费下载链接】nixpkgsNix Packages collection NixOS项目地址https://gitcode.com/GitHub_Trending/ni/nixpkgs点击查看免费下载相关推荐GetQzonehistory扫码一次把QQ空间历史说说完整备份到本地6张表格加网页版全带走GetQzonehistory扫码一次把QQ空间历史说说完整备份到本地6张表格加网页版全带走 深夜翻手机相册翻出一张毕业时的合照。照片还在当时配的那段网页爬虫数据分析nixpkgs 中 k3s 包维护指南版本化升级、补丁发布与生命周期管理nixpkgs 中 k3s 包维护指南版本化升级、补丁发布与生命周期管理 本指南以 K3s 包维护文档 https://link.gitcode.com/i/包管理器操作系统Alluxio集群部署与运维指南从单节点到生产环境Alluxio集群部署与运维指南从单节点到生产环境 前言 Alluxio作为内存加速层在现代数据架构中扮演着重要角色。本文将全面介绍如何在集群环境中部署和运维存储分布式文件系统缓存大数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考