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

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

制限事項

• クラスターの既定のアップグレード プロセスはスケールアウトアプローチです。つまり、少なくとも 1 つの追加ノード (または 最大サージで構成されている数のノード) が追加されます。 十分な容量がない場合、アップグレードは成功しません。
• 新しい Kubernetes バージョンが使用可能になると、テナント クラスターは自動アップグレードされません。 クラスター内のすべてのネットワーク機能が新しい Kubernetes バージョンをサポートする準備ができたら、アップグレードを開始する必要があります。 詳細については、 クラスターのアップグレードを参照してください。
• Operator Nexus は、クラスター全体のアップグレードを提供し、すべてのノード プールの一貫性を確保します。 単一ノード プールのアップグレードはサポートされていません。 また、新しいバージョンが使用可能になると、ノード イメージはクラスター アップグレードの一環としてアップグレードされます。
• エージェント ノードに対して行われたカスタマイズは、クラスターのアップグレード中に失われます。 これらのカスタマイズは、アップグレード後にノード構成を保持するために手動で変更するのではなく、 DaemonSet に配置します。
• コア アドオン構成に加えられた変更は、クラスターのアップグレード プロセスの一環として既定のアドオン構成に復元されます。 アップグレードエラーの可能性を防ぐため、アドオン構成 (Calico など) のカスタマイズは避けてください。 アドオン構成の復元で問題が発生した場合、アップグレードエラーが発生する可能性があります。
• etcd 構成に対する変更は、クラスターのアップグレード プロセスの一環として既定の構成に復元されます。 アップグレードエラーの可能性を防ぐために etcd 構成をカスタマイズしないようにします。 etcd 構成の復元で問題が発生すると、アップグレードエラーが発生する可能性があります。
• Operator Nexus Kubernetes クラスターをアップグレードすると、Kubernetes のマイナー バージョンをスキップできません。 すべてのアップグレードは、マイナー バージョン番号で順番に実行する必要があります。 たとえば、 1.14.x ->1.15.x または 1.15.x ->1.16.x 間のアップグレードは許可されますが、 1.14.x ->1.16.x は許可されません。 バージョンが複数のマイナー バージョンによって遅れている場合は、複数の順次アップグレードを実行する必要があります。
• マイナー バージョン間の一部のアップグレード パスは、サポートされていないコンポーネントのアップグレード パスがバージョン バンドル内に入れ子になっているためにブロックされる可能性があります。 ユーザーは、アプリケーションがバージョン バンドル内のすべてのアップグレードを含むアップグレード パスをサポートしていることを確認する必要があります。 バージョン バンドルのアップグレード間でジャンプが大きくなると、リスクが高まります。 アップグレードエラーのリスクを最小限に抑えるために、クラスターを頻繁に更新して最新バージョンに近づける。

[前提条件]

• Azure サブスクリプションのリソース グループにデプロイされた Azure Operator Nexus Kubernetes クラスター。
• Azure CLI を使用している場合、この記事では最新の Azure CLI バージョンを実行している必要があります。 インストールまたはアップグレードする必要がある場合は、「Azure CLI のインストール」を参照してください
• az-cli 拡張機能のバージョン networkcloud 必要最小限: 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 portal を使用する

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

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

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

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

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

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

• 指定した Kubernetes バージョンの新しいコントロール プレーン ノードをクラスターに追加します。
• 新しいノードが追加されたら、既存の制御プレーンノードのうち1つをコーディングしてドレインします。 その上で実行されているワークロードが、他の正常なコントロール プレーン ノードに正常に移動されていることを確認します。
• 古いコントロール プレーン ノードがドレインされると削除され、新しいコントロール プレーン ノードがクラスターに追加されます。
• このプロセスは、クラスター内のすべてのコントロール プレーン ノードがアップグレードされるまで繰り返されます。
• サージを使用してワーカー ノードをアップグレードする場合 (既定値):
  • クラスター内のエージェント プールごとに、指定した Kubernetes バージョンの新しいワーカー ノード (または 最大サージで構成された数のノード) を追加します。 複数のエージェント プールが同時にアップグレードされます。
  • 実行中のアプリケーションの中断を最小限に抑えるために、古いワーカー ノードの 1 つをコルドンしてドレインします。 最大サージを使用している場合、指定されたバッファーノード数に応じて、ワーカーノードが同時に隔離され、解放されます。
  • 古いワーカーノードがドレインされた後に削除され、新しい Kubernetes バージョンのワーカーノードがクラスターに追加されます（または 最大サージで設定された数のノードが追加されます）
• サージなしでワーカー ノードをアップグレードする場合:
  • クラスター内のエージェント プールごとに、古いワーカー ノード (または 最大使用不可で構成された数のノード) が、指定された Kubernetes バージョンの新しいワーカー ノードに置き換えられる前に、切断、ドレイン、および削除されます。 複数のエージェント プールが同時にアップグレードされます。
  • アップグレード中、古いワーカーノードからポッドがドレインされ、新しいノードにすぐ移動できないため、クラスターの容量が一時的に減少します。 これにより、十分な容量がない場合、ポッドが保留中の状態に入る可能性があります。 そのため、特にサージなしのアップグレード中に、アプリケーションの容量要件を満たすようにクラスターを設計することが重要です。
• このプロセスは、クラスター内のすべてのワーカー ノードがアップグレードされるまで繰り返されます。

アップグレードする前に、ワークロードをドレインできるように準備してください。 PodDisruptionBudgets (PDB) で、少なくとも 1 つのポッド レプリカを一度に移動できることを確認します。 また、削除できない終了猶予期間、ファイナライザー、ノード アフィニティとトポロジの制約、クラスターの容量、ワークロードも確認します。 これらの条件により、ドレインが完了するのを防ぐことができます。

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

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

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

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

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

"v1.26.3"

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 倍) が提供されますが、ノード プール内のすべてのノードが同時にドレインされます。 テスト環境には、このような高い値を使用することを検討すると良いでしょう。 運用ノード プールの場合は、33%のmax_surge設定をお勧めします。

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

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

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

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

エージェント プールの作成後に、 maxSurge、 maxUnavailable、および upgradeSettings のドレイン設定を更新できます。 これらの設定を変更すると、既存のエージェント プールの構成が更新され、それ自体でノードが置き換えられたりロールされたりすることはありません。 アップグレード中に設定を変更すると、アップグレードを開始していないノードに新しい設定が適用されます。

たとえば、次のコマンドを使用して、30 分のドレイン タイムアウトでエージェント プールを更新します。

az networkcloud kubernetescluster agentpool update \
  --agent-pool-name <agent-pool-name> \
  --kubernetes-cluster-name <cluster-name> \
  --resource-group <resource-group> \
  --upgrade-settings drain-timeout=1800

ワーカー ノードのドレイン タイムアウトを設定する

ドレイン設定は、アップグレードまたはスケールダウン中に各ワーカー ノードがドレインされるまでに Operator Nexus が待機する時間を制御します。 これらの設定は、コントロール プレーン ノードには適用されません。 コントロールプレーンのドレインタイムアウトは5分に固定されており、設定できません。

各ワーカー ノードがドレインされるまで待機する最大秒数で upgradeSettings.drainTimeout を構成します。 この設定を省略すると、ドレイン タイムアウトは 1,800 秒 (30 分) になります。

Standard Kubernetes ワークロードは、古いノードがドレインされると、新しいノードにネイティブに循環します。 オペレーターの Nexus Kubernetes サービスでは、非標準の Kubernetes 動作に対してワークロードを保証することはできません。

次のステップ

• Nexus Kubernetes バージョン バンドルの詳細を確認します。