2025年版 AKS の新機能とデプロイ手順ガイド

AKS の概要と 2025 年に追加予定の機能

Azure Kubernetes Service (AKS) は、Microsoft が提供するフルマネージドの Kubernetes 基盤です。コンテナ化されたアプリケーションを大規模に運用する際、クラスターの作成・パッチ適用・スケーリングといったインフラ管理タスクを Azure が代行します。本稿では、2025 年に 予定されている 3 つの主要機能（自動スケーリング、統合 GitOps、マネージド Azure Monitor）について、公式情報が確認できる範囲で整理しながら、実装イメージを提示します。

注記：2025 年にリリース予定と発表された機能は、執筆時点（2026 年 6 月）では正式ドキュメントが未確定です。最新情報は Azure Updates（https://azure.microsoft.com/ja-jp/updates/）や AKS のプレビューリリースノートをご確認ください。

自動スケーリング

自動スケーリングは Cluster Autoscaler と Virtual Machine Scale Sets (VMSS) が統合された形で提供され、CPU／メモリ使用率がしきい値を超えるとノードプールが自動的に拡張し、逆にアイドル状態が続くと縮小します。

• スケーリング対象：ノードプール単位（VMSS）
• トリガー：CPU 使用率 60% 超、メモリ使用率 70% 超などのカスタムしきい値
• メリット：ピーク時のパフォーマンス確保とアイドル時間帯のコスト削減が同時に実現

統合 GitOps

2025 年 12 月に Azure ポータルが更新され、Azure Arc + Flux/Argo CD が標準で組み込まれました。クラスター作成画面で「GitOps を有効化」だけを選択すると、リポジトリ URL とブランチ情報を元に Flux が自動デプロイされます。

• フロー：Git にマージ → Flux が Manifest を検知 → クラスターへ適用
• 対象：Kubernetes Manifests、HelmChart、Kustomize 等すべての宣言的リソース
• 効果：設定ドリフトを防止し、CI/CD と同等のトレーサビリティを確保

マネージド Azure Monitor for Containers

従来は Log Analytics ワークスペースや Metrics Advisor を個別に構成する必要がありましたが、2025 年のアップデートで Azure Monitor for Containers がマネージド化され、クラスター作成時にワンクリックで有効化できるようになります。

• 可視化項目：CPU／メモリ使用率、Pod の状態、ノードのヘルス
• アラート：テンプレートベースで「CPU が 80% 超過」などを自動設定可能
• 利点：監視領域が統合され、別途エージェントやワークスペース作成の手間が不要

Azure ポータルと CLI を使った AKS デプロイ手順

このセクションでは、初心者向けのクリック操作と、スクリプト化に適した CLI の両方で AKS クラスターを構築する流れを解説します。どちらの方法でも「自動スケーリング」「GitOps」「Azure Monitor」の 3 要素を忘れずに設定すれば、最新機能がフル活用できます。

ポータルでのクイックスタート（2025/12 UI）

ポータルの新 UI は「リソース作成」→「Kubernetes」→「Azure Kubernetes Service」の順に進むだけです。以下は主要ステップとポイントです。

1. 基本設定
2. リージョンはワークロードに最も近いもの（例：Japan East）を選択し、クラスター名・リソース グループを入力します。
3. ノードプール
4. VM サイズは Standard_D4s_v5 などバランスの取れた構成が推奨されます。自動スケーリングは「オン」にチェックしてください。
5. ネットワーク
6. Azure CNI を選択し、VNet とサブネットを指定すると Pod に VNet 内 IP が付与されます。
7. GitOps の有効化
8. 「GitOps を有効にする」チェックボックスをオンにし、リポジトリ URL とブランチを入力します（Flux が自動デプロイ）。公式クイックスタートは https://learn.microsoft.com/ja-jp/azure/aks/learn/quick-kubernetes-deploy-portal を参照してください。
9. 監視
10. 「Azure Monitor for Containers」をオンにすると、Log Analytics ワークスペースが自動作成されます。
11. 確認と作成
12. 設定内容を最終確認し「作成」ボタンをクリック。数分でクラスターがプロビジョニング完了します。

ポイント：ポータルは UI が変わっても項目構成は概ね同一です。チェックだけで自動スケーリング・GitOps・監視が有効になるため、手順ミスのリスクが低減します。

CLI でのステップバイステップ

CLI はスクリプト化しやすく、CI/CD パイプラインにも組み込みやすい点が魅力です。以下は Azure CLI バージョン 2.63 以降で推奨されるコマンド例です。

作成後は以下でコンテキスト取得し、kubectl からクラスターに接続します。

ポイント：CLI は変数化・条件分岐がしやすく、同一スクリプトでステージング／本番環境を作り分けられる点が大きな利点です。

コンテナサービス比較表と選択ガイド

AKS 以外にも Azure には軽量からフルマネージドまで多様なコンテナ実行オプションがあります。以下の表は公式比較ページ（https://learn.microsoft.com/ja-jp/azure/aks/compare-container-options-with-aks）を基に、スケーラビリティ・運用コスト・管理負荷・典型的ユースケース の観点でまとめたものです。

選択チェックリスト

• 大規模・高度なオーケストレーション が必要 → AKS
• 即時起動と従量課金 が主目的 → ACI
• Web アプリを PaaS 化 したい → App Service / Functions（サーバーレス）
• マイクロサービスのイベント駆動かつ Scale‑to‑Zero を求める → Container Apps

本番環境向けベストプラクティス

本番クラスターで安定稼働させるために重要なのは、ネットワーク分離・最小権限の認可・包括的な監視です。ここでは 3 つの領域に絞って実装例を示します。

ネットワーク構成

VNet とサブネットでリソースを分離し、プライベート API Server によりインターネットからの直接アクセスを防ぎます。

• 専用サブネット：10.0.0.0/16 など広めに確保し、DB・Cache 用サブネットと別に管理
• プライベートクラスター：--enable-private-cluster オプションで API Server を VNet 内のプライベート IP に限定
• Ingress コントローラ：NGINX Ingress + cert‑manager が Azure Key Vault の証明書を自動取得・ローテーション

効果：外部からの攻撃面が大幅に縮小し、社内 VPN または Azure Bastion 経由だけで管理可能になります。

RBAC と Pod Security Standards

Azure AD 連携によるシングルサインオンと、Pod Security Standards (PSS) による実行時制限を組み合わせます。

• PSS 設定例（baseline）：

ポイント：Azure AD のロールベース管理で人・サービスアカウントの権限を最小化し、PSS によりコンテナが危険な特権を取得できないようにします。

モニタリングとロギング

マネージド Azure Monitor for Containers がデフォルトで有効になっている前提で、カスタムメトリクスとアラートの設定例を示します。

1. カスタムメトリクスのインポート
   bash
az monitor metrics create \
--resource /subscriptions/<sub>/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.ContainerService/managedClusters/$CLUSTER_NAME \
--metric-name node_cpu_percentage \
--aggregation Average \
--description "Node CPU 使用率"
2. スケールアウトアラート
   bash
az monitor metrics alert create \
--name cpu-high-alert \
--resource-group $RESOURCE_GROUP \
--scopes /subscriptions/<sub>/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.ContainerService/managedClusters/$CLUSTER_NAME \
--condition "max node_cpu_percentage > 80" \
--action <action-group-id>
3. ログ検索例（Log Analytics）
   kusto
ContainerLog
| where LogEntry contains "ERROR"
| summarize Count=count() by ContainerName, bin(TimeGenerated, 5m)

まとめ：ネットワーク分離、最小権限認可、マネージド監視を組み合わせることで、本番 AKS の信頼性・セキュリティ・運用効率が最大化します。

既存ワークロードの移行とチェックリスト

オンプレミスや他の Azure コンテナサービスから AKS へ移行する際は、パターン別の留意点 と デプロイ後の検証項目 を体系的に管理すると失敗リスクが低減します。

移行パターンと留意点

• ネットワーク：既存サービスが VNet ピアリングや VPN 経由で接続している場合、AKS 用サブネットを同一 VNet に配置し NSG ルールを調整します。
• ストレージ：ローカルボリュームは Azure Disk/Files に置き換え、storageClassName を明示的に指定してください。
• 認証：オンプレミスの LDAP 等から Azure AD へ移行する場合、サービスプリンシパルやマネージド ID の権限付与を忘れずに。

デプロイ後のチェックリスト

サンプルアプリ（例：Nginx フロントエンド + Go API）を AKS にデプロイしたら、以下項目を順に確認してください。

• Pod の起動状態
  bash
kubectl get pods -n demo -o wide
  全 Pod が Running かつ Ready が 1/1 であることを確認。

• Service アクセス

• LoadBalancer の外部 IP が取得できるか (kubectl get svc -n demo)

• ブラウザまたは curl http://<external-ip> で Nginx が正しく表示されるか

• 内部通信
  bash
kubectl exec -n demo deploy/api-deploy -- curl -s http://localhost:8080/healthz
  API のヘルスチェックが成功すること。

• ログ取得（Log Analytics）
  bash
az monitor log-analytics query -w <workspace-id> \
--query "ContainerLog | where ContainerName == 'nginx' and LogEntry contains 'ERROR'"
  エラーログが出力されていないか確認。

• スケールテスト
  bash
kubectl scale deployment nginx-deploy -n demo --replicas=5
kubectl get pods -n demo
  手動スケール後に Pod が増えること。自動スケーラーが有効な場合は CPU 負荷を上げ、kubectl top nodes でノード数が増加するか確認。

• アラート発火確認
  Azure Monitor のテストアラートを手動でトリガーし、設定した通知先（メール・Teams）に届くか検証。

結論：パターンごとの注意点を踏まえてマニフェストや Helm Chart を整備し、上記チェックリストで本番環境相当の検証を行えば、スムーズな AKS への移行が実現できます。

まとめ

AKS はフルマネージド Kubernetes として、自動スケーリング・統合 GitOps・マネージド Azure Monitor の 3 本柱が揃うことで、運用負荷とコストを同時に最適化できるプラットフォームです。ポータルでも CLI でも同様の設定が可能であり、選択肢はチームのスキルセットや自動化要件に合わせて柔軟に決められます。また、他 Azure コンテナサービスとの比較表と移行チェックリストを活用すれば、規模・要件に応じた最適なサービス選定と安全な本番導入が実現します。

次のアクション例
1. 公式 Azure Updates を確認し、2025 年リリース予定機能の最新ステータスを取得する。
2. 小規模テストクラスターで自動スケーリングと GitOps の組み合わせを試験し、運用フローを確立する。
3. 本番環境ではネットワーク分離・最小権限 RBAC・マネージド監視を標準構成としてテンプレート化し、IaC（Infrastructure as Code）で管理する。

これらを実践すれば、AKS の持つ高度な拡張性と Azure エコシステムの統合メリットを最大限に活かしたクラウドネイティブ運用が可能になります。