Orchestrated Combined Host Software Deployment and Kubernetes Upgrade¶
Overview
Host Software deployment orchestration can optionally include a Kubernetes version upgrade as part of the same strategy. This eliminates the need to run a separate kube-upgrade-strategy command after the host software deployment completes.
When the --kube-upgrade option is specified on the
sw-manager sw-deploy-strategy create command, the system
orchestrates both the software deployment and the Kubernetes upgrade in the
correct order for the system type.
Note
The orchestrated combined host software deployment and kubernetes upgrade is only supported for AIO-SX systems, for AIO-DX and standard systems the legacy serial host software deployment and kubernetes upgrade will be performed by the orchestration/strategy.
On AIO-SX systems, the Kubernetes control-plane upgrade runs before the software deployment. The kubelet upgrade happens automatically during the host unlock as part of the new software load.
On AIO-DX and standard systems, the full software deployment runs first on all hosts, and then the Kubernetes upgrade proceeds sequentially after the system stabilizes.
Note
The rollback option is only available for AIO-SX systems. For AIO-DX and
standard (multi-node) systems, rollback of the Kubernetes upgrade is not
supported, so the combined software deployment and Kubernetes upgrade cannot
be rolled back once applied. If --delete is not specified on an AIO-SX
system, you retain the option of rolling back after the strategy completes;
otherwise, clean up afterward by creating a separate strategy with the
--cleanup option.
Note
For orchestrating the combined software deployment and Kubernetes upgrade of subclouds in a Distributed Cloud system, see Deploy a Combined Software and Kubernetes Upgrade Across Subclouds.
After the software is deployed and the Kubernetes upgrade completes on all
hosts, the strategy will optionally complete and delete the Kubernetes upgrade,
the software deployment, and the system-deploy record if the --delete
option was specified.
Note
If --delete is not specified, after the strategy completes, you still
have the option of rolling back, otherwise you can clean up afterward by
creating a separate strategy with the --cleanup option.
The following table summarizes what the combined strategy supports by system type.
System type |
Combined (host + K8s) orchestration |
LVM snapshot |
Rollback |
|---|---|---|---|
AIO-SX |
Parallel (control-plane before software deployment) |
Supported |
Supported |
AIO-DX |
Legacy serial (software deployment, then K8s upgrade) |
Not supported |
Not supported |
Standard (multi-node) |
Legacy serial (software deployment, then K8s upgrade) |
Not supported |
Not supported |
Prerequisites
No other orchestration strategy exists. A combined software deployment and Kubernetes upgrade cannot be orchestrated while another orchestration is in progress.
You have the administrator role privileges.
The system is clear of alarms (except alarm 900.023 indicating the software deployment in progress and alarm 900.007 indicating the Kubernetes upgrade in progress, in case of a previous strategy execution).
All the hosts are unlocked, enabled, and available.
For duplex systems, the system should be fully redundant. There should be two controller nodes available, at least one complete storage replication group available for systems with Ceph backend.
The target software release has been uploaded.
~(keystone_admin)]$ software list +--------------------------+-------+-----------+ | Release | RR | State | +--------------------------+-------+-----------+ | starlingx-12.0.0 | True | deployed | | <new-release-id> | True | available | +--------------------------+-------+-----------+
The target Kubernetes version is available on the system.
~(keystone_admin)]$ system kube-version-list +----------+--------+-------------+ | version | target | state | +----------+--------+-------------+ | v1.29.2 | False | unavailable | | v1.30.6 | False | unavailable | | v1.31.5 | False | unavailable | | v1.32.2 | False | unavailable | | v1.32.13 | True | active | | v1.33.0 | False | available | | v1.34.1 | False | available | | v1.35.2 | False | available | +----------+--------+-------------+
No existing Kubernetes upgrade is in progress past the control-plane phase. If a previous Kubernetes upgrade was aborted, it will be cleaned up automatically during the build phase.
Procedure
Create a combined software deployment and Kubernetes upgrade orchestration strategy.
~(keystone_admin)]$ sw-manager sw-deploy-strategy create <release> \ --kube-upgrade <kube-version> \ [--controller-apply-type {serial,ignore}] \ [--storage-apply-type {serial,parallel,ignore}] \ [--worker-apply-type {serial,parallel,ignore}] \ [--max-parallel-worker-hosts {2,3,4,5,6,7,8,9,10}] \ [--instance-action {stop-start,migrate}] \ [--alarm-restrictions {strict,relaxed}] \ [--delete] [--rollback] [--snapshot]where,
<release>Specifies the target major software release to deploy.
--kube-upgrade <kube-version>Specifies the target Kubernetes version to upgrade to.
[--delete](Optional) When specified, the strategy will finalize and delete the Kubernetes upgrade, the software deployment, and the system-deploy record after successful completion. When not specified for purposes of keeping the option to rollback available, these must be cleaned up manually or using the
--cleanupoption.
All other options behave the same as described in Orchestrated Deployment Host Software Deployment.
Wait for the build phase to complete.
~(keystone_admin)]$ sw-manager sw-deploy-strategy show Strategy Software Deploy Strategy: strategy-uuid: a1b2c3d4-e5f6-7890-abcd-ef1234567890 release-id: <software-release-id> kube-version: <kube-version> controller-apply-type: serial storage-apply-type: serial worker-apply-type: serial default-instance-action: stop-start alarm-restrictions: strict current-phase: build current-phase-completion: 100% state: ready-to-apply build-result: success build-reason:
Note
If the build phase fails (
build-result: failedthat will appear in the show command), determine the issue from the build error reason (build-reason: <Error information>that will appear in the show command) and/or in/var/log/nfv-vim*.logon the active controller, address the issues, delete the strategy, and retry the create.Apply the strategy.
~(keystone_admin)]$ sw-manager sw-deploy-strategy apply Strategy Software Deploy Strategy: strategy-uuid: a1b2c3d4-e5f6-7890-abcd-ef1234567890 release-id: <software-release-id> kube-version: <kube-version> controller-apply-type: serial storage-apply-type: serial worker-apply-type: serial default-instance-action: stop-start alarm-restrictions: strict current-phase: apply current-phase-completion: 0% state: applying inprogress: true
Monitor the strategy progress.
~(keystone_admin)]$ sw-manager sw-deploy-strategy show Strategy Software Deploy Strategy: strategy-uuid: a1b2c3d4-e5f6-7890-abcd-ef1234567890 release-id: <software-release-id> kube-version: <kube-version> controller-apply-type: serial storage-apply-type: serial worker-apply-type: serial default-instance-action: stop-start alarm-restrictions: strict current-phase: apply current-phase-completion: 7% state: applying inprogress: true
To see the active stage and step:
~(keystone_admin)]$ sw-manager sw-deploy-strategy show --active Strategy Software Deploy Strategy: strategy-uuid: a1b2c3d4-e5f6-7890-abcd-ef1234567890 release-id: <software-release-id> kube-version: <kube-version> controller-apply-type: serial storage-apply-type: serial worker-apply-type: serial default-instance-action: stop-start alarm-restrictions: strict current-phase: apply current-phase-completion: 7% state: applying apply-phase: total-stages: 3 current-stage: 0 stop-at-stage: 3 timeout: 12019 seconds completion-percentage: 7% start-date-time: 2026-09-23 12:19:51 inprogress: true stages: stage-id: 0 stage-name: sw-upgrade-start total-steps: 3 current-step: 1 timeout: 1321 seconds start-date-time: 2026-09-23 12:19:51 inprogress: true steps: step-id: 1 step-name: start-upgrade timeout: 1200 seconds start-date-time: 2026-09-23 12:19:51 result: wait reason:Wait for the strategy to complete.
~(keystone_admin)]$ sw-manager sw-deploy-strategy show Strategy Software Deploy Strategy: strategy-uuid: a1b2c3d4-e5f6-7890-abcd-ef1234567890 release-id: <software-release-id> kube-version: <kube-version> controller-apply-type: serial storage-apply-type: serial worker-apply-type: serial default-instance-action: stop-start alarm-restrictions: strict current-phase: apply current-phase-completion: 100% state: applied apply-result: success apply-reason:
If the strategy fails, address the issue that caused the failure, then delete and re-create the strategy before attempting to apply it again.
~(keystone_admin)]$ sw-manager sw-deploy-strategy show --error-details
Delete the completed strategy.
~(keystone_admin)]$ sw-manager sw-deploy-strategy delete Strategy deleted
Postrequisites
After a successful combined software deployment and Kubernetes upgrade:
Validate that the system and hosted applications are healthy.
Verify that Kubernetes is at the target version:
~(keystone_admin)]$ system kube-version-list
Strategy Cleanup Option¶
When the combined strategy is applied without the --delete option, the
software deployment is not removed once the strategy completes. This leaves
the rollback path available so that you can evaluate the system before
committing to the upgrade.
After the strategy completes, perform a short evaluation to confirm the system is healthy. Based on that evaluation, you can either:
Roll back the deployment if issues are found, or
Complete (clean up) the deployment to finalize the upgrade once the system is confirmed healthy.
The --cleanup option creates a strategy that finalizes the Kubernetes
upgrade, deletes the software deployment, and removes the system-deploy
record. Use it when the combined strategy was applied without --delete
and you have verified that the system is healthy and no rollback is needed.
The cleanup strategy can also be used to delete an aborted kube-upgrade,
system-deploy, or software deployment when the strategy failed or was
aborted before locking the hosts, and you do not want to continue with the
upgrade and want to clear the system of upgrade-related alarms.
~(keystone_admin)]$ sw-manager sw-deploy-strategy create --cleanup
