Upgrades & Lifecycle
ServerMind decides whether, when and in what order a cluster moves to a new Kubernetes version, while Cluster API, kubeadm or your provider does the work. It tells you what will break before anything moves, and confirms the result afterwards.
Before You Upgrade
Readiness scan
Blocks on NotReady nodes, kubelet skew past n-3, PodDisruptionBudgets that cannot be satisfied and undeclared encryption config. One minor at a time.
Drain preview
Strictly read-only. Shows PDB headroom, local storage, Services that would lose every ready endpoint and whether pods can reschedule. It never calls the Eviction API.
Deprecated APIs
Scanned every 15 minutes and kept for 30 days, attributed to the workload and field manager using them. Readable even while the cluster is down.
Apiserver flag drift
Finds kube-apiserver flags that kubeadm upgrade would drop. A missing encryption-provider-config is flagged critical. Declare them after a preview.
Support window
The newest Kubernetes minor and the four before it. Targets outside the window are refused; older clusters can still be imported to upgrade them.
During the Upgrade
- Cluster API clusters: the hub hands the upgrade to Cluster API and follows the control plane, then the workers
- kubeadm, k3s and managed clusters: the hub waits for the operator, confirms the apiserver reached the target, then runs post-upgrade health checks
- Each stage has a time budget, so a stalled upgrade fails visibly instead of hanging
- Pause or cancel eligible runs; revert is available on Cluster API clusters
- Live upgrade logs keep streaming while a control-plane node replaces its own apiserver
- An offline cluster is skipped until it reconnects, with no phase churn
ServerMind is the upgrade control plane, not the upgrade mechanism. There is no control-plane rollback for kubeadm, k3s or RKE2 clusters, and the console does not offer one.
Ingress-nginx to Gateway API
- ingress-nginx was archived on 24 March 2026: no further releases or CVE patches
- Every Ingress is graded translatable, needs review or blocked, following ingress2gateway
- A fleet view totals readiness across clusters, with a work queue of blocking annotations
- HTTPRoutes are generated only for translatable Ingresses; nothing is written to the cluster
- The cutover check never moves DNS and never deletes an Ingress
| Serving | Routes accepted and the Gateway programmed with an address. Safe to point DNS at it. |
| Attached | Routes look healthy, but the Gateway is not live yet |
| Degraded | A route exists but is not accepted or cannot resolve its backends, with the reason |
| Not started | Translatable Ingress with no matching HTTPRoute yet |
| Not migratable | Uses annotations with no Gateway API equivalent |
Keeping ServerMind Current
- Compatibility is tracked by contract revision; agents up to 3 revisions behind are supported
- Agents outside the window stay connected, so they can still be upgraded remotely
- Agent upgrades patch the controller image over the existing connection, with no kubeconfig
- The old agent keeps serving until the new one holds a live hub session
- A server-side dry-run refuses the patch if anything besides the image would change
- Check for updates and apply a new console version from the Updates page
- Preflight checks run before the image is changed
- A run is marked failed if the new version is not live within 15 minutes
- The update Role can change only the manager’s own Deployment