Azure Container LinuxがAKSでGAに：変更点と移行・運用時の注意点

Azure Kubernetes Service（AKS）でノードプールのOS選定を見直している管理者にとって、今回のポイントは明確です。Azure Container Linux（ACL）がAKS向けのGA機能として利用できるようになり、コンテナ実行に特化したイミュータブルなノードOSを本番選択肢として検討できるようになりました。

ACLは、Flatcar Container Linuxのコンテナファーストな設計をベースに、Azure Linuxのパッケージ、サービス提供、Azureプラットフォーム統合を組み合わせたAKS向けOSです。AKS v1.34以降でOSオプションとして一般提供され、新規クラスターへの導入、既存クラスターへのACLノードプール追加、既存Linuxノードプールからの移行が可能です。(Microsoft Learn)

ただし、「GAになったからすぐ全ノードを置き換える」という判断は危険です。Trusted Launch、Secure Boot、vTPM、対応VM SKU、OSアップグレードチャネル、未対応機能を確認したうえで、まず検証環境のノードプールから段階的に導入するのが現実的です。

Azure Container Linux（ACL）のGAでAKSに何が追加されたのか

Azure Updatesでは、Azure Container Linux（ACL）がAzure Kubernetes Service（AKS）で一般提供された更新として案内されています。Azure Updatesにおける「Launched」は、すべてのAzure顧客が利用できる本番対応の状態を示します。(マイクロソフト Azure) (マイクロソフト Azure)

今回の更新で重要なのは、AKSのノードOSに「よりコンテナホスト専用に設計された選択肢」が加わったことです。従来の汎用Linux OSは、コンテナ以外の用途にも使える柔軟性がある一方で、ノード上に不要なパッケージや変更余地が残りやすくなります。ACLはこの発想と逆で、ノードOSをできるだけ小さく、変更しにくく、コンテナ実行に必要なものへ絞る設計です。

実務上は、次のような変化として捉えると分かりやすいです。

観点	従来の一般的なノードOS	Azure Container Linux（ACL）
主な目的	汎用Linux環境としても利用可能	AKSノードでコンテナを実行することに特化
OS変更	パッケージ追加や設定変更の余地が大きい	`/usr`の不変性などによりOS改変を抑制
セキュリティ運用	OS構成の差分管理が重要	最小構成とイメージベース更新で差分を減らす
更新単位	パッケージ更新やノードイメージ更新	週次のノードイメージ更新が中心
向いている環境	既存運用との互換性を重視する環境	ノードを使い捨て前提で標準化したいAKS環境

ACLは「アプリケーションをノードに入れて動かすOS」ではありません。ノードOSは固定化し、アプリケーションやエージェントの変更はコンテナ、DaemonSet、AKS標準機能、または管理されたアドオンで扱うという考え方に寄せる必要があります。

ACLの主な特徴：イミュータブル、最小構成、Azure統合

Azure Container Linuxの中心にある考え方は、ノードOSを攻撃されにくく、壊れにくく、ばらつきにくくすることです。

Microsoftのドキュメントでは、ACLのメリットとして、/usrディレクトリのカーネル強制による不変性、コンテナ実行に必要なコンポーネントだけに絞った最小攻撃面、週次のイメージベース更新、Azure Linuxの署名済みパッケージやサプライチェーンプロセス、Trusted LaunchやSecure Bootとの統合が挙げられています。(Microsoft Learn)

`/usr`の不変性によりノード改変リスクを下げる

ACLでは、OSイメージの整合性を起動時と実行時に検証し、許可されていない変更がクラスターに影響する前にブロックする設計が採用されています。これにより、ノード上での意図しない改変や、侵害後の永続化リスクを下げやすくなります。(Microsoft Learn)

一方で、これは運用上の制約にもなります。たとえば、従来のようにノードへSSHしてパッケージを追加する、ホストOSのファイルを直接変更する、ノードローカルに手作業でツールを入れる、といった運用はACLと相性がよくありません。

移行前には、次のような運用が残っていないか確認してください。

確認項目	ACL移行時の判断
ノードへSSHして障害調査している	`kubectl debug`、ログ収集、Azure Monitorなどへ置き換える
ホストOSに監視エージェントを直接インストールしている	DaemonSetまたはAKS対応アドオンで提供できるか確認する
`/usr`配下やシステム領域を書き換えている	ACLでは前提を見直す必要がある
ノードごとに手作業の設定差分がある	IaC、Helm、Kustomize、GitOpsで再現可能にする
セキュリティパッチを個別パッケージ単位で管理している	ノードイメージ更新を前提に運用設計を見直す

SELinuxやTrusted Launchを前提にした堅牢化

ACLにはSELinuxによる必須アクセス制御が含まれ、既定で強制モードで動作します。また、Secure BootとvTPMを使用するTrusted Launchが必要で、非Trusted Launchのバリアントは提供されません。(Microsoft Learn) (Microsoft Learn)

この点はセキュリティ面では大きな利点ですが、既存クラスターのVMサイズや運用ツールによっては移行の前提条件になります。現在使っているVM SKUがTrusted Launchに対応していない場合、そのままインプレース移行できない可能性があります。

影響範囲：誰が何を確認すべきか

ACLのGAは、AKSを使うすべてのチームに同じ影響を与えるわけではありません。特に影響を受けやすいのは、AKSノードOSの標準化、セキュリティ基準、ノード更新、GPUノード、既存Linuxノードプールの移行を管理しているチームです。

立場	確認すべきこと
AKS管理者	AKSバージョン、ノードプールのOS SKU、VM SKU、Trusted Launch対応
セキュリティ担当	イミュータブルOS、SELinux、Secure Boot、vTPM、未対応機能の扱い
アプリ開発者	PodがACLノード上で問題なく起動するか、ホスト依存がないか
SRE/運用担当	ノードイメージ更新、PDB、DaemonSet、ログ収集、障害調査手順
プラットフォームチーム	新規クラスターの標準OSにするか、既存ノードを段階移行するか

特に開発者が見落としやすいのは、アプリケーション自体ではなく周辺コンポーネントのホスト依存です。たとえば、ログエージェント、セキュリティエージェント、CSI関連コンポーネント、ノードローカルDNS、GPU関連DaemonSetなどが、ACL上で期待どおり動くかを確認する必要があります。

対応バージョンと利用条件

ACLはAKS v1.34以降で一般提供されています。AMD64とARM64の両方に対応し、AMD64ではNVIDIA GPU対応ノードプールもサポートされます。ただし、ARM64のGPU対応ノードプールはサポートされません。(Microsoft Learn)

導入前に最低限確認すべき条件は次のとおりです。

項目	確認内容
AKSバージョン	AKS v1.34以降か
OS SKU	`AzureContainerLinux`を指定できるか
VM世代	Generation 1 VMを使っていないか
Trusted Launch	Secure BootとvTPMを有効化できるVM SKUか
ARM64	Cobaltベースのv6 SKUを使えるか
OSアップグレードチャネル	`NodeImage`または`None`を使う設計か
FIPS要件	FIPS有効ノードが必要ないか
CVM要件	Confidential VMが必要ないか

Microsoftのドキュメントでは、ACLの制限として、Artifact Streaming、Pod Sandboxing、Confidential Virtual Machines、Generation 1 VM、FIPS有効ノードがサポートされないことも明記されています。(Microsoft Learn)

既存環境でこれらの機能を使っている場合、ACLへの移行は一旦保留するか、該当ワークロードを別ノードプールに分離する判断が必要です。

新規AKSクラスターでACLを使う基本手順

新規クラスターでACLを使う場合は、Azure CLIのaz aks createで--os-sku AzureContainerLinuxを指定します。Microsoftのクイックスタートでも、このパラメーターを使ってACLクラスターを作成する手順が示されています。(Microsoft Learn)

az aks create \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --node-count 3 \
  --generate-ssh-keys \
  --os-sku AzureContainerLinux

作成後は、通常のAKSと同じように資格情報を取得し、ノードを確認します。

az aks get-credentials \
  --resource-group <resource-group> \
  --name <cluster-name>

kubectl get nodes -o wide

検証環境では、単にノードがReadyになるだけでなく、次の点まで確認してください。

検証項目	確認コマンド例
ノードOSイメージ	`kubectl get nodes -o wide`
すべてのPodの配置	`kubectl get pods -A -o wide`
DaemonSetの稼働	`kubectl get ds -A`
ノードラベル	`kubectl get nodes --show-labels`
ノードイメージバージョン	`az aks nodepool list --query '[].{name:name,osSku:osSku,nodeImageVersion:nodeImageVersion}'`

既存AKSクラスターにACLを導入する2つの方法

既存クラスターでは、大きく分けて2つの移行方法があります。Microsoftは、既存ノードプールのOS SKUを変更して自動的に再イメージ化する「インプレースOS SKU移行」と、新しいACLノードプールを追加してワークロードを移し、古いノードプールを削除する方法を案内しています。(Microsoft Learn)

方法	向いているケース	注意点
新しいACLノードプールを追加	本番影響を抑えて段階移行したい	ノードプール追加分の一時的なコストが発生する
インプレースOS SKU移行	ノードプール構成を大きく変えずに移行したい	ノードが再イメージ化されるためPDBや可用性確認が重要

本番環境では、まず新しいACLノードプールを追加する方式が扱いやすいです。既存ノードプールとACLノードプールを並行稼働させ、ワークロード単位で移行できるため、問題発生時の切り戻し判断もしやすくなります。

方法1：新しいACLノードプールを追加して移行する

既存クラスターにACLノードプールを追加する場合は、次のように--os-sku AzureContainerLinuxを指定します。

az aks nodepool add \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <new-node-pool-name> \
  --os-sku AzureContainerLinux \
  --mode System \
  --node-count 3

Microsoftの移行手順では、新しいノードプールをシステムエージェントプールとして使えるように--mode Systemを指定する例が示されています。これにより、元のシステムノードプール削除へ進める構成にできます。(Microsoft Learn)

ただし、すべてのケースでいきなりSystemプールを置き換える必要はありません。まずUserノードプールとしてACLを追加し、アプリケーションワークロードだけを検証する進め方も現実的です。

方法2：既存ノードプールをインプレース移行する

インプレース移行では、既存LinuxノードプールのOS SKUをAzureContainerLinuxへ変更します。この操作はノードプールの再イメージ化を伴い、標準的なノードイメージアップグレードの流れで処理されます。(Microsoft Learn)

az aks nodepool update \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <existing-node-pool-name> \
  --os-sku AzureContainerLinux \
  --enable-secure-boot \
  --enable-vtpm

ACLへの移行ではTrusted Launchが必要なため、--enable-secure-bootと--enable-vtpmを指定します。現在のVMサイズがTrusted Launchに対応していない場合は、移行前にVMサイズ変更またはノードプール再作成を検討する必要があります。(Microsoft Learn)

なお、インプレースOS SKU移行には制限があります。PowerShellやAzure portalからは利用できず、既存ノードプール名の変更、UseGPUDedicatedVHDが有効なノードプール、Windows OS SKU移行はサポートされません。(Microsoft Learn)

移行前に必ず確認したいチェックリスト

ACL移行で失敗しやすいのは、OSそのものよりも「ノードに依存した運用」が残っているケースです。次のチェックリストを使って、移行前に影響範囲を洗い出してください。

チェック項目	確認の観点
AKSバージョン	v1.34以降に上げられるか
VM SKU	Trusted Launch、Secure Boot、vTPMに対応しているか
PDB	ノード再イメージ中にPod退避できる余裕があるか
DaemonSet	監視、ログ、セキュリティ、CSI関連がACLで動作するか
ホストパス利用	`hostPath`でOS領域に依存していないか
権限設定	privileged PodやSELinuxとの相性を確認したか
OS更新方針	`NodeImage`または`None`で運用できるか
未対応機能	Artifact Streaming、Pod Sandboxing、CVM、FIPS要件がないか
ロールバック	旧OS SKUへ戻す手順と判断基準を決めたか
監視期間	検証後、数週間の監視期間を確保できるか

Microsoftの移行ドキュメントでも、本番移行前に開発・ステージング環境でワークロードがACL上で正常に動作すること、PDBに十分な余裕があること、移行後しばらくサービス状態を監視することが推奨されています。(Microsoft Learn) (Microsoft Learn)

OSアップグレードチャネルの注意点

ACLでは、サポートされるOSアップグレードチャネルがNodeImageとNoneに限られます。UnmanagedとSecurityPatchは、ACLの不変な/usrディレクトリと互換性がありません。(Microsoft Learn)

これは運用設計に影響します。個別パッケージのセキュリティパッチ適用ではなく、ノードイメージ単位で更新する前提になるためです。

実務では、次のように整理すると判断しやすくなります。

運用方針	ACLでの考え方
セキュリティ更新を自動で取り込みたい	`NodeImage`チャネルを軸に検討
更新タイミングを厳密に制御したい	`None`を使い、検証後に明示的に更新
パッケージ単位で即時パッチしたい	ACLの設計と合わないため運用見直しが必要
ノード差分を減らしたい	ACLのイメージベース更新と相性がよい

ACLのノードイメージは週次でリリースされ、バージョンはAKSの日付ベース形式に従います。現時点では完全なノードイメージ更新のみをサポートします。(Microsoft Learn)

OS GuardやFlatcarプレビュー利用者が注意すべき点

ACLは、2025年11月にプレビュー入りした「Flatcar Container Linux for AKS」のGAリリースとして位置付けられています。一方で、OS Guardプレビューの機能、たとえばIntegrity Policy Enforcement（IPE）によるコード整合性は現時点でACLではサポートされていません。OS Guard機能が今すぐ必要な場合は、該当機能がACLで利用可能になるまでOS Guardを継続することが推奨されています。(Microsoft Learn)

つまり、移行判断は単純に「新しいからACL」ではありません。

現在の利用状況	判断の目安
Flatcar Container Linux for AKSプレビューを検証中	ACLへの移行計画を立てる
OS GuardのIPEなどを要件にしている	ACLで該当機能が使えるまで継続利用を検討
Azure Linuxノードで一般的なWeb/APIを運用	ACL検証の優先度は高い
FIPS有効ノードが必須	ACLは現時点で対象外
Confidential VMが必須	ACLは現時点で対象外

セキュリティ強化を目的にACLを検討する場合でも、既存のセキュリティ要件とACLの未対応機能を照合することが重要です。

管理者・開発者別の具体的な対応

AKS管理者が行うこと

AKS管理者は、まずクラスターとノードプールの棚卸しを行います。

az aks list \
  --query '[].{name:name,resourceGroup:resourceGroup,kubernetesVersion:kubernetesVersion}' \
  -o table

az aks nodepool list \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --query '[].{name:name,mode:mode,osSku:osSku,vmSize:vmSize,nodeImageVersion:nodeImageVersion}' \
  -o table

確認すべきポイントは、AKSバージョン、OS SKU、VMサイズ、System/Userノードプールの分離状況です。SystemプールをACLへ移す場合は、CoreDNS、konnectivity、CSI関連、監視エージェントなどの基盤コンポーネントが問題なく動くかを先に検証してください。

開発者が行うこと

開発者は、アプリケーションがACLノードに依存せず動くかを確認します。特に次のようなPod仕様は要注意です。

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.nodeName}{"\n"}{end}'

確認したいのは、単にPodが起動しているかではありません。以下の観点まで見る必要があります。

観点	例
ホスト依存	`hostPath`で特定ディレクトリを参照していないか
特権実行	`privileged: true`が必要な理由を説明できるか
ノード固定	`nodeSelector`やaffinityで旧OSノードに固定していないか
ストレージ	CSIドライバーやマウント処理がACL上で正常か
ログ	標準出力、サイドカー、DaemonSet収集が想定どおりか
起動時間	ノード再作成時にPodが許容時間内に復旧するか

アプリ側で「ノードに入って調べればよい」という前提が残っている場合、ACL移行を機にデバッグ方法も見直すべきです。ログ、メトリック、トレース、イベント、kubectl describe、kubectl logsで原因を追える状態にしておくと、イミュータブルOSの利点を活かしやすくなります。

本番展開のおすすめ手順

本番展開では、一度に全ノードをACLへ変更しないことが重要です。以下の順番で進めると、影響範囲を抑えながら判断できます。

フェーズ	実施内容	合格基準
棚卸し	AKSバージョン、ノードプール、VM SKU、未対応機能を確認	ACL対象外のノードプールを識別できている
検証環境	新規ACLクラスターまたはACLノードプールを作成	主要DaemonSetとアプリが正常稼働
ステージング	本番相当の負荷・監視・更新手順を確認	再起動、スケール、障害時対応が確認済み
一部本番	低リスクなUserノードプールから移行	エラー率、レイテンシ、再スケジュールに問題なし
本格展開	Systemプールや主要ワークロードを段階移行	ロールバック手順と監視基準が整っている

移行後は、Microsoftの手順にあるように、kubectl get nodes -o wideでACL OSイメージを確認し、kubectl get pods -o wide -AでPodとDaemonSetの稼働状況を確認し、az aks nodepool listでosSkuとnodeImageVersionを確認します。(Microsoft Learn)

導入すべきケース、まだ待つべきケース

ACLは多くのAKS環境で有力な選択肢になりますが、すべての環境に即時適用すべきものではありません。

導入を前向きに検討したいケース

AKSノードの標準化を進めたい
ノードOSの手作業変更をなくしたい
コンテナ実行専用ホストとして最小構成を重視したい
Secure Boot、vTPM、SELinuxなどを前提にしたセキュリティ強化を進めたい
新規AKSクラスターをこれから設計する
既存のノードプール運用をイメージベース更新へ寄せたい

まだ慎重に判断すべきケース

FIPS有効ノードが必須
Confidential VMが必須
Artifact StreamingやPod Sandboxingを利用している
OS GuardのIPEなど、ACL未対応の機能を要件にしている
VM SKUがTrusted Launchに対応していない
ノード上に直接エージェントやツールを入れる運用が残っている
PDBや冗長化が不十分で、ノード再イメージに耐えられない

特に本番環境では、「ACLに移行できるか」よりも「ACLらしい運用に変えられるか」が成功の分かれ目です。ホストOSを触る運用が多いほど、移行前の整理に時間をかけるべきです。

まとめ：ACLはAKSノード運用を“使い捨て前提”へ近づける更新

Azure Container Linux（ACL）のGAは、AKSのノードOS運用をよりセキュアで標準化された方向へ進める重要な更新です。Flatcar Container Linux由来のイミュータブル設計、Azure Linuxベースの供給網、Trusted LaunchやSecure Bootとの統合により、AKSノードをコンテナ専用ホストとして扱いやすくなります。

一方で、ACLは従来型の「ノードに入って変更する」運用とは相性がよくありません。移行前には、AKS v1.34以降であること、Trusted Launch対応VM SKUを使えること、未対応機能に該当しないこと、PDBと監視が整っていることを確認してください。

次に取るべき行動は、既存ノードプールの棚卸しです。osSku、vmSize、nodeImageVersion、DaemonSet、PDB、未対応機能を確認し、まずは検証環境または低リスクなUserノードプールでACLを試すところから始めるのが安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Container LinuxがAKSでGAに：変更点と移行・運用時の注意点

Azure Container Linux（ACL）のGAでAKSに何が追加されたのか

ACLの主な特徴：イミュータブル、最小構成、Azure統合

`/usr`の不変性によりノード改変リスクを下げる

SELinuxやTrusted Launchを前提にした堅牢化

影響範囲：誰が何を確認すべきか

対応バージョンと利用条件

新規AKSクラスターでACLを使う基本手順

既存AKSクラスターにACLを導入する2つの方法

方法1：新しいACLノードプールを追加して移行する

方法2：既存ノードプールをインプレース移行する

移行前に必ず確認したいチェックリスト

OSアップグレードチャネルの注意点

OS GuardやFlatcarプレビュー利用者が注意すべき点

管理者・開発者別の具体的な対応

AKS管理者が行うこと

開発者が行うこと

本番展開のおすすめ手順

導入すべきケース、まだ待つべきケース

導入を前向きに検討したいケース

まだ慎重に判断すべきケース

まとめ：ACLはAKSノード運用を“使い捨て前提”へ近づける更新

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Container LinuxがAKSでGAに：変更点と移行・運用時の注意点

Azure Container Linux（ACL）のGAでAKSに何が追加されたのか

ACLの主な特徴：イミュータブル、最小構成、Azure統合

/usrの不変性によりノード改変リスクを下げる

SELinuxやTrusted Launchを前提にした堅牢化

影響範囲：誰が何を確認すべきか

対応バージョンと利用条件

新規AKSクラスターでACLを使う基本手順

既存AKSクラスターにACLを導入する2つの方法

方法1：新しいACLノードプールを追加して移行する

方法2：既存ノードプールをインプレース移行する

移行前に必ず確認したいチェックリスト

OSアップグレードチャネルの注意点

OS GuardやFlatcarプレビュー利用者が注意すべき点

管理者・開発者別の具体的な対応

AKS管理者が行うこと

開発者が行うこと

本番展開のおすすめ手順

導入すべきケース、まだ待つべきケース

導入を前向きに検討したいケース

まだ慎重に判断すべきケース

まとめ：ACLはAKSノード運用を“使い捨て前提”へ近づける更新

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`/usr`の不変性によりノード改変リスクを下げる

コメントするコメントをキャンセル