Share via

Azure Operator Nexus Kubernetes クラスターをアップグレードする

  • [アーティクル]

このアーティクルでは、Operator Nexus Kubernetes クラスターをアップグレードして最新のフィーチャーとセキュリティ更新プログラムを取得する方法について説明します。 Kubernetes クラスターのライフサイクルのパーツには、最新の Kubernetes バージョンへの定期的なアップグレードの実行が含まれます。 最新のセキュリティ リリースを適用するか、アップグレードして最新の機能を入手することが重要です。 このアーティクルでは、Kubernetes クラスターのアップグレードを確認、構成、適用する方法について説明します。

制限事項

  • クラスターのアップグレード プロセスはスケールアウトアプローチです。つまり、少なくとも 1 つのノードが追加されます (または、最大サージ で構成されたノード数)。 十分な容量がない場合、アップグレードは成功しません。
  • 新しい Kubernetes バージョンが使用可能になると、テナント クラスターは自動アップグレードされません。 クラスター内のすべてのネットワーク機能が新しい Kubernetes バージョンをサポートする準備ができたら、アップグレードを開始する必要があります。 詳細については、「 クラスターのアップグレード」を参照してください。
  • Operator Nexus は、クラスター全体のアップグレードを提供し、すべてのノード プールの一貫性を確保します。 単一ノード プールのアップグレードはサポートされていません。 また、新しいバージョンが使用可能になると、ノード イメージはクラスター アップグレードの一環としてアップグレードされます。
  • エージェント ノードに対して行われたカスタマイズは、クラスターのアップグレード中に失われます。 これらのカスタマイズは、アップグレード後にノード構成を保持するために手動で変更するのではなく、 DaemonSet に配置することをお勧めします。
  • コア アドオン構成に加えられた変更は、クラスターのアップグレード プロセスの一環としてデフォルトのアドオン構成に復元されます。 アップグレード失敗の可能性を防ぐため、アドオン構成 (Calico など) のカスタマイズは避けてください。 アドオン構成の復元でイシューが発生した場合、アップグレード失敗が発生する可能性があります。
  • Operator Nexus Kubernetes クラスターをアップグレードすると、Kubernetes のマイナー バージョンをスキップできません。 すべてのアップグレードは、メジャー バージョン番号の順番に実行する必要があります。 たとえば、1.14.x ->1.15.x または 1.15.x ->1.16.x の間のアップグレードは許可されていますが、1.14.x ->1.16.x は許可されていません。 バージョンが複数のメジャー バージョンより遅れている場合は、複数の連続したアップグレードを実行する必要があります。
  • 最大サージ値は、クラスターの作成時に設定する必要があります。 クラスターの作成後に最大サージ値を変更することはできません。 詳細については、「 Azure Operator Nexus Kubernetes クラスター の作成」のupgradeSettingsを参照してください。

前提条件

  • Azure サブスクリプションのリソース グループにデプロイされた Azure Operator Nexus Kubernetes クラスター。
  • Azure CLI を使用している場合、この記事では最新の Azure CLI バージョンを実行している必要があります。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください
  • バージョン バンドルの概念を理解します。 詳細については、Nexus Kubernetes バージョン バンドルを参照してください。

利用可能なアップグレードを確認する

次の手順を使用して、ご使用のクラスターに利用できる Kubernetes リリースを確認します。

Azure CLI の使用

次の Azure CLI コマンドは、クラスターで使用可能なアップグレードを返します：

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

サンプル出力:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Azure ポータルの使用

  1. Azure portal にサインインします。
  2. Operator Nexus Kubernetes クラスターに移動します。
  3. [ 概要]で、[利用可能なアップグレード] タブを選択します。

Screenshot of available upgrades.

アップグレードするバージョンを選択する

使用可能なアップグレード出力は、アップグレードの選択の対象として複数のバージョンがあることを示しています。 この特定のシナリオでは、現在のクラスターはバージョン v1.25.4-3. で動作しています。その結果、使用可能なアップグレード オプションには v1.25.4-4 が含まれており、最新のパッチ リリース v1.25.6-1. さらに、新しいマイナー バージョンも使用できます。

使用可能な任意のバージョンに柔軟にアップグレードできます。 ただし、推奨されるアクションは、利用可能な最新の major-minor-patch-versionbundle バージョンへのアップグレードを実行することです。

Note

バージョンの入力形式は major.minor.patch または major.minor.patch-versionbundleです。 バージョン入力は、使用可能なアップグレード バージョンのいずれかである必要があります。 たとえば、現在のバージョンのクラスターが 1.1.1-1の場合、有効なバージョンの入力は 1.1.1-2 または 1.1.1-xです。 1.1.1 は有効な形式ですが、現在のバージョンが既に 1.1.1のため、更新プログラムはトリガーされません。 更新を開始するには、 1.1.1-2など、バージョン バンドルで完全なバージョンを指定できます。 ただし、 1.1.2 と 1.2.x は有効な入力であり、 1.1.2 または 1.2.xで使用できる最新バージョンのバンドルを使用します。

クラスターをアップグレードする

クラスターのアップグレード プロセス中に、Operator Nexus は次の操作を実行します：

  • 指定した Kubernetes バージョンの新しいコントロール プレーン ノードをクラスターに追加します。
  • 新しいノードが追加されたら、古いコントロール プレーン ノードの 1 つを切断してドレインし、そのノードで実行されているワークロードが他の正常なコントロール プレーン ノードに適切に移動されるようにします。
  • 古いコントロール プレーン ノードがドレインされると削除され、新しいコントロール プレーン ノードがクラスターに追加されます。
  • このプロセスは、クラスター内のすべてのコントロール プレーン ノードがアップグレードされるまで繰り返されます。
  • クラスター内のエージェント プールごとに、新しいワーカー ノード (または最大サージ で構成された数のノード) を、指定された Kubernetes バージョンで追加します。 複数のエージェント プールが同時にアップグレードされます。
  • 古いワーカー ノードの 1 つを切断およびドレインし、実行中のアプリケーションの中断を最小限に抑えます。 最大サージを使用している場合は、指定されたバッファー ノードの数と同数のワーカー ノードが同時に切断およびドレインされます。
  • 古いワーカー ノードがドレインされた後、削除され、新しい Kubernetes バージョンの新しいワーカー ノードがクラスターに追加されます (または、最大サージ で構成された数のノード)
  • このプロセスは、クラスター内のすべてのワーカー ノードがアップグレードされるまで繰り返されます。

重要

すべての PodDisruptionBudgets (PDB) で、少なくとも 1 つの ポッド レプリカを一度に移動できるようにしてください。そうしないと、ドレイン/削除操作は失敗します。 ドレイン操作が失敗した場合、アップグレード操作も失敗し、アプリケーションが中断されないようにします。 操作が停止した原因 (つまり、PDB が正しくない、クォータ不足など) を修正し、操作を再試行してください。

  1. networkcloud kubernetescluster update コマンドを使用してクラスターをアップグレードします。
az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3
  1. show コマンドを使用して、アップグレードが成功したことを確認します。
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

次の出力例は、クラスターが v1.26.3 実行されていることを示しています：

"v1.26.3"
  1. クラスターが正常であることを確認します。
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

次の出力例は、クラスターが正常であることを示しています：

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

ノード サージ アップグレードのカスタマイズ

既定では、Operator Nexus は、1 つの追加ワーカー ノードでサージするようにアップグレードを構成します。 最大サージ設定の既定値の 1つ を使用すると、Operator Nexus は、古いバージョン管理されたノードを置き換えるために、既存のアプリケーションの切断/ドレインの前に追加のノードを作成することで、ワークロードの中断を最小限に抑えることができます。 最大サージ値をノード プールごとにカスタマイズすると、アップグレードの速度とアップグレードの中断とのトレードオフが可能になります。 最大サージ値を増やすと、アップグレード プロセスがより速く完了します。 最大サージに大きな値を設定すると、アップグレード プロセス中に中断が発生する可能性があります。

たとえば、最大サージ値が 100% の場合、(ノード数が 2 倍になり) 可能な限り最速のアップグレード プロセスが提供されますが、ノード プール内のすべてのノードが同時にドレインされます。 テスト環境では、このようなより大きな値を使用することができます。 運用ノード プールの場合は、max_surge 設定を 33% にすることをお勧めします。

API は、最大サージの整数値とパーセンテージ値の両方を受け入れます。 たとえば、整数 5 は、サージする 5 つの追加ノードを示します。 値 50% は、プール内の現在のノード数の半分のサージ値を示します。 最大サージのパーセント値には、最低 1%、最大 100% の値を指定できます。 パーセント値は、最も近いノード数に切り上げられます。 最大サージ値が、アップグレードが必要なノードの数より大きい場合、アップグレードするノードの数が最大サージ値に使用されます。

アップグレード中、最大サージ値には、最小値を 1 とし、最大値をノード プール内のノード数とする値を指定することができます。 より大きな値を設定することもできますが、最大サージに使用されるノードの最大数は、アップグレード時のプール内のノードの数を超えることはありません。

重要

標準の Kubernetes ワークロードは、切断されるノードからドレインされると、新しいノードにネイティブに循環します。 Operator Nexus Kubernetes サービスは、非標準の Kubernetes ビヘイビアーに対してワークロードPromiseを行うことができないことに注意してください。

次のステップ