documentation.suse.com / SUSE Edgeドキュメント / Day 2操作 / Edge 3.1のマイグレーション

27 Edge 3.1のマイグレーション

このセクションでは、既存の Edge 3.0 (3.0.1や3.0.2などのマイナーリリースを含む) 管理クラスタとダウンストリームクラスタをEdge 3.1.0に移行するためのガイドラインを提供します。

Edge 3.1.0コンポーネントバージョンのリストについては、リリースノート(45.1項 「要約」)を参照してください。

27.1 管理クラスタ

このセクションでは、管理クラスタをEdge 3.0からEdge 3.1.0に移行する方法について説明します。

管理クラスタコンポーネントは、次の順序で移行する必要があります。

27.1.1 オペレーティングシステム(OS)

このセクションでは、管理クラスタノードのOSをEdge 3.1.0でサポートされているバージョンに移行するために必要な手順について説明します。

重要
重要

以下の手順は管理クラスタの各ノードに実行する必要があります。

予期しない問題を避けるため、クラスタのコントロールプレーンノードを最初に移行してからワーカーノードを移行してください。

27.1.1.1 前提条件

  • SCC登録ノード - クラスタのノードのOSが、Edge 3.1リリース(45.1項 「要約」)で指定されているオペレーティングシステムのバージョンをサポートするサブスクリプションキーで登録されていることを確認してください。

エアギャップ:

  • SUSE RPMリポジトリのミラーリング - Edge 3.1.0リリース(45.1項 「要約」)で指定されるオペレーティングシステムに関連するRPMリポジトリはローカルにミラーリングし、 transactional-updateがそのリポジトリにアクセスできるようにする必要があります。このためには、RMTまたはSUMAを使用します。

27.1.1.2 マイグレーション手順

注記
注記

以下の手順は、rootとして実行しており、kubectl管理クラスタに接続するように設定されていることを前提としています。

  1. ノードをunschedulableとマークします。

    kubectl cordon <node_name>

    cordonコマンドのオプションの全リストについては、「kubectl cordon」を参照してください。

  2. オプションで、ノードのワークロードにdrainを実行するユースケースがある場合があります。

    kubectl drain <node>

    drainコマンドのオプションの全リストについては、「kubectl drain」を参照してください。

  3. マイグレーション前に、現在のOSのパッケージが更新されていることを確認する必要があります。これには、次のコマンドを実行します。

    transactional-update

    上記のコマンドは、zypper upを実行して、OSパッケージを更新します。 transactional-updateの詳細については、transactional-updateガイドを参照してください。

  4. OSマイグレーションに進みます。

    transactional-update --continue migration
    注記
    注記

    ここでは、--continueオプションは、システムを再起動せずに以前のスナップショットを再使用するために使用されます。

    • サブスクリプションキーがSUSE Linux Micro 6.0バージョンをサポートしている場合は、次のようなプロンプトが表示されます。

      day2マイグレーションOSマイグレーションプロンプト

      SUSE Linux Micro 6.0 <arch>に対応する番号を選択します。

      注記
      注記

      Edge 3.1.0リリースは、SUSE Linux Micro 6.0オペレーティングシステムのみをサポートしています。

  5. transactional-updateが正常に実行されたら、変更をシステムに適用するために、再起動する必要があります。

    reboot
  6. ホストが再起動された後で、オペレーティングシステムがSUSE Linux Micro 6.0に移動されていることを検証します。

    cat /etc/os-release

    出力は次のようになるはずです。

    NAME="SL-Micro"
    VERSION="6.0"
    VERSION_ID="6.0"
    PRETTY_NAME="SUSE Linux Micro 6.0"
    ID="sl-micro"
    ID_LIKE="suse"
    ANSI_COLOR="0;32"
    CPE_NAME="cpe:/o:suse:sl-micro:6.0"
    HOME_URL="https://www.suse.com/products/micro/"
    DOCUMENTATION_URL="https://documentation.suse.com/sl-micro/6.0/"
    注記
    注記

    マイグレーションで何らかの障害が発生した場合は、次のコマンドを使用して、最後の動作しているスナップショットにロールバックできます。

    transactional-update rollback last

    ロールバックを有効にするには、システムを再起動する必要があります。ロールバック手順に関する詳細については、公式のtransactional-updateドキュメントを参照してください。

  7. ノードをschedulableとしてマークします。

    kubectl uncordon <node_name>

27.1.2 RKE2

重要
重要

以下の手順は管理クラスタの各ノードに実行する必要があります。

RKE2ドキュメントで説明してるように、アップグレード手順では、一度にクラスタのコントロールプレーンノードをアップグレードしてから、エージェントノードをアップグレードする必要があります。

注記
注記

ディザスタリカバリを確実行えるように、RKE2クラスタデータのバックアップを取ることをお勧めします。この実行方法については、『RKE2 backup and restore guide (RKE2バックアップおよびリストアガイド) 』を参照してください。rke2バイナリのデフォルトの場所は、/opt/rke2/binです。

次のようにRKE2インストールスクリプトを使用して、RKE2バージョンをEdge 3.1.0と互換性のあるバージョンにアップグレードできます。

  1. ノードをunschedulableとマークします。

    kubectl cordon <node_name>

    cordonコマンドのオプションの全リストについては、「kubectl cordon」を参照してください。

  2. オプションで、ノードのワークロードにdrainを実行するユースケースがある場合があります。

    kubectl drain <node>

    drainコマンドのオプションの全リストについては、「kubectl drain」を参照してください。

  3. RKE2インストールスクリプトを使用して、正しいEdge 3.1.0と互換性のあるRKE2バージョンをインストールします。

    curl -sfL https://get.rke2.io | INSTALL_RKE2_VERSION=v1.30.3+rke2r1 sh -
  4. rke2プロセスを再起動します。

    # For control-plane nodes:
    systemctl restart rke2-server
    
    # For worker nodes:
    systemctl restart rke2-agent
  5. ノードのRKE2バージョンがアップグレードされていることを検証します。

    kubectl get nodes
  6. ノードをschedulableとしてマークします。

    kubectl uncordon <node_name>

27.1.3 Edge Helmチャート

注記
注記

このセクションでは、システムにhelmをインストールしており、必要なクラスタを指す有効なkubeconfigを持っていることを前提としています。helmインストール手順については、『Installing Helm (Helmのインストール)ガイド』を参照してください。

このセクションでは、特定のEdgeリリースを構成するHelmチャートコンポーネントに関するガイドラインを提供します。次のトピックについて説明します。

27.1.3.1 既知の制限事項

このセクションでは、現在のマイグレーションプロセスに対する既知の制限事項について説明します。ユーザは、helmチャートをアップグレードするために移動する前に、まずここで説明されている手順を実行する必要があります。

27.1.3.1.1 Rancherのアップグレード

Edge 3.1.0が使用している現在のRKE2バージョンでは、IngressClassを含まないIngressがIngressコントローラ によって無視されるという問題が発生します。この問題を軽減するには、ユーザはデフォルトのIngressClassの名前をデフォルトのRancher Ingressに手動で追加する必要があります。

以下の手順で修正される問題の詳細については、アップストリームの RKE2の問題、より具体的には、こちらのコメントを参照してください。

注記
注記

デフォルトのIngressClassの名前がnginxとは異なる場合があります。

次のコマンドを実行して、名前を検証してください。

kubectl get ingressclass

Rancherをアップグレードする前に、次のコマンドを実行してください。

  • RancherがEIB (第9章 「Edge Image Builder)を通じてデプロイされた場合:

    kubectl patch helmchart rancher -n <namespace> --type='merge' -p '{"spec":{"set":{"ingress.ingressClassName":"nginx"}}}'
  • RancherがHelmを通じてデプロイされた場合は、--set ingress.ingressClassName=nginxフラグをupgradeコマンドに追加します。このオプションを利用する方法の完全な例については、次の例(27.1.3.4.1項 「例」)を参照してください。

27.1.3.2 Cluster APIコントローラのマイグレーション

Edge 3.1.0以降、Metal3管理クラスタ上のCluster API (CAPI)コントローラは、Rancher Turtlesを介して管理されます。

CAPIコントローラバージョンをEdge 3.1.0と互換性のあるバージョンに移行するには、Rancher Turtlesチャートをインストールします。

helm install rancher-turtles oci://registry.suse.com/edge/3.1/rancher-turtles-chart --version 0.3.2 --namespace rancher-turtles-system --create-namespace

しばらくしたら、capi-systemcapm3-systemrke2-bootstrap-systemrke2-control-plane-systemネームスペースで実行されているコントローラポッドがEdge 3.1.0と互換性のあるコントローラバージョンでアップグレードされます。

エアギャップ環境にRancher Turtlesをインストールする方法については、 「Rancher Turtlesのエアギャップインストール」(27.1.3.2.1項 「Rancher Turtlesのエアギャップインストール」)を参照してください。

27.1.3.2.1 Rancher Turtlesのエアギャップインストール
注記
注記

以下の手順は、アップグレードする管理クラスタに接続するようにkubectlを設定していることを前提としています。

  1. 以下で説明しているrancher-turtles-airgap-resources Helmチャートをインストールする前に、作成されたclusterctlネームスペースに正しい所有権があることを確認します。

    1. capi-system所有権の変更:

      kubectl label namespace capi-system app.kubernetes.io/managed-by=Helm --overwrite
      
      kubectl annotate namespace capi-system meta.helm.sh/release-name=rancher-turtles-airgap-resources --overwrite
      kubectl annotate namespace capi-system meta.helm.sh/release-namespace=rancher-turtles-system --overwrite
    2. capm3-system所有権の変更:

      kubectl label namespace capm3-system app.kubernetes.io/managed-by=Helm --overwrite
      
      kubectl annotate namespace capm3-system meta.helm.sh/release-name=rancher-turtles-airgap-resources --overwrite
      kubectl annotate namespace capm3-system meta.helm.sh/release-namespace=rancher-turtles-system --overwrite
    3. rke2-bootstrap-system所有権の変更:

      kubectl label namespace rke2-bootstrap-system app.kubernetes.io/managed-by=Helm --overwrite
      
      kubectl annotate namespace rke2-bootstrap-system meta.helm.sh/release-name=rancher-turtles-airgap-resources --overwrite
      kubectl annotate namespace rke2-bootstrap-system meta.helm.sh/release-namespace=rancher-turtles-system --overwrite
    4. rke2-control-plane-system所有権の変更:

      kubectl label namespace rke2-control-plane-system app.kubernetes.io/managed-by=Helm --overwrite
      
      kubectl annotate namespace rke2-control-plane-system meta.helm.sh/release-name=rancher-turtles-airgap-resources --overwrite
      kubectl annotate namespace rke2-control-plane-system meta.helm.sh/release-namespace=rancher-turtles-system --overwrite
  2. rancher-turtles-airgap-resourcesrancher-turtlesチャートアーカイブを取得します。

    helm pull oci://registry.suse.com/edge/3.1/rancher-turtles-airgap-resources-chart --version 0.3.2
    helm pull oci://registry.suse.com/edge/3.1/rancher-turtles-chart --version 0.3.2
  3. Rancher Turtles Helmチャートのエアギャップインストールに必要なリソースを提供するため、rancher-turtles-airgap-resources Helmチャートをインストールします。

    helm install rancher-turtles-airgap-resources ./rancher-turtles-airgap-resources-chart-0.3.2.tgz --namespace rancher-turtles-system --create-namespace
  4. Rancher Turtles Helmチャートのcluster-api-operatorを設定し、正しい場所からコントローラデータをフェッチします。

    cat > values.yaml <<EOF
    cluster-api-operator:
      cluster-api:
        core:
          fetchConfig:
            selector: "{\"matchLabels\": {\"provider-components\": \"core\"}}"
        rke2:
          bootstrap:
            fetchConfig:
              selector: "{\"matchLabels\": {\"provider-components\": \"rke2-bootstrap\"}}"
          controlPlane:
            fetchConfig:
              selector: "{\"matchLabels\": {\"provider-components\": \"rke2-control-plane\"}}"
        metal3:
          infrastructure:
            fetchConfig:
              selector: "{\"matchLabels\": {\"provider-components\": \"metal3\"}}"
    EOF
  5. Rancher Turtlesをインストールします。

    helm install rancher-turtles ./rancher-turtles-chart-0.3.2.tgz --namespace rancher-turtles-system --create-namespace --values values.yaml

しばらくすると、capi-systemcapm3-systemrke2-bootstrap-system、およびrke2-control-plane-systemネームスペースで実行しているコントローラポッドがEdge 3.1.0と互換性のあるバージョンでアップグレードされます。

27.1.3.3 Edge Helmチャートのアップグレード - EIB

このセクションでは、EIB (第9章 「Edge Image Builder)を通じてデプロイされたEdgeコンポーネントスタックからEdge 3.1.0と互換性のあるバージョンへのHelmチャートのアップグレード方法について説明します。

27.1.3.3.1 前提条件

Edge 3.1では、EIBはチャートのデプロイ方法を変更し、RKE2/K3sマニフェスト自動デプロイメカニズムを「使用していません」

これは、Edge 3.1.0と互換性のあるバージョンにアップグレードする前に、EIBを使用してEdge 3.0環境にデプロイされたすべてのHelmチャートは、関連するKubernetesディスとリビューションのマニフェストディレクトリからチャートマニフェストを削除する必要があります。

警告
警告

これが実行されない場合、プロセスまたはオペレーティングシステムの再起動時にチャートアップグレードがRKE2/K3sプロセスによって元に戻されます。

注記
注記

RKE2/K3sディレクトリからマニフェストを削除しても、クラスタからリソースが削除されることは「ありません」

RKE2/K3sのドキュメンによると:

「このディレクリのファイルを削除しても、クラスタから対応するリソースは削除されません。」

EIBでデプロイされたチャートマニフェストの削除には、次の手順が含まれます。

  1. ディザスタリカバリを確保するため、各EIBでデプロイされたマニフェストのバックアップを取ります。

    注記
    注記

    EIBでデプロイされたマニフェストは、"edge.suse.com/source: edge-image-builder"ラベルが付きます。

    注記
    注記

    以下のコマンドに提供する<backup_location>が存在すること確認します。

    grep -lrIZ 'edge.suse.com/source: edge-image-builder' /var/lib/rancher/rke2/server/manifests | xargs -0 -I{} cp {} <backup_location>
  2. すべてのEIBでデプロイされたマニフェストを削除します。

    grep -lrIZ 'edge.suse.com/source: edge-image-builder' /var/lib/rancher/rke2/server/manifests | xargs -0 rm -f --
27.1.3.3.2 アップグレード手順
注記
注記

以下の手順は、アップグレードする管理クラスタに接続するようにkubectlを設定していることを前提としています。

  1. リリースノート(45.1項 「要約」)を確認して、移行するEdge 3.1と互換性のあるチャートバージョンを特定します。

  2. 必要なHelmチャートバージョンを取得 します。

    • HTTPリポジトリでホストされているチャートの場合:

      helm repo add <chart_repo_name> <chart_repo_urls>
      
      helm pull <chart_repo_name>/<chart_name> --version=X.Y.Z
    • OCIレジストリでホストされているチャートの場合:

      helm pull oci://<chart_oci_url> --version=X.Y.Z
  3. 取得されたチャートアーカイブをエンコードします。

    base64 -w 0 <chart_name>-X.Y.Z.tgz  > <chart_name>-X.Y.Z.txt
  4. チャートに対して実行する必要がある追加の手順がある場合は、既知の制限事項(27.1.3.1項 「既知の制限事項」)セクションを確認します。

  5. 既存のHelmChartリソースにパッチを適用します。

    重要
    重要

    必ずHelmChart ネームスペースエンコードされたファイル、およびバージョンを次のコマンドに渡します。

    kubectl patch helmchart <helmchart_name> --type=merge -p "{\"spec\":{\"chartContent\":\"$(cat <helmchart_name>-X.Y.Z.txt)\", \"version\":\"<helmchart_version>\"}}" -n <helmchart_namespace>
  6. これにより、目的のHelmチャートをアップグレードするPodを作成するジョブをスケジュールするように helm-controllerに指示します。作成されたPodのログを確認するには、次の手順を実行します。

    1. 作成したPodを見つけます。

      kubectl get pods -l helmcharts.helm.cattle.io/chart=<helmchart_name> -n <namespace>
    2. Podのログを確認します。

      kubectl logs <pod_name> -n <namespace>

エラーのないログを含む完了したPodは、目的のHelmチャートのアップグレードが成功したことを示します。

EIBを通じてデプロイされたHelmチャートのアップグレード方法の完全な例については、「例」(27.1.3.3.3項 「例」)のセクションを参照してください。

27.1.3.3.3

このセクションでは、RancherおよびMetal3 HelmチャートをEdge 3.1.0リリースと互換性のあるバージョンにアップグレードする例を示します。「アップグレード手順」(27.1.3.3.2項 「アップグレード手順」)セクションで概説した手順に従います。

ユースケース:

  • 現在のRancherおよびMetal3チャートは、Edge 3.1.0と互換性のあるバージョンにアップグレードする必要があります。

    • RancherはEIBを通じてデプロイされ、そのHelmChartは、デフォルトネームスペースにデプロイされます。

    • Metal3はEIBを通じてデプロイされ、そのHelmChartkube-systemネームスペースにデプロイされます。

手順:

  1. リリースノート(45.1項 「要約」)からRancherおよびMetal3の目的のバージョンを見つけます。Edge 3.1.0の場合、これらのバージョンは、Rancher の場合は2.9.1で、Metal3の場合は0.8.1です。

  2. 目的のチャートバージョンを取得します。

    • Rancherの場合:

      helm repo add rancher-prime https://charts.rancher.com/server-charts/prime
      helm pull rancher-prime/rancher --version=2.9.1
    • Metal3の場合:

      helm pull oci://registry.suse.com/edge/3.1/metal3-chart --version=0.8.1
  3. RancherおよびMetal3 Helmチャートをエンコードします。

    base64 -w 0 rancher-2.9.1.tgz > rancher-2.9.1.txt
    base64 -w 0 metal3-chart-0.8.1.tgz > metal3-chart-0.8.1.txt
  4. ディレクトリ構造は次のようになるはずです。

    .
    ├── metal3-chart-0.8.1.tgz
    ├── metal3-chart-0.8.1.txt
    ├── rancher-2.9.1.tgz
    └── rancher-2.9.1.txt
  5. チャートに対して実行する必要がある追加の手順がある場合は、既知の制限事項(27.1.3.1項 「既知の制限事項」)セクションを確認します。

    • Rancherの場合:

      • 既知の制限事項」セクションで説明されているコマンドを実行します。

        # In this example the rancher helmchart is in the 'default' namespace
        kubectl patch helmchart rancher -n default --type='merge' -p '{"spec":{"set":{"ingress.ingressClassName":"nginx"}}}'
      • ingressClassNameプロパティが正常に追加されたことを検証します。

        kubectl get ingress rancher -n cattle-system -o yaml | grep -w ingressClassName
        
        # Example output
          ingressClassName: nginx
  6. RancherおよびMetal3 HelmChartリソースにパッチを適用します。

    # Rancher deployed in the default namespace
    kubectl patch helmchart rancher --type=merge -p "{\"spec\":{\"chartContent\":\"$(cat rancher-2.9.1.txt)\", \"version\":\"2.9.1\"}}" -n default
    
    # Metal3 deployed in the kube-system namespace
    kubectl patch helmchart metal3 --type=merge -p "{\"spec\":{\"chartContent\":\"$(cat metal3-chart-0.8.1.txt)\", \"version\":\"0.8.1\"}}" -n kube-system
  7. helm-controllerで作成されたRancherおよびMetal3 Podを見つけます。

    • Rancher:

      kubectl get pods -l helmcharts.helm.cattle.io/chart=rancher -n default
      
      # Example output
      NAME                         READY   STATUS      RESTARTS   AGE
      helm-install-rancher-wg7nf   0/1     Completed   0          5m2s
    • Metal3:

      kubectl get pods -l helmcharts.helm.cattle.io/chart=metal3 -n kube-system
      
      # Example output
      NAME                        READY   STATUS      RESTARTS   AGE
      helm-install-metal3-57lz5   0/1     Completed   0          4m35s
  8. kubectlログを使用して各ポッドのログを表示します。

    • Rancher:

      kubectl logs helm-install-rancher-wg7nf -n default
      
      # Example successful output
      ...
      Upgrading rancher
      + helm_v3 upgrade --namespace cattle-system --create-namespace --version 2.9.1 --set-string global.clusterCIDR=10.42.0.0/16 --set-string global.clusterCIDRv4=10.42.0.0/16 --set-string global.clusterDNS=10.43.0.10 --set-string global.clusterDomain=cluster.local --set-string global.rke2DataDir=/var/lib/rancher/rke2 --set-string global.serviceCIDR=10.43.0.0/16 --set-string ingress.ingressClassName=nginx rancher /tmp/rancher.tgz --values /config/values-01_HelmChart.yaml
      Release "rancher" has been upgraded. Happy Helming!
      ...
    • Metal3:

      kubectl logs helm-install-metal3-57lz5  -n kube-system
      
      # Example successful output
      ...
      Upgrading metal3
      + echo 'Upgrading metal3'
      + shift 1
      + helm_v3 upgrade --namespace metal3-system --create-namespace --version 0.8.1 --set-string global.clusterCIDR=10.42.0.0/16 --set-string global.clusterCIDRv4=10.42.0.0/16 --set-string global.clusterDNS=10.43.0.10 --set-string global.clusterDomain=cluster.local --set-string global.rke2DataDir=/var/lib/rancher/rke2 --set-string global.serviceCIDR=10.43.0.0/16 metal3 /tmp/metal3.tgz --values /config/values-01_HelmChart.yaml
      Release "metal3" has been upgraded. Happy Helming!
      ...
  9. 特定のチャートのポッドが実行されていることを確認します。

    # For Rancher
    kubectl get pods -n cattle-system
    
    # For Metal3
    kubectl get pods -n metal3-system

27.1.3.4 Edge Helmチャートのアップグレード - EIB以外

このセクションでは、Helmを介してデプロイされたEdgeコンポーネントスタックから、Edge 3.1.0と互換性のあるバージョンにHelmチャートをアップグレードする方法について説明します。

注記
注記

以下の手順は、アップグレードする管理クラスタに接続するようにkubectlを設定していることを前提としています。

  1. リリースノート(45.1項 「要約」)を参照して、移行するEdge 3.1.0と互換性のあるチャートバージョンを見つけます。

  2. 現在実行中のHelmチャートのカスタム値を取得します。

    helm get values <chart_name> -n <chart_namespace> -o yaml > <chart_name>-values.yaml
  3. 追加の手順やチャートに対して実行する必要がある変更がある場合は、「既知の制限事項」(27.1.3.1項 「既知の制限事項」)セクションを確認します。

  4. Helmチャートを目的のバージョンにアップグレードします。

    • 非エアギャップセットアップの場合:

      # For charts hosted in HTTP repositories
      helm upgrade <chart_name> <chart_repo>/<chart_name> --version <version> --values <chart_name>-values.yaml -n <chart_namespace>
      
      # For charts hosted in OCI registries
      helm upgrade <chart_name> oci://<oci_registry_url>/<chart_name> --namespace <chart_namespace> --values <chart_name>-values.yaml --version=X.Y.Z
    • エアギャップセットアップの場合:

      • インターネットにアクセスできるマシンで、目的のチャートバージョンを取得します。

        # For charts hosted in HTTP repositories
        helm pull <chart_repo_name>/<chart_name> --version=X.Y.Z
        
        # For charts hosted in OCI registries
        helm pull oci://<chart_oci_url> --version=X.Y.Z
      • チャートアーカイブを管理クラスタに転送します。

        scp <chart>.tgz <machine-address>:<filesystem-path>
      • チャートをアップグレードします。

        helm upgrade <chart_name> <chart>.tgz --values <chart_name>-values.yaml -n <chart_namespace>
  5. チャートポッドが実行されていることを確認します。

    kubectl get pods -n <chart_namespace>

チャートに固有のリソースを確認して、アップグレードの追加検証を行うこともできます。これを実行した後で、アップグレードは成功したとみなされます。

完全な例については、「例」(27.1.3.4.1項 「例」)セクションを参照してください。

27.1.3.4.1

このセクションでは、RancherおよびMetal3 HelmチャートをEdge 3.1.0リリースと互換性のあるバージョンにアップグレードする例を示します。「Edge Helmチャートのアップグレード - EIB以外」(27.1.3.4項 「Edge Helmチャートのアップグレード - EIB以外」)セクションで概説されている手順い従います。

ユースケース:

  • 現在のRancherおよびMetal3チャートは、Edge 3.1.0と互換性のあるバージョンにアップグレードする必要があります。

    • Rancher helmチャートは cattle-systemネームスペースのRancher Primeリポジトリからデプロイされます。Rancher Primeリポジトリは次の方法で追加されました。

      helm repo add rancher-prime https://charts.rancher.com/server-charts/prime
    • Metal3metal3-systemネームスペースのregistry.suse.com OCIレジストリからデプロイされます。

手順:

  1. リリースノート(45.1項 「要約」)から目的のバージョンのRancherおよびMetal3を見つけます。 Edge 3.1.0の場合、これらのバージョンは、Rancherの場合は 2.9.1、 Metal3の場合は0.8.1になります。

  2. 現在実行中のRancherおよびMetal3 helmチャートのカスタム値を取得します。

    # For Rancher
    helm get values rancher -n cattle-system -o yaml > rancher-values.yaml
    
    # For Metal3
    helm get values metal3 -n metal3-system -o yaml > metal3-values.yaml
  3. チャートに対して実行する必要がある追加の手順がある場合は、既知の制限事項(27.1.3.1項 「既知の制限事項」)セクションを確認します。

    • Rancherの場合、--set ingress.ingressClassName=nginxオプションをアップグレードコマンドに追加する必要があります。

  4. RancherおよびMetal3 helmチャートをアップグレードします。

    # For Rancher
    helm upgrade rancher rancher-prime/rancher --version 2.9.1 --set ingress.ingressClassName=nginx --values rancher-values.yaml -n cattle-system
    
    # For Metal3
    helm upgrade metal3 oci://registry.suse.com/edge/3.1/metal3-chart --version 0.8.1 --values metal3-values.yaml -n metal3-system
  5. RancherおよびMetal3ポッドが実行されていることを確認します。

    # For Rancher
    kubectl get pods -n cattle-system
    
    # For Metal3
    kubectl get pods -n metal3-system

27.2 ダウンストリームクラスタ

このセクションでは、Edge 3.0.XダウンストリームクラスタをEdge 3.1.0に移行する方法について説明します。

27.2.1 前提条件

このセクションでは、マイグレーションプロセスを開始する前に、ユーザが実行する必要がある前提条件となる手順について説明します。

27.2.1.1 EIBを通じてデプロイされたチャート

Edge 3.1では、EIB (第9章 「Edge Image Builder)はチャートのデプロイ方法を変更し、 RKE2/K3sマニフェスト自動デプロイメカニズムは「使用されなくなりました」

これは、Edge 3.1.0と互換性のあるバージョンに移行する前に、EIBを使用してEdge 3.0環境にデプロイされたすべてのHelmチャートは、関連する Kubernetesディストリビューションのマニフェストディレクトリからチャートマニフェストを削除する必要があります。

警告
警告

これが実行されない場合、プロセスまたはオペレーティングシステムの再起動時にチャートアップグレードがRKE2/K3sプロセスによって元に戻されます。

ダウンストリームクラスタでは、EIBで作成されたチャートマニフェストファイルの削除は、suse-edge/fleet-examplesリポジトリにあるeib-charts-migration-prepと呼ばれるFleetによって処理されます。

警告
警告

メインブランチからの eib-charts-migration-prep Fleetファイルの使用は、推奨されて「いません」。Fleetファイルは、常に有効なEdge リリースタグから使用する必要があります。

重要
重要

このプロセスには、System Upgrade Controller (SUC)がすでにデプロイされている必要があります。インストールの詳細については、「System Upgrade Controllerのインストール」(19.2項 「System Upgrade Controllerのインストール」)を参照してください。

作成されると、eib-charts-migration-prep Fleetは以下を実行するスクリプトを含むSUC (第19章 「System Upgrade Controller) Planを配布します。

  1. 実行中の現在のノードが initializerノードであるか判断します。そうでない場合、何も実行しません。

  2. ノードがinitializerの場合、次のようになります。

    • EIBによってデプロイされたすべての HelmChartリソースを検出します。

    • 上記のHelmChartリソースのそれぞれのマニフェストファイルを見つけます。

      注記
      注記

      HelmChartマニフェストファイルは、RKE2の場合は/var/lib/rancher/rke2/server/manifests、K3sの場合は/var/lib/rancher/k3s/server/manifests下の initializerノードにのみあります。

    • ディザスタリカバリを確保するため、/tmpの下にある各マニフェストのバックアップを作成します。

      注記
      注記

      バックアップの場所は、FleetのSUC PLANのMANIFEST_BACKUP_DIR環境変数を定義して変更できます。

    • EIBによってデプロイされた HelmChartリソースに関連する各マニフェストファイルを削除します。

      注記
      注記

      RKE2/K3sディレクトリからマニフェストを削除しても、クラスタからリソースが削除されることは「ありません」

      RKE2/K3sのドキュメンによると:

      「このディレクリのファイルを削除しても、クラスタから対応するリソースは削除されません。」

ユースケースに応じて、eib-charts-migration-prep Fleetを次の2つの方法でデプロイできます。

27.2.1.1.1 EIBチャートマニフェストの削除のFleetデプロイメント - GitRepo
  1. 管理クラスタに、次のGitRepoリソースをデプロイします。

    注記
    注記

    以下のリソースをデプロイする前に、有効な ターゲット設定を提供する「必要があります」。Fleetがリソースをデプロイするダウンストリームクラスタを認識できるようにするためです。ダウンストリームクラスタへのマッピング方法については、 Mapping to Downstream Clusters (ダウンストリームクラスタへのマッピング」を参照してください。

    kubectl apply -n fleet-default -f - <<EOF
    apiVersion: fleet.cattle.io/v1alpha1
    kind: GitRepo
    metadata:
      name: eib-chart-migration-prep
    spec:
      revision: release-3.1.0
      paths:
      - fleets/day2/system-upgrade-controller-plans/eib-charts-migration-prep
      repo: https://github.com/suse-edge/fleet-examples.git
      targets:
      - clusterSelector: CHANGEME
      # Example matching all clusters:
      # targets:
      # - clusterSelector: {}
    EOF

    または、利用可能な場合はRancherのUIからリソースを作成することもできます。詳細については、「Accessing Fleet in the Rancher UI (Rancher UIでのFleetへのアクセス)」を参照してください。

  2. 管理クラスタに上記の GitRepoを作成することにより、FleetはGitRepoで指定されたターゲットに一致する各ダウンストリームクラスタにSUC Plan (eib-chart-migration-prepと呼ばれる)をデプロイします。このプランのライフサイクルを監視するには、「System Upgrade Controller Plansのモニタリング」 (19.3項 「System Upgrade Controller Planのモニタリング」)を参照してください。

27.2.1.1.2 EIBチャートマニフェストの削除のFleetデプロイメント - バンドル

このセクションでは、eib-chart-migration-prep Fleetをローカルgitサーバを利用できないエアギャップ環境で使用可能なバンドルリソースに変換する方法について説明します。

手順:

  1. ネットワークにアクセスできるマシンで、fleet-cliをダウンロードします。

    注記
    注記

    ダウンロードするfleet-cliのバージョンが、クラスタにデプロイしたFleetのバージョンに一致していることを確認します。

    • Macユーザの場合、fleet-cli Homebrew Formulaeがあります。

    • Linuxユーザの場合、バイナリが各Fleetリリースへの アセットとして用意されています。

      • 目的のバイナリを取得します。

        • Linux AMD:

          curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/<FLEET_VERSION>/fleet-linux-amd64
        • Linux ARM:

          curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/<FLEET_VERSION>/fleet-linux-arm64
      • バイナリを/usr/local/binに移動します。

        sudo mkdir -p /usr/local/bin
        sudo mv ./fleet-cli /usr/local/bin/fleet-cli
        sudo chmod 755 /usr/local/bin/fleet-cli
  2. eib-chart-migration-prepフリートを使用するsuse-edge/fleet-examples リリースのクローンを作成します。

    git clone -b release-3.1.0 https://github.com/suse-edge/fleet-examples.git
  3. fleet-examplesリポジトリにある、eib-chart-migration-prepフリートに移動します。

    cd fleet-examples/fleets/day2/system-upgrade-controller-plans/eib-charts-migration-prep
  4. フリートをデプロイするすべてのダウンストリームクラスタを指すtargets.yamlファイルを作成します。

    cat > targets.yaml <<EOF
    targets:
    - clusterSelector: CHANGEME
    EOF

    ダウンストリームクラスタのマッピング方法については、「Mapping to Downstream Clusters (ダウンストリームクラスタへのマッピング)」を参照してください。

  5. バンドルの構築に進みます。

    注記
    注記

    fleet-examples/fleets/day2/system-upgrade-controller-plans/eib-charts-migration-prepディレクトリのfleet-cliをダウンロード「していない」ことを確認してください。これをダウンロードすると、バンドルにパッケージ化され、これは推奨されません。

    fleet-cli apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-chart-migration-prep . > eib-chart-migration-prep-bundle.yaml

    このプロセスの詳細については、「Convert a Helm Chart into a Bundle (Helmチャートをバンドルに変換する)」を参照してください。

    fleet-cli applyコマンドの詳細については、「fleet apply」を参照してください。

  6. 管理クラスタマシンに eib-chart-migration-prep-bundle.yamlバンドルを転送します。

    scp eib-chart-migration-prep-bundle.yaml <machine-address>:<filesystem-path>
  7. 管理クラスタに、eib-chart-migration-prep-bundle.yamlバンドルをデプロイします。

    kubectl apply -f eib-chart-migration-prep-bundle.yaml
  8. 管理クラスタで、バンドルがデプロイされていることを確認します。

    kubectl get bundle eib-chart-migration-prep -n fleet-default
    NAME                       BUNDLEDEPLOYMENTS-READY   STATUS
    eib-chart-migration-prep   1/1
  9. 管理クラスタに上記のバンドルを作成することで、Fleetは、targets.yamlファイルで指定されたターゲットに一致するSUC Plan (eib-chart-migration-prepと呼ばれる)を各ダウンストリームクラスタ上にデプロイします。このプランのファイルサイクルを監視するには、「System Upgrade Controller Planのモニタリング」(19.3項 「System Upgrade Controller Planのモニタリング」)を参照してください。

27.2.2 マイグレーション手順

前提条件(27.2.1項 「前提条件」)の手順を実行した後で、Edge 3.1.0リリース用のダウンストリームクラスタ(第29章 「ダウンストリームクラスタ)アップグレードドキュメントに従って作業を続行できます。

Documentation survey