この記事は、AEON Advent Calendar 2025の3日目 です🎉
イオンスマートテクノロジーのDevSecOps Div SREチーム さいとう です。
去る2025年11月17日から21日にMicrosoft Ignite 2025に参加してきました。
今回は、AKS(Azure Kubernetes Service)関連のセッションからグッときた情報をまとめていこうと思います。Part2です！
Part1はこちら↓
AKS(Azure Kubernetes Service)とは
Azureで提供されているマネージドなKubernetesサービスです。
Azure Kubernetes Service (AKS) は、コンテナー化されたアプリケーションをデプロイして管理するために使用できるマネージド Kubernetes サービスです。 AKS を使用するには、最小限のコンテナー オーケストレーションの専門知識が必要です。 AKS では、責任の多くを Azure にオフロードすることで、Kubernetes の管理の複雑さと運用上のオーバーヘッドを軽減します。 AKS は、高可用性、スケーラビリティ、移植性を必要とするコンテナー化されたアプリケーションのデプロイおよび管理と、複数のリージョンへのアプリケーションのデプロイ、オープンソース ツールの使用、既存の DevOps ツールとの統合に最適なプラットフォームです。
[BRK144]Build, modernize, and secure AKS workloads with Azure Linux
このセッションではAzure Linuxの紹介がメインでした。
Azure LinuxはAKSを含むAzure上のワークロードのために設計されたLinuxディストリビューションです。
そんなAzure Linuxのベネフィットや今後の展望について語られたセッションです。
Azure Linuxの強み
- 回復力（Resiliency）の強化
- OSのアップグレードが頻繁な再起動やダウンタイム、回帰を引き起こすという懸念に対し、Azure LinuxはAKS固有の厳格なエンドツーエンド（E2E）テストをすべてのパッケージに実行し、これをリリースプロセスのゲートとしている。これにより、ユーザーがリリースを受け取る時点でAKSシナリオで十分にテストされていることが保証される。
- また、カーネル、systemd、runC、containerdなどの主要なパッケージは安定したLTSブランチに維持される。
- 軽量OSによる性能向上とセキュリティ向上
- Azure LinuxはAKS向けに最適化され、OSイメージが非常に軽量。
- パッケージ数ベースで、他のディストリビューションに対して約70%ほど
- これにより、VHD作成、ノード作成、スケールアップ、削除時間などのあらゆる操作が高速化される。これによりクラスター作成時間やアップグレード時間が短くなるというメリットがある。
- パッケージ数が少ないため、対処すべきCVEの数が少なくなる。Microsoftは、クリティカルなCVEに対して5日以内にパッチを適用するという厳格なSLAを設けている。
Azure Linuxの新機能(1): Pod Sandboxing on AKS(GA)
前編の記事: Microsoft Ignite 2025のまとめ〜AKS編〜
でも紹介した Pod Sandboxing on AKSです。
- 今後、GPUサポートが予定されているらしい。
- AIワークロード（GPUリソースを必要とする & セキュリティリスクも高い処理）を、完全に隔離した状態で実行可能になる日が近い。
Azure Linuxの新機能(2): Azure Linux with OS Guard (Public Preview)
Azure Linux with OS Guardは、Azure Linuxをさらにセキュアにし堅牢にしたものです。
- 整合性
- OS Guardは、起動時からバイナリの実行に至るまで、ランタイムコンポーネントの整合性を保証するエンドツーエンドでセキュアなOSのSKU。
- 不変なファイルシステム（DM-Verity）
-
/usrなどのUnixシステムリソースが置かれているファイルシステムは、DM-Verity（Device-Mapper-Verity）読み取り専用のファイルシステムとしてマウントされる。 - これにより、Kubernetesクラスター上で時間とともにファイルシステムを変更したり新しいバイナリをインストールしたりするなどの運用上のドリフトが防止される。
-
- セキュアブートとUKI
- FIPSとセキュアブートがデフォルトで有効になっている。Unified Kernel Image (UKI)を使用することで、カーネルと初期RAMファイルシステムが1つのパッケージにまとめられて署名され、ブート時にコアリソースの整合性がチェックされる。
- IPE（Integrity Policy Enforcement）
- 信頼されたコード（コンテナ内を含む）のみが実行時にロード・実行されることを保証される(Public Preview中は監査モード)
- SE Linuxの使用
- 必須アクセス制御（Mandatory Access Control）としてSE Linuxを使用(Public Preview中はPermissiveモード)
- さらに軽量に
- Azure Linuxより更にパッケージが100個ほど少なく、軽量化つセキュアになっている。
そして、今後の予定は以下とのこと。
- SE LinuxおよびIPEのenforcingモードでの提供。
- シェルとインタプリタを完全に削除
• Azure Linux 4.0の開発
[BRK121]Build, modernize, and secure AKS workloads with Azure Linux
AKSの運用を楽にする、スケールさせるというテーマに特化したセッションです。
前編の記事: Microsoft Ignite 2025のまとめ〜AKS編〜
でも言及していたAKS Automaticの紹介がメインになります。
StandardとAutomaticの違いのドキュメントはこちら↓
ここからは、AKS Automaticの注目機能についていくつか解説していきます。
Pod Readiness SLA
- 業界初のPodの準備時間にSLAを設定🤯
- 99.9%ileで5分
- 更新されたSLAは以下からダウンロードが可能。
Pod Readiness SLAに関する記述は以下
自動クラスターの準備状況の計算とサービス レベル
・「当該サービス料金」とは、当該期間において、サービス クレジットが所有されている自動クラスター内の仮想マシンで発生した合計追加時間当たりサービス料金から、仮想マシン自体の料金を除いたものです。
・「適用対象ポッド」は、シークレット、構成マップ、下方 API、emptyDir 以外のソースでボリュームをマウントせず、Windows、GPU、機密情報、または他の特別な SKU などのノードを必要としないポッドと定義されます。
・「除外ウィンドウ」は、中規模から大規模の (100 以上のノードを含む) 操作が開始された 5 分間、または自動クラスターでクォータ/サブスクリプション エラーが検出された 5 分間と定義されます。
・「合計ポッド操作数」とは、当該期間中に除外ウィンドウの範囲外でお客様によって開始された適用対象ポッド作成操作の総数です。
・「遅延ポッド操作数」は、ポッド オブジェクト作成時点から計測された 5 分間に (ただし、イメージの取得とコンテナー ランタイムの初期化にかかった時間は除外されます)、適用対象ポッドのコンテナーが開始済みと報告されなかった適用対象ポッド作成操作の総数です。
・自動クラスターの「準備完了率」は、所定の Microsoft Azure サブスクリプションでの当該期間における、合計ポッド操作数から遅延ポッド操作数を引いた値を合計ポッド操作数で割った値として計算されます。準備完了率を数式で表すと、次のようになります。
(合計ポッド操作数 – 遅延ポッド操作数) / (合計ポッド操作数) x 100
- 当たり前と言えば当たり前だが、
ただし、イメージの取得とコンテナー ランタイムの初期化にかかった時間は除外されますと記載がある。 - Pod作成からコンテナ起動（initContainer起動）までの時間という理解であっているのか...。ここは調べておきたい。
Automated Deployments
- GitHubやAzure DevOpsのリポジトリにあるコードから、DockerfileやKubernetesマニフェストを自動生成してくれる🤯
- デプロイプロセス（CI/CDパイプライン）も自動的に設定されるため、プルリクエストをマージするだけでデプロイ完了する🤯
まさに開発者がコードに集中するという世界が実現しています。
また、Service Connectorとの統合についても言及されています。
- これまでWorkload Identityを利用するにはフェデレーション設定など面倒な作業が必要だったのだが、それを裏側で自動化してくれるService Connectorというものがある。
- これがAutomated Deploymentsに組み込まれた👏
Deployment Safeguards
- AKS Automaticで散々語られているが、AKS Automaticは初めからMicrosoftの考えるベストプラクティスが既に実装されている。
- 必要なポリシーは初めから組み込まれていてガードレールとして機能している🤯
-
latestタグの禁止とか👹 - limits/requestsの設定不備とか👹
- probeの設定漏れとか👹
-
おわりに
以上2記事にわたってAKS関連情報をまとめてみました。
特に、AKS AutomaticはMicrosoftの知見が詰まった、まさに開発者のためのマネージドサービスと感じます。
実際に使ってみてまた共有したいと思います。
参考: AKS情報の入手先
イオングループで、一緒に働きませんか？
イオングループでは、エンジニアを積極採用中です。少しでもご興味をもった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています！
Discussion