Skip to content

Management Component Version Upgrade Guide

This guide applies to daily version upgrades and patch updates for an installed xSpace management component environment.

1. Upgrade Preparation

  1. Obtain Component Packages: Obtain the latest versions of astute-k3s-deploy*.bin, astute-xspace-image*.bin, and astute-xspace-deploy*.bin upgrade packages.

  2. Upload Files: The astute-k3s-deploy*.bin package needs to be uploaded to all nodes, while astute-xspace-image*.bin and astute-xspace-deploy*.bin packages only need to be uploaded to the master node.

2. Upgrade Execution Process

The upgrade process greatly simplifies interaction steps, usually only requiring confirmation of default configurations.

If the version number of a component package is consistent with the current environment, you can skip the execution step for that component.

2.1 Container Cluster Upgrade (All Nodes)

Operation Order: Upgrade all worker nodes first, then the master node.

  • Worker Node Upgrade: Execute the following command on each worker node, pressing Enter to confirm default options throughout the process.
[root@host152 ~]$ bash ./astute-k3s-deploy-*.bin
  • Master Node Upgrade: Execute the following command on the master node, similarly pressing Enter to confirm default options throughout the process.
[root@host151 ~]$ bash ./astute-k3s-deploy-*.bin

2.2 Prepare Images and Deploy Components (Master Node Only)

After the master node completes the cluster upgrade and confirms the cluster status is normal, execute the following packages in sequence:

  • Image Update:
[xspace@host151 ~]$ sudo bash ./astute-xspace-image-*.bin
  • Component Deployment:
[xspace@host151 ~]$ sudo bash ./astute-xspace-deploy-*.bin

3. Important Feature: Installation Reentrancy

During the upgrade process, if the installation is interrupted due to network fluctuations, SSH disconnection, management node VM shutdown/restart, or other reasons:

  • No need to panic: The system supports reentrant execution.
  • Handling Method: Simply re-execute the .bin file for that stage. The script will automatically identify the completed progress and resume installation from the point of interruption without damaging existing data.

4. Post-Upgrade Configuration Recovery (Critical)

Since some system components will reload default configurations during the upgrade process, the following custom settings may be reset. Please be sure to check and manually restore them after deployment:

  • Nginx Configuration (ConfigMap):

    • Check if nginx-conf has lost the previously configured allow list for public network ports and custom internal network ports.
    • If lost, please refer to the Network Configuration section in the deployment manual for reconfiguration.

  • Nacos Middleware Configuration:

    • If you previously modified specific microservice configuration files in the Nacos console, please check if these configurations have been restored to their default values.
    • Built-in SMS authentication service related settings are stored in Nacos. If SMS authentication was enabled, it needs to be reconfigured after the upgrade.

5. Result Verification

After the upgrade is complete, refer to Completion Verification to check the operating status of the upgraded system.

Execute Verification Command:

[xspace@host151 ~]$ sudo /opt/installation/scripts/env_check.sh 0

Judgment Criteria: Observe the script output.

  • Success: All checked items are in green font, without any red error prompts.
  • Anomaly: If red text appears, check the Pod logs according to the indicated component name.