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

[アーティクル]
09/02/2024

このアーティクルでは、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 のインストールに関するページを参照してください
最小限必要な networkcloudaz-cli 拡張機能バージョン: 2.0.b3
バージョンバンドルの概念を理解します。詳細については、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 ポータルの使用

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

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

使用可能なアップグレード出力は、アップグレードの選択の対象として複数のバージョンがあることを示しています。この特定のシナリオでは、現在のクラスターはバージョン 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 バージョンの新しいワーカーノードがクラスターに追加されます (または、最大サージで構成された数のノード)
サージなしでワーカーノードをアップグレードする場合:
- クラスター内の各エージェントプールについて、古いワーカーノード (または最大使用不可によって構成されている数のノード) が切断、ドレイン、削除された後、指定した Kubernetes バージョンの新しいワーカーノードに置き換えられます。複数のエージェントプールが同時にアップグレードされます。
- アップグレード中は、古いワーカーノードからドレインされたポッドに、移動先の新しいノードがすぐにはないため、クラスターの容量が一時的に減少します。これにより、十分な容量がない場合に、ポッドが保留中の状態に入る可能性があります。そのため、特にサージなしのアップグレード中に、アプリケーションの容量要件を満たすようにクラスターを設計することが重要です。
このプロセスは、クラスター内のすべてのワーカーノードがアップグレードされるまで繰り返されます。

Note

オペレーティングシステム (OS) のイメージバージョンと Kubernetes バージョンがバージョンバンドル間で同じままの場合、クラスターのアップグレードで新しいノードは作成されず、古いノードが置き換えられます。アップグレードには、新しい OS または K8s バージョンではなくアドオンバージョンの更新プログラムのみが含まれる可能性があるため、これは予期される動作です。ローリングアップグレードは関係しないため、ノードで切断およびドレインはなく、ポッドの中断は発生しません。

重要

すべての PodDisruptionBudgets (PDB) で、少なくとも 1 つの ポッドレプリカを一度に移動できるようにしてください。そうしないと、ドレイン/削除操作は失敗します。ドレイン操作が失敗した場合、アップグレード操作も失敗し、アプリケーションが中断されないようにします。操作が停止した原因 (つまり、PDB が正しくない、クォータ不足など) を修正し、操作を再試行してください。ワーカーノードプールごとにドレインタイムアウトを構成することもできます。このタイムアウトが経過すると、ポッドのドレインがまだ完了していなくてもノードが削除されます。これにより、正しく構成されていない PDB によってアップグレードがブロックされるのを防ぐことができます。ドレインタイムアウト設定は秒単位で構成し、既定値は 1800 です。

networkcloud kubernetescluster update コマンドを使用してクラスターをアップグレードします。

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

show コマンドを使用して、アップグレードが成功したことを確認します。

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

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

"v1.26.3"

クラスターが正常であることを確認します。

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% にすることをお勧めします。

リソースの制約のある環境などでは、サージによるアップグレードが常に適切であるとは限りません。アップグレードはサージなしで進めることもでき、その場合、まずワーカーノードが削除されてから、置き換えられます。これは、追加のリソースが必要ないことを意味しますが、容量が減少する期間が発生し、その間、ポッドをノードにスケジュールできない可能性があります。この種類のアップグレードは、最大使用不可設定によってノードプールごとに制御されます。既定では、最大使用不可は 0 に設定されています。これは、最大 0 個のノードが使用できないことを示します。つまり、この種類のアップグレードは既定では行われません。

API は、最大サージと最大使用不可の整数値とパーセンテージ値の両方を受け入れます。 5 などの整数は、5 つのノードをサージまたは使用不可にできることを示します。値 50% は、プール内の現在のノード数の半分のサージまたは使用不可の値を示します。

最大サージまたは最大利用不可の 1 つが少なくとも 1 (または 1%) である必要があります。そうでない場合、クラスターをアップグレードできるメカニズムがなくなります。パーセント値は、最も近いノード数に切り上げられます。最大サージと最大使用不可の両方を最大 100% に設定できます。最大サージ値が、アップグレードが必要なノードの数より大きい場合、アップグレードするノードの数が最大サージ値に使用されます。

最大サージと最大使用不可を同時に構成できます。その場合、アップグレードはサージと使用不可を組み合わせて続行されます。

重要

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

次のステップ

Nexus Kubernetes バージョンバンドルの詳細について参照してください。

次の方法で共有