How-torke2spray

Operate the cluster lifecycle

Check health, scale, upgrade, snapshot, recover, and remove nodes from an RKE2 cluster.

Updated Verified SourceEdit this page

Core summary

  • Every change begins with an Inventory review, Vault check, preflight, and current health check.
  • Add workers through scale.yml and add servers one at a time through cluster.yml.
  • Upgrades sequence cordon, drain, release replacement, readiness verification, and uncordon.
  • Recovery and removal require topology-specific prerequisites and exact confirmation.
  • Do not treat CNI or cluster-CIDR changes as ordinary convergence of an existing cluster.

Follow the common execution sequence

  1. Review Inventory and inline Vault diffs

  2. Validate local Vault structure and remote topology

    make inventory-vault-check
    make inventory-preflight
  3. Preserve the current cluster state

    make cluster-health
  4. Confirm targets and scope, then run the lifecycle

  5. Verify completion with the same health checks

Select the operation entrypoint

TaskPlaybook or targetRKE2 behavior
Install or reconvergecluster.yml / make cluster-convergeConfigure servers and agents, then verify readiness
Add workerscale.yml --limit=<worker>Converge only the selected agent batch
Add servercluster.yml --limit=<server>Join one server at a time
Upgradeupgrade-cluster.yml / make cluster-upgradeSequential drain and release replacement
Healthmake cluster-healthRead-only service, API, Node, and etcd checks
Snapshotmake cluster-snapshotCreate an RKE2 embedded-etcd snapshot
Recoveryrecover-control-plane.ymlRecover embedded etcd from a selected snapshot
Remove noderemove-node.ymlDrain, verify membership, and uninstall RKE2
Reset allreset.ymlStop services and run the official uninstaller

Enforce destructive-operation boundaries

  • Remove only one server at a time and leave at least two servers.
  • Do not remove the bootstrap server without a separate lifecycle-identity review.
  • With an external load balancer, first remove the server from the 80, 443, 6443, and 9345 backends.
  • Do not use recover-control-plane.yml for an external datastore.
  • Never bypass confirmations for reset, remove, recover, or AddOn pruning.

Operational boundary

Off-host snapshot copies and long-term retention belong to a separate backup system; creating a local snapshot alone does not complete disaster recovery.

Conclusion

  • Preserve evidence from checks before and after each change instead of treating the command as the whole operation.
  • When a prerequisite is unclear, check Compatibility first.