Azure Kubernetes Service (AKS)

解決する課題

• コンテナを 本番で Kubernetes として運用したいが、API サーバーや etcd の構築・保守はしたくない
• Helm・Operator・CRD など Kubernetes エコシステムや K8s API そのものが必要
• オンプレや他クラウドの Kubernetes 資産を 移植性を保ったまま動かしたい
• 負荷に応じて Pod とノードの両方を自動でスケールさせたい
• クラスターの認証・認可を Entra ID と Azure RBACで一元管理したい
• ここまでの制御が不要で運用を最小化したいだけなら、AKS ではなく Container Apps が候補になる

主要概念と用語

• コントロールプレーン: API サーバー・スケジューラ・etcd などの管理面。Microsoft が運用し、利用者は直接保守しない
• ノードプール: 同一構成のワーカーノード（VM）の集合。OS・VM サイズ・スケール設定をプール単位で管理し、システム用とユーザー用を分けられる
• ノード / Pod: ノードは実際にコンテナを動かす VM、Pod はコンテナの最小デプロイ単位
• Cluster Autoscaler: 保留中の Pod に応じてノード数を増減させる仕組み
• Horizontal Pod Autoscaler（HPA）: CPU やメモリなどのメトリクスに応じて Pod レプリカ数を増減させる仕組み
• KEDA: キュー長やトピックなどイベント駆動で Pod をスケールさせるアドオン
• CNI（コンテナーネットワーク）: Pod の IP 割り当て方式。仮想ネットワーク統合型（Azure CNI）とオーバーレイ型などを選べる
• マネージド ID / ワークロード ID: クラスターや Pod が資格情報なしで他の Azure リソースへアクセスするための ID
• アドオン / 拡張機能: 監視・イングレス・シークレット連携などを Azure 管理で追加する仕組み

仕様・制限・クォータ

• コントロールプレーンは Microsoft が管理し、課金はワーカーノード（VM）・ディスク・ロードバランサーなどに対して発生する
• 可用性レベルとして、SLA を伴う有償の階層と無償の階層が選べ、本番では SLA 付きを推奨
• 複数ノードプールを持て、システム用とユーザー用、CPU 用と GPU 用、通常ノードとスポットノードなどを混在できる
• ノードは 可用性ゾーンに分散配置でき、ゾーン障害への耐性を高められる
• Kubernetes のバージョンにはサポート期間があり、定期的なアップグレードが前提。バージョンやノード数・コア数にはサブスクリプション/リージョン単位のクォータがあり、引き上げ申請が可能
• 具体的なバージョン番号・ノード上限・クォータ値は変動するため、最新値は公式ドキュメントで確認する

内部の仕組み

AKS では コントロールプレーン（API サーバー・etcd・スケジューラ・コントローラ）を Microsoft が運用し、利用者は ワーカーノード（VM）のノードプールを保有します。Pod のスケジューリング・ノードのスケール・Kubernetes バージョンのアップグレードを利用者が制御でき、CRD・Operator・Helm を含む Kubernetes の全機能を使えます。

スケールは二段で考えます。HPA がメトリクスに応じて Pod レプリカ数を増減させ、Pod がノードに乗り切らなくなると Cluster Autoscaler がノードを追加します。イベント駆動でゼロ付近まで縮めたい場合は KEDA を併用します。ネットワークは選んだ CNI に従って Pod へ IP を割り当て、サービス公開はクラスター内のロードバランサーやイングレスコントローラ経由で行います。

認証は Entra ID と連携し、認可は Kubernetes RBAC または Azure RBAC for Kubernetes で制御します。クラスターや Pod から他の Azure リソースへは、マネージド ID / ワークロード ID を使い資格情報を持たずにアクセスします。これは AWS でいう EKS の IRSA（Pod へ IAM ロールを割り当てる仕組み）に対応する考え方です。

設計パターン / ベストプラクティス

• システムノードプールとユーザーノードプールを分離し、システムコンポーネントとアプリのワークロードを混在させない
• ノードは 可用性ゾーンに分散し、Pod は配置制約やレプリカ数でゾーン障害に耐えられるようにする
• バッチや耐障害性のあるワークロードは スポットノードプールでコストを下げ、重要なワークロードは通常ノードに置く
• 状態はクラスター外（Azure Database / Cosmos DB / Blob / Cache for Redis）へ逃がし、Pod をステートレスに保つ
• イメージは Azure Container Registry（ACR） に置き、マネージド ID でパスワードレスにプル認証する
• デプロイは Helm やマニフェストの GitOps で宣言的に管理し、アップグレードはサージ設定で段階的に行う

運用・監視

• Container Insights（Azure Monitor） でノード/Pod のメトリクスとログを集約し、kubectl で個別調査する
• クラスターとアプリのアップグレードは コントロールプレーンとノードプールを分けて実施し、サージで無停止を狙う
• Pod が起動しない → イメージ取得権限（ACR とマネージド ID）、リソース要求量、ノードの空き容量、ノードプールの状態を確認
• 外部からアクセスできない → サービス種別とイングレス、ターゲットポート、ネットワークポリシー、ロードバランサーの構成を確認
• ノードが増えない/減らない → Cluster Autoscaler の上下限と、Pod のリソース要求・配置制約を確認

コスト

ノードを動かしている限り課金が続くため、Cluster Autoscaler の下限を適切に設定し、夜間や閑散期に縮められる構成にするとコスト効率が上がります。

セキュリティ

• 認証は Entra ID、認可は Azure RBAC for Kubernetes または Kubernetes RBAC で最小権限を設計する
• クラスター/Pod には マネージド ID / ワークロード ID を付与し、ACR・Key Vault・他リソースへ資格情報なしでアクセスする（AWS の IRSA 相当）
• シークレットは Key Vault から注入し、イメージや環境変数への平文埋め込みを避ける
• ネットワークポリシーで Pod 間通信を制限し、必要なら API サーバーをプライベート化してインターネット露出を抑える
• イメージは ACR で脆弱性スキャンし、Microsoft Defender for Containers でランタイムの脅威を検知する
• ノードと Kubernetes は定期的にパッチ/アップグレードを当て、既知の脆弱性を放置しない

Well-Architected の観点

• 信頼性: 可用性ゾーンへのノード分散、複数ノードプール、Cluster Autoscaler と HPA、SLA 付きコントロールプレーンで可用性を高める
• 運用性: GitOps による宣言的デプロイ、サージアップグレード、Container Insights による可観測性で運用を標準化する
• パフォーマンス効率: HPA/KEDA で負荷に追従し、GPU や適切な VM サイズのノードプールでワークロード特性に合わせる
• セキュリティ: Entra ID 連携・Azure RBAC・ネットワークポリシー・ワークロード ID で最小権限と分離を担保する
• コスト最適化: スポットノード・予約割引・オートスケールの下限調整でノード課金を抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソースグループを準備
az group create --name demo-rg --location japaneast

# AKS クラスターを作成（2 ノード・マネージド ID・監視アドオン有効）
az aks create \
  --resource-group demo-rg \
  --name demo-aks \
  --node-count 2 \
  --enable-managed-identity \
  --enable-addons monitoring \
  --generate-ssh-keys

# kubectl 用の資格情報を取得
az aks get-credentials --resource-group demo-rg --name demo-aks

# クラスターとノードの状態を確認
kubectl get nodes

# ユーザーノードプールを追加（スポット VM を例に）
az aks nodepool add \
  --resource-group demo-rg \
  --cluster-name demo-aks \
  --name spotpool \
  --priority Spot \
  --node-count 2

# Cluster Autoscaler を有効化（1〜5 ノードで自動増減）
az aks nodepool update \
  --resource-group demo-rg \
  --cluster-name demo-aks \
  --name nodepool1 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

# Kubernetes バージョンの選択肢を確認してアップグレード
az aks get-upgrades --resource-group demo-rg --name demo-aks -o table
az aks upgrade --resource-group demo-rg --name demo-aks --kubernetes-version <VERSION>