Long-Term Supported Versions

    Innovation Versions

      Usage Instructions

      Precautions

      1. KubeOS upgrades the container OS in an atomic manner, where all software packages are upgraded at the same time. By default, single-package upgrade is not supported.
      2. KubeOS supports container OSs with two partitions. Partitions more than two are not supported.
      3. You can view the upgrade logs of a single node in the /var/log/messages file on the node.
      4. Strictly follow the upgrade and rollback procedures described in this document. If the steps are performed in a wrong sequence, the system may fail to be upgraded or rolled back.
      5. Currently, cross-version kernel upgrade is not supported.

      Upgrade

      Compile the YAML file for deploying the OS as a custom resource (CR) instance in the cluster. The following is an example YAML file for deploying the CR instance:

      apiVersion: upgrade.openeuler.org/v1alpha1
      kind: OS
      metadata:
        name: os-sample
      spec:
        osversion: KubeOS 1.0.0
        imageurl: edit.image.url
        maxunavailable: 1
        checksum: image checksum
        flagSafe: imageurl is safe or not
      

      Parameter description:

      ParameterDescriptionMandatory (Yes/No)
      osversionOS version of the image used for the upgradeYes
      imageurlAddress of the image used for the upgradeYes
      maxunavailableNumber of nodes that are upgraded concurrentlyYes
      checksumChecksum (SHA-256) value of the image used for the upgradeYes
      flagSafeWhether imageurl specifies a secure addressYes

      The address specified by imageurl contains the protocol. Only the HTTP or HTTPS protocol is supported. If imageurl is set to an HTTPS address, secure transmission is used. If imageurl is set to an HTTP address, set flagSafe to true, because the image can be downloaded only when the address is secure. If imageurl is set to an HTTP address but flagSafe is not set to true, the address is considered insecure by default. The image will not be downloaded, and a message is written to the log of the node to be upgraded indicating that the address is insecure.

      You are advised to set imageurl to an HTTPS address. In this case, ensure that the required certificate has been installed on the node to be upgraded. If the image server is maintained by yourself, you need to sign the certificate and ensure that the certificate has been installed on the node to be upgraded. Place the certificate in the /etc/pki/ca-trust/source/anchors directory of the container OS and run the update-ca-trust extract command to install the certificate. The administrator specifies the address and must ensure the security of the address. An intranet address is recommended.

      Assume that the YAML file is upgrade_v1alpha1_os.yaml.

      Check the OS version of the node that is not upgraded.

      kubectl get nodes -o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.osImage'
      

      Run the following command to deploy the CR instance in the cluster. The node is upgraded based on the configured parameters.

      kubectl apply -f upgrade_v1alpha1_os.yaml
      

      Check the node OS version again to determine whether the node upgrade is complete.

      kubectl get nodes -o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.osImage'
      

      NOTE:

      If the upgrade needs to be performed again, modify the imageurl, osversion, checksum, maxunavailable, and flagSafe parameters in the upgrade_v1alpha1_os.yaml file.

      Rollback

      Application Scenarios

      • If a node cannot be started, you can only manually roll back the container OS to the previous version that can be properly started.
      • If a node can be started and run the system, you can manually or use KubeOS (similar to the upgrade) to roll back the container OS. You are advised to use KubeOS.

      Manual Rollback

      Manually restart the node and select the second boot option to roll back the container OS. Manual rollback can only roll back the container OS to the version before the upgrade.

      KubeOS-based Rollback

      1. Modify the YAML configuration file (for example, upgrade_v1alpha1_os.yaml) of the OS CR instance. Set the imageurl, osversion, checksum, and flagSafe parameters to the information about the target version to be rolled back to.

      2. Update the CR instance in the cluster.

        kubectl apply -f upgrade_v1alpha1_os.yaml
        

        After the update is complete, the node rolls back the container OS based on the configuration information.

      3. Check the container OS version on the node to determine whether the rollback is successful.

        kubectl get nodes -o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.osImage'
        

      Bug Catching

      Buggy Content

      Bug Description

      Submit As Issue

      It's a little complicated....

      I'd like to ask someone.

      PR

      Just a small problem.

      I can fix it online!

      Bug Type
      Specifications and Common Mistakes

      ● Misspellings or punctuation mistakes;

      ● Incorrect links, empty cells, or wrong formats;

      ● Chinese characters in English context;

      ● Minor inconsistencies between the UI and descriptions;

      ● Low writing fluency that does not affect understanding;

      ● Incorrect version numbers, including software package names and version numbers on the UI.

      Usability

      ● Incorrect or missing key steps;

      ● Missing prerequisites or precautions;

      ● Ambiguous figures, tables, or texts;

      ● Unclear logic, such as missing classifications, items, and steps.

      Correctness

      ● Technical principles, function descriptions, or specifications inconsistent with those of the software;

      ● Incorrect schematic or architecture diagrams;

      ● Incorrect commands or command parameters;

      ● Incorrect code;

      ● Commands inconsistent with the functions;

      ● Wrong screenshots.

      Risk Warnings

      ● Lack of risk warnings for operations that may damage the system or important data.

      Content Compliance

      ● Contents that may violate applicable laws and regulations or geo-cultural context-sensitive words and expressions;

      ● Copyright infringement.

      How satisfied are you with this document

      Not satisfied at all
      Very satisfied
      Submit
      Click to create an issue. An issue template will be automatically generated based on your feedback.
      Bug Catching
      编组 3备份