次の方法で共有

Azure CLI からのクラスター ランタイムのアップグレード

  • [アーティクル]

この攻略ガイドでは、Operator Nexus を操作するために必要な Azure CLI と拡張機能をインストールする手順について説明します。

前提条件

  1. Azure CLI をインストールする必要があります。
  2. networkcloud CLI 拡張機能が必要です。 networkcloud 拡張機能がインストールされていない場合は、こちらに記載されている手順のようにしてインストールできます。
  3. アップグレードするターゲット クラスターの Azure portal にアクセスします。
  4. az login を使って、ターゲット クラスターと同じサブスクリプションにログインする必要があります
  5. ターゲット クラスターは、実行状態になっていて、すべてのコントロール プレーン ノードが正常で、コンピューティング ノードの 80% 以上が実行中で正常な状態である必要があります。

使用可能なランタイム バージョンの検索

ポータルを使用

使用できるアップグレード可能なランタイム バージョンを見つけるには、Azure portal でターゲット クラスターに移動します。 クラスターの概要ペインで、[Available upgrade versions] (利用可能なアップグレード バージョン) タブに移動します。

使用可能なクラスターのアップグレードを特定するための正しいタブを示す Azure portal のスクリーンショット。

[Available upgrade versions] (利用可能なアップグレード バージョン) タブでは、現在アップグレードに利用できるさまざまなクラスター バージョンを確認できます。 オペレーターは、一覧のターゲット ランタイム バージョンから選択できます。 選んだら、クラスターのアップグレードに進みます。

使用可能なクラスターのアップグレードを示す Azure portal のスクリーンショット。

Azure CLI を使用する

利用できるアップグレードは、Azure CLI を使って取得できます。

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

出力で、availableUpgradeVersions プロパティを見つけて、targetClusterVersion フィールドを確認できます。

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

クラスターに利用できるアップグレードがない場合、一覧は空になります。

CLI を使用したクラスター ランタイムのアップグレード

ランタイムのアップグレードを実行するには、次の Azure CLI コマンドを使います。

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

ランタイムのアップグレードは長いプロセスです。 アップグレードでは、最初に管理ノードをアップグレードした後、ワーカー ノードのラックごとに順番にアップグレードします。 各ラックのワーカー ノードの 80% と管理ノードの 100% が正常にアップグレードされたら、アップグレードは完了したものと見なされます。 ワーカー ノードがアップグレード中であるラック内のワークロードは影響を受ける可能性がありますが、他のすべてのラックのワークロードは影響を受けません。 この実装設計を参考にしてワークロードの配置を検討することをお勧めします。

すべてのノードをアップグレードするには何時間もかかりますが、ファームウェアの更新などの他のプロセスもアップグレードの一部になっている場合は、さらに時間がかかる可能性があります。 アップグレード プロセスは長くかかるため、クラスターの詳細な状態を定期的に調べて、アップグレードの現在の状態を確認することをお勧めします。 アップグレードの状態を調べるには、クラスターの詳細な状態を観察します。 このチェックは、ポータルまたは az CLI を使って行うことができます。

Azure portal を使ってアップグレードの状態を確認するには、対象のクラスター リソースに移動します。 クラスターの [概要] 画面には、詳細な状態と詳細なステータス メッセージが表示されます。

detailedStatus が Updating に設定され、detailedStatusMessage にアップグレードの進行状況が示される場合、クラスターのアップグレードは進行中です。 detailedStatusMessage に表示されるアップグレードの進行状況の例としては、Waiting for control plane upgrade to complete...、Waiting for nodepool "<rack-id>" to finish upgrading... などがあります。

detailedStatus が Running に設定され、detailedStatusMessage にメッセージ Cluster is up and running が表示されると、クラスターのアップグレードは完了します

進行中のクラスターのアップグレードを示す Azure portal のスクリーンショット。

Azure CLI でアップグレードの状態を確認するには、az networkcloud cluster show を使います。

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

出力はターゲット クラスターの情報であり、クラスターの詳細な状態と詳細なステータス メッセージが含まれるはずです。 アップグレードの進行状況をより詳細に把握するには、各ラック内の個々の BMM の状態を確認します。 この例については、リファレンス セクションの「BareMetal マシンの役割」を参照してください。

クラスターの updateStrategy を使用してランタイム アップグレードのコンピューティングしきい値パラメーターを構成する

ランタイム アップグレードのコンピューティングしきい値パラメーターを構成するには、次の Azure CLI コマンドを使います。

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks>

[Required parameters]\(必須のパラメーター\):

  • strategy-type: 更新戦略を定義します。 この場合の "Rack" は、ラックごとに更新を行うことを意味します。 既定値は "Rack" です。
  • threshold-type: 戦略で定義されている単位で適用される、しきい値の評価方法を決定します。 既定値は "PercentSuccess" です。
  • threshold-value: 更新を評価するために使われる数値のしきい値。 既定値は 80 です。

省略可能なパラメーター:

  • max-unavailable: オフラインにできるワーカー ノード (つまり、一度にアップグレードされるラック) の最大数。 既定値は 32767 です。
  • wait-time-minutes: ラックを更新する前の遅延または待機期間。 既定値は 15です。

コマンドの使用例を次に示します。

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

コマンドが正常に実行されると、指定した updateStrategy の値がクラスターに適用されます。

    "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    }

Note

しきい値が 100% 未満に設定されている場合、正常ではないノードがアップグレードされていない可能性があるにもかかわらず、"クラスター" の状態はアップグレードが成功したことを示すことがあります。 ベアメタル マシンに関する問題のトラブルシューティングについては、「Azure Operator Nexus サーバーの問題のトラブルシューティング」を参照してください

PauseRack 戦略を使用したアップグレード

API バージョン 2024-06-01-preview 以降、ランタイム アップグレードは "PauseRack" 戦略を使用してトリガーできます。 "PauseRack" 戦略を使用してクラスター ランタイムのアップグレードを実行すると、クラスター内のラックが 1 つずつ順に更新され、次のラックに進む前に確認を求めるメッセージが表示されます。 "PauseRack" 戦略では、既存のすべてのしきい値が引き続き適用されます。 "PauseRack" 戦略を使用してクラスター ランタイムのアップグレードを実行するには、PauseRack 戦略を使用したクラスター ランタイムのアップグレードに関する記事で説明されている手順に従います

よく寄せられる質問

クラスター アップグレードのストールまたはスタックの識別

ランタイムのアップグレードの間に、アップグレードが先に進んでいないのに、詳細な状態ではアップグレードがまだ進行中であることが示される場合があります。 ランタイムのアップグレードは正常に完了するまでに非常に長い時間がかかる可能性があるため、現在は一定のタイムアウトの長さは指定されていません。 そのため、クラスターの詳細な状態とログを定期的に調べて、アップグレードがいつまでもアップグレードを試みているかどうか判断することをお勧めします。

そうなっている場合は、クラスターのログ、詳細メッセージ、詳細なステータス メッセージを調べることで特定できます。 タイムアウトが発生した場合は、クラスターが同じことをいつまでも調整し続けていて、先に進まないことがわかります。 その後は、クラスターのログまたは構成されている LAW を調べて、障害が発生したかどうか、または特定のアップグレードが原因で進行しなくなっているかどうかを確認することをお勧めします。

ハードウェア障害ではアップグレードの再実行は必要ない

アップグレードの間にハードウェア障害が発生した場合、コンピューティング ノードと管理および制御ノードに設定されているしきい値が満たされている限り、ランタイム アップグレードは続行されます。 マシンが修理または交換されると、現在のプラットフォーム ランタイムの OS でプロビジョニングされ、これには対象となるバージョンのランタイムが含まれます。

ハードウェア障害が発生し、コンピューティング ノードと制御ノードのしきい値が満たされなかったためにランタイム アップグレードが失敗した場合、障害が発生したタイミングと、ラック内の個々のサーバーの状態によっては、ランタイム アップグレードの再実行が必要になることがあります。 障害の前にラックが更新された場合、ノードの再プロビジョニング時にはアップグレードされたランタイム バージョンが使われます。 ハードウェア障害が発生する前に、ラックの仕様がアップグレードされたランタイム バージョンに更新されなかった場合、マシンは以前のランタイム バージョンでプロビジョニングされます。 新しいランタイム バージョンにアップグレードするには、新しいクラスター アップグレード要求を送信します。これにより、以前のランタイム バージョンのノードのみがアップグレードされます。 前のアップグレード アクションが正常に行われたホストはアップグレードされません。

ランタイムのアップグレード後に、クラスターに "Failed" というプロビジョニング状態が表示される

ランタイム アップグレード中に、クラスターは Upgrading という状態になります。 ランタイムのアップグレードに失敗した場合、クラスターは Failed というプロビジョニングの状態になります。 アップグレード中の失敗は、インフラストラクチャ コンポーネント (ストレージ アプライアンスなど) によって発生する可能性があります。 一部のシナリオでは、Microsoft サポートによるエラーの診断が必要になる場合があります。

クラスター ランタイム アップグレード中の Nexus Kubernetes テナント ワークロードへの影響

ランタイム アップグレード中に、影響を受ける Nexus Kubernetes クラスター ノードは、ベア メタル ホスト (BMH) がアップグレードされる前に切断され、ドレインされます。 Kubernetes クラスター ノードを切断すると、そのノードで新しいポッドがスケジュールされなくなり、Kubernetes クラスター ノードをドレインすると、テナント ワークロードを実行しているポッドを別の使用可能な Kubernetes クラスター ノードに移行できるようになるため、サービスへの影響を軽減できます。 ドレイン メカニズムの有効性は、Nexus Kubernetes クラスター内の使用可能な容量に左右されます。 Kubernetes クラスターの容量がほぼいっぱいであり、ポッドを再配置するためのスペースがない場合、それらはドレイン プロセスの後に保留中の状態に移行します。

テナント クラスター ノードの切断とドレインのプロセスが完了すると、BMH のアップグレードが行われます。 各テナント クラスター ノードは、ドレイン プロセスが完了するまで最大 10 分の時間が与えられ、その後、BMH のアップグレードが開始されます。 これにより、BMH のアップグレードが確実に進行します。 BMH は一度に 1 つのラックでアップグレードされ、アップグレードは同じラック内で並行して実行されます。 BMH アップグレードでは、テナント リソースがオンラインになるのを待たずに、アップグレード対象のラック内の BMH のランタイム アップグレードを続行します。 このことの利点は、使用可能なノードの数に関係なく、ラック アップグレードの全体的な最大待機時間が 10 分に維持される点です。 この最大待機時間は、切断とドレインの手順に固有であり、全体的なアップグレード手順には適用されません。 各 BMH アップグレードが完了すると、Nexus Kubernetes クラスター ノードが起動し、クラスターに再参加して、切断が解除され、ポッドをノードで再びスケジュールできるようになります。

Nexus Kubernetes クラスター ノードは、切断とドレインのプロセスの後にシャットダウンされない点に注意することが重要です。 すべての Nexus Kubernetes クラスター ノードが切断されてドレインされるとすぐに、あるいは、ドレイン プロセスが完了していない場合は 10 分後に、BMH は新しいイメージで再起動されます。 また、切断とドレインは、BMH の電源オフまたは再起動アクションでは開始されません。ランタイム アップグレード中にのみ排他的にアクティブ化されます。

ランタイムのアップグレード後に、Nexus Kubernetes クラスター ノードが切断されたままになる場合があることに注意することが重要です。 このようなシナリオでは、次のコマンドを実行することで、ノードの切断を手動で解除できます

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table