Azure Kubernetes Service（AKS）入門｜コンテナオーケストレーションをAzureで始めるための実践ガイド

オンプレでDockerやKubernetesを自前で運用している方なら、コントロールプレーンの管理コストの重さはよくわかるはずだ。etcdのバックアップ、API Serverのバージョン管理、証明書ローテーション……こういった作業が本来の開発・運用業務を圧迫していることも少なくない。

Azure Kubernetes Service（AKS）は、Kubernetesのコントロールプレーンをマネージドで提供するサービスだ。ワーカーノードの管理は引き続き自分で行うが、Kubernetesの最も難しい部分をAzureに任せることで、本来注力すべきアプリケーション運用に集中できる。

この記事では、AKSの仕組みと基本的なアーキテクチャ、Azure CLIでのクラスター作成手順、料金の考え方、そして現場で使える実務Tipsまでを体系的に解説する。

なぜAKSなのか？オンプレKubernetesとの決定的な違い

オンプレミスやプライベートクラウド上でKubernetesを動かしたことがある方は、「コントロールプレーンの管理が一番つらい」という経験があるはずだ。マスターノード3台の冗長構成を維持しながら、etcdのスナップショット・APIサーバーの証明書更新・バージョンアップを計画的に回すのは、それだけで専任担当が必要なレベルの作業量になる。

AKSでは、KubernetesのコントロールプレーンをAzureが無料で管理する。ユーザーが意識するのはワーカーノード（実際のPodが動くVM）だけだ。

オンプレでKubernetesを動かすのは「自転車を自分で組み立てて走る」ようなものだ。AKSは「整備済みの自転車を借りて、コースを走ることだけに集中できる」状態に近い。

AKSの基本アーキテクチャを理解する

AKSを正しく設計するには、「コントロールプレーン」と「データプレーン（ノードプール）」の2層構造を頭に入れておく必要がある。

コントロールプレーン（Azureが管理・ユーザーはアクセス不可）：
・API Server: kubectlやCI/CDからのリクエストを受け付けるKubernetesの中心
・etcd: クラスターの状態を保持するキーバリューストア
・Scheduler: Podをどのノードに配置するかを決定するコンポーネント
・Controller Manager: DeploymentやReplicaSetの整合性を維持するコントローラー群

データプレーン（ユーザーが管理・コストが発生）：
・システムノードプール: CoreDNSやkube-proxyなどのシステムコンポーネントが動く。最低1つ必要
・ユーザーノードプール: アプリケーションのPodが動く。用途別に複数作成可能

現場でよくある設計パターンは「システムプール（Standard_D2s_v3 × 2台）＋汎用ユーザープール（Standard_D4s_v3 × 3台）＋GPUプール（NCas_T4_v3 × 必要時のみ）」のような3層分離だ。ノードプールを分離することで、Podの配置をtaint/tolerationで制御しやすくなり、アプリがシステムコンポーネントのリソースを食い荒らすリスクを防げる。

AKSクラスターの作成手順（Azure CLIで始める）

実際にAKSクラスターを作成する手順をAzure CLIで解説する。ポータルから操作することもできるが、インフラエンジニアならCLIの方が再現性が高くて扱いやすい。

1. リソースグループとACRの準備

まずリソースグループとAzure Container Registry（ACR）を作成する。リージョンは東日本リージョン（japaneast）を例にする。

# Azure CLI でログインしてサブスクリプションを確認
az login
az account show --query "name" -o tsv

# リソースグループを作成
az group create \
  --name rg-aks-demo \
  --location japaneast

# Azure Container Registry（ACR）を作成
# ACR名はグローバルで一意な英数字のみ（小文字推奨）
az acr create \
  --resource-group rg-aks-demo \
  --name acraksdemoprod \
  --sku Standard \
  --location japaneast

ACRのSKUはBasic（小規模検証用）、Standard（本番向け・Webhookやgeo-replication可）、Premium（Geo-replication・Private Link対応）から選択できる。本番では最低Standardを選ぶのが鉄則だ。

2. AKSクラスターの作成

AKSクラスターを作成する。`–enable-managed-identity` をつけることで、サービスプリンシパルではなくManaged Identityを使った安全な認証設定になる。`–attach-acr` オプションで、作成したACRへのPull権限（AcrPull role）をクラスターに自動付与できる。

# AKSクラスターの作成（完了まで5～10分かかる）
az aks create \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --node-count 2 \
  --node-vm-size Standard_D2s_v3 \
  --enable-managed-identity \
  --attach-acr acraksdemoprod \
  --kubernetes-version 1.31.2 \
  --zones 1 2 3 \
  --location japaneast \
  --generate-ssh-keys

`–zones 1 2 3` を指定することでノードをアベイラビリティゾーン（AZ）に分散配置し、単一AZの障害時でもクラスターが継続稼働する構成になる。本番環境では必須の設定だ。

3. kubectlでクラスターにアクセスする

クラスター作成後、kubectlの認証情報（kubeconfig）を取得してアクセスする。

# kubeconfigを取得（~/.kube/config にマージされる）
az aks get-credentials \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster

# ノードの確認
kubectl get nodes -o wide

# 出力例:
# NAME                                STATUS   ROLES    AGE   VERSION
# aks-nodepool1-12345678-vmss000000   Ready       5m    v1.31.2
# aks-nodepool1-12345678-vmss000001   Ready       5m    v1.31.2

`az aks get-credentials` を実行すると、ローカルの `~/.kube/config` にAKSクラスターのcontextが追加される。複数のクラスターを管理する場合は `kubectl config get-contexts` でcontextの一覧を確認してから作業することを習慣にしてほしい。

料金の仕組みとコスト感覚

AKSの料金を正しく理解しておかないと、月末の請求書を見て驚くことになる。大前提として、コントロールプレーンはFreeティアであれば無料だ。ただしSLAが保証されるStandardティアは月額約$0.10/クラスター時間かかる（2026年5月時点）。

実際に主要な料金が発生するのはワーカーノードのVMだ。

コスト削減の3つのポイント：
・開発環境はFreeティアで運用し、Standardティアは本番のみ： 本番のSLA保証にはStandardが必要だが、開発・検証はFreeで十分
・夜間・週末は開発クラスターのノード数を0に： ノードプールのmin-count=0に設定してスケールダウンすることで平日夜間・休日のVM費用を削減できる
・Spot Node Poolの活用： バッチ処理や開発用途のPodはSpot VMのノードプールに乗せることで最大80%のVM料金削減が可能

応用・実務Tips

【重要】サービスプリンシパルではなくManaged Identityを使う

古いAKSドキュメントにはサービスプリンシパル（クライアントID＋シークレット）での認証設定が載っているが、現在のベストプラクティスはManaged Identityだ。サービスプリンシパルのシークレットには有効期限があり、更新を忘れると本番クラスターがACRからイメージをPullできなくなる。Managed Identityはシークレット自体が存在しないため、この種の障害が根本的に発生しなくなる。

# Managed Identityが有効か確認する
az aks show \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --query "identity.type" -o tsv

# "SystemAssigned" と表示されていればManaged Identity有効

Cluster Autoscalerで水平スケーリングを自動化する

ノードの数を手動で増減するのではなく、Cluster Autoscalerを有効にしておけばPodのリソース不足時にノードが自動追加される。オンプレのVMwareやKVM環境では「ノードを追加する＝ラック搭載・OS設定・ネットワーク設定」という工数が必要だったが、AKSのCluster AutoscalerはVM Scale Set（VMSS）を自動制御して数分でノードを追加してくれる。

# 既存クラスターにCluster Autoscalerを有効化
az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 10

システムプールとユーザープールを分離する

本番運用では、CoreDNS等のシステムコンポーネントをアプリと同じプールで動かすのはリスクが高い。アプリのバースト時にシステムコンポーネントのPodがEvictされ、クラスター全体の安定性に影響することがある。システムノードプールとユーザーノードプールを分離し、アプリPodがシステムコンポーネントのリソースを圧迫しない構成にすること。

# アプリ用のユーザーノードプールを追加する
az aks nodepool add \
  --resource-group rg-aks-demo \
  --cluster-name aks-demo-cluster \
  --name userpool \
  --node-count 3 \
  --node-vm-size Standard_D4s_v3 \
  --mode User \
  --zones 1 2 3

# デフォルトのnodepool1をSystemモードのみに限定する
az aks nodepool update \
  --resource-group rg-aks-demo \
  --cluster-name aks-demo-cluster \
  --name nodepool1 \
  --mode System

AKSノードのOSはLinuxベースが標準

AKSのワーカーノードはAzure Linux（旧CBL-Mariner）またはUbuntuが標準だ。コンテナのデバッグやノードのdmesgを読む際には、Linuxの基礎知識が必要になる。姉妹サイトLinuxMaster.JPでは、インフラエンジニア向けにLinuxのプロセス管理・ネットワーク設定・ログ解析まで体系的に解説しているので参考にしてほしい。

よくあるトラブルと対処法

kubectlのcontextが意図しないクラスターを向いている

複数のAKSクラスターを管理していると、kubectlのcontextが意図しないクラスターに向いていることがある。本番クラスターに誤ってリソースを適用する前に、常にcontextを確認する習慣をつけること。

# 現在のcontextを確認（必ず作業前に実行する）
kubectl config current-context

# 利用可能なcontextの一覧
kubectl config get-contexts

# contextを切り替える
kubectl config use-context aks-demo-cluster

CI/CDパイプラインでkubectlを使う場合は、`az aks get-credentials` の後に明示的にcontextを指定してから実行するとミスを防げる。

ノードプールのアップグレード中にPodがPendingになる

ノードプールをKubernetesの新バージョンにアップグレードすると、旧バージョンのノードがcordon→drain→削除の順で処理される。PodにPodDisruptionBudget（PDB）が設定されていない場合、Podが一時的にPending状態になることがある。

本番環境のアップグレード前に、対象のDeploymentにPDBを設定しておくことを強く推奨する。

# PodDisruptionBudgetの設定例（YAML）
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 1    # 最低1つのPodは常に稼働させる
  selector:
    matchLabels:
      app: myapp

PodがInsufficient memoryでPendingのまま動かない

新しいPodをデプロイしてもPendingのまま動かない場合、`kubectl describe pod ` を実行してEventsを確認すること。「Insufficient memory」や「Insufficient cpu」が表示されていたら、ノードのリソースが枯渇している。

・短期対処: ノードプールの台数を手動で増やす（`az aks scale`コマンド）
・根本対処: Cluster Autoscalerを有効化し、最大ノード数を適切に設定する
・設計見直し: PodのresourceRequests/Limitsが過大に設定されていないか確認する

resource.requestsを過大に設定すると、ノードに余裕があるにもかかわらずPodがスケジュールされない「ゴースト枯渇」が起きる。requests≒実際の使用量に近い値を設定することが重要だ。

本記事のまとめ

Azure Kubernetes Service（AKS）はオンプレのKubernetes運用で最も重荷になるコントロールプレーン管理をAzureに任せ、アプリケーション運用に集中できる環境を提供するマネージドサービスだ。

AKSは「Kubernetesを使いたいが、Kubernetesそのものの管理に時間を割きたくない」という現場のニーズに直球で応えるサービスだ。まずはFreeティアでAKSクラスターを立ち上げ、オンプレの構成をリフト＆シフトするところから始めてみてほしい。