Azure Kubernetes Service（AKS）の「Core Concepts」は、AKSを使う前提知識を整理しただけの記事ではありません。今回確認すべき要点は、Azure Linux 2.0ノードのサポート終了、ノードプールとOS SKUの見直し、VMサイズを未指定にした場合の挙動、Automatic／Standardモードの選び方です。特にAzure Linux 2.0を使っている環境では、2026年3月31日以降にノードイメージが削除され、ノードプールをスケールできなくなる影響があるため、管理者は早めに棚卸しと移行計画を進める必要があります。(Microsoft Learn)
この記事では、Azure Kubernetes Serviceの「Azure Kubernetes Service (AKS) Core Concepts – Azure Kubernetes Service」で押さえるべき変更点を、管理者・開発者・インフラ担当者の視点で整理します。単なる用語解説ではなく、既存クラスターの確認方法、移行時の注意点、展開設計で失敗しやすいポイントまで実務向けにまとめます。
Azure Kubernetes ServiceのCore Conceptsでまず押さえるべき結論
Azure Kubernetes Service（AKS）のCore Conceptsは、AKSクラスターを「何で構成するか」「どこまでAzureが管理するか」「利用者がどこを設計・運用するか」を整理する公式ドキュメントです。AKSクラスターは、Azureが管理するコントロールプレーンと、アプリケーションを実行するノードで構成されます。ノードはAzure VMとして動作し、kubelet、kube-proxy、container runtimeなどのKubernetesノードコンポーネントを実行します。(Microsoft Learn)
今回の実務上のポイントは、次の3つです。
| 確認ポイント | 実務への影響 | 優先度 |
|---|---|---|
| Azure Linux 2.0ノードの有無 | サポート終了、セキュリティ更新停止、スケール不可につながる | 高 |
| ノードプールのOS SKUとKubernetesバージョン | Azure Linux 3.0やUbuntu 24.04への移行計画に関係する | 高 |
| VMサイズ・ノードプール・クラスターSKUの指定 | IaCや本番展開で構成差分・コスト差分が出やすい | 中 |
kube-systemやノードリソースグループの扱い | AKS管理領域を誤って変更すると障害調査が難しくなる | 中 |
| Automatic／Standardモード、Free／Standard／Premium価格レベル | 運用責任、SLA、LTS利用可否に影響する | 中 |
Core Conceptsの更新を「初心者向けの用語整理」と見なして放置すると、OS移行、スケール、ノードプール設計、SLA設計で後から手戻りが発生します。特に本番AKSでは、ノードプール単位でOS SKU、Kubernetesバージョン、VMサイズ、システム用・アプリ用の分離状況を確認することが重要です。
何が変わるのか：重要なのはAzure Linux 2.0とノード構成
今回もっとも注意すべき内容は、Azure Linux 2.0の扱いです。Microsoft Learnでは、2025年11月30日からAKSがAzure Linux 2.0のサポートおよびセキュリティ更新を提供しなくなり、2026年3月31日以降はノードイメージが削除され、該当ノードプールをスケールできなくなると案内されています。移行先としては、サポートされるKubernetesバージョンへのノードプールアップグレード、またはosSku AzureLinux3への移行が示されています。(Microsoft Learn)
これは「新規作成時の推奨が変わった」だけではありません。既存クラスターでAzure Linux 2.0を使い続けている場合、次のような運用リスクがあります。
| リスク | 起こり得る事象 | 影響を受ける場面 |
|---|---|---|
| セキュリティ更新が止まる | 既知脆弱性への対応が遅れる | 本番ワークロード、監査対象環境 |
| ノードイメージが削除される | ノードプールのスケールアウトや復旧ができない | 障害復旧、オートスケール、繁忙期対応 |
| Kubernetesアップグレードが詰まる | OS SKUとKubernetesバージョンの組み合わせが制約になる | LTS利用、定期アップグレード |
| IaCの再適用で差分が出る | 未指定項目が現在の既定値で解釈される | Terraform、Bicep、ARMテンプレート |
管理者が最初に行うべきことは、全AKSクラスターのノードプールを棚卸しし、osSku、Kubernetesバージョン、VMサイズ、ノードイメージバージョンを確認することです。
az aks nodepool list \
--resource-group <resource-group-name> \
--cluster-name <cluster-name> \
--query "[].{name:name,mode:mode,osType:osType,osSku:osSku,kubernetesVersion:orchestratorVersion,vmSize:vmSize,nodeImageVersion:nodeImageVersion,count:count}" \
--output tableこの確認でAzureLinuxかつ古いKubernetesバージョンのノードプールが見つかった場合は、単にノードイメージを更新するだけでなく、KubernetesバージョンアップとOS SKU移行のどちらを先に進めるかを検討してください。
管理者が確認すべき設定：ノードプール、OS SKU、VMサイズ
AKSのノードは、同じ構成のノードをまとめたノードプールとして管理されます。初期作成時には、CoreDNSやkonnectivity-agentなど重要なシステムPodをホストするシステムノードプールが作成され、アプリケーション用にはユーザーノードプールを追加して分離できます。(Microsoft Learn)
本番環境では、システムノードプールとアプリケーション用ノードプールを混在させない設計が基本です。たとえば、バッチ処理やGPUワークロードをシステムノードプールに同居させると、CoreDNSなどの基盤Podに影響が出たとき、アプリ障害なのかクラスター基盤の問題なのか切り分けに時間がかかります。
VMサイズを未指定にしているIaCは見直す
Core Conceptsでは、2025年5月以降、デプロイ時にVM SKUやサイズのパラメーターを空白のままにした場合、AKSが利用可能な容量とクォータに基づいて既定のVM SKUとサイズを動的に選択すると説明されています。(Microsoft Learn)
これは検証環境では便利ですが、本番環境のIaCでは注意が必要です。VMサイズが明示されていないと、リージョン、クォータ、作成タイミングによって想定と異なるVMサイズが選ばれる可能性があります。結果として、CPU・メモリ、エフェメラルOSディスク可否、コスト、Pod配置数の前提が変わることがあります。
本番環境では、少なくとも次の項目を明示することを推奨します。
| 項目 | 明示すべき理由 |
|---|---|
vmSize | 性能、単価、Pod密度、ディスク構成を固定するため |
osSku | Azure Linux 3.0、Ubuntu、Windowsなど移行方針を明確にするため |
orchestratorVersion | Kubernetesアップグレード計画を管理するため |
mode | システムノードプールとユーザーノードプールを区別するため |
nodeCountまたはオートスケール設定 | 最小・最大ノード数とコストを管理するため |
「Azureに任せる」設定と「自社で固定する」設定を混同しないことが、AKS運用の安定性を左右します。
Azure Linux 3.0へ移行する場合の注意点
Azure Linux 3.0へ移行する方法は、大きく2つあります。既定のOS SKUを使ってKubernetesバージョンアップに合わせて移行する方法と、AzureLinux3のようなバージョン指定OS SKUへ手動で移行する方法です。Microsoft Learnでは、AzureLinux3はKubernetes 1.28から1.36でサポートされ、Azure Linux 2.0からAzure Linux 3.0へ移行するためにも利用できると説明されています。(Microsoft Learn)
既存ノードプールのOS SKUは、Linuxノードプールであればaz aks nodepool updateを使って更新できます。ただし、対象OSが現在のKubernetesバージョン、VMサイズ、FIPS設定などに対応していない場合は失敗する可能性があります。(Microsoft Learn)
az aks nodepool update \
--resource-group <resource-group-name> \
--cluster-name <cluster-name> \
--name <nodepool-name> \
--os-sku AzureLinux3 \
--kubernetes-version <supported-kubernetes-version>移行前には、次の順で確認すると失敗を減らせます。
| 手順 | 確認内容 | 判断基準 |
| -: | —————— | ———————————- |
| 1 | 現在のKubernetesバージョン | AzureLinux3のサポート範囲内か |
| 2 | 現在のOS SKUとノードイメージ | Azure Linux 2.0依存がないか |
| 3 | ワークロードの互換性 | DaemonSet、CSI、CNI、監視エージェントが新OSで動くか |
| 4 | ノードプールの冗長性 | ローリング更新中も必要Pod数を維持できるか |
| 5 | 失敗時の戻し方 | 別ノードプールへの退避、スケール調整、メンテナンス時間を決めているか |
注意したいのは、OS移行を「ノードだけの作業」と捉えないことです。実際には、コンテナランタイム、ネットワークプラグイン、CSIドライバー、監視エージェント、セキュリティエージェントがノードOSに依存することがあります。検証環境で同じDaemonSetや拡張機能を使い、Podの再スケジュール、ログ収集、メトリック収集まで確認してください。
Kubernetesバージョンアップ時の確認ポイント
AKSのアップグレードでは、コントロールプレーン、全クラスター、ノードプール単位のアップグレードを使い分けます。Microsoft Learnでは、コントロールプレーンのみ、フルクラスター、ノードプールのみの3種類のアップグレードが整理されており、コントロールプレーンを先に上げることでKubernetes API互換性を確認しやすくなると説明されています。(Microsoft Learn)
また、サポートされるAKSクラスターをアップグレードする場合、Kubernetesのマイナーバージョンを飛ばすことはできません。たとえば1.28から1.30へ直接上げるのではなく、1.28から1.29、1.29から1.30のように順番に進める必要があります。(Microsoft Learn)
アップグレード前には、利用可能なバージョンを確認します。
az aks get-upgrades \
--resource-group <resource-group-name> \
--name <cluster-name> \
--output table実務では、次のように段階的に進めると安全です。
| フェーズ | 作業 | 目的 |
|---|---|---|
| 事前確認 | az aks get-upgradesで候補バージョンを確認 | サポートされる移行先を把握する |
| API確認 | deprecated APIを検出 | マニフェストの互換性問題を先に直す |
| 検証 | 非本番クラスターで同じ手順を実行 | ノード更新、Pod再配置、監視を確認する |
| コントロールプレーン更新 | APIサーバー側を先に更新 | API互換性を確認する |
| ノードプール更新 | システム、ユーザーの順に計画的に更新 | ワークロード影響を抑える |
| 事後確認 | Pod、Ingress、ログ、メトリックを確認 | 表面上の成功だけで終わらせない |
AKSのサポート対象Kubernetesバージョンは定期的に変わります。Microsoft Learnでは、Kubernetesコミュニティのマイナーバージョンリリースはおおよそ4か月ごとで、AKSはGAのKubernetesバージョンに対して12か月のサポートポリシーを採用していると説明されています。(Microsoft Learn)
開発者が押さえるべきCore Concepts：Pod、Namespace、kube-system
開発者にとって重要なのは、AKSがマネージドサービスであっても、Kubernetesの基本概念は変わらないという点です。Podは、同じネットワークとストレージリソースを共有する1つ以上のコンテナーのグループです。通常は1Podに1コンテナーで設計しますが、サイドカーなど複数コンテナーを1Podに入れる構成もあります。(Microsoft Learn)
Namespaceは、PodやDeploymentなどのKubernetesリソースを論理的に分け、表示・管理・アクセス制御をしやすくする仕組みです。AKSではdefault、kube-node-lease、kube-public、kube-systemなどが既定で作成されます。kube-systemはCoreDNS、konnectivity-agent、metrics-serverなどクラスター管理用リソースに使われるため、独自アプリケーションをここへデプロイすることは推奨されていません。(Microsoft Learn)
よくある失敗は、検証時にdefault名前空間へアプリを置き続け、本番でもそのまま使ってしまうことです。チーム、環境、アプリケーション単位でNamespaceを切ると、RBAC、NetworkPolicy、ResourceQuota、監視ダッシュボードを整理しやすくなります。
| 悪い例 | 問題 | 改善例 |
|---|---|---|
すべてdefaultへデプロイ | 権限、ログ、障害範囲が曖昧になる | app-prod、app-stgなどに分ける |
kube-systemへ独自アプリを配置 | AKS管理コンポーネントと競合しやすい | アプリ用Namespaceを作る |
| Namespaceだけ作り、ResourceQuotaを設定しない | 特定アプリがCPU・メモリを使い切る | Namespace単位でQuotaとLimitRangeを設定 |
| 環境名とアプリ名が混在 | 運用時に対象を誤りやすい | 命名規則を先に決める |
開発者は、マニフェストを書く段階でNamespace、requests／limits、ヘルスチェック、PodDisruptionBudgetをセットで考えると、ノードプール更新やOS移行時の影響を抑えやすくなります。
AutomaticとStandardはどう選ぶべきか
AKSでは、AutomaticモードとStandardモードを選択できます。Core Conceptsでは、AKS Automaticはノード、スケーリング、セキュリティ、事前構成済み設定などをよりマネージドに扱えるモードであり、AKS Standardはノードプールやスケーリングなどクラスター構成をより細かく制御できるモードと説明されています。(Microsoft Learn)
AKS Automaticは、Azureがクラスター設定、ノード管理、スケーリング、セキュリティ、Well-Architected推奨に沿った事前構成を担う体験として案内されています。Automaticクラスターは、ワークロード要件に基づいてコンピューティングリソースを動的に割り当てるため、Kubernetes運用に慣れていないチームや、標準的な本番アプリを素早く展開したいケースに向いています。(Microsoft Learn)
一方で、VMサイズ、ノードプール分離、特殊なDaemonSet、GPU、細かなネットワーク設計、コスト最適化を自社で詰めたい場合はStandardの方が適しています。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| AKS Automatic | 早く安全な既定構成で始めたい、運用負荷を下げたい | すべてを細かく制御したい用途には合わない場合がある |
| AKS Standard | ノードプール、ネットワーク、スケール、拡張機能を細かく設計したい | 設計・監視・更新の責任が大きくなる |
判断基準は「Kubernetesをどこまで自社で運用したいか」です。アプリ開発に集中したいチームはAutomatic、プラットフォームチームが標準基盤を作り込む場合はStandardを検討するとよいでしょう。
Free、Standard、Premium価格レベルの見直しも必要
AKSには、クラスター管理の価格レベルとしてFree、Standard、Premiumがあります。Microsoft Learnでは、Freeは開発・テストや学習用途、Standardは本番ワークロードやSLAが必要な環境、PremiumはLTS Kubernetesバージョンの24か月サポートや規制対応が必要な環境向けと整理されています。(Microsoft Learn)
StandardとPremiumにはUptime SLAが既定で含まれ、可用性ゾーンありではKubernetes APIサーバーの99.95%、可用性ゾーンなしでは99.9%の可用性が示されています。一方、FreeはベストエフォートでSLA保証はありません。(Microsoft Learn)
本番環境でFreeを使っている場合は、コストだけで判断せず、APIサーバー可用性、監査要件、障害時の説明責任を考慮してください。特にCI/CD、GitOps、オートスケーラー、監視ツールがKubernetes APIに依存している環境では、APIサーバーの安定性はアプリケーション運用全体に影響します。
ノードリソースグループとAKS管理領域を触りすぎない
AKSクラスターを作成すると、通常のAzureリソースグループとは別に、ノードリソースグループが自動作成されます。このリソースグループには、VM、仮想マシンスケールセット、ストレージなどクラスターに関連するインフラリソースが含まれます。(Microsoft Learn)
運用でありがちな失敗は、Azureポータルからノードリソースグループ内のVMSSやディスク、NICを直接変更してしまうことです。AKSが管理しているリソースを手動変更すると、アップグレード、スケール、修復、削除時に予期しない差分が出る可能性があります。
AKS管理領域であることを示すラベルやHelmリリースにも注意してください。Core Conceptsでは、AKS管理コンポーネントにはkubernetes.azure.com/managedby: aksラベルがあり、aks-managedプレフィックスのHelmリリースはAKSが管理し、リビジョンが増え続けることは想定内で安全と説明されています。(Microsoft Learn)
運用ルールとして、次の線引きを明文化しておくと安全です。
| 対象 | 推奨される扱い |
|---|---|
| AKS管理ラベル付きリソース | 原則として手動変更しない |
aks-managed Helmリリース | リビジョン増加を異常と判断しない |
| ノードリソースグループ内のVMSS | Azureポータルで直接変更せず、AKS CLIやIaCで管理する |
| アプリ用Namespaceのリソース | GitOpsやCI/CDで変更履歴を残す |
| セキュリティ・監視アドオン | 更新前に公式ドキュメントと互換性を確認する |
既存AKSクラスターで今日確認するチェックリスト
既存環境を運用している場合は、まず「現在の状態」を一覧化してください。特に複数サブスクリプションや複数リージョンにAKSが分散している場合、古い検証クラスターがAzure Linux 2.0のまま残っていることがあります。
| 確認項目 | コマンド・確認先 | 対応方針 |
|---|---|---|
| AKSクラスター一覧 | az aks list | 不要な検証環境を削除する |
| ノードプールのOS SKU | az aks nodepool list | Azure Linux 2.0相当の環境を特定する |
| Kubernetesバージョン | az aks show、az aks get-upgrades | サポート対象内か確認する |
| VMサイズ | ノードプール情報、IaC定義 | 未指定や過小サイズを見直す |
| System/Userノードプール分離 | mode列 | アプリPodをUser側へ分離する |
| Namespace設計 | kubectl get ns | default依存を減らす |
kube-system内の独自リソース | kubectl get all -n kube-system | 原則として専用Namespaceへ移す |
| 価格レベル | AKSのSKU/tier | 本番はStandard以上を検討する |
| OS移行検証環境 | 非本番クラスター | AzureLinux3やUbuntu 24.04を先に試す |
確認後は、対応を3段階に分けると進めやすくなります。
| 対応区分 | 対象 | 実施例 |
|---|---|---|
| 即時対応 | Azure Linux 2.0、サポート切れKubernetes、スケール不可リスク | 移行計画、検証、メンテナンス日程の確保 |
| 計画対応 | VMサイズ未指定、System/User混在、Free本番利用 | IaC修正、ノードプール追加、価格レベル変更 |
| 継続改善 | Namespace設計、監視、GitOps、リソース制限 | 運用標準化、レビュー項目化 |
移行・展開で失敗しやすいポイント
AKSのCore Conceptsを読み替えるうえで重要なのは、「概念」を「運用設計」に落とし込むことです。たとえば、ノードプールは単なるVMの集合ではなく、OS、Kubernetesバージョン、VMサイズ、スケール設定、ワークロード分離をまとめて管理する境界です。
移行や展開でよくある失敗は次の通りです。
| 失敗例 | なぜ危険か | 回避策 |
|---|---|---|
| OS移行とKubernetesアップグレードを同時に本番適用する | 障害時に原因を切り分けにくい | 非本番で検証し、本番は段階適用する |
| VMサイズをIaCで未指定にする | タイミングにより構成が変わる可能性がある | 本番ではvmSizeを明示する |
default Namespaceへ継続的にデプロイする | 権限・監視・Quotaの管理が曖昧になる | アプリ・環境単位でNamespaceを分ける |
| システムノードプールに重いアプリを配置する | CoreDNSなど基盤Podに影響する | Userノードプールへ分離する |
| ノードリソースグループ内のリソースを直接変更する | AKS管理状態と差分が生じる | AKS CLI、API、IaC経由で変更する |
| 価格レベルをコストだけで決める | APIサーバーSLAやLTS要件を見落とす | 本番要件からFree／Standard／Premiumを選ぶ |
展開時は「作れるか」ではなく「更新できるか」「スケールできるか」「障害時に戻せるか」を基準にしてください。AKSはマネージドKubernetesですが、ワークロード、ノードプール、OS SKU、バージョン、価格レベルの選択は利用者側の設計責任です。
次に取るべき行動
Azure Kubernetes ServiceのCore Conceptsは、AKSの基本構造を理解するための記事であると同時に、既存環境を見直すためのチェックリストとして使えます。特に2026年時点では、Azure Linux 2.0のサポート終了とノードイメージ削除の影響を最優先で確認してください。
まずは、すべてのAKSクラスターでノードプールのosSku、Kubernetesバージョン、VMサイズ、System/User分離を棚卸しします。そのうえで、Azure Linux 2.0相当の環境はAzure Linux 3.0やサポートされるOSへ移行し、IaCでは本番に必要なVMサイズやOS SKUを明示します。
開発者はNamespace、リソース制限、ヘルスチェックを見直し、管理者はアップグレード計画、価格レベル、ノードプール設計を整理してください。Core Conceptsを単なる入門記事として読むのではなく、AKS運用の前提条件を点検する材料として使うことが、安定したコンテナー基盤への近道です。
コメント