Run any Skill in Manus with one click

rancher-upgrade

Stars3

Forks1

UpdatedMay 30, 2026 at 22:00

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) downstream- Kubernetes support matrix that decides 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). Community editions only; Prime-gated content is flagged and excluded. Companion to k8s-components-checker, which owns the management-cluster k8s compatibility verdict; this skill owns the upgrade methodology and downstream coordination.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

air-gapped

air-gapped/skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Network and Computer Systems AdministratorsComputer and Mathematical Occupations·SOC 15-1244

File Explorer

9 files

SKILL.md

readonly

More from this repository

same repository

vllm-deployment

air-gapped/skills

Use this skill when authoring, reviewing, or fixing a vLLM Kubernetes manifest, Docker/Podman pod, or OpenShift ServingRuntime — even when the user does not say "vllm". Triggers on: lab cluster performance practices, cache mount + survival across pod restarts (/root/.cache, VLLM_CACHE_ROOT, TORCHINDUCTOR_CACHE_DIR, TRITON_CACHE_DIR, "do we have caches saved"), HF_TOKEN secret in pod env, liveness + readiness probe tuning (initialDelaySeconds, failureThreshold, "pod takes 12 min to boot"), serve_args review, --enforce-eager rationale, MoE deployment ("ep2 dp2", --enable-expert-parallel, expert-parallel sizing), TP/PP sizing, ConfigMap parser-plugin mount, image tag selection, cold-boot reduction, multi-node LWS + Ray, control planes (llm-d, production-stack, AIBrix, NVIDIA Dynamo, KServe), KEDA autoscaling, GAIE routing, disaggregated prefill/decode (Nixl/Mooncake/LMCache/MORI-IO), RHAIIS on OpenShift (SCC, arbitrary UID, Routes 60s, ModelCar, air-gapped). Lead with operator intent, not vendor names.

2026-07-183

skill-improver

air-gapped/skills

Autoresearch loop for Claude Code skills — greedy keep/discard hill climbing on a 10-dimension quality rubric, with blind subagent validation for self-scoring bias, plus a `freshen` mode that probes external references (release notes, docs, deprecation signals) and applies verified updates, plus a `trigger` mode that measures and tunes the skill's frontmatter description until it reliably fires when it should and stays silent when it shouldn't (60/40 train/test split, 3 runs/query, blinded test scores).

2026-07-183

redis-to-valkey

air-gapped/skills

Migrate Redis deployments (especially Bitnami Redis Helm charts in Sentinel HA mode) to Valkey on Kubernetes, including fully air-gapped clusters. Core knowledge: the RDB-version wall (Valkey replicates/loads only from Redis ≤ 7.2.x; Redis 7.4+ writes RDB v12 which Valkey rejects; Valkey 9 writes its own v80 — a one-way door), the two transfer layers (version-bound REPLICAOF/DUMP-RESTORE vs version-agnostic logical replay with RedisShake or rdb-cli), a side-by-side cutover runbook, Valkey chart selection (groundhog2k / CloudPirates / official valkey-io tradeoffs), Bitnami-redis→valkey values translation, consumer-app reconnection (Sentinel discovery, master-set names, frozen redis_version 7.2.4), Prometheus exporter continuity, air-gap tool/image mirroring, and Argo CD source rewiring away from charts.bitnami.com. Part of the bitnami-exit suite.

2026-07-183

airgap-vetting

air-gapped/skills

Vet an open-source product for air-gap readiness BEFORE adoption. Answers eight questions — telemetry, does-opt-out-actually-work, proxy-in-disguise over a hosted API, runtime downloads, custom-CA support, feature-level content egress / offline degradation, day-two sustainment (feed mirroring, staleness), and a 4-grade verdict (air-gap-native / possible-with-mirror / proxy-in-disguise / no-go). Two-pass: static grep of source + container image (bundled fingerprint tables work offline), then an optional dynamic harness (--network=none, egress deny+log, mitmproxy CA injection, faketime). Writes AIRGAP-VETTING.json + .md. Use for any "should we adopt X?" question in a disconnected environment, not just when the user says "air gap".

2026-07-183

triage

air-gapped/skills

Triage a batch of raw security findings. Verify each is real, collapse duplicates, re-rank by impact-on-asset x exploitability, and tag with an owner. Takes a directory or file of scanner output and writes TRIAGE.json + TRIAGE.md sorted by what actually needs engineering attention. Use when asked to "triage findings", "validate scanner output", "prioritize vulns", or "review the backlog". Runs interactively by default; pass --auto to skip the interview.

2026-07-093

patch

air-gapped/skills

Generate candidate fixes for verified security findings. Consumes TRIAGE.json (preferred), VULN-FINDINGS.json, or an execution-harness results directory. Static-analysis input gets a per-finding patch subagent + an independent reviewer and is written as inert diffs for human review; results-directory input from an external execution harness (the defending-code reference pipeline, if installed) is delegated to its verified build→reproduce→regress→re-attack patch ladder. Writes PATCHES/bug_NN/{patch.diff,patch_result.json}, PATCHES.md, and PATCHES.json. Use when asked to "fix the findings", "patch these vulns", "generate fixes", or "close the loop on triage".

2026-07-053

name	rancher-upgrade
description	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) downstream- Kubernetes support matrix that decides 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). Community editions only; Prime-gated content is flagged and excluded. Companion to k8s-components-checker, which owns the management-cluster k8s compatibility verdict; this skill owns the upgrade methodology and downstream coordination.
when_to_use	Use whenever the user mentions "rancher upgrade", "upgrade Rancher", "Rancher 2.X to 2.Y", "KDM", "which k8s can my Rancher manage", "downstream cluster stranded", "Rancher Turtles migration", "embedded cluster-api removed", "Fleet Helm v4", "Rancher air-gap upgrade", or "rancher-backup / cert-manager prerequisite" — or plans an upgrade of a Rancher management cluster and the downstream clusters under it, even without naming KDM or Turtles. NOT for Harvester or the single-cluster component-compat verdict (use k8s-components-checker).

rancher-upgrade

Plan, sequence, and de-risk a community-edition Rancher upgrade across a real fleet: a management ("hosting") cluster and the downstream RKE2/K3s clusters it provisions. The hard part of a Rancher upgrade is almost never the helm upgrade itself — it's the cross-cluster coordination: a management-cluster Rancher bump silently changes which downstream Kubernetes versions the fleet can run, and getting the order wrong strands sub-clusters or forces a rebuild.

Community editions only. SUSE Rancher Prime backports, Prime-only patches, and Prime support matrices are out of scope — flag them when they appear, never build a plan on them. House Rule #1.

Companion to k8s-components-checker — who owns what

This skill is the upgrade-methodology companion to k8s-components-checker (same repo), mirroring the argo-cd-apps ↔ compat/argo-cd.md split. The boundary is load-bearing — respect it to avoid drift:

Question	Skill
"Is Rancher version X compatible with the management cluster's k8s minor?"	k8s-components-checker — `references/compat/rancher.md` is the single source of truth for the mgmt-cluster k8s window per Rancher minor. Cite it; never restate those numbers here.
"Is component Y (Cilium, Rook, …) OK on k8s 1.NN on one cluster?"	k8s-components-checker (per-cluster verdict)
"How do I plan/sequence a Rancher version upgrade, and what happens to my downstream clusters?"	this skill
"Which downstream RKE2/K3s k8s minors can Rancher 2.X manage?" (KDM)	this skill
Harvester host→guest upgrade coordination	neither yet — a separate `harvester-upgrade` skill (planned). Cross-reference only.

The mental model — two coupled axes

A Rancher fleet upgrade moves on two axes that are decoupled but ordered:

Management-cluster axis — the k8s minor the Rancher server itself runs on, and the Rancher version. (k8s window → cite compat/rancher.md.)
Downstream axis — which RKE2/K3s k8s minors Rancher can provision and manage, governed by Kontainer Driver Metadata (KDM), NOT by the management cluster's own k8s version.

The rule that ties them: introducing a downstream k8s minor requires upgrading Rancher first; downstream patch upgrades do not. So the management Rancher always moves before any downstream minor bump — and a trailing downstream cluster can fall out of support when the host Rancher rolls forward. This is the single most common way a fleet upgrade goes wrong. See references/kdm-downstream-matrix.md.

Workflow

1. Establish the change set and the fleet shape

Versions: current Rancher minor+patch, target Rancher minor. Get this from the cluster (helm list -A -n cattle-system | grep rancher), not from memory.
Fleet shape: does this Rancher actually provision downstream clusters? kubectl get clusters.cluster.x-k8s.io -A (populated = real fleet; empty = standalone mgmt cluster — the CAPI/Turtles migration is then a near-non-event). kubectl get clusters.provisioning.cattle.io -A — any row whose name ≠ local is a downstream cluster.
Air-gap? If the registry is internal-mirror-only, the air-gap procedure (what to mirror) applies — references/air-gap-procedure.md. (Direct-pull clusters skip mirroring entirely.)
Kubeconfig path: if your kubeconfig is Rancher-proxied (server contains /k8s/clusters/), switch to a Rancher-independent admin kubeconfig BEFORE upgrading — helm upgrade of the rancher release restarts the proxy pods and severs the API mid-apply. references/prereqs-and-ordering.md § Pre-flight.

2. Compute the upgrade path (no minor skipping)

The only supported path between minors is latest-patch-of-current-minor → latest-patch-of-next- minor, one minor at a time (2.11→2.12→2.13→2.14; never 2.11→2.14). Intra-minor patch jumps are fine. Ground the actual latest patch of each minor via gh (House Rule #8 below) — don't assert a patch from memory.

3. For each minor step, run the pre-flight → upgrade → post-flight runbook

The per-minor breaking changes and the ordered runbook live in references/per-minor-runbook.md. Prerequisites common to every step (cert-manager window, Helm floor, mandatory backup, RKE1 sweep, API aggregation layer) and the cross-cluster ordering + rollback floor are in references/prereqs-and-ordering.md.

4. Coordinate the downstream clusters

Before bumping the host Rancher, check every downstream cluster's k8s minor against the target Rancher's KDM window (references/kdm-downstream-matrix.md). Lift any trailing downstream into the new window first, or it loses manageability after the host upgrade. After the host upgrade (which ships a new KDM branch), the newly-unlocked downstream minors become selectable — bump downstreams then.

5. Produce the plan

Emit an ordered plan: per-minor-step pre-flight gates, the upgrade command (air-gap variant if applicable), post-flight verification, and the downstream-coordination steps interleaved at the right points. Cite the reference + grounded version for every specific claim. Recognizable shape:

<cluster/fleet> — Rancher <current> → <target>   (path: <minor steps, no skips>)

prerequisites  - cert-manager <window> · Helm <floor> · RKE1 sweep · BRO backup + etcd snapshot
downstream     - <cluster>: k8s <ver> — <in target's KDM window | lift to ≥X BEFORE host upgrade>
                 source: references/kdm-downstream-matrix.md
per step (×N)  1. pre-flight gates  2. upgrade mgmt Rancher  3. post-flight  4. bump downstream
blockers       - <one-way rollback / known regression / Prime-gated path>  source: references/<file>.md

Every cited version is cluster-reported or freshly gh-grounded (House Rule #3), never from memory; target versions follow look-ahead (House Rule #4).

House rules (encode into every plan)

Community editions only. Flag Prime-gated versions/patches/features; never plan on them. The reliable community-vs-Prime signal is the GitHub release-notes first line — see references/lifecycle.md.
Cite, don't restate, the mgmt-cluster k8s window. That lives in k8s-components-checker/references/compat/rancher.md. Pointing at it keeps the two skills from drifting.
Never invent versions; ground or abstain (House Rule #8 lineage). k8s windows and KDM mechanics are methodology the skill states. Specific release/patch numbers — "latest 2.13 patch", "Turtles version on 2.14", "BRO chart for 2.12" — are volatile and the #1 fabrication risk. State a specific version only if it is cluster-reported, freshly grounded via gh, or explicitly marked UNVERIFIED. Grounding method (anti-confirmation): anchor on gh api repos/rancher/rancher/releases/latest, enumerate-and-derive the real latest patch, never ask "does vX.Y.Z exist?" (existence/list queries get rubber-stamped). gh must be run with valid auth from the operator's workstation — anonymous is 60 requests/hour and exhausts almost immediately on an enumeration sweep (gh auth status first). Repo map + protocol: references/lifecycle.md § Grounding.
Look-ahead version targeting. When recommending any target version, pick the one that covers the operator's next planned hop too, not the bare immediate minimum — a version sitting at its own support ceiling forces an avoidable second upgrade. (Same rule as k8s-components-checker House Rule #9.)
Management Rancher upgrades BEFORE downstream k8s minor bumps, always. And no minor skipping on the Rancher axis. Violating either is the classic fleet-stranding / rebuild path.
Back up before every step. An RKE2 etcd snapshot of the management cluster is the real rollback floor — the 2.14 CAPI-v1beta2 boundary is one-way without it. Add a backup-restore-operator backup if BRO is installed; many community installs have none, so don't block on it (substitute targeted resource exports — Rancher/Fleet objects + the auth AuthConfig & secrets). See references/prereqs-and-ordering.md § Backup & rollback.

Decision guide

Task	Read
Community vs Prime, cadence, EOL, latest-patch grounding, `gh` repo map	`references/lifecycle.md`
Which downstream k8s a Rancher minor can manage; stranding; air-gap KDM mirror	`references/kdm-downstream-matrix.md`
cert-manager / Helm / backup prereqs, cross-cluster ordering, etcd rollback	`references/prereqs-and-ordering.md`
embedded-CAPI→Turtles migration, CAPRKE2/CAAPF, Fleet per-minor + Helm v4	`references/capi-turtles-fleet.md`
Air-gapped upgrade: what to mirror, `helm upgrade` flags, downstream RKE2 SUC	`references/air-gap-procedure.md`
Per-minor (2.11→2.14) breaking changes + ordered pre/upgrade/post runbook	`references/per-minor-runbook.md`

All version specifics in the references were grounded via gh on the date stamped in each file. Re-ground per House Rule #8 only if that stamp is stale (≳1–2 weeks) — same-day re-grounding is wasted churn the operator will (rightly) push back on; don't present it as an unconditional step.