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

[アーティクル]
01/10/2024

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

背景と更新の種類

AKS には 3 種類の更新プログラムがあり、各更新プログラムは次のものに構築されます。

更新の種類	アップグレードの頻度	サポートされる計画メンテナンス	サポートされる操作方法	ターゲット	ドキュメントへのリンク
ノードの OS セキュリティパッチ	夜間	はい	自動 (毎週)、手動/アンマネージド (夜間)	ノード	ノードのイメージを自動アップグレードする
ノードイメージバージョンのアップグレード	Linux: 毎週 Windows: 毎月	はい	自動、手動	ノードプール	AKS ノードイメージのアップグレード
Kubernetes バージョン(クラスター)のアップグレード	四半期	はい	自動、手動	クラスターとノードプール	AKS クラスターのアップグレード

更新タイプ

ノード 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 のバージョン」を参照してください。

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

クラスター全体への影響

インプレースアップグレード(ノードとクラスターの両方)は、進行中の Kubernetes 環境のパフォーマンスに影響します。ポッド中断予算の適切な構成、ノードのサージ構成、適切な計画により、この影響を最小限に抑えることができます。
インプレースアップグレードをせず、青/緑の更新戦略を使用すると、クラスターパフォーマンスへの影響がなくなりますが、コストと複雑さが増します。
アップグレードとパッチ適用の戦略に関係なく、クラスターの信頼性の高いなテストと検証プロセスが必要になります。まず、下位の環境にパッチを適用してアップグレードし、メンテナンス後の検証を実行してクラスター、ノード、展開、アプリケーションの正常性を確認します。

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

メンテナンス中に AKS クラスターの円滑な動作を確保するには、次のベストプラクティスに従ってください。

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

警告

Kubernetes API は、ロールするノードイメージのアップグレードで発生する必要な切断とドレインを防ぐため、誤って構成された PDB はアップグレードプロセスをブロックする可能性があります。さらに、同時に移動されるポッドが多すぎる場合、アプリケーションの停止が発生する可能性があります。 PDB 構成はこのリスクが軽減します。
利用可能なコンピューティングとネットワーク制限を確認します。 Azure portal の「クォータページ」または「az quota」コマンドを使用し、Azure サブスクリプションで利用可能なコンピューティングとネットワーク制限を確認します。コンピューティングリソースとネットワークリソース(特にノードの VM vCPU)、ならびに仮想マシンと仮想マシンスケールセットの数を確認します。制限に近い場合、アップグレードする前にクォータの引き上げを要求してください。
ノードサブネットで利用可能な IP 空間を確認します。 更新中、クラスターに追加のサージノードが作成され、ポッドがこれらのノードに移動されます。ノードサブネットの IP アドレス空間を監視し、これらの変更を行うために十分なアドレス空間があることを確認することが重要です。 Kubernetes ネットワーク構成が異なると、 IP 要件が異なります。開始点として、次の考慮事項を確認してください。
- アップグレード中、サージ値に応じてノード IP の数が増加します。 (最小のサージ値は 1 です)
- Azure CNI に基づくクラスターは、個々のポッドに IP アドレスを割り当てるため、ポッド移動に十分な IP 空間が必要になります。
- クラスターはアップグレード中でも動作を継続します。ノードのスケーリング(有効になっている場合)をできるために十分な IP 空間が残っていることを確認します。
複数の環境を設定します。 運用環境にロールアウトする前に変更をテストと検証できるように、開発、ステージング、運用などの個別環境を設定することをお勧めします。
サージアップグレードの値をチューニングします。 既定では、AKS のサージ値は 1 であり、アップグレードプロセスの一環として一度に 1 つの追加ノードが作成されることを指します。この値を引き上げて AKS アップグレードの速度を上げることができます。 33% のサージは、中断の影響を受けやすいワークロードに推奨される最大値です。詳細については、「ノードサージアップグレードのカスタマイズ」を参照してください。
ノードのドレインタイムアウトを調整します。ノードのドレインタイムアウトは、更新中のノード上のポッドの再スケジュールを試みている間にクラスターが待機する最大時間を指定します。この既定値は 30 分です。ポッドの再スケジュールに苦労しているワークロードの場合は、この既定値を調整すると便利です。
メンテナンス期間を計画してスケジュールします。 アップグレードプロセスは、Kubernetes クラスターの全体的なパフォーマンスに影響する可能性があります。適切なサイズ設定(特に更新プロセス中)を確保するため、ピーク使用期間外にインプレースアップグレードプロセスをスケジュールし、クラスターのパフォーマンスを監視します。
クラスターのその他の依存関係を確認します。 Kubernetes オペレーターは、KEDA スケーラー、Dapr、サービスメッシュなどの操作の一環として、多くの場合はその他のツールを Kubernetes クラスターに配置します。アップグレードプロセスを計画するとき、対象バージョンとの互換性を確保するため、使用しているコンポーネントのリリースノートを確認してください。

ノードイメージに毎週の更新の管理

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

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

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

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

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

一般的には、ほとんどのクラスターは NodeImage 更新プログラムチャネルを使用する必要があります。このチャンネルでは、更新されたノードイメージ VHD が毎週提供され、クラスターのメンテナンス期間に応じて更新されます。

利用可能なチャンネルには、次の内容が含まれます。

None= 自動的に適用される更新プログラムはありません。
Unmanaged= Ubuntu と Azure Linux の更新プログラムは、夜間に OS が適用します。再起動は個別に管理する必要があります。 AKS はこれをテストすることも、この頻度を制御することもできません。
SecurityPatch= AKS でテストされ、完全に管理され、安全なデプロイ手法で適用される OS セキュリティパッチ。セキュリティ更新プログラムだけの OS バグ修正は含まれていません。
NodeImage= AKS では、週 1 回の頻度で、セキュリティ修正とバグ修正を含む新しくパッチが適用された VHD でノードを更新します。これは完全にテストされ、安全な展開方法でデプロイされます。現在デプロイされているノードイメージのリアルタイム情報については、「AKS ノードイメージの更新」を参照してください。

メンテナンス期間が確定されていない場合の既定の頻度については、更新の所有権と頻度に関する記事を参照してください。

Unmanaged 更新プログラムチャネルを選択した場合、Kured などのツールを使用して再起動プロセスを管理する必要があります。 Unmanaged には、AKS が提供する安全なデプロイプラクティスが付属していないため、メンテナンス期間では機能しません。 SecurityPatch 更新チャネルを選択した場合は、週次で更新を適用できます。このパッチレベルでは、VHD をリソースグループに格納する必要があります。これにより、わずかな料金が発生します。ワークロードに最適な頻度に合わせて、適切に aksManagedNodeOSUpgradeSchedule 設定を行って、 SecurityPatch を適用するタイミングを制御します。詳細については、「メンテナンス期間を作成」を参照してください。通常、新しいノードイメージ (VHD) に付属するバグ修正も必要な場合は、 SecurityPatchの代わりに NodeImage チャネルを選択する必要があります。

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

name= ノード OS の更新プログラムに aksManagedNodeOSUpgradeSchedule を使用します。
utcOffset= タイムゾーンを構成する。
startTime= メンテナンス期間の開始時間を設定します。
dayofWeek= 期間の曜日を設定します。たとえば、 Saturdayのようにします。
schedule= 期間の頻度を設定します。 NodeImage 更新プログラムの場合、 weeklyをお勧めします。
durationHours= この属性を少なくとも 4 時間に設定します。

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

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 でメンテナンス期間の構成の追加」を参照してください。

この構成は、クラスターのコードとしてのインフラストラクチャ展開の一環として展開することが理想的です。

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 メンテナンスは構成された期間内に行われますが、メンテナンスの時間は保証されません。

重要

多数のノードを含むノードプールがあるが、ノードサージが構成されていない場合、自動アップグレードイベントがトリガーされない可能性があります。ノードプール内のノードイメージは、推定合計アップグレード時間が 24 時間以内にのみアップグレードされます。

この状況では、次のいずれかを検討できます。

vCPU クォータがほぼ満杯で、vCPU クォータを増やすことができない場合に、ノードを異なるノードプールに分割する
vCPU クォータが十分な場合に、ノードサージを構成して推定アップグレード時間を短縮する

アップグレードイベントの状態をチェックするには、 Azure アクティビティログを使用するか、クラスターのリソースログを確認します。

AKS アップグレードイベントを含む Azure Event Grid を使用して、Azure Kubernetes Service (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.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

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

出力例:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

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

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

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

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

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

クラスターのアップグレードにはノードのアップグレードが含まれており、同様の切断とドレインプロセスが使用されます。

アップグレードする前に

ベストプラクティスとして、運用環境で中断のリスクを最小限に抑えるため、常に下位の環境でアップグレードしてテストする必要があります。 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-upgrade」を使用して AKS クラスターに利用可能なアップグレードバージョンのリストを取得します。結果からクラスターの対象バージョンを確認します。

次に例を示します。

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

出力例:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

ノードプールのノードの Kubernetes バージョンを確認し、アップグレードが必要なプールを確認します。

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

出力例:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

手動でアップグレード中

中断を最小限に抑えて AKS クラスターのスムーズなアップグレードを行えるようにするには、次のアップグレードアプローチに従ってください。

AKS コントロールプレーンのアップグレード AKS コントロールプレーンのアップグレードから開始します。この手順では、クラスターの管理と調整を行うコントロールプレーンコンポーネントのアップグレードが含まれます。最初にコントロールプレーンをアップグレードすると、個々のノードプールをアップグレードする前に互換性と安定性が確保されます。
システムノードプールをアップグレードします。 コントロールプレーンをアップグレードした後、AKS クラスターのシステムノードプールをアップグレードします。ノードプールは、アプリケーションワークロードを実行する仮想マシンのインスタンスで構成されます。ノードプールを個別にアップグレードすると、アプリケーションをサポートする基のインフラストラクチャの制御された体系的なアップグレードが可能になります。
ユーザーノードプールのアップグレード システムノードプールをアップグレードした後、AKS クラスターの任意のユーザーノードプールをアップグレードします。

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

--control-plane-only フラグで az aks upgrade コマンドを実行し、クラスターのノードプールではなく、クラスターコントロールプレーンのみをアップグレードします。
```
az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>
```
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 時間以上である必要があります。クラスターをリリースチャンネルに登録すると、マイクロソフトはクラスターとそのノードプールのバージョンとアップグレード頻度を自動的に管理します。

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

環境	アップグレードチャンネル	説明
実稼働	`stable`	安定性とバージョンの成熟度のために、運用ワークロードには安定版または通常版のチャネルを使います。
ステージング、テスト、開発	運用環境と同じです	テストが運用環境をアップグレードするバージョンを示すようにするには、運用環境と同じリリースチャンネルを使用してください。
カナリア	`rapid`	最新の Kubernetes リリースと新しい AKS の機能または API をテストするには、 `rapid` チャンネルを使用してください。 `rapid` のバージョンが運用環境に使用しているチャンネルに昇格されると、市場投入するための時間を短縮できます。

考慮事項

次のテーブルでは、AKS のアップグレードとパッチ適用のさまざまなシナリオの特性について説明します。

シナリオ	ユーザーが開始	Kubernetes のアップグレード	OS カーネルのアップグレード	ノードイメージのアップグレード
セキュリティ修正	いいえ	いいえ	はい、再起動後に	はい
クラスターの作成	はい	可能性あり	はい、更新されたノードイメージが更新されたカーネルを使用している場合。	はい、新しいリリースが利用可能な場合、既存クラスターに相対的
コントロールプレーン Kubernetes のアップグレード	はい	はい	いいえ	いいえ
ノードプール Kubernetes のアップグレード	はい	はい	はい、更新されたノードイメージが更新されたカーネルを使用している場合。	はい、新しいリリースが利用可能な場合
ノードプールのスケールアップ	はい	いいえ	いいえ	いいえ
ノードイメージのアップグレード	はい	いいえ	はい、更新されたノードイメージが更新されたカーネルを使用している場合。	はい
クラスターの自動アップグレード	いいえ	はい	はい、更新されたノードイメージが更新されたカーネルを使用している場合。	はい、新しいリリースが利用可能な場合

ノードイメージのアップグレードの一環として適用された OS セキュリティパッチは、新しいクラスターの作成によってインストールされるバージョンよりも、新しいバージョンのカーネルがインストールされる可能性があります。
ノードプールのスケールアップでは、仮想マシンスケールセットに現在関連付けられているモデルが使用されます。 OS カーネルは、セキュリティパッチが適用されてノードが再起動されたときにアップグレードされます。

共同作成者

この記事は、Microsoft によって保守されています。当初の寄稿者は以下のとおりです。

プリンシパル作成者:

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

その他の共同作成者:

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

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

次の方法で共有

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

背景と更新の種類

更新タイプ

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

クラスター全体への影響

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

ノードイメージに毎週の更新の管理

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

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

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

アップグレードする前に

アップグレードプロセス

手動でアップグレード中

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

考慮事項

共同作成者

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

背景と更新の種類

更新タイプ

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

クラスター全体への影響

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

ノード イメージに毎週の更新の管理

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

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

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

アップグレードする前に

アップグレード プロセス

手動でアップグレード中

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

考慮事項

共同作成者

次のステップ

関連リソース

フィードバック

その他のリソース

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

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

ノードイメージに毎週の更新の管理

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

アップグレードプロセス

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