Repository navigation
docs: add outage expectation, order and gateway node upgrade to upgrade page - #356
pau-hedgehog wants to merge 1 commit into
Conversation
…de page Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Pau Capdevila <pau@githedgehog.com>
|
🚀 Deployed on https://preview-356--hedgehog-docs.netlify.app |
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
No unresolved review issues were identified.
Review effort: Lite
Findings: None
What changed in this PR
Updates the upgrade guide with outage expectations, control-node-first ordering, gateway upgrade steps, and post-upgrade checks.
Changes:
- Documents gateway traffic interruption during upgrades.
- Adds gateway package upgrade instructions.
- Adds node and pod readiness verification.
| File | Summary |
|---|---|
docs/install-upgrade/upgrade.md |
Documents gateway upgrades, outage expectations, and post-upgrade checks. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
The page doesn't say whether the gateways should be upgraded one at a time or both together. I did one at a time in my test, but I didn't compare the two. I'm also not sure what the page should say about restarting a gateway. The recipe swaps the k3s binary but leaves the running k3s agent alone, so the cluster keeps reporting the old version for that node until the agent restarts. The reboot after the Flatcar update, which the page describes for the control node, isn't covered for gateways. |
The upgrade page now tells readers to plan for an outage during the upgrade: traffic through the gateways can be interrupted while the gateway components restart during the control node upgrade. It also says the control node is upgraded first, then the gateway nodes. A new "Upgrade gateway nodes" section describes the steps for a gateway node and what to check afterwards (node
Ready, gateway podsRunning), with example output.