Azure Kubernetes Service (AKS) クラスターのアップグレード
AKS クラスター ライフサイクルの一部には、最新の Kubernetes バージョンへの定期的なアップグレードの実行が含まれます。 最新のセキュリティ リリースを適用するか、アップグレードして最新の機能を入手することが重要です。 この記事では、AKS クラスターへのアップグレードを確認、構成、適用する方法について説明します。
複数のノード プールまたは Windows Server ノードを使用する AKS クラスターについては、AKS 内のノード プールのアップグレードに関するページを参照してください。 Kubernetes クラスターのアップグレードを行わずに特定のノード プールをアップグレードするには、「特定のノード プールのアップグレード」を参照してください。
警告
Calico を有効にしている AKS クラスターを Kubernetes v1.25 プレビューにアップグレードしないでください。
注意
手動でも自動でも、アップグレード操作を実行すると、ノード イメージのバージョンがまだ最新でない場合はアップグレードされます。 最新バージョンは完全な AKS リリースに依存しており、AKS リリース トラッカーにアクセスすることで特定できます。
注意
アップグレード操作を実行するには、Microsoft.ContainerService/managedClusters/agentPools/write RBAC ロールが必要です。 Azure RBAC ロールの詳細については、「Azure リソース プロバイダーの操作」を参照してください
開始する前に
- Azure CLI を使用する場合、この記事では、Azure CLI バージョン 2.34.1 以降を実行する必要があります。 バージョンを確認するには、
az --versionを実行します。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。 - Azure PowerShell を使用する場合、このチュートリアルでは、Azure PowerShell バージョン 5.9.0 以降を実行する必要があります。 バージョンを確認するには、
Get-InstalledModule -Name Azを実行します。 インストールまたはアップグレードする必要がある場合は、Azure PowerShell のインストールに関するページをご覧ください。
警告
AKS クラスターのアップグレードで、ノードの切断とドレインがトリガーされます。 使用可能なコンピューティング クォータが少ない場合は、アップグレードが失敗する可能性があります。 詳しくは、「クォータの増加」をご覧ください。
利用できる AKS クラスターのアップグレードを確認する
ご使用のクラスターに利用できる Kubernetes リリースを確認するには、az aks get-upgrades コマンドを使用します。 次の例では、myResourceGroup で myAKSCluster への使用可能なアップグレードを確認します。
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
Note
サポートされている AKS クラスターをアップグレードする場合、Kubernetes マイナー バージョンはスキップできません。 すべてのアップグレードは、メジャー バージョン番号で順番に実行する必要があります。 たとえば、1.14.x - >1.15.x または 1.15.x - >1.16.x の間のアップグレードは許可されていますが、1.14.x - >1.16.x は許可されていません。
複数のバージョンのスキップは、"サポートされていないバージョン" から "サポートされているバージョン" にアップグレードする場合にのみ可能です。 たとえば、サポートされていない 1.10.x -> サポートされている 1.15.x というアップグレードは、使用可能な場合には実行できます。 2 つ以上のマイナー バージョンをスキップしているサポート対象外バージョンからのアップグレードを実行すると、そのアップグレードは機能の保証なしで実行され、サービス レベル アグリーメントと限定的保証から除外されます。 バージョンが大幅に古い場合は、クラスターを再作成することをお勧めします。
次の出力例は、クラスターをバージョン 1.19.1 と 1.19.3 にアップグレードできることを示しています。
Name ResourceGroup MasterVersion Upgrades
------- --------------- --------------- --------------
default myResourceGroup 1.18.10 1.19.1, 1.19.3
次の出力例は、appservice-kube 拡張機能が Azure CLI バージョンと互換性がないことを意味します (バージョン 2.34.1 以降が必要)。
The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
この出力が返された場合は、Azure CLI のバージョンを更新する必要があります。 az upgrade コマンドはバージョン 2.11.0 で追加されたもので、2.11.0 より前のバージョンでは動作しません。 以前のバージョンは、「Azure CLI のインストール」の説明に従って Azure CLI を再インストールすることによって更新できます。 Azure CLI バージョンが 2.11.0 以降の場合は、az upgrade を実行して Azure CLI を最新バージョンにアップグレードするよう求めるメッセージが表示されます。
Azure CLI が更新され、次の出力例が返された場合は、アップグレードが利用できないということです。
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
アップグレードを使用できない場合、サポートされている Kubernetes バージョンを使用して新しいクラスターを作成し、既存のクラスターからこの新しいクラスターにワークロードを移行します。 az aks get-upgrades でアップグレードを使用できないことが示される場合に、クラスターを新しい Kubernetes バージョンにアップグレードすることはサポートされていません。
ノード サージ アップグレードのカスタマイズ
重要
ノード サージには、アップグレード操作ごとに、要求された最大サージ カウントに対するサブスクリプション クォータが必要です。 たとえば、クラスターに 5 つのノード プールがあり、そのそれぞれに 4 つのノードが含まれる場合、合計で 20 個のノードがあります。 各ノード プールの最大サージ値が 50% の場合、アップグレードを完了するには、10 ノード (2 ノード * 5 プール) の追加のコンピューティングおよび IP クォータが必要です。
Azure CNI を使用する場合は、サブネット内に使用可能な IP があることと、Azure CNI の IP 要件を満たしていることを検証します。
AKS は、既定で、1 つの追加ノードを使用してサージ操作するようにアップグレードを構成します。 最大サージ設定の既定値は 1 です。これにより、AKS は、既存のアプリケーションの切断またはドレインの前に追加のノードを作成して古いバージョンのノードを置き換えることにより、ワークロードの中断を最小限に抑えることができます。 最大サージ値をノード プールごとにカスタマイズすると、アップグレードの速度とアップグレードの中断とのトレードオフが可能になります。 最大サージ値を大きくすることでアップグレード プロセスはより速く完了しますが、最大サージに大きな値を設定するとアップグレード プロセス中に中断が発生する可能性があります。
たとえば、最大サージ値が 100% の場合、(ノード数が 2 倍になり) 可能な限り最速のアップグレード プロセスが提供されますが、ノード プール内のすべてのノードが同時にドレインされます。 テスト環境では、このようなより大きな値を使用することをお勧めします。 運用ノード プールの場合は、max_surge 設定を 33% にすることをお勧めします。
AKS では、最大サージに対して整数値とパーセント値の両方を受け入れます。 たとえば、整数 "5" は、サージする 5 つの追加ノードを示します。 値 "50%" は、プール内の現在のノード数の半分のサージ値を示します。 最大サージ パーセント値には、最低 1%、最大 100% の値を指定できます。 パーセント値は、最も近いノード数に切り上げられます。 最大サージ値が、アップグレードが必要なノードの数より大きい場合、アップグレードするノードの数が最大サージ値に使用されます。
アップグレード中、最大サージ値には、最小値を 1 とし、最大値をノード プール内のノード数とする値を指定することができます。 より大きな値を設定することもできますが、最大サージに使用されるノードの最大数は、アップグレード時のプール内のノードの数を超えることはありません。
重要
ノード プールの最大サージ設定は永続的です。 以降の Kubernetes アップグレードまたはノード バージョンのアップグレードでは、この設定が使用されます。 ノード プールの最大サージ値はいつでも変更できます。 運用ノード プールの場合は、最大サージ設定を 33% にすることをお勧めします。
新規または既存のノード プールの最大サージ値を設定するには、次のコマンドを使用します。
# Set max surge for a new node pool
az aks nodepool add -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%
# Update max surge for an existing node pool
az aks nodepool update -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
AKS クラスターのアップグレード
AKS クラスターに利用できるバージョンの一覧を参照し、az aks upgrade コマンドを使用してアップグレードします。 アップグレード プロセス中、AKS によって次のことが行われます。
- 指定された Kubernetes バージョンを実行するクラスターに 1 つの新しいバッファー ノード (または最大サージに構成されている数のノード) が追加されます。
- 実行中のアプリケーションの中断を最小限に抑えるために、古いノードを 1 つ 切断およびドレインします。 最大サージを使用している場合は、指定されたバッファー ノードの数と同数のノードが同時に切断およびドレインされます。
- 古いノードが完全にドレインされると、新しいバージョンを受け取るための再イメージ化が実行され、次にアップグレードされるノード用のバッファー ノードになります。
- このプロセスは、クラスター内のすべてのノードがアップグレードされるまで繰り返されます。
- プロセスの最後に、最後にバッファー ノードが削除され、既存のエージェント ノードの数とゾーン バランスが維持されます。
注意
パッチが指定されていない場合、クラスターは指定されたマイナー バージョンの最新 GA パッチに自動的にアップグレードされます。 たとえば、--kubernetes-version を 1.21 に設定すると、クラスターは 1.21.9 にアップグレードされます。
エイリアス マイナー バージョンでアップグレードする場合、上位のマイナー バージョンのみがサポートされます。 たとえば、1.20.x から 1.20 にアップグレードした場合、最新 GA 1.20 パッチにはアップグレードされませんが、1.21 にアップグレードした場合、最新 GA 1.21 パッチにアップグレードされます。
az aks upgrade \
--resource-group myResourceGroup \
--name myAKSCluster \
--kubernetes-version KUBERNETES_VERSION
ノード数にもよりますが、クラスターのアップグレードには数分かかります。
重要
PodDisruptionBudgets (PDB) で一度に少なくとも 1 つのポッド レプリカを確実に移動できるようにします。そうしない場合、ドレインまたは強制削除操作は失敗します。
ドレイン操作が失敗した場合、アプリケーションが中断されないように、アップグレード操作は設計によって失敗します。 操作を停止させる原因 (間違った PDB やクォータの不足など) を解消し、操作をやり直してください。
アップグレードが成功したことを確認するには、az aks show コマンドを使用します。
az aks show --resource-group myResourceGroup --name myAKSCluster --output table
次の出力例は、クラスターが現在 1.19.1 を実行していることを示しています。
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn
------------ ---------- --------------- ------------------- ------------------- ----------------------------------------------
myAKSCluster eastus myResourceGroup 1.19.1 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
アップグレード イベントの表示
クラスターをアップグレードすると、各ノードで次の Kubernetes イベントが発生する可能性があります。
- サージ – サージ ノードを作成します。
- ドレイン – ポッドがノードから削除されます。 各ポッドには、削除完了までの 30 分間のタイムアウトが設定されています。
- 更新 – ノードの更新が成功したか、失敗しています。
- 削除 – サージ ノードを削除しました。
kubectl get events を使用すると、アップグレード中、既定の名前空間にイベントが表示されます。 次に例を示します。
kubectl get events
次の出力例では、上記のイベントの一部がアップグレード中に一覧表示されています。
...
default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001]
...
default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool %!s(MISSING)
...
自動アップグレード チャネルを設定する
クラスターの手動アップグレードに加え、クラスターに自動アップグレード チャネルを設定できます。 詳細については、AKS クラスターの自動アップグレードに関する記事を参照してください。
複数の Availability Zones にまたがるノード プールに関する特別な考慮事項
AKS では、ノード グループでのベストエフォート ゾーン バランシングが使用されます。 アップグレード中は、仮想マシン スケール セット内のサージ ノードのゾーンは事前にはわかりません。 これにより、アップグレード中に一時的に不均衡なゾーン構成が発生する可能性があります。 ただし、アップグレードが完了し、元のゾーン バランスが維持されると、AKS によりサージ ノードが削除されます。 アップグレード中にゾーン バランスを維持する場合は、サージをノード数の 3 の倍数に増やします。 すると、仮想マシンのスケールセットは、ベストエフォート ゾーン バランシングによって Availability Zones 間でノードのバランスを取ります。
Azure LRS ディスクで PVC を使用している場合、それらは特定のゾーンにバインドされ、サージ ノードが PVC のゾーンと一致しない場合はすぐに復旧できない可能性があります。 このため、アップグレード操作によってノードのドレインが続行されても、PV がゾーンにバインドされていると、アプリケーションのダウンタイムが発生する可能性があります。 このケースを処理し、高可用性を維持するには、アプリケーションでポッド中断バジェットを構成します。 これにより、アップグレードのドレイン操作中に Kubernetes で可用性の要件を遵守するようにできます。
次のステップ
この記事では、既存の AKS クラスターをアップグレードする方法について説明しました。 AKS クラスターのデプロイと管理の詳細については、一連のチュートリアルを参照してください。