結論から言うと、2026年4月20日の Coordinated AKS management SDK release wave は、Azure Kubernetes Service management SDKs を使ってAKSを自動化している開発者・Platform Engineer・DevOpsチームにとって、「新しいAKS管理APIの項目を、RESTの手書きJSONではなく各言語のSDKから扱いやすくする」更新です。
特に注目すべきは、Gateway API、App Routing/Istio、Azure Monitorのアプリケーション監視、Hosted System Profile、Windows Server 2025向けOS SKUを、SDKのモデルや列挙型として扱いやすくなった点です。Goでは armcontainerservice/v9.1.0、Pythonでは azure-mgmt-containerservice 41.1.0 に複数のモデル・プロパティ・列挙型が追加され、Javaでは azure-resourcemanager-containerservice 2.59.0 で api-version が 2026-02-01 に更新されています。(GitHub)
Azure Kubernetes Service management SDKs の今回の更新で何が変わったのか
今回のリリースは、AKSそのものに単一の大きな新機能が突然追加されたというより、AKS管理API側で扱える構成項目を、複数言語のSDKが足並みをそろえて追従したことに意味があります。
AKSをポータルやAzure CLIで操作しているだけなら、すぐにコード変更が必要とは限りません。一方で、次のような運用をしているチームには影響があります。
| 対象チーム | 影響が出やすい場面 |
|---|---|
| Developers | AKSクラスタ作成・更新をアプリや社内ツールから実行している |
| Platform engineers | 複数クラスタの標準設定、監視、Ingress方針をコードで統制している |
| DevOps teams | CI/CD、GitOps、リリースパイプラインからAKS構成を検査・更新している |
| グローバル運用チーム | Go、Python、Javaなど複数言語でAKS管理コードが混在している |
今回の更新で見える主なポイントは次のとおりです。
| 言語・パッケージ | バージョン | 主な変更 | 実務上の意味 |
|---|---|---|---|
Go armcontainerservice | v9.1.0 | Gateway API、App Monitoring、Hosted System Profile、Windows 2025 OSSKUなどの型・フィールドを追加 | Go製の管理ツールや社内CLIで新しいAKS構成を扱いやすい |
Python azure-mgmt-containerservice | 41.1.0 | app_monitoring、gateway_api、hosted_system_profile などを追加 | インベントリ収集、監査、自動修復スクリプトに向く |
Java azure-resourcemanager-containerservice | 2.59.0 | api-version を 2026-02-01 に更新 | Javaベースの管理サービスで新しいAKS管理API世代に追従しやすい |
AKSのREST APIでは、Managed Clusterの作成・更新が api-version=2026-02-01 の PUT 操作として定義されており、要求本文には properties.azureMonitorProfile、properties.hostedSystemProfile、properties.ingressProfile などの管理項目が含まれます。SDK更新は、このREST APIの構成を各言語のモデルに落とし込む役割を持ちます。(Microsoft Learn)
そもそも management SDKs は何を管理するものか
Azure Kubernetes Service management SDKs は、KubernetesのPod、Deployment、Serviceを直接操作するためのSDKではありません。主な対象は、Azure Resource Manager上の AKSクラスタリソース です。
つまり、次のように役割を分けて考えると分かりやすくなります。
| やりたいこと | 主に使うもの |
|---|---|
| AKSクラスタを作成・更新・削除する | Azure Kubernetes Service management SDKs |
| ノードプール、クラスタ設定、監視、Ingress構成を管理する | Azure Kubernetes Service management SDKs |
| DeploymentやServiceをデプロイする | Kubernetes client、kubectl、Helm、GitOpsツール |
| Podのログや状態を確認する | Kubernetes API、kubectl、監視ツール |
| Azure上のリソースID、Managed Identity、ネットワーク設定と連携する | Azure management SDKs |
今回のリリースで楽になるのは、主に「AKSクラスタそのものの設定」をコードで扱う領域です。たとえば、クラスタごとにGateway APIが有効か、Azure Monitorのアプリケーション監視が有効か、Hosted System Profileがどう設定されているかを、SDK経由で読み取り・判定・自動化しやすくなります。
Gateway API と App Routing の管理がコードに寄せやすくなる
今回の更新で特に実務インパクトが大きいのは、Ingressまわりです。
REST API上では、ingressProfile.gatewayAPI が「マネージドGateway APIインストールの設定」として定義されています。installation には ManagedGatewayType が使われ、指定しない場合は Disabled が既定で、Standard を指定すると標準リリースチャネルのGateway API CRDがクラスタに反映される説明になっています。(Microsoft Learn)
これは、Platform Engineerにとって重要です。なぜなら、Ingressの標準化はクラスタ構成の中でもブレやすい領域だからです。
たとえば、複数チームがAKSを使う組織では、次のような状態が起こりがちです。
| よくある状態 | 問題 |
|---|---|
| 一部クラスタだけGateway APIを有効化している | アプリチームごとにマニフェストの書き方が変わる |
| NGINX Ingress、App Routing、Gateway APIが混在している | 障害時の切り分けや権限設計が複雑になる |
| ポータル操作で設定変更されている | IaCやCI/CD上の期待値と実環境がずれる |
| 新しいクラスタだけ設定が異なる | 本番・検証・開発環境で再現性が落ちる |
SDKで gatewayAPI や gatewayAPIImplementations を扱いやすくなると、全クラスタを走査して「Gateway APIの状態が社内標準に合っているか」を判定できます。
たとえば、次のような監査ルールを作れます。
| 監査ルール例 | 判定内容 |
|---|---|
| 本番クラスタはGateway APIを標準設定にする | ingressProfile.gatewayAPI.installation を確認 |
| App Routingを使うクラスタはDNSゾーンIDを必須にする | webAppRouting.dnsZoneResourceIds を確認 |
| App RoutingのManaged Identityを必ず設定する | webAppRouting.identity を確認 |
| Gateway API実装の種類を環境ごとに制御する | gatewayAPIImplementations を確認 |
App Routing側にも gatewayAPIImplementations があり、REST APIでは「App Routingを用いた管理型Ingressに使用されるGateway APIプロバイダーの構成」と説明されています。また、Application RoutingアドオンのManaged Identityは、Azure DNSリソースの管理やAzure Key Vaultからの証明書取得などに使われると説明されています。(Microsoft Learn)
ここでの実務上のポイントは、Ingressの有効化だけでなく、DNS、証明書、Managed Identityの権限までセットで確認することです。SDKで設定値を読めるようになっても、Azure DNSやKey Vault側の権限が不足していれば、アプリ公開の自動化は途中で止まります。
Istio と Gateway API の組み合わせを管理しやすくなる
GoとPythonのリリースでは、ManagedClusterAppRoutingIstio と GatewayAPIIstioEnabled が追加されています。REST API上でも、Managed Cluster App Routing Istio は、Gateway APIとApp Routing経由でIstioコントロールプレーンを管理する設定として説明されています。(GitHub)
この更新は、サービスメッシュやトラフィック制御をAKS上で標準化したいチームに向いています。
ただし、ここで注意したいのは「SDKで型が追加された」ことと「自社環境ですぐ有効化できる」ことは別だという点です。IstioやGateway APIまわりは、AKSのバージョン、リージョン、機能提供状況、既存Ingress設計に左右されます。
移行判断では、次の順番で確認すると失敗しにくくなります。
| 確認順 | 見るべきポイント |
|---|---|
| 1 | 既存クラスタのIngress方式を棚卸しする |
| 2 | Gateway APIを使う対象環境を決める |
| 3 | 既存のIngressリソースをGateway APIへ移行できるか確認する |
| 4 | DNS、TLS証明書、Managed Identityの権限を確認する |
| 5 | SDKで読み取り監査を作ってから、更新処理を実装する |
いきなり更新APIを呼ぶのではなく、まずは「現状を読む」自動化から始めるのが安全です。
Azure Monitorのアプリケーション監視を自動化しやすくなる
もう一つの大きなポイントは、azureMonitorProfile.appMonitoring です。
REST APIでは、appMonitoring はKubernetesアプリケーションコンテナーのアプリケーション監視プロファイルとして説明されており、Azure Monitor OpenTelemetryベースのSDKを用いた自動インストゥルメンテーションにより、ログ、メトリック、トレースを収集する構成とされています。さらに autoInstrumentation.enabled により、アプリケーション監視の自動計測が有効かどうかを表せます。(Microsoft Learn)
これにより、監視設定を「アプリチームの任意対応」にせず、Platform側で次のように統制できます。
| 活用シーン | 具体例 |
|---|---|
| 新規クラスタの標準監視 | 本番クラスタではアプリ監視を必須にする |
| 監査 | 監視が無効なクラスタを定期レポートに出す |
| リリース前チェック | デプロイ先クラスタで監視設定が有効か確認する |
| コスト管理 | 監視対象環境を本番・検証に限定する |
| 障害対応 | ログ、メトリック、トレースの取得前提を統一する |
特にグローバルチームでは、監視の有効・無効が環境ごとにバラつくと、インシデント時に「どのクラスタだけ情報が足りないのか」を調べるところから始まってしまいます。SDKで状態を読めるなら、クラスタ作成後のチェックや定期監査に組み込む価値があります。
Hosted System Profile はネットワーク設計とセットで見る
GoとPythonでは ManagedClusterHostedSystemProfile、hosted_system_profile も追加されています。REST APIでは、Hosted System Profileはホスト型システムアドオンの設定として定義され、enabled、nodeSubnetID、systemNodeSubnetID などの項目が説明されています。(GitHub)
ここで注意すべきなのは、サブネット指定です。REST APIの説明では、nodeSubnetID は systemNodeSubnetID と apiserverAccessProfile.subnetId と一緒に提供される必要があり、3つのサブネットIDは同じVNet内に存在する必要があるとされています。指定しない場合、AKSが管理リソースグループ内に既定のサブネットを作成する説明もあります。(Microsoft Learn)
つまり、Hosted System Profileをコードで扱えるようになっても、ネットワーク設計を後回しにすると詰まります。
実務では、次の観点で設計を確認してください。
| 確認項目 | 理由 |
|---|---|
| 同一VNet内のサブネット設計 | API要件に合わないと作成・更新で失敗する可能性がある |
| 既存クラスタとの互換性 | 既存ネットワーク構成を後から変えるのは影響が大きい |
| IPアドレス枯渇 | サブネットをAKSが使うため、余裕のあるCIDR設計が必要 |
| IaCとの整合性 | SDKで更新してもTerraformやBicep側が古いとドリフトになる |
| 権限 | サブネットやVNetへの参照・変更権限が必要になる |
Hosted System Profileは「SDKで設定できるようになったから有効化する」ではなく、AKSの基盤設計を見直すきっかけとして扱うのが現実的です。
Windows Server 2025 OSSKU 追加はWindowsノード運用に効く
GoとPythonのリリースでは、OSSKU にWindows 2025相当の値が追加されています。Goでは OSSKUWindows2025、Pythonでは OSSKU の WINDOWS2025 が追加されています。(GitHub)
WindowsコンテナをAKSで運用しているチームにとって、OS SKUをSDK上の列挙型として扱えることは重要です。文字列の直書きよりも、レビューやテストでミスを見つけやすくなるからです。
ただし、Windowsノードプールの移行では次の点を確認してください。
| 確認項目 | 注意点 |
|---|---|
| 対象リージョン | すべてのリージョンで同じタイミングに使えるとは限らない |
| Kubernetesバージョン | ノードOSとAKSバージョンの組み合わせを確認する |
| アプリ互換性 | Windowsコンテナのベースイメージやランタイム依存を確認する |
| 既存ノードプール | 既存プールの直接変更より、新規プール追加と段階移行が安全な場合がある |
| CI/CD | Windows用ビルドイメージ、テスト、脆弱性スキャンを更新する |
SDKの列挙型追加は、移行そのものを自動で完了させるものではありません。移行計画、検証環境、ロールバック方針とセットで使うべき更新です。
実装前に確認すべき移行判断
今回のSDK更新は、すべてのチームが即日対応すべき緊急更新というより、AKS管理コードの成熟度によって優先度が変わります。
| 状況 | 判断 |
|---|---|
| AKSをAzure CLIやポータル中心で管理している | すぐにSDK移行する必要はないが、将来の自動化候補として把握する |
| PythonでAKS棚卸し・監査スクリプトを書いている | 41.1.0 への更新価値が高い |
| Goで社内Platform CLIを作っている | armcontainerservice/v9.1.0 への更新を検討する |
| Javaで管理サービスを作っている | 2.59.0 でAPIバージョン追従を確認する |
| Gateway APIやApp Routingを標準化したい | 優先度は高い |
| Azure Monitorのアプリ監視を全クラスタで統制したい | 優先度は高い |
| 既存コードがクラスタ作成・削除だけ | まずは依存関係更新と回帰テストで十分 |
重要なのは、SDK更新を「新機能を有効化する作業」と捉えないことです。まずは 読み取り、棚卸し、差分検出 に使い、その後に更新処理へ進むと安全です。
依存関係の更新手順
Goの場合
Goでは、今回のリリースで armcontainerservice/v9.1.0 が公開されています。pkg.go.devでも v9.1.0 が2026年4月20日公開のバージョンとして表示され、ManagedClustersClient などの管理クライアントが用意されています。(Go Packages)
go get github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/containerservice/armcontainerservice/[email protected]
go mod tidy読み取り中心のインベントリ例は次のようになります。
package main
import (
"context"
"fmt"
"log"
"os"
"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
"github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/containerservice/armcontainerservice/v9"
)
func main() {
subscriptionID := os.Getenv("AZURE_SUBSCRIPTION_ID")
if subscriptionID == "" {
log.Fatal("AZURE_SUBSCRIPTION_ID is required")
}
cred, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil {
log.Fatal(err)
}
client, err := armcontainerservice.NewManagedClustersClient(subscriptionID, cred, nil)
if err != nil {
log.Fatal(err)
}
pager := client.NewListPager(nil)
for pager.More() {
page, err := pager.NextPage(context.Background())
if err != nil {
log.Fatal(err)
}
for _, cluster := range page.Value {
name := ""
if cluster.Name != nil {
name = *cluster.Name
}
gatewayAPIConfigured := false
appMonitoringConfigured := false
hostedSystemConfigured := false
if cluster.Properties != nil {
if cluster.Properties.IngressProfile != nil &&
cluster.Properties.IngressProfile.GatewayAPI != nil {
gatewayAPIConfigured = true
}
if cluster.Properties.AzureMonitorProfile != nil &&
cluster.Properties.AzureMonitorProfile.AppMonitoring != nil {
appMonitoringConfigured = true
}
if cluster.Properties.HostedSystemProfile != nil {
hostedSystemConfigured = true
}
}
fmt.Printf(
"name=%s gatewayAPI=%t appMonitoring=%t hostedSystem=%t\n",
name,
gatewayAPIConfigured,
appMonitoringConfigured,
hostedSystemConfigured,
)
}
}
}このコードは、いきなりAKSを更新せず、まず新しい構成項目が存在するかを確認する目的の例です。運用コードでは、リソースグループ名、クラスタID、環境タグ、リージョンも一緒に出力すると監査に使いやすくなります。
Pythonの場合
Pythonでは、PyPI上で azure-mgmt-containerservice 41.1.0 が2026年4月20日にリリースされ、Python 3.9以上が要件として示されています。リリース履歴には app_monitoring、gateway_api、gateway_api_implementations、hosted_system_profile などの追加が記載されています。(PyPI)
pip install -U azure-mgmt-containerservice==41.1.0 azure-identity読み取り中心のインベントリ例です。
import os
from azure.identity import DefaultAzureCredential
from azure.mgmt.containerservice import ContainerServiceClient
subscription_id = os.environ["AZURE_SUBSCRIPTION_ID"]
client = ContainerServiceClient(
credential=DefaultAzureCredential(),
subscription_id=subscription_id,
)
for cluster in client.managed_clusters.list():
props = cluster.properties
ingress_profile = getattr(props, "ingress_profile", None)
gateway_api = getattr(ingress_profile, "gateway_api", None) if ingress_profile else None
monitor_profile = getattr(props, "azure_monitor_profile", None)
app_monitoring = getattr(monitor_profile, "app_monitoring", None) if monitor_profile else None
hosted_system_profile = getattr(props, "hosted_system_profile", None)
print({
"name": cluster.name,
"location": cluster.location,
"gateway_api_configured": gateway_api is not None,
"app_monitoring_configured": app_monitoring is not None,
"hosted_system_configured": hosted_system_profile is not None,
})Python SDKの ContainerServiceClient は、既定のAPIバージョンとして 2026-02-01 を使う説明になっており、managed_clusters 操作グループからAKSクラスタ操作にアクセスできます。(Microsoft Learn)
Javaの場合
Javaでは、Maven Centralで com.azure.resourcemanager:azure-resourcemanager-containerservice:2.59.0 が公開されており、依存関係スニペットも提示されています。(Maven Central)
<dependency>
<groupId>com.azure.resourcemanager</groupId>
<artifactId>azure-resourcemanager-containerservice</artifactId>
<version>2.59.0</version>
</dependency>ContainerServiceManager はAzure Container Service managementのエントリポイントで、kubernetesClusters() からAKSクラスタ管理APIにアクセスできます。(Microsoft Learn)
import com.azure.core.credential.TokenCredential;
import com.azure.core.management.AzureEnvironment;
import com.azure.core.management.profile.AzureProfile;
import com.azure.identity.DefaultAzureCredentialBuilder;
import com.azure.resourcemanager.containerservice.ContainerServiceManager;
public class AksInventory {
public static void main(String[] args) {
TokenCredential credential = new DefaultAzureCredentialBuilder().build();
AzureProfile profile = new AzureProfile(AzureEnvironment.AZURE);
ContainerServiceManager manager =
ContainerServiceManager.authenticate(credential, profile);
manager.kubernetesClusters().list().forEach(cluster -> {
System.out.printf(
"name=%s region=%s resourceGroup=%s%n",
cluster.name(),
cluster.regionName(),
cluster.resourceGroupName()
);
});
}
}Javaでは高水準のFluent APIと内部モデルのどちらを使うかで、新しい管理項目へのアクセス方法が変わる場合があります。既存コードを更新する際は、単にバージョンを上げるだけでなく、対象プロパティが利用しているモデル階層で露出しているかを確認してください。
更新APIを実装する前に守るべき安全策
AKSの管理SDKでは、作成・更新が長時間操作になることがあります。また、Managed Clusterの作成・更新はREST API上では PUT として定義されています。if-match や if-none-match のような要求ヘッダーも用意されており、更新時の競合制御に関係します。(Microsoft Learn)
そのため、更新処理を書く場合は次の順序を推奨します。
| 手順 | 内容 |
| -: | —————- |
| 1 | 既存クラスタを読み取る |
| 2 | 必要なプロパティだけを判定する |
| 3 | 変更対象クラスタを限定する |
| 4 | 検証環境で更新する |
| 5 | 更新前後のJSON差分を保存する |
| 6 | 本番では段階的にロールアウトする |
| 7 | IaCと実環境の差分を再確認する |
特に避けたいのは、サンプルコードをもとに不完全なManaged Clusterオブジェクトを組み立て、既存クラスタに対してそのまま更新APIを呼ぶことです。クラスタ更新では、既存値を落とさないように、取得した現在値をベースに必要箇所だけを変更する実装にしてください。
IaC、CLI、SDKのどれを使うべきか
Azure Kubernetes Service management SDKs が便利になっても、すべてをSDKで管理するのが正解とは限りません。
| 選択肢 | 向いている用途 | 注意点 |
|---|---|---|
| Bicep / ARM / Terraform | 標準的なクラスタ作成、宣言的な環境管理 | 新しいAPI項目への追従が遅れる場合がある |
| Azure CLI | 手動確認、PoC、運用時の一時操作 | スクリプトがJSONパースだらけになりやすい |
| management SDKs | 社内ツール、監査、自動修復、CI/CD連携 | 更新処理の設計を誤ると影響範囲が大きい |
| Kubernetes client | ワークロード操作 | AKSリソース自体の設定は管理できない |
おすすめは、IaCで標準状態を定義し、SDKで監査・補助・例外処理を行う構成です。
たとえば、次のように分担すると運用しやすくなります。
| 領域 | 推奨 |
|---|---|
| 新規クラスタの標準構成 | Bicep、Terraform |
| 全クラスタのGateway API有効状況の棚卸し | SDK |
| 監視設定が無効なクラスタの検出 | SDK |
| 例外クラスタのレポート作成 | SDK |
| 本番クラスタの大きな構成変更 | IaC変更 + レビュー + 段階適用 |
| 一時的な調査 | Azure CLI |
SDKは「何でも更新する道具」ではなく、Azure APIを使った運用判断をプログラムに組み込む道具として使うと効果が出ます。
よくある失敗と回避策
| 失敗しやすいポイント | 回避策 |
|---|---|
| SDKを更新しただけで新機能が有効になると思い込む | SDK更新は型やAPI追従であり、機能有効化は別作業と考える |
| 既存クラスタへ部分的なオブジェクトをPUTする | 既存値を取得し、差分を確認してから更新する |
| Gateway APIだけ有効化してDNSや証明書権限を忘れる | App RoutingのManaged Identity、DNS、Key Vault権限をセットで確認する |
| Hosted System Profileをネットワーク設計なしで使う | VNet、サブネット、IPアドレス設計を先に確認する |
| SDKとIaCが別々に同じ設定を変更する | どの設定をどのツールが管理するかを決める |
| 本番だけで新APIを試す | 開発・検証サブスクリプションでレスポンス差分を確認する |
| 複数言語でSDKバージョンがずれる | Go、Python、Javaの依存関係をリリース単位で管理する |
実務でのおすすめ導入パターン
今回の更新を活かすなら、次のような小さな自動化から始めるのが現実的です。
まず全クラスタの状態を棚卸しする
最初に作るべきなのは、更新ツールではなくレポートです。
出力項目の例です。
| 項目 | 目的 |
|---|---|
| subscriptionId | 対象範囲の確認 |
| resourceGroup | 管理単位の確認 |
| clusterName | 対象クラスタの識別 |
| location | リージョン差分の把握 |
| kubernetesVersion | 機能互換性の確認 |
| ingressProfile.gatewayAPI | Gateway API状態の確認 |
| webAppRouting | App Routing状態の確認 |
| azureMonitorProfile.appMonitoring | アプリ監視状態の確認 |
| hostedSystemProfile | Hosted System設定の確認 |
| Windows node pool OS SKU | Windows移行対象の把握 |
この棚卸しをCSVやJSONで保存し、CI/CDや定期ジョブで差分を取れるようにすると、SDK更新の価値が出ます。
次にポリシー違反を検出する
棚卸しの次は、社内標準に合わないクラスタの検出です。
例として、本番環境では次のようなルールを作れます。
productionクラスタ:
- Gateway APIの方針が定義されていること
- Azure Monitorアプリケーション監視の設定が存在すること
- App Routingを使う場合はManaged Identityが設定されていること
- Hosted System Profileを使う場合はサブネット設計が明示されていることここまでなら読み取り中心なので、導入リスクは低めです。
最後に限定的な自動修復へ進む
自動更新は、対象を絞って始めます。
たとえば、いきなり本番クラスタのIngress設定を変更するのではなく、次のような低リスクな処理から始めるとよいでしょう。
| 自動化 | リスク |
|---|---|
| レポート作成 | 低い |
| SlackやTeamsへの通知 | 低い |
| チケット作成 | 低い |
| 開発環境クラスタへの設定反映 | 中程度 |
| 本番クラスタのIngress設定変更 | 高い |
| ネットワーク関連設定の変更 | 高い |
AKS管理SDKは強力ですが、クラスタ基盤を変更できるため、更新処理にはレビュー、承認、ロールバック手順を組み込むべきです。
今回のリリースで「楽になること」の本質
今回の Coordinated AKS management SDK release wave で楽になるのは、単に新しいプロパティが増えたことではありません。
本質は、次の3つです。
| 楽になること | 理由 |
|---|---|
| 手書きREST JSONを減らせる | SDKのモデル・列挙型で扱える項目が増える |
| 複数クラスタの標準化がしやすい | Gateway API、監視、Hosted System設定を走査できる |
| 複数言語チームで移行計画を立てやすい | Go、Python、Javaで同時期にAKS管理SDKが更新されている |
特に、AKSを「クラスタ単体」ではなく「社内Platform」として管理しているチームにとっては、今回の更新は地味ながら重要です。ポータル操作や個別CLIではなく、コードで状態を読み、標準との差分を検出し、必要な変更を安全に進めるための足場になります。
次に取るべき行動
まずは、使っているAzure Kubernetes Service management SDKs のバージョンを確認してください。Goなら armcontainerservice/v9.1.0、Pythonなら azure-mgmt-containerservice 41.1.0、Javaなら azure-resourcemanager-containerservice 2.59.0 が今回の確認対象です。
次に、更新APIを書く前に、全AKSクラスタの読み取りインベントリを作成します。Gateway API、App Routing、Azure Monitorアプリケーション監視、Hosted System Profile、WindowsノードのOS SKUを一覧化すれば、自社環境で今回のSDK更新をどこに活かせるかが見えます。
最後に、IaCで管理する項目とSDKで監査・補助する項目を分けてください。AKS管理SDKは、クラスタ構成を安全に標準化するための強力な道具です。まずは読み取りから始め、差分検出、通知、限定的な自動修復へと段階的に広げるのが、今回のリリースを実務に落とし込む最も堅実な進め方です。
コメント