harvester-upgrade

Solid

Plan and run a controlled, COMMUNITY-edition Harvester HCI upgrade off an EOL line up to latest stable — the no-skip minor ladder (1.5→1.6→1.7→1.8; embedded RKE2/KubeVirt/Longhorn/SLE-Micro ride along), gated at each hop on first upgrading the EXTERNAL Rancher + a matching Harvester UI-extension (1.6↔Rancher 2.12, 1.7↔2.13, 1.8↔2.14). Covers air-gapped version detection, why node-upgrade order is NOT operator-choosable (forced serial; the pause knob is v1.7.0+ only) and how to protect VM-hosted control planes anyway via anti-affinity spread + N+1 live-migration, making self-managed RKE2 guests Harvester-aware (cloud-provider, CSI, qemu-guest-agent), per-hop breaking changes (wicked→NetworkManager, Intel NIC rename, DHCP IP churn), the enforced pre-flight health gates, and the no-downgrade backup/rollback reality. Companion to k8s-components-checker and rancher-upgrade.

DevOps & Infrastructure 3 stars 1 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 79/100

Stars 20%
20
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# harvester-upgrade Plan, sequence, and de-risk a **community-edition Harvester HCI** upgrade across a real fleet — typically off an **EOL line** (1.5.x) up to the latest *settled* stable. The hard part is almost never the ISO/UI upgrade click. It is the **coordination**: Harvester is one bundle whose embedded RKE2, KubeVirt, Longhorn, SLE Micro, and Rancher pairing all move together, the upgrade controller **picks its own node order**, and the workloads that matter most — VM-hosted Kubernetes control planes — must stay quorate while each host reboots underneath them. **Community editions only.** SUSE sells "SUSE Virtualization" (Prime) as a paid *support subscription on the same bits* — it is **not** a different artifact set, and **patch releases are community-downloadable** (House Rule #1). Flag Prime-only support claims; never build a plan on them. ## Companion to k8s-components-checker and rancher-upgrade — who owns what This skill is the Harvester-side upgrade-methodology companion in the same trio (`rancher-upgrade` SKILL.md explicitly defers Harvester host→guest coordination here). Respect the boundary to avoid drift: | Question | Skill | |----------|-------| | Harvester↔RKE2↔Rancher *pairing numbers*, Node-Driver ranges, per-minor compat | **k8s-components-checker** — `references/compat/harvester.md` is the source of truth. **Cite it; don't restate.** | | Is a component (Cilium, Rook, …) OK on k8s 1.NN on one cluster? | **k8s-components-checker** (per-cluster ver...

Details

Author
air-gapped
Repository
air-gapped/skills
Created
3 months ago
Last Updated
yesterday
Language
Python
License
MIT

Integrates with

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

rancher-upgrade

Plan and sequence COMMUNITY-edition Rancher upgrades across air-gapped multi-cluster fleets — a management/"hosting" Rancher cluster plus the downstream RKE2/K3s clusters it provisions. Covers the community release model (2.11→2.14, community-vs-Prime cadence, EOL), the Kontainer Driver Metadata (KDM) matrix deciding which downstream k8s minors each Rancher version can manage (and the stranding risk when a host-Rancher bump outruns its sub-clusters), cross-cluster upgrade ordering, the embedded-CAPI→Rancher-Turtles migration, Fleet coupling, cert-manager/Helm/backup prerequisites, backup- restore-operator + etcd rollback, and the air-gapped upgrade procedure (which images/charts/KDM to mirror). Assumes the Helm-on-Kubernetes install. Community editions only; Prime content excluded. Companion to k8s-components-checker, which owns the management-cluster k8s compatibility verdict; this skill owns the upgrade methodology and downstream coordination.

3 Updated yesterday
air-gapped
DevOps & Infrastructure Solid

k8s-components-checker

Survey an RKE2 community cluster against an embedded compatibility registry of 19 stack components and produce a verdict for upgrade-readiness, drift-review, and version-skew questions. Components: RKE2, Rancher, Harvester, Cilium, Tetragon, cert-manager, Kyverno, KEDA, Argo CD, Harbor, Traefik, Rook, Ceph, OpenEBS, GitLab, ECK, Zalando postgres-operator, Grafana Mimir, NVIDIA GPU Operator. Works air-gapped — compatibility data lives in `references/compat/`. Surveys run via `kubectl` + `helm` + `pluto` + the apiserver `apiserver_requested_deprecated_apis` metric from the operator's workstation. Community editions only — Prime/EE-gated content is ignored. NOT for installing components, NOT for executing upgrades, NOT for tracking per-cluster running state (the registry is methodology, not inventory).

3 Updated yesterday
air-gapped
DevOps & Infrastructure Solid

rancher-logging-exit

Migrate off the Rancher-bundled `rancher-logging` chart (cattle-logging-system, rancher/mirrored-kube-logging-* images) to the upstream kube-logging logging-operator ≥6.7.0 — air-gap-first. Rancher 2.11 through 2.15-dev all bundle a frozen operator 4.10.0 that is inside the affected range of CVE-2026-54680 (CVSS 9.9 config-injection RCE, no SUSE fix) — so the exit is security-urgent. Covers the maintainer-endorsed helm-release-secret strategy (near-zero gap; NOT `helm uninstall rancher-logging-crd`, which cascade-deletes every CR and the data plane), CR compatibility 4.10→6.7 (silent field pruning), server-side CRD apply (828KB CRDs), buffer-PVC preservation, air-gap image/chart mirroring, rollback, and stale-CRD debris cleanup.

3 Updated yesterday
air-gapped