Azure Kubernetes Service
権威あるガイダンス — 必須遵守
このスキルは、ユーザーの要件に基づいて 推奨される AKS クラスター構成 を生成し、Day-0 決定 (ネットワーキング、API サーバー — 後からの変更が困難) と Day-1 機能 (作成後に有効化可能) を区別します。コマンドについては CLI リファレンス を参照してください。
クイックリファレンス
| プロパティ | 値 |
|---|---|
| 最適な用途 | AKS クラスター計画と Day-0 決定 |
| MCP ツール | mcp_azure_mcp_aks |
| CLI | az aks create, az aks show, kubectl get, kubectl describe |
| 関連スキル | azure-diagnostics (AKS トラブルシューティング), azure-validate (準備確認) |
このスキルを使用するタイミング
以下の場合にこのスキルを有効化します:
- 新しい AKS クラスターを作成したい場合
- 本番環境ワークロード向けに AKS クラスター構成を計画したい場合
- AKS ネットワーキング (API サーバーアクセス、Pod IP モデル、エグレス) を設計したい場合
- AKS の ID とシークレット管理を設定したい場合
- AKS ガバナンス (Azure Policy、Deployment Safeguards) を構成したい場合
- AKS 可観測性 (Container Insights、Managed Prometheus、Grafana) を有効化したい場合
- AKS のアップグレードおよびパッチ適用戦略を定義したい場合
- AKS のコスト可視性と分析を有効化したい場合
- AKS Automatic と Standard SKU の違いを理解したい場合
- AKS クラスターのセットアップと構成のための Day-0 チェックリストを入手したい場合
ルール
- コンピューティング、ネットワーキング、セキュリティ、その他の設定に関するユーザーの要件から開始します。
azureMCP サーバーを使用し、最初にmcp_azure_mcp_aksを選択して、クライアントによって公開されている AKS 固有の MCP ツールを特定します。タスクに最適な最小の AKS ツールを選択し、必要な機能が AKS MCP サーフェスを通じて公開されていない場合にのみ、Azure CLI (az aks) にフォールバックします。- ユーザーの制御と利便性のニーズに基づいて、AKS Automatic と Standard SKU のどちらがより適切かを判断します。特定のカスタマイズが必要でない限り、デフォルトで AKS Automatic を選択します。
- 特に後から変更が困難な Day-0 決定 (ネットワーキング、API サーバーアクセス) については、クラスター構成の選択に関する決定と根拠を文書化します。
必須入力 (必要なものだけを質問)
ユーザーが不明確な場合は、安全なデフォルト値を使用します。
- AKS 環境タイプ: 開発/テスト または 本番
- リージョン、可用性ゾーン、優先ノード VM サイズ
- 想定されるスケール (ノード/クラスター数、ワークロードサイズ)
- ネットワーキング要件 (API サーバーアクセス、Pod IP モデル、イングレス/エグレス制御)
- セキュリティと ID 要件 (イメージレジストリを含む)
- アップグレードと可観測性の設定
- コスト制約
ワークフロー
1. クラスタータイプ
- AKS Automatic (デフォルト): ほとんどの本番環境ワークロードに最適。セキュリティ、信頼性、パフォーマンスに関する事前設定済みのベストプラクティスを備えた厳選されたエクスペリエンスを提供します。Node Auto-Provisioning (NAP) でサポートされていないネットワーキング、オートスケーリング、またはノードプール構成に関する特定のカスタム要件がない限り、これを使用します。
- AKS Standard: 環境構成を完全に制御する必要がある場合に使用します。セットアップと管理には追加のオーバーヘッドが必要です。
2. ネットワーキング (Pod IP、エグレス、イングレス、データプレーン)
Pod IP モデル (主要な Day-0 決定):
- Azure CNI Overlay (推奨): Pod IP はプライベートオーバーレイ範囲から割り当てられ、VNet ルーティング不可。大規模環境にスケーラブルで、ほとんどのワークロードに適しています。
- Azure CNI (VNet ルーティング可能): Pod IP は VNet から直接割り当てられます (Pod サブネットまたはノードサブネット)。Pod が VNet またはオンプレミスから直接アドレス指定可能である必要がある場合に使用します。
データプレーンとネットワークポリシー:
- Azure CNI powered by Cilium (推奨): eBPF ベースで、高性能なパケット処理、ネットワークポリシー、可観測性を実現します。
エグレス:
- 静的エグレス Gateway: 安定した予測可能な送信元 IP を提供します。
- 制限されたエグレス: UDR + Azure Firewall または NVA
イングレス:
- App Routing アドオンと Gateway API — HTTP/HTTPS ワークロードの推奨デフォルト。
- Istio サービスメッシュと Gateway API — 高度なトラフィック管理、mTLS、カナリアリリース向け。
- Application Gateway for Containers — WAF 統合用の L7 ロードバランシング。
DNS:
- すべてのノードプールで LocalDNS を有効にし、信頼性が高く高性能な DNS 解決を実現します。
3. セキュリティ
- Microsoft Entra ID をすべての場所で使用します (コントロールプレーン、Pod 用 Workload Identity、ノードアクセス)。静的資格情報は避けてください。
- シークレットには、Secrets Store CSI Driver 経由で Azure Key Vault を使用します。
- Azure Policy + Deployment Safeguards を有効にします。
- etcd/API サーバーの 保存時の暗号化、ノード間の 転送中の暗号化 を有効にします。
- 署名済みでポリシー承認済みのイメージのみを許可します (Azure Policy + Ratify)。Azure Container Registry を推奨します。
- 分離: 名前空間、ネットワークポリシー、スコープ付きログ記録を使用します。
4. 可観測性
- AKS の可観測性 (ログ + メトリクス) には、Managed Prometheus と Container Insights を Grafana と共に使用します。
- セキュリティ監視とトラブルシューティングのために、診断設定を有効にして、コントロールプレーンログと監査ログを Log Analytics ワークスペースに収集します。
- その他の監視およびトラブルシューティングツールについては、Agentic CLI for AKS、Application Insights、Resource Health Center、AppLens detectors、Azure Advisors などの機能を使用します。
5. アップグレードとパッチ適用
- 制御されたアップグレードタイミングのために メンテナンスウィンドウ を構成します。
- コントロールプレーンとノード OS の 自動アップグレード を有効にして、セキュリティパッチと Kubernetes バージョンを最新の状態に保ちます。
- エンタープライズ安定性 (2 年間サポート) のために LTS バージョン を検討し、AKS 環境を Premium ティアにアップグレードします。
- Fleet アップグレード: AKS Fleet Manager を使用して、テスト環境から本番環境への段階的なロールアウトを実施します。
6. パフォーマンス
- ノードの起動を高速化するために エフェメラル OS ディスク (
--node-osdisk-type Ephemeral) を使用します。 - ノード OS として Azure Linux を選択します (フットプリントが小さく、起動が高速)。
- HPA を超えたイベント駆動型オートスケーリングのために KEDA を有効にします。
7. ノードプールとコンピューティング
- 専用システムノードプール: 少なくとも 2 ノードで、システムワークロードのみに汚染を設定します (
CriticalAddonsOnly)。 - コスト削減と応答性の高いスケーリングのために、すべてのプールで Node Auto Provisioning (NAP) を有効にします。
- ホストレベルの最適化のために 最新世代の SKU (v5/v6) を使用します。
- B シリーズ VM は避けてください — バースト可能 SKU はパフォーマンスと信頼性の問題を引き起こします。
- 本番環境ワークロードには、少なくとも 4 vCPU の SKU を使用します。
- SLO に従ってホスト/ゾーン全体に Pod を分散するために トポロジー分散制約 を設定します。
8. 信頼性
- 3 つの可用性ゾーン にデプロイします (
--zones 1 2 3)。 - ゾーン冗長コントロールプレーンと API サーバー可用性の 99.95% SLA のために Standard ティア を使用します。
- ランタイム保護のために Microsoft Defender for Containers を有効にします。
- すべての本番環境ワークロードに対して PodDisruptionBudgets を構成します。
- 障害ドメイン全体に Pod が分散されるように トポロジー分散制約 を使用します。
9. コスト管理
- バッチ/中断可能ワークロードには スポットノードプール を使用します (最大 90% のコスト削減)。
- 開発/テストクラスターの 停止/開始:
az aks stop/start - 定常状態のワークロードには 予約インスタンス または Savings Plans を検討します。
ガードレール / 安全性
- シークレット (トークン、キー) を要求したり出力したりしないでください。
- Day-0 の重要な決定について要件が不明確な場合は、ユーザーに明確化の質問をしてください。Day-1 で有効化可能な機能については、トレードオフを含む 2～3 の安全なオプションを提案し、保守的なデフォルトを選択します。
- ダウンタイムゼロを約束しないでください。信頼性とパフォーマンスのベストプラクティスとともに、ワークロード保護機能 (PDB、プローブ、レプリカ) と段階的なアップグレードをアドバイスします。
MCP ツール
| ツール | 目的 | 主要パラメータ |
|---|---|---|
mcp_azure_mcp_aks | AKS MCP エントリポイント。クライアントによって公開されている AKS 固有のツールを特定するために使用します。 | 最初に呼び出し可能な AKS ツールを特定し、そのツールのパラメータを使用します。 |
エラー処理
| エラー / 症状 | 考えられる原因 | 修正方法 |
|---|---|---|
| MCP ツール呼び出しが失敗、またはタイムアウト | 無効な資格情報、サブスクリプション、または AKS コンテキスト | az login を確認し、az account show でアクティブなサブスクリプションコンテキストを確認し、ターゲットリソースグループを確認します (サブスクリプション ID をユーザーにエコーバックしないでください)。 |
| クォータ超過 | リージョンの vCPU またはリソース制限 | クォータ増加を要求するか、別のリージョン/VM SKU を選択します。 |
| ネットワーキング競合 (IP 枯渇) | オーバーレイ/CNI に対して Pod サブネットが小さすぎる | IP 範囲を再計画します。クラスターの再作成が必要になる場合があります (Day-0)。 |
| Workload Identity が機能しない | OIDC 発行者またはフェデレーション資格情報がない | --enable-oidc-issuer --enable-workload-identity を有効にし、フェデレーション ID を構成します。 |