Clone of https://github.com/NixOS/nixpkgs.git (to stress-test knotserver)
1# RKE2 Version 2 3RKE2, Kubernetes, and other clustered software has the property of not being able to update 4atomically. Most software in nixpkgs, like for example bash, can be updated as part of a 5`nixos-rebuild switch` without having to worry about the old and the new bash interacting in some 6way. RKE2/Kubernetes, on the other hand, is typically run across several machines, and each machine 7is updated independently. As such, different versions of the package and NixOS module must maintain 8compatibility with each other through temporary version skew during updates. The upstream Kubernetes 9project documents this in their 10[version-skew policy](https://kubernetes.io/releases/version-skew-policy/#supported-component-upgrade-order). 11 12Within nixpkgs, we strive to maintain a valid "upgrade path" that does not run afoul of the upstream 13version skew policy. 14 15> [!NOTE] 16> Upgrade the server nodes first, one at a time. Once all servers have been upgraded, you may then 17> upgrade agent nodes. 18 19## Release Channels 20 21RKE2 has two named release channels, i.e. `stable` and `latest`. Additionally, there exists a 22release channel tied to each Kubernetes minor version, e.g. `v1.32`. 23 24Nixpkgs follows active minor version release channels (typically 4 at a time) and sets aliases for 25`rke2_stable` and `rke2_latest` accordingly. 26 27Patch releases should be backported to to the latest stable release branch, however, new minor 28versions are not backported. 29 30For further information visit the 31[RKE2 release channels documentation](https://docs.rke2.io/upgrades/manual_upgrade?_highlight=manua#release-channels). 32 33## EOL Versions 34 35Approximately every 4 months a minor RKE2 version reaches EOL. EOL versions should be removed from 36`nixpkgs-unstable`, preferably by throwing with an explanatory message in 37`pkgs/top-level/aliases.nix`. With stable releases, however, it isn't expected that packages will be 38removed. Instead we set `meta.knownVulnerabilities` for stable EOL packages, like it is also done 39for EOL JDKs, browser engines, Node.js versions, etc. 40 41For further information on the RKE2 lifecycle, see the 42[SUSE Product Support Lifecycle page](https://www.suse.com/lifecycle#rke2).