Azure Kubernetes Service のパッチとアップグレード ガイダンス

Azure Kubernetes Service(AKS)の day-2 操作ガイドのこのセクションでは、AKS ワーカー ノードと Kubernetes バージョンのパッチ適用とアップグレード戦略について説明します。 クラスター オペレーターとして、クラスターを最新の状態に保って Kubernetes API の変更と非推奨を時間の経過と同時に監視する計画が必要になります。

背景と更新の種類

AKS には 3 種類の更新プログラムがあり、それぞれが前の更新プログラムに基づいて構築されています。

更新タイプ

• ノード OS のセキュリティ パッチ (Linux のみ): Linux ノードの場合、 Canonical Ubuntu と Azure Linux の両方で、オペレーティング システムのセキュリティ パッチを 1 日に 1 回使用できます。 Microsoft では、これらのパッチをノード イメージに対する毎週の更新プログラムでテストしてバンドルします。

• ノード イメージの毎週の更新: AKS では、ノード イメージが毎週更新されます。 これらの更新プログラムには、最新の OS と AKS のセキュリティ パッチ、バグ修正、改良が含まれます。 ノードの更新プログラムは、Kubernetes のバージョンを変更しません。 バージョンは、Linux の場合は日付(たとえば、202311.07.0)で書式設定されますが、Windows の場合は Windows Server OS のビルドと日付(たとえば、20348.2113.231115)で書式設定されます。 詳細については、 AKS リリースの状態に関するページを参照してください。

• 四半期ごとの Kubernetes リリース: AKS では、 Kubernetes リリースの四半期ごとの更新プログラムが提供されます。 これらの更新プログラムを使用すると、AKS ユーザーは、セキュリティ パッチやノード イメージの更新プログラムなど、最新の Kubernetes の機能と拡張機能を使用できます。 詳細については、「AKS でサポートされる Kubernetes のバージョン」を参照してください。

アップグレード前の考慮事項

AKS ワーカー ノードと Kubernetes バージョンをアップグレードする前に、次の効果とベスト プラクティスを検討してください。

クラスター全体への影響

• ノードとクラスターのインプレース アップグレードは、進行中の Kubernetes 環境のパフォーマンスに影響します。 ポッド中断予算の適切な構成、ノードのサージ構成、適切な計画により、この影響を最小限に抑えることができます。

• 青緑色の更新戦略はクラスターのパフォーマンスには影響しませんが、コストと複雑さが増します。

• アップグレードとパッチ適用の戦略に関係なく、クラスターの信頼性の高いなテストと検証プロセスが必要になります。 まず、下位の環境にパッチを適用してアップグレードし、メンテナンス後の検証を実行して クラスター、 ノード、 展開、アプリケーションの正常性を確認します。

AKS ワークロードのベスト プラクティス

メンテナンス中に AKS クラスターが円滑に動作するようにするには、次のベスト プラクティスに従います。

• ポッド中断予算(PDB)を定義します。 デプロイ用のPBDを設定することは重要です。 中断イベント中に継続的な機能性を確保するため、PDB は利用可能なアプリケーション レプリカの最小数を実施します。 PDB は、メンテナンスまたはノード障害時にクラスターの安定性の維持に役立ちます。

  警告

  Kubernetes API は、ロールするノード イメージのアップグレードで発生する必要な切断とドレインを防ぐため、誤って構成された PDB はアップグレード プロセスをブロックする可能性があります。 さらに、同時に移動されるポッドが多すぎる場合、アプリケーションの停止が発生する可能性があります。 適切な PDB 構成により、このリスクが軽減されます。

• 利用可能なコンピューティングとネットワーク制限を確認します。 Azure portal の「クォータ ページ」または「az quota」コマンドを使用し、Azure サブスクリプションで利用可能なコンピューティングとネットワーク制限を確認します。 コンピューティング リソースとネットワーク リソース、特にノードの仮想マシン (VM) vCPU、VM と仮想マシン スケール セットの数を確認します。 制限に近い場合、アップグレードする前にクォータの引き上げを要求してください。

• ノード サブネットで使用可能な IP アドレス空間を確認します。 更新中、クラスターに追加のサージ ノードが作成され、ポッドがこれらのノードに移動されます。 これらの変更が発生するのに十分なアドレス空間があることを確認するために、ノード サブネット内の IP アドレス空間を監視することが重要です。 Kubernetes ネットワーク構成が 異なると、IP アドレスの要件が異なります。 開始するには、次の考慮事項を確認します。

  • アップグレード中は、サージ値に応じてノード IP アドレスの数が増えます。 最小サージ値は 1 です。
  • Azure Container Network Interface に基づくクラスターは、個々のポッドに IP アドレスを割り当てます。そのため、ポッドの移動に十分なアドレス空間が必要です。
  • クラスターはアップグレード中でも動作を継続します。 ノードのスケーリングを可能にするために十分な IP アドレス空間が残っていることを確認します。

• 複数の環境を設定します。 開発、ステージング、運用環境など、複数の Kubernetes 環境を設定します。 この分離により、運用環境に移行する前に、変更を完全にテストして検証できます。 検証は、1.28 から 1.31 など、複数のバージョンの AKS 間を移動する場合に特に重要です。

• メンテナンス期間を計画してスケジュールします。 アップグレード プロセスは、Kubernetes クラスターの全体的なパフォーマンスに影響する可能性があります。 適切なサイズ設定(特に更新プロセス中)を確保するため、ピーク使用期間外にインプレース アップグレード プロセスをスケジュールし、クラスターのパフォーマンスを監視します。

• 排水できないノードの動作に合わせてクラスターを最適化します。 既定では、ノードのドレインが正常に失敗した場合、クラスターへの修正プログラムの適用も失敗します。 この問題に対処するには、 ノード ドレイン コードを構成する必要があります。 このプロセスでは、使用できないノードが検疫され、クラスターが正常にアップグレードされます。 その後、更新に失敗したノードを修正するには、修正プログラムを適用または削除します。

• サージ アップグレードの値をチューニングします。 既定では、AKS のサージ値は 1 であり、アップグレード プロセスの一環として一度に 1 つの追加ノードが作成されることを指します。 この値を引き上げて AKS アップグレードの速度を上げることができます。 中断の影響を受けやすいワークロードに推奨される最大サージ値は、33%です。 詳細については、「ノード サージ アップグレードのカスタマイズ」を参照してください。

• ノードドレインタイムアウトを調整します。ノードドレインタイムアウト は、ワークロードが更新中のノード上のポッドの再スケジュールを試みる間にクラスターが待機する最大時間を指定します。 既定値は 30 分です。 ポッドのスケジュール変更に苦労しているワークロードの場合は、この値を大きくすると役立ちます。

• ノードのソーク タイムアウトを調整します。 既定では、 ノード ソーク構成 は、ノードが更新プロセスを完了した後、次のノードの再イメージ化に進みます。 特定のレガシワークロードや機密性の高いワークロードでは、次のノードに進む前に遅延を追加すると便利な場合があります。 ノードの滞留時間を設定して、遅延を追加します。

• クラスターのその他の依存関係を確認します。 Kubernetes オペレーターは、多くの場合、KEDA スケーラー、DAPR、サービス メッシュなどの操作の一環として、他のツールを Kubernetes クラスターにデプロイします。 アップグレード プロセスを計画するときは、ターゲット バージョンとの互換性を確保するために使用するコンポーネントのリリース ノートを確認します。

• AKS ゾーン構成に合わせて調整します。 ゾーン AKS クラスターの場合、急激なアップグレードにより、ゾーン間のワークロードの分散が一時的に不均衡になる可能性があります。 このシナリオを回避するには、サージ値を 33% サージなどの 3 つの倍数に設定します。

ノード イメージの毎週の更新を管理する

Microsoft は、AKS ノードの新しいノード イメージを週に 1 回程度作成します。 ノード イメージには、最新の OS セキュリティ パッチ、OS のカーネル更新プログラム、Kubernetes のセキュリティ更新プログラム、Kubelet などのバイナリの更新されたバージョン、「リリース ノート」にリストされているコンポーネント バージョンの更新プログラムが含まれています。

ノード イメージが更新されると、対象ノード プールのノードで「切断とドレイン」アクションがトリガーされます。

1. 更新されたイメージを持つノードがノード プールに追加されます。 サージ値は、同時に追加されるノードの数を制御します。
2. サージ値に応じて、既存のノードのバッチが 隔離 され 、排出されます。 切断すると、ノードがポッドをスケジュールしないようにします。 ドレインすると、ポッドが削除されて他のノードにスケジュールされます。
3. これらのノードが完全にドレインされると、ノード プールから削除されます。 サージによって追加された更新済みのノードが、それらに取って代わります。
4. このプロセスは、ノード プールで更新する必要がある残りのノード バッチごとに繰り返されます。

クラスターのアップグレード中も同様のプロセスが発生します。

自動ノード イメージ アップグレード

一般に、ほとんどのクラスターでは NodeImage 更新チャネルを使用する必要があります。 このチャネルは、更新されたノード イメージ仮想ハード ディスク (VHD) を毎週提供し、クラスターのメンテナンス期間に従って更新されます。

使用可能なチャネルは次のとおりです。

• None。 自動的に適用される更新プログラムはありません。

• Unmanaged。 OS は、Ubuntu と Azure Linux の更新プログラムを夜間に適用します。 再起動は個別に管理する必要があります。 AKS では、これらの更新プログラムの周期をテストまたは制御できません。

• SecurityPatch。 OS は、AKS でテストされ、完全に管理され、安全なデプロイ プラクティスを使用するセキュリティ パッチをデプロイします。 このパッチには、OS のバグ修正は含まれません。 セキュリティ更新プログラムのみが含まれています。

• NodeImage。 AKS は、新しくパッチが適用された VHD を使用してノードを更新します。この VHD には、毎週のセキュリティ修正とバグ修正が含まれています。 これらの更新プログラムは、安全な展開プラクティスを使用して完全にテストおよびデプロイされます。 現在デプロイされているノード イメージのリアルタイム情報については、「AKS ノード イメージの更新」を参照してください。

メンテナンス期間が確立されていない既定の周期を理解するには、「 所有権とスケジュールを更新する」を参照してください。

Unmanaged 更新プログラム チャネルを選択した場合、Kured などのツールを使用して再起動プロセスを管理する必要があります。 Unmanaged チャネルには、AKS が提供する安全なデプロイ プラクティスは付属していないため、メンテナンス期間では機能しません。

SecurityPatch更新チャネルを選択した場合は、週単位の頻度で更新プログラムを適用できます。 このパッチ レベルでは、VHD をリソース グループに格納する必要があります。これにより、わずかな料金が発生します。 SecurityPatchを適用するタイミングを制御するには、ワークロードに最適なaksManagedNodeOSUpgradeSchedule周期を設定します。 新しいノード イメージ (VHD) に通常付属するバグ修正も必要な場合は、SecurityPatchではなくNodeImage チャネルを選択する必要があります。

詳細については、「 計画メンテナンスを使用して AKS クラスターのアップグレードをスケジュールおよび制御する」を参照してください。

ベスト プラクティスとして NodeImage 更新プログラム チャネルを使用し、クラスターがピーク使用期間外のときに aksManagedNodeOSUpgradeSchedule メンテナンス期間を構成します。 クラスターのメンテナンス期間の構成に使用できる属性については、「 メンテナンス期間の作成」を参照してください。 主な属性は次のとおりです。

• name。 ノード OS の更新プログラムに aksManagedNodeOSUpgradeSchedule を使用します。

• utcOffset。 タイム ゾーンを構成する。

• startTime。 メンテナンス期間の開始時間を設定します。

• dayofWeek。 期間の曜日を設定します。 たとえば、「 Saturday 」のように入力します。

• schedule。 期間の頻度を設定します。 NodeImage 更新プログラムの場合、 weeklyをお勧めします。

• durationHours。 この属性を少なくとも 4 時間に設定します。

次の例では、毎週のメンテナンス期間を土曜日の午後 8 時 (東部標準時) に設定します。

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

この構成は、クラスターのコードとしてのインフラストラクチャデプロイの一部として理想的にデプロイされます。

その他の例については、「 メンテナンス期間の構成を追加する」を参照してください。

Azure CLI を使用し、構成されたメンテナンス期間を確認できます。

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

CLI を使用し、特定のメンテナンス期間の詳細を確認することもできます。

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

クラスターのメンテナンス期間が構成されていない場合、ノード イメージの更新プログラムは 2 週間に 1 回行われます。 AKS のメンテナンスは、可能な限り構成された期間内に行われますが、メンテナンスの時間は保証されません。

更新プログラムの状態を自動的に監視するには、 AKS 通信マネージャー を使用して、計画メンテナンス アクティビティの自動アラートを提供できます。 または、Azure Monitor アクティビティ ログを使用して直接監視するか、kubectl get eventsを使用してクラスターのリソース ログを確認することもできます。

Azure Event Grid で AKS イベントをサブスクライブして、AKS アップグレード イベントを取得します。 これらのイベントは、新しいバージョンの Kubernetes が使用可能になったときにアラートを生成し、アップグレード プロセス中にノードの状態の変更を追跡するのに役立ちます。

GitHub Actions を使用し、毎週の更新プロセスを管理することもできます。 この方法では、更新プロセスをより細かく管理できます。

手動ノード更新のプロセス

kubectl describe nodes コマンドを使用し、クラスターのノードの OS カーネル バージョンと OS イメージ バージョンを確認できます。

kubectl describe nodes <NodeName>

出力例 (抜粋):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.173.1-1.cm2
  OS Image:                   CBL-Mariner/Linux
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.6.26
  Kubelet Version:            v1.31.3
  Kube-Proxy Version:         v1.31.3

Azure CLI az aks nodepool list コマンドを使用し、クラスターのノードのノード イメージ バージョンを確認します。

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

出力例:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

az aks nodepool get-upgrades コマンドを使用して、特定のノード プールで使用可能な最新のノード イメージ バージョンを確認します。

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

出力例:

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V2gen2-202501.12.0
user    AKSAzureLinux-V2gen2arm64-202501.12.0

クラスターのアップグレード

Kubernetes コミュニティでは、おおよそ 3 か月ごとにKubernetes のマイナー バージョンをリリースします。 新しい AKS のバージョンとリリースに関する最新情報を把握するため、「AKS リリース ノート ページ」が定期的に更新されます。 GitHub AKS RSS フィードにサブスクライブすると、変更と改良機能に関するリアルタイムの更新情報を得られます。

AKS は N - 2 サポート ポリシーに従います。これは、最新リリース (N) と以前の 2 つのマイナー バージョンに対して完全なサポートが提供されることを意味します。 3 番目の以前のマイナー バージョンには、制限付きのプラットフォーム サポートが提供されます。 詳細については、「 AKS のサポート ポリシー」を参照してください。

AKS クラスターがサポートされ続けるようにするには、クラスターの継続的なアップグレード プロセスを確立する必要があります。 このプロセスでは、下位の環境で新しいバージョンをテストし、新しいバージョンがデフォルトになる前に運用環境へのアップグレードを計画することを必要とします。 このアプローチは、アップグレード プロセスの予測可能性を維持し、アプリケーションの中断を最小限に抑えるのに役立ちます。 詳細については、「 AKS クラスターのアップグレード オプション」を参照してください。

クラスターがアップグレード サイクルを長くする必要がある場合、 長期サポート(LTS)オプションをサポートする AKS バージョンを使用します。 LTS オプションを有効にした場合、マイクロソフトは Kubernetes バージョンに 2 年間の延長サポートを提供します。これにより、アップグレード サイクルの延長と管理を向上できるようにします。 詳細については、「AKS でサポートされる Kubernetes のバージョン」を参照してください。

クラスターのアップグレードにはノードのアップグレードが含まれており、cordon と drain プロセスが使用されます。

アップグレードする前に

ベスト プラクティスとして、運用環境で中断のリスクを最小限に抑えるため、常に下位の環境でアップグレードしてテストする必要があります。 Kubernetes の展開に影響する恐れがある API 変更が含まれているため、クラスターのアップグレードには追加のテストが必要です。 次のリソースは、アップグレード プロセスに役立ちます。

• 非推奨の API の AKS ブック: Azure portal のクラスターの概要ページで、[問題の 診断と解決] を選択し、[ 作成、アップグレード、削除、スケール ] カテゴリに移動して、 Kubernetes API の非推奨を選択します。 この手順では、クラスターでまだ使用されている非推奨の API バージョンをチェックするブックを実行します。 詳細については、「非推奨 API の使用の削除」を参照してください。

• AKS リリース ノート ページ: このページでは、新しい AKS のバージョンとリリースに関する包括的な情報を提供します。 最新の更新プログラムと変更に関する最新情報を得るには、これらのメモを確認してください。

• Kubernetes のリリース ノート ページ: このページでは、最新の Kubernetes バージョンに関する詳細な分析情報を提供します。 緊急のアップグレードに関する注意事項に特に注意してください。 AKS クラスターに影響する可能性がある重要な情報が強調表示されます。

• バージョン別の変更を中断する AKS コンポーネント: 次の表は、バージョン別の AKS コンポーネントの破壊的変更の包括的な概要を示しています。 このガイドを参照することで、アップグレード プロセスの前に潜在的な互換性の問題に事前に対処できます。

これらのマイクロソフト リソースに加え、オープンソース ツールを使用してクラスターのアップグレード プロセスを最適化することを検討してください。 このようなツールの 1 つは Fairwinds Pluto であり、展開や非推奨の Kubernetes API の Helm グラフをスキャンできます。 これらのツールは、アプリケーションが最新の Kubernetes バージョンとの互換性を維持するために役立ちます。

アップグレード プロセス

クラスターにアップグレードが必要なタイミングを確認するには、 az aks get-upgrades コマンドを使用して、AKS クラスターで使用可能なアップグレード バージョンの一覧を取得します。 結果からクラスターの対象バージョンを確認します。

次に例を示します:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

出力例:

MasterVersion  Upgrades
-------------  ---------------------------------
1.30.7         1.31.1, 1.31.2, 1.31.3

アップグレードする必要があるプールを見つけるには、ノード プール内のノードの Kubernetes バージョンを確認します。

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

出力例:

Name          K8version
------------  ------------
systempool    1.30.7
usernodepool  1.30.7

手動アップグレード

中断を最小限に抑え、AKS クラスターのスムーズなアップグレードを確実に行うには、次のアップグレード アプローチを使用します。

1. AKS コントロール プレーンのアップグレード クラスターの管理と調整を担当するコントロール プレーン コンポーネントをアップグレードします。 個々のノード プールをアップグレードする前に互換性と安定性を確保するために、最初にコントロール プレーンをアップグレードします。

2. システム ノード プールをアップグレードします。 コントロール プレーンをアップグレードした後、AKS クラスターのシステム ノード プールをアップグレードします。 ノード プールは、アプリケーション ワークロードを実行する VM インスタンスで構成されます。 ノード プールを個別にアップグレードすると、アプリケーションをサポートする基のインフラストラクチャの制御された体系的なアップグレードが可能になります。

3. ユーザー ノード プールのアップグレード システム ノード プールをアップグレードした後、AKS クラスターの任意のユーザー ノード プールをアップグレードします。

このアプローチに従うことにより、アップグレード プロセス中の中断を最小限に抑えてアプリケーションの可用性を維持できます。 次の手順を実行します。

1. フラグで az aks upgrade--control-plane-only コマンドを実行し、クラスターのノード プールではなく、クラスター コントロール プレーンのみをアップグレードします。

   az aks upgrade \
      --resource-group <ResourceGroupName> --name <AKSClusterName> \
      --control-plane-only \
      --kubernetes-version <KubernetesVersion>
   

2. az aks nodepool upgrade コマンドを実行して、ノード プールをターゲット バージョンにアップグレードします。

   az aks nodepool upgrade \
      --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
      --no-wait --kubernetes-version <KubernetesVersion>
   

   ノード プールのアップグレード中、AKSはサージノードを作成し、アップグレード中のノードでポッドを立ち入り制限および排出し、ノードを再イメージ化してから、ポッドの立ち入り制限を解除します。 このプロセスは、ノード プール内の他のノードに対して繰り返されます。

kubectl get events を実行し、アップグレード プロセスの状態を確認できます。 クラスターのアップグレード問題のトラブルシューティングに関する詳細については、「AKS のトラブルシューティング ドキュメント」を参照してください。

自動アップグレード リリース チャネルにクラスターを登録する

AKS には、クラスターを最新の状態に保つための 自動クラスター アップグレード ソリューション も用意されています。 このソリューションを使用する場合、アップグレードのタイミングを制御するために メンテナンス期間 とペアリングする必要があります。 アップグレード期間は 4 時間以上である必要があります。 クラスターをリリース チャンネルに登録すると、マイクロソフトはクラスターとそのノード プールのバージョンとアップグレード頻度を自動的に管理します。

クラスターの自動アップグレードには、さまざまなリリース チャネル オプションが用意されています。 推奨される環境とリリース チャンネルの構成は次のとおりです。

考慮事項

次の表では、さまざまな AKS のアップグレードと修正プログラムの適用シナリオの特性について説明します。

• ノード イメージのアップグレードの一部として適用される OS セキュリティパッチは、新しいクラスターの作成がインストールされるよりも新しいバージョンのカーネルをインストールする可能性があります。

• ノード プールのスケールアップでは、仮想マシン スケール セットに現在関連付けられているモデルが使用されます。 OS カーネルは、セキュリティ パッチが適用され、ノードが再起動されるとアップグレードされます。

共同作成者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパル作成者:

• Anthony Nevico | 主要クラウド ソリューション アーキテクト

その他の共同作成者:

• Rishabh Saha | プリンシパル ソリューション アーキテクト
• Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Ali Yousefi |クラウド ソリューション アーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• 製品ドキュメント AKS
• AKS リリース トラッカー
• AKS のロードマップ
• AKS ランディング ゾーン アクセラレータ
• AKS の問題のトラブルシューティング
• AKS のアップグレードを最適化する
• ノード OS のアップグレードに関する FAQ
• AKS の構築セット
• AKS ベースラインの自動化
• day-2 操作の定義
• ゾーン冗長 AKS クラスターの実用的なガイド

関連リソース

• AKS の 2 日目の運用ガイド
• AKS のトリアージ プラクティス