Azure Kubernetes Service (AKS) クラスターのアップグレード オプション

  • [アーティクル]

この記事では、AKS クラスターのさまざまなアップグレード オプションについて説明します。 基本的な Kubernetes バージョンのアップグレードを実行するには、「AKS クラスターのアップグレード」を参照してください。

複数のノード プールまたは Windows Server ノードを使用する AKS クラスターについては、AKS 内のノード プールのアップグレードに関するページを参照してください。 Kubernetes クラスターをアップグレードせずに特定のノード プールをアップグレードするには、「特定のノード プールのアップグレード」を参照してください。

手動アップグレードの実行

手動アップグレードを実行して、クラスターを新しい Kubernetes バージョンにアップグレードするタイミングを制御できます。 手動アップグレードは、運用クラスターをアップグレードする前に新しい Kubernetes バージョンをテストする場合に便利です。 手動アップグレードを使って、クラスターを使用できる最新バージョンではない特定の Kubernetes バージョンにアップグレードすることもできます。

手動アップグレードを実行するには、次の記事を参照してください。

自動アップグレードを構成する

クラスターを使用できる最新の Kubernetes バージョンに自動的にアップグレードするように自動アップグレードを構成できます。 自動アップグレードは、クラスターが常に最新の Kubernetes バージョンを実行している必要がある場合に便利です。 自動アップグレードを使って、クラスターが常にサポートされている Kubernetes バージョンが実行されるようにすることもできます。

自動アップグレードを構成するには、次の記事を参照してください。

複数の可用性ゾーンにまたがるノード プールに関する特別な考慮事項

AKS では、ノード グループでのベストエフォート ゾーン バランシングが使用されます。 アップグレード サージ中、Virtual Machine Scale Sets のサージ ノードのゾーンは事前に不明であるため、アップグレード中にゾーン構成が一時的に不均衡になる可能性があります。 ただし、アップグレードが完了すると、AKS によりサージ ノードが削除され、元のゾーン バランスが維持されます。 アップグレード中にゾーンのバランスを維持したい場合は、サージを 3 つのノードの倍数に増やします。すると、Virtual Machine Scale Sets により、ベスト エフォートのゾーン分散を使用して可用性ゾーン間でノードのバランスが保たれます。 ベスト エフォートのゾーン バランスでは、スケール セットはバランスを維持しながらスケールインとスケールアウトを試みます。 ただし、何らかの理由によりそれが不可能な場合 (たとえば、1 つのゾーンがダウンして、スケール セットがそのゾーンに新しい VM を作成できなくなった場合)、スケール セットは、スケールインまたはスケールアウトを成功させるため、一時的なアンバランスを許可します。

Azure ローカル冗長ストレージ (LRS) ディスクによってサポートされる永続ボリューム要求 (PVC) は特定のゾーンにバインドされており、サージ ノードが PVC のゾーンと一致しない場合、すぐに回復できない可能性があります。 ゾーンが一致しない場合、アップグレード操作によってノードのドレインが続行されても、PV がゾーンにバインドされていると、アプリケーションのダウンタイムが発生する可能性があります。 このようなケースに対応し、高可用性を維持するには、アプリケーションにポッド中断予算を構成して、ドレイン操作中に Kubernetes が可用性要件を尊重できるようにします。

使用できないノードの動作を最適化する (プレビュー)

ドレイン エラーのアップグレード プロセスの動作を構成できます。 既定のアップグレード動作は Schedule です。これは、ノードのドレイン エラーによって構成され、アップグレード操作が失敗し、枯渇していないノードはスケジュール可能な状態になります。 または、Cordon の動作を選択できます。これにより、検疫された状態に配置してドレインに失敗したノードをスキップし、kubernetes.azure.com/upgrade-status:Quarantined ラベルを付け、残りのノードのアップグレードを続行できます。 この動作により、すべてのノードがアップグレードまたは検疫されます。 この方法では、ドレイン エラーのトラブルシューティングを行い、検疫されたノードを適切に管理できます。

新しい Cordon 動作を設定する方法

CLI プレビューを使用し、aks-preview 拡張機能 9.0.0b3 以降をインストールします。

次のコマンドを使用して、拡張機能 aks-preview をアップグレードまたはインストールできます。

az extension update --name aks-preview

az extension add --name aks-preview

ノード プールの読み取り不可能なノードの動作を Cordon に更新します。

az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon

次の出力例は、アップグレードされた、読み取り不可能なノードの動作を示しています。

"upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxSurge": "1",
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": "Cordon"
  }

ブロックされているノードのラベルを確認します。 次のコマンドを使用して、アップグレード時にドレイン ノードの障害が発生した場合:

kubectl get nodes --show-labels=true

ブロックされたノードはポッドに対してスケジュール解除され、ラベル "kubernetes.azure.com/upgrade-status: Quarantined" でマークされます。 ブロックしたままにできるノードの最大数は、Max-Surge 値を超えることはできません。

ブロックされたノードを削除する方法

まず、ドレインの原因となっている問題を解決します。 次の例では、責任ある PDB を削除します。

kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.

次に、az aks nodepool delete-machines コマンドを使用して、ブロックされたノードを削除します。 このコマンドは、古いバージョンで残っているノードを削除してノード プールのフットプリントを減らす場合に便利です。

az aks nodepool delete-machines --cluster-name MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG

この手順を完了した後は、ここで説明するオプションのフィールドを指定せずにアップグレード操作を実行することで、クラスターの状態を調整できます。

コマンドの例:

az aks update --resource-group TestRG --name MyCluster

または、ノード プールを、アップグレードされたノードの数と同じ数のノードにスケーリングすることもできます。 このアクションにより、ノード プールが意図した元のサイズに到達します。 AKS は、ブロックされたノードの削除に優先順位を付けます。 また、このコマンドは、クラスターのプロビジョニング状態を Succeeded に復元します。 この例では、2 はアップグレードされたノードの合計数です。

az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2

アップグレードを最適化してパフォーマンスを改善し中断を最小限に抑える

計画メンテナンス期間、最大サージ、ポッド中断バジェット、ノード ドレイン タイムアウト、ノード ソーク時間を組み合わせると、メンテナンス期間の終了までにノード アップグレードが正常に完了する可能性が大幅に高まるだけでなく、中断も最小限に抑えられます。

  • 計画メンテナンス期間によってサービス チームは、事前に定義された期間中 (通常はトラフィックの少ない期間) に自動アップグレードをスケジュールして、ワークロードへの影響を最小限に抑えることができます。 少なくとも "4 時間" の期間を設けることをお勧めします。
  • ノード プールの最大サージにより、アップグレード プロセス中に追加のクォータを要求することができ、同時にアップグレードするために選ばれるノードの数が制限されます。 最大サージが大きいほど、アップグレード プロセスが高速になります。 すべてのノードが同時にアップグレードされ、実行中のアプリケーションが中断される可能性があるため、100% に設定することはお勧めしません。 運用ノード プールには、最大サージ クォータを 33% にすることをお勧めします。
  • ポッド中断バジェットはサービス アプリケーションに対して設定され、AKS によって制御されるノードのアップグレードなど、自発的な中断の最中にダウンする可能性があるポッドの数を制限します。 これは、アクティブである必要があるアプリケーション ポッドの最小数を示す minAvailable レプリカとして、あるいは終了できるアプリケーション ポッドの最大数を示す maxUnavailable レプリカとして構成してアプリケーションの高可用性を確保することができます。 ポッド中断バジェット (PDB) の構成に関して提供されているガイダンスを参照してください。 PDB 値を検証して、特定のサービスに最適な設定を決定する必要があります。
  • ノード プールのノード ドレイン タイムアウトを使用すると、アップグレード中におけるポッドの削除とノードごとの正常終了の待機時間を構成できます。 このオプションは、長期のワークロードを処理する場合に役立ちます。 ノード ドレイン タイムアウトが (分単位で) 指定されているとき、AKS では、ポッド中断バジェットで待機を適用します。 指定されていない場合、既定のタイムアウトは 30 分です。
  • ノード ソーク時間によって、ノードのアップグレードを制御された方法でずらすことができ、アップグレード中のアプリケーションのダウンタイムを最小限にすることができます。 ノードのアップグレード間のアプリケーションの準備状況を確認するために、待機時間 (できるだけ 0 分に近い値が望ましい) を指定できます。 指定しない場合、既定値の 0 分が使用されます。 ノードのソーク時間は、ノード プールで使用可能な最大サージおよびノード ドレイン タイムアウトのプロパティと共に機能し、アップグレードの速度とアプリケーションの可用性という点で適切な結果が得られるようにします。

次のステップ

この記事では、AKS クラスターのさまざまなアップグレード オプションを示しました。 アップグレードのベスト プラクティスとその他の考慮事項の詳細については、「AKS のパッチとアップグレードのガイダンス」を参照してください。