AKS（Azure Kubernetes Service、Microsoftが提供するマネージドKubernetesサービス）のノードOS選択肢のひとつ、Flatcar Container Linux for AKS（プレビュー機能）が段階的に廃止される。Azureは2026年6月8日にサポートを終了し、新規ノードプールの作成とセキュリティパッチの提供を止めた[1]。さらに2026年9月8日には既存のFlatcarノードイメージそのものを削除し、以降はスケールアウトや修復（reimage・redeploy）操作が失敗する[1][2]。本稿執筆時点の2026年7月10日で、イメージ削除まで残り60日である。AKS上でFlatcarノードプールを運用するインフラ担当者にとって、これは単なるOSアップデートの話ではない。インプレースでの移行経路が用意されておらず、新規ノードプール作成・ワークロード移行・旧プール削除という3段階の作業を期限内に終える必要がある。運用コストと人員配分の判断材料として、実務手順とタイムラインを整理する。
予備知識
- AKS（Azure Kubernetes Service）: Microsoftが提供するマネージド型Kubernetesサービス。クラスタの制御プレーンをAzureが運用し、利用者はワーカーノードとワークロードの管理に専念できる。
- Flatcar Container Linux: コンテナ実行に特化した軽量・イミュータブル（構成を書き換えず丸ごと入れ替える設計）なLinuxディストリビューション。CoreOS系譜のOSで、OS自体を自動更新する仕組みを持つ。
- ノードプール: AKSクラスタ内で同一のOS種別・VMサイズ・スケール設定を共有するワーカーノードの集合。1クラスタは複数のノードプールを組み合わせて構成できる。
- インプレース移行: 既存のノードやOSイメージを維持したまま設定値だけを切り替える移行方式。新規リソースを作らずに済むため、作業時間と切り替えリスクを抑えやすい。
AKS上でのノードプール設計やKubernetesの基礎概念を体系的に押さえておくと、今回のような移行判断を迅速に進めやすい。
何がいつ起きるのか——廃止のタイムライン
Flatcar Container Linux for AKSの廃止は2段階で進む。Azureスタッフは2026年3月10日、GitHub上のAzure/AKSリポジトリでこの廃止を発表した[1]。
| 日付 | 何が起きるか | 影響 |
|---|---|---|
| 2026-03-10 | 廃止発表（GitHub Issue #5648） | 移行計画の起点 |
| 2026-06-08 | サポート終了 | 新規Flatcarノードプール作成不可、新規イメージ提供・セキュリティパッチ停止[1] |
| 2026-09-08 | ノードイメージ完全削除 | 既存Flatcarノードプールのスケール操作・修復（reimage/redeploy）が失敗[1][2] |
本稿執筆時点の2026年7月10日は、サポート終了からすでに32日が経過している。つまり新規のFlatcarノードプールは、もう作成できない状態にある。残っているのは、既存プールがイメージ削除の影響を受けるまでの60日間である。
本番運用でのノードプール設計や運用ノウハウを深掘りしたい場合、現場目線で基礎から本番運用までを地図的に俯瞰できる一冊が役立つ。
なぜインプレース移行ができないのか
AKSは通常、稼働中のノードプールのOS SKUをインプレースで切り替える移行機能を持つ[2]。しかしFlatcarから他のOSへの移行は、このインプレース移行の対象外である[2]。Azure公式ドキュメントは、Flatcarノードプールについて「新しいOSでノードプールを作成し、ワークロードを移行し、旧ノードプールを削除する」という手順を明記している[1][2]。
インプレース移行と新規作成型の移行では、必要な作業内容が大きく異なる。
| 移行方式 | 対象 | 作業内容 | 主なリスク |
|---|---|---|---|
| インプレースOS SKU移行 | Ubuntu⇔Azure Linuxなど | 既存ノードプールの設定変更のみ | 低い（段階的ロールアウト可能） |
| 新規プール作成＋移行 | Flatcar→他OS | 新規ノードプール作成、ワークロード移動、旧プール削除 | 移行順序と並行稼働期間の設計に依存[1][2] |
Azure Storage GPv1（General Purpose v1、汎用ストレージアカウント旧バージョン）が2026年10月13日に廃止される。Azureでストレージアカウントを持つ組織は、この期日までにGPv2（General […]
移行手順——新規プール作成からのワークロード移行
移行は3段階に分かれる。まずAzure LinuxまたはUbuntuを指定した新規ノードプールを、既存クラスタに追加する[1][2]。次にPodのスケジューリングを新ノードプールへ寄せ、既存ワークロードを段階的に移す。最後に旧Flatcarノードプールを削除する[1]。
移行先の選択肢は2つある。Azure LinuxはMicrosoftがAzure向けに最適化した後継OSで、AKS v1.34からGA（一般提供）として使える[2]。Ubuntuは他クラウドとの構成互換性を重視する場合に選びやすい。
AWSは2025年後半から、ALB・NLB・KMS・ACM・CloudFront・Secrets Managerで、ML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism、NISTが[…]
移行先OSの選択——Azure LinuxとUbuntu
移行先の判断は、運用方針によって分かれる。Azure LinuxはFlatcarと同じくイミュータブル志向のOSで、Azure専業運用との相性を重視した設計である[2]。
| 項目 | Azure Linux | Ubuntu |
|---|---|---|
| 位置づけ | Azure向け最適化・Flatcarの実質後継 | AKS標準・汎用Linux |
| GA時期 | AKS v1.34以降でGA[2] | 既存バージョンから提供 |
| 向いている用途 | Azure専業運用、イミュータブル志向の継承 | マルチクラウド運用、既存Ubuntu運用資産の流用 |
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
よくある質問（FAQ）
Q1. 2026年9月8日を過ぎるとFlatcarノードプールはどうなるのか。
ノードイメージそのものがAzure側から削除されるため、スケールアウトやノードの修復（reimage・redeploy）操作が失敗する[1]。既存Podの稼働は即座には止まらないが、ノード追加や障害復旧ができなくなる。
Q2. インプレースでOSを切り替えることはできないのか。
できない。AKSは他OS間ではインプレースのOS SKU移行に対応するが、Flatcarはこの対象外であり、新規ノードプール作成による移行が必須である[2]。
Q3. 移行先はAzure LinuxとUbuntuのどちらを選べばよいか。
Azure専業でイミュータブル運用を継承したいならAzure Linux、他クラウドとの構成互換性や既存Ubuntu運用資産を活かしたいならUbuntuが選択肢になる[2]。
まとめ
Flatcar Container Linux for AKSは、2026年6月8日のサポート終了に続き、9月8日にノードイメージが完全に削除される。本稿執筆時点で残り60日である。インプレースでの移行経路はなく、新規ノードプールの作成、ワークロードの段階移行、旧プールの削除という手順を踏む必要がある。移行先はAzure LinuxかUbuntuの二択で、運用方針に応じて選ぶ。まだFlatcarノードプールが残っている場合、移行計画の着手を先送りする余地は小さい。
