【Microsoft Azure】Azure Kubernetes Serviceの新しい利用開始方法、AKS Automaticのご紹介
目次
こんにちは、MS開発部の渋谷です。
みなさんはコンテナアプリケーションを運用する際、どのような基盤を使っていますか？
Azureのサービスだと、Container AppsやApp Service for Containersを使うことが多いと思います。
一方で、マネージドサービスがあるがゆえに、細かい制御ができなかったり、
大規模なユースケースでは利用しにくく、AzureのKubernetes基盤（AKS）を使うこともあるでしょう。
その場合、Kubernetes自体の構築や設定項目の多さに苦労することもあると思います。
そのような中で新たな選択肢として、AKS Automaticが出てきました。
今回はこのAKS Automaticについて紹介します。
AKS Automatic とは
Azure Kubernetes Service (AKS) Automaticは、Kubernetesをより速く、より摩擦なく、そして専門知識が深くないユーザーにも利用可能にすることを目指した、新しいマネージドKubernetesエクスペリエンスです。AKS Automaticによって、開発者はインフラ管理ではなく、アプリケーション開発そのものに集中できる環境を得られます。
AKS Automaticは、以下の3つの基本理念に基づいて構築されています。
- デフォルトで本番環境対応 (Production-Ready by Default): ベストプラクティスに基づき事前設定されたクラスターが提供され、即座に本番ワークロードを稼働させることが可能です。
- 組み込みのベストプラクティスと保護機能 (Built-in Best Practices and Safeguards): セキュリティと信頼性が初期段階から組み込まれており、設定ミスによるリスクを軽減します。
- 数分でコードからKubernetesへ (Code to Kubernetes in Minutes): コンテナイメージの作成からアプリケーションのデプロイまで、開発ライフサイクル全体を加速させるために、エクスペリエンスが合理化されています。
初期のマネージドKubernetesはコントロールプレーンの管理を担いましたが、データプレーンや運用設定の多くは依然としてユーザーの手に委ねられていました。AKS AutomaticはKubernetesへのハードルを低くし、Kubernetesを民主化し、これまで専門的な運用能力を持たなかった小規模チームや企業でも活用できる選択肢ができました。これにより、価値の提案は「Kubernetesを管理すること」から「Kubernetesを使ってビジネス価値を提供すること」へとシフトしています。
実際にAzure Portal上でAKS Automaticを利用する方法は非常に簡単です。通常のKubernetesクラスターではなく「自動」と書かれたオプションを選択するだけです。
その後出てくるウィザードで必要事項を入力するだけでデプロイが完了します。特に、モニターやロギング関係の構成を最初から利用できる点が特徴です。
AKS Automatic vs. Standardモード：どちらを選ぶべきか？
AKSを導入する際に最も重要な選択の一つが、Automaticモードと従来のStandardモードのどちらを利用するかです。もちろん、銀の弾丸はないのでどちらのモードにもメリットとデメリットがあります。そのため、両者の特徴や想定されるユースケースを知ることは重要です。
AKS Automaticは、Azureがベストプラクティスに基づいてほとんどの意思決定を行う、完全に管理されたエクスペリエンスを提供します。一方、AKS Standardは、クラスター構成、ノードプール、スケーリングメカニズムに至るまで、ユーザーに完全な制御権を与えます。
この違いを理解するために、主要な機能を比較してみましょう。
| 機能カテゴリ | 項目 | AKS Automatic (事前構成/デフォルト) | AKS Standard (デフォルト/オプション) |
| ノード管理とスケーリング | ノード管理 | Node Autoprovisioning (NAP) による動的な完全マネージド。手動でのノードプール作成は不要。 | ユーザーがシステムおよびユーザーノードプールを手動で作成・管理。 |
| ノードスケーリング | Node Autoprovisioning (Karpenterベース) がワークロード要件に基づき自動でノードを作成・削除。 | デフォルトは手動スケーリング。オプションでCluster AutoscalerやNAPを利用可能。 | |
| Podスケーリング | HPA, VPA, KEDAがデフォルトで有効化済み。 | デフォルトは手動。HPA, VPA, KEDAはオプションで手動設定が必要。 | |
| クラスター運用 | クラスター層とSLA | Standard Tierクラスター (最大5,000ノード) とアップタイムSLAが事前構成済み。 | デフォルトはFree Tier (SLAなし)。Standard/Premium Tierへのアップグレードはオプション。 |
| ノードOS | Azure Linux。 | デフォルトはUbuntu。Azure LinuxやWindows Serverはオプション。 | |
| アップグレード | クラスター全体が自動的にアップグレードされる。 | デフォルトは手動アップグレード。自動アップグレードチャネルはオプション。 | |
| セキュリティ | 認証・認可 | Kubernetes向けAzure RBACが事前構成済み。 | デフォルトはローカルアカウント。Azure RBACはオプション。 |
| ノードリソースグループ | 完全に管理され、偶発的な変更を防ぐためにロックダウンされている。 | デフォルトは制限なし。ロックダウンはプレビュー機能としてオプションで提供。 | |
| ネットワーク | CNI (ネットワークプラグイン) | Azure CNI Overlay with Ciliumがデフォルト。高性能なネットワークとセキュリティを提供。 | Azure CNIを基本利用。Overlayはオプションで利用可能。 |
| Ingress | マネージドNGINX (App Routingアドオン) が事前構成済み。Azure DNS/Key Vaultと統合。 | オプションでApp Routingアドオンなどを手動で設定。 | |
| Egress | マネージドNAT Gatewayが事前構成済み。 | デフォルトはAzure Load Balancer。NAT Gatewayなどはオプション。 |
この選択は、チームの役割を反映します。Standardモードは、高度にカスタマイズされた要件を持つチームや、独自のツールと自動化に多大な投資を行ってきた「プラットフォーム構築者」のためのものです。
一方で、Automaticモードは、シンプルさとスピードを優先し、インフラの専門家になることなく本番環境への「舗装された道」を求めるアプリケーション開発チームに最適です。
大規模な企業では、この両方を戦略的に活用するハイブリッドアプローチが考えられます。中央のプラットフォームエンジニアリングチームがStandardモードを使用して基盤となる共有サービスを構築・管理し、一方で社内のアプリケーションチームには、ガバナンスの効いたセルフサービス製品としてAutomaticモードのクラスターを提供することも考えられるでしょう。
Kubernetesのノードをプロビジョニングについて
AKS Automaticのスケーリング機能の裏には、Node Autoprovisioning (NAP)と呼ばれるものが存在します。これは、オープンソースプロジェクトのKarpenterを活用しています。NAPは、保留中のPodのリソース要件（CPU、メモリなど）を監視し、ワークロードに最適なVM構成を最もコスト効率の高い方法で自動的にプロビジョニングするAKSの機能です。
従来のCluster Autoscaler (CAS) との比較は次のとおりです。
| 項目 | Karpenter (NAPのエンジン) | Cluster Autoscaler (CAS) |
| スケーリングメカニズム | Pod中心。保留中のPodの要件に完全に一致するノードをオンデマンドで直接プロビジョニング 。 | ノードグループ中心。事前定義されたノードグループ（VMSS）全体をスケールアップ/ダウン 。 |
| 速度 | クラウドAPIと直接連携するため、数分ではなく数秒でノードをプロビジョニング可能。非常に高速。 | ノードグループの抽象化を介して動作するため、プロビジョニングに遅延が生じる傾向がある。 |
| リソース効率 | ワークロードを最もコスト効率の良いインスタンスに高密度で配置（ビンパッキング）し、無駄を最小化。 | ノードグループ内のインスタンスタイプが固定されているため、リソースの断片化や過剰プロビジョニングが発生しやすい。 |
| 柔軟性 | CPU/メモリ比、アーキテクチャ、スポット/オンデマンドなど、幅広いインスタンスタイプから動的に選択可能 。 | ノードグループに設定された単一のインスタンスタイプに制約される。 |
| 運用複雑性 | ノードグループの管理が不要なため、運用が大幅に簡素化される。 | 多様なワークロードに対応するために、多数のノードグループを手動で作成・管理する必要があり、複雑化しやすい。 |
従来のCASモデルはインフラ中心であり、「この既存のノードグループに、この保留中のPodをどこに配置できるか？」という探索を行いました。一方、Karpenterモデルはアプリケーション中心であり、「この保留中のPodはXXCPU、YYメモリ、GPUを必要としている。この要件を満たす最も安価で、最も迅速にプロビジョニングできるVMは何か？」という探索を行います。これによって、複雑なキャパシティプランニングや手動でのノードプール管理をすることなく、開発者は単にアプリケーションの要求を宣言するだけで、システムが残りのすべてを解決します。
その他ビルドインされている機能
インテリジェントなオートスケーリング
ノードスケーリングを担うKarpenterに加え、ワークロードレベルでの包括的なスケーリングを実現するために、以下のオートスケーラーがデフォルトで有効化されています。
- Horizontal Pod Autoscaler (HPA): CPUやメモリ使用率などのメトリクスに基づいてPodのレプリカ数を自動的に増減させます。
- Vertical Pod Autoscaler (VPA): 過去の使用状況に基づいて、コンテナのリソース要求（request）と制限（limit）を自動的に調整し、リソースの適切なサイジングを支援します。
- Kubernetes Event-driven Autoscaling (KEDA): メッセージキューの長さやストリームのラグなど、外部イベントに応じてPodを0からNまでスケーリングします。
最適化されたネットワーキング
高性能なネットワーキングとセキュリティポリシーの適用を実現するため、以下のコンポーネントがデフォルトで構成されます。
- Azure CNI Overlay with Cilium: 高性能なデータプレーンを提供し、Pod間の通信を効率化します。
- マネージドNGINX Ingress: Application Routingアドオンとして提供され、Azure DNSやAzure Key Vaultとシームレスに統合され、アプリケーションへの外部アクセスを簡素化します。
- マネージドNAT Gateway: クラスターからの外部への通信（Egress）のために、スケーラブルで信頼性の高いアウトバウンド接続を提供します。
強化されたセキュリティ
クラスター作成時から堅牢なセキュリティ体制が適用されます。
- Microsoft Entra ID統合: Kubernetesのロールベースアクセス制御（RBAC）と統合され、セキュアな認証・認可基盤を提供します。
- Azure Linuxと自動パッチ適用: ノードはセキュリティが強化されたAzure Linux OS上で実行され、パッチは自動的に適用されます。SSHアクセスはデフォルトで無効化されています。
- Deployment Safeguards: Azure Policyを利用して、特権コンテナの禁止など、一般的な設定ミスやセキュリティリスクを未然に防ぎます。
統合された可観測性
Day2オペレーションの大きな課題である監視は、以下のマネージドサービスによって初期設定時からカバーされています。
- Azure Managed Prometheus: メトリクス収集の標準であるPrometheusをマネージドサービスとして提供します。
- Container Insights: Podやノードからログを収集し、分析のためのプラットフォームを提供します。
- Azure Managed Grafana: 事前構築済みのダッシュボードと共に提供され、収集したメトリクスやログを視覚化し、クラスターの状態を即座に把握できます。
制限事項について
AKS Automaticは多くのメリットを提供しますが、その規範的なアプローチにはトレードオフも存在します。
制御の喪失
最も大きなトレードオフは、シンプルさと引き換えに詳細な制御を失う点です。事前構成された機能（CNIプラグイン、監視スタックなど）は無効化したり変更したりすることはできません。これは、非常に特殊な要件を持つワークロードや、既存の標準ツールとの厳密な統合が求められる場合には適合しない可能性があります。
サポートされていない機能
現時点では、以下の主要な機能はサポートされていません。
- Windowsノードプール
- IPv6クラスター
- クラスターの停止機能
自動アップグレードのリスク管理
クラスターの自動アップグレードはセキュリティと機能性を最新に保つ上で有益ですが、適切に管理しないとリスクにもなり得ます。特定のワークロードでは、意図しないアップグレードが本番環境の動作に影響を与える可能性があります。
このリスクを軽減するためには、以下の戦略が不可欠です。
- 計画的メンテナンス期間 (Planned Maintenance): アップグレードが実行される時間帯を指定することで、ビジネスへの影響が最も少ない時間帯にアップグレードをスケジュールできます。
- Pod Disruption Budgets (PDBs): アプリケーションの可用性を維持するために、アップグレード中に同時に停止できるPodの最小数または最大数を定義します。これにより、安全なローリングアップデートが保証されます。
まとめ
今回はAKSの新しいデプロイオプションであるAKS Automaticをご紹介しました。Kubernetesの運用からアプリケーション開発へよりフォーカスできるようにインフラ部分が抽象化されていますが、最終的に、どちらのモードを選択すべきかは、組織の優先順位と要件によって決まります。
- AKS Automaticを選択すべき場合:
- 開発速度と運用のシンプルさを最優先する。
- 新しいクラウドネイティブプロジェクトを開始する。
- トラフィックが突発的、またはAI/MLのような計算集約型のワークロードを実行する。
- 開発者向けに標準化されたセルフサービスプラットフォームを提供したい。
- AKS Standardを選択すべき場合:
- ネットワーク、セキュリティ、アドオンなど、クラスターのあらゆるコンポーネントに対する詳細な制御が必要。
- Windowsコンテナを実行する必要がある。
- 既存の運用ツールがAutomaticモードのデフォルト設定と互換性がない。
AKS Automaticは、Standardモードの代替品ではなく、Kubernetesをより多くの人々にとってアクセスしやすく、効率的なものにするための強力な新しい選択肢です。
以上、最後までご愛読いただき
ありがとうございました。
お問い合わせは、
以下のフォームへご連絡ください。
関連記事
渋谷
この著者の保持資格
渋谷