この記事では、コンテナ化されたアプリケーションを Azure に大規模にデプロイして運用するために使用できるマネージド Kubernetes サービスである Azure Kubernetes Service (AKS) の主要な概念について説明します。
Important
2025 年 11 月 30 日から、Azure Kubernetes Service (AKS) は、Azure Linux 2.0 のセキュリティ更新プログラムをサポートまたは提供しなくなりました。 Azure Linux 2.0 ノード イメージは、 202512.06.0 リリースでフリーズします。 2026 年 3 月 31 日以降、ノード イメージは削除され、ノード プールをスケーリングできなくなります。 ノード プールをサポートされている Kubernetes バージョンにアップグレードするか、osSku AzureLinux3 に移行して、サポートされている Azure Linux バージョンに移行します。 詳細については、 廃止に関する GitHub の問題 と Azure 更新プログラムの提供終了に関するお知らせを参照してください。 お知らせや更新情報を常に把握するには、 AKS のリリース ノートに従ってください。
Kubernetes とは
Kubernetes は、コンテナー化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための、オープンソースのコンテナー オーケストレーション プラットフォームです。 詳細については、公式の Kubernetes のドキュメントを参照してください。
AKS とは
AKS は、Kubernetes を使用するコンテナー化されたアプリケーションのデプロイ、管理、スケーリングを簡素化するマネージド Kubernetes サービスです。 AKS では、次の 2 つのクラスター モードがサポートされています。
- AKS Automatic は、運用準備完了の一般的な運用タスクの既定値を使用した、よりフル マネージドのエクスペリエンスです。
- AKS Standard は、クラスターのセットアップと操作をより詳細に制御する必要があるチームにとって、より構成可能なエクスペリエンスです。
詳細については、Azure Kubernetes Service (AKS) とは および AKS Automatic とは を参照してください。
クラスター モード
AKS では、自動モードまたは標準モードでクラスターを作成できます。 どちらのモードでも Kubernetes の主要な概念が使用されますが、運用上の責任は異なります。
- AKS Automatic は、運用オーバーヘッドの削減を望むチーム向けに設計されています。 これには、ノード管理、スケーリング、セキュリティ ガードレール、アップグレードの事前構成済みの既定値が含まれます。
- AKS Standard は、クラスターの構成、ノード プール、スケーリング、ネットワーク、運用に対して最大限の柔軟性と直接制御を必要とするチーム向けに設計されています。
2 日目のプラットフォーム管理を減らした運用環境対応のベースラインが必要な場合は、AKS Automatic を使用します。 カスタムの運用パターンとクラスター機能間のより深いチューニングが必要な場合は、AKS Standard を使用します。
機能の詳細な違いについては、 AKS の自動機能と標準機能の比較に関する記事を参照してください。
注
AKS Automatic と AKS Standard は、サービス レベル アグリーメント (SLA) エクスペリエンスが異なります。 AKS Automatic には、デフォルトで稼働時間 SLA と対象となるポッドの稼働状態の SLA が含まれています。 AKS Standard では、アップタイム SLA は価格レベルとクラスターのセットアップに関連付けられています。 詳細については、AKS クラスター管理の AKS 自動および標準機能の比較 と 価格レベルに関する記事を参照してください。
クラスターのコンポーネント
AKS クラスターは、次の 2 つの主要コンポーネントに分割されています。
- コントロール プレーン: コントロール プレーンは、Kubernetes の主要サービスと、アプリケーション ワークロードのオーケストレーションを提供します。
- ノード: ノードは、お使いのアプリケーションを実行する基になる仮想マシン (VM) です。
これらのアーキテクチャの概念は、両方の AKS クラスター モードで同じです。 運用モデルの違いは、AKS Automatic では既定でより構成済みのプラットフォーム操作を適用しますが、AKS Standard ではノードとクラスターの操作の構成と管理方法をより直接的に制御できます。
注
AKS マネージド コンポーネントには、ラベル kubernetes.azure.com/managedby: aksがあります。
AKS は、プレフィックス aks-managedを使用して Helm リリースを管理します。 これらのリリースのリビジョンが大きくなり続けるのは予想されることであり、安全です。
コントロール プレーン
次の表では、Azureマネージド AKS コントロール プレーンを構成するコンポーネントについて説明します。
| コンポーネント | 説明 |
|---|---|
kube-apiserver |
API サーバー (kube-apiserver) は、Kubernetes API を公開して、クラスターの内外からクラスターへの要求を有効にします。 |
etcd |
高可用性キー値ストア etcd は、Kubernetes クラスターと構成の状態を維持するのに役立ちます。 |
kube-scheduler |
スケジューラ (kube スケジューラ) は、スケジュールの決定に役立ちます。 ノードが割り当てられていない新しいポッドを監視し、実行するノードを選択します。 |
kube-controller-manager |
コントローラー マネージャー (kube-controller-manager) は、ノードがダウンしたときに検知して応答するといったコントローラー プロセスを実行します。 |
cloud-controller-manager |
クラウド コントローラー マネージャー (cloud-controller-manager) には、クラウド プロバイダー固有のコントローラーを実行するためのクラウド固有の制御ロジックが組み込まれています。 |
コントロール プレーンは、AKS Automatic と AKS Standard の両方でAzure管理されたままになります。 どちらのモードでも、Azureは、kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-managerなどの重要なコントロール プレーン コンポーネントを操作します。
ノード
各 AKS クラスターには少なくとも 1 つのノードがあります。これは、Kubernetes ノード コンポーネントを実行する Azure VM です。 次の表では、各 AKS ノードで実行される Kubernetes コンポーネントについて説明します。
| コンポーネント | 説明 |
|---|---|
kubelet |
kubelet は、コンテナーが確実にポッド内で実行されるようにします。 |
kube-proxy または Cilium |
kube-proxy は、ノード上にネットワーク規則を保持するネットワーク プロキシです。
Cilium を利用Azure CNI を使用するクラスターでは、kube-proxyではなく Cilium が使用されます。 |
container runtime |
container runtime は、コンテナーの実行とライフサイクルを管理します。 |
ノードは、とkubeletなど、container runtimeの両方で同じコア Kubernetes ノード コンポーネントを実行します。 クラスターのネットワーク データ プレーンに応じて、ノードはサービス ルーティングに kube-proxy または Cilium を使用します。 違いは、既定の操作エクスペリエンスです。
- AKS Automatic では、一般的なノード関連の操作に事前構成済みの既定値が使用されます。
- AKS Standard では、ノードの動作を直接構成して操作する柔軟性が高くなります。
機能の詳細な比較については、 AKS の自動機能と標準機能の比較に関する記事を参照してください。
ノード構成
ノードに対して次の設定を構成します。
VM のサイズとイメージ
ノードの Azure VM サイズ は、CPU、メモリ、サイズ、および使用可能なストレージの種類 (高パフォーマンスのソリッド ステート ドライブや通常のハード ディスク ドライブなど) を定義します。 選択する VM サイズは、ワークロードの要件と、各ノードで実行する予定のポッドの数によって異なります。 2025 年 5 月以降、既定の VM SKU とサイズは、デプロイ中にパラメーターが空白のままになっている場合、使用可能な容量とクォータに基づいて AKS によって動的に選択されます。 詳しくは、Azure Kubernetes Service (AKS) でサポートされている VM サイズに関する記事をご覧ください。
AKS は、Ubuntu Linux、Azure Linux、Azure Container Linux など、サポートされている Linux オペレーティング システム用の VM イメージと、Windows Server 2022 および Windows Server 2025 を含むサポートされているWindows オペレーティング システムを提供します。 現在の OS とイメージの可用性については、Azure Kubernetes Serviceのノード イメージを参照してください。 AKS クラスターを作成したり、ノード数をスケールアウトしたりすると、Azure プラットフォームによって、要求された数の VM が作成され構成されます。 エージェント ノードは標準 VM として課金されます。 Azure の予約を含め、VM サイズの割引が自動的に適用されます。
OS ディスク
既定の OS ディスクサイズ設定は、既定の OS ディスク サイズが指定されていない場合にのみ、新しいクラスターまたはノード プールで使用されます。 この動作は、マネージド OS ディスクとエフェメラル OS ディスクの両方に適用されます。 詳細については、「既定の OS ディスクのサイズ設定」を参照してください。
リソース予約
AKS では、ノード リソースを使用して、クラスターの一部としてノードを機能させることができます。 このような使い方では、ノードの合計リソースと AKS での割り当て可能リソースが一致しなくなることがあります。 ノードのパフォーマンスと機能を維持するために、AKS では各ノード上で 2 つのタイプのリソース (CPU とメモリ) を予約します。 詳しくは、AKS でのリソース予約に関する記事を参照してください。
オペレーティングシステム (OS)
AKS では、Ubuntu、Azure Linux、Azure Container Linux など、複数の Linux オペレーティング システムがサポートされています。 AKS Standard では既定で Ubuntu が使用されますが、AKS 自動構成ではマネージド システム ノード プールAzure Linux が事前構成されます。 Windows ノード プールは、既定のチャネルとして長期サービス チャネル (LTSC) を使用する AKS でもサポートされます。 現在の OS バージョンと既定値については、 AKS のノード イメージを参照してください。
コンテナー ランタイム
コンテナー ランタイムは、ノードでコンテナーを実行し、コンテナー イメージを管理するソフトウェアです。 ランタイムは、Linux または Windows 上でコンテナーを実行するためのシステム呼び出しまたは OS 固有の機能を抽象化するのに役立ちます。 Linux ノード プールの場合、 コンテナー化 は Kubernetes バージョン 1.19 以降で使用されます。 Windows Server 2019 および 2022 ノード プールの場合、 コンテナー 化は一般公開されており、Kubernetes バージョン 1.23 以降では唯一のランタイム オプションです。
ポッド
"ポッド" は、同じネットワークとストレージ リソースを共有する 1 つ以上のコンテナーのグループであり、コンテナーを実行する方法を示す仕様です。 通常、ポッドにはコンテナーとの 1 対 1 のマッピングがありますが、複数のコンテナーを 1 つのポッドで実行することもできます。
ノード プール
注
AKS 自動 構成は、システム ノード プールの動作とノード プロビジョニングの既定値を事前構成して管理します。 AKS Standard では、明示的なノード プールの設計とライフサイクルの選択が必要です。 詳細については、「AKS の Automatic と Standard の機能比較」を参照してください。
AKS では、ノードはノード プールにグループ化されます。 既定では、ノード プールはVirtual Machine Scale Setsを使用して、アプリケーションを実行する VM を管理します。 AKS では、Virtual Machines ノード プールもサポートされています。このプールでは、AKS が個々の VM を直接管理します。
AKS クラスターを作成するときは、ノードの初期数とそのサイズとバージョンを定義し、 システム ノード プールを作成します。 システム ノード プールは、CoreDNS (coredns) や konnectivity (konnectivity-agent) など、重要なシステム ポッドをホストする主な目的を果たします。
コンピューティングまたは記憶域の要件が異なるアプリケーションをサポートするには、ユーザー ノード プールを作成します。 ユーザー ノード プールは、アプリケーション ポッドをホストするという主要な目的を果たします。
詳細については、AKS でのノード プールの作成に関する記事と AKS でのノード プールの管理に関する記事を参照してください。
ノード リソース グループ
Azure リソース グループ内に AKS クラスターを作成すると、AKS リソース プロバイダーにより "ノード リソース グループ" と呼ばれる 2 つ目のリソース グループが自動的に作成されます。 このリソース グループには、VM、Virtual Machine Scale Sets、ストレージなど、クラスターに関連付けられているすべてのインフラストラクチャ リソースが含まれます。
詳細については、次のリソースを参照してください。
- AKS と一緒にリソース グループが 2 つ作成されるのはなぜでしょうか?
- AKS ノード リソース グループに独自の名前を指定できますか?
- AKS ノード リソース グループ内のリソースのタグや他のプロパティを変更できますか?
名前空間
AKS クラスターを分割し、リソースへのアクセス権の作成、表示、管理を制限するために、ポッドやデプロイなどの Kubernetes リソースは、論理的に 1 つの "名前空間" にグループ化されます。
AKS クラスターでは、以下の名前空間が既定で作成されます。
| 名前空間 | 説明 |
|---|---|
default |
default 名前空間を使用すると、新しい名前空間を作成せずにクラスター リソースの使用を開始できます。 |
kube-node-lease |
kube-node-lease 名前空間を使用すると、ノードがその可用性をコントロール プレーンに通信できるようになります。 |
kube-public |
通常、kube-public 名前空間は使用されませんが、任意のユーザーがクラスター全体でリソースを表示できるように使用できます。 |
kube-system |
kube-system 名前空間は、coredns、konnectivity-agent、metrics-server などのクラスター リソースを管理するために Kubernetes によって使用されます。 独自のアプリケーションをこの名前空間にデプロイすることはお勧めしません。 この名前空間に独自のアプリケーションをデプロイする必要があるまれなケースについては、 FAQ を参照してください。 |
価格レベル
AKS には、クラスター管理用の 3 つの価格レベル (Free、Standard、Premium) が用意されています。 選択した価格レベルによって、クラスターの管理に使用できる機能が決まります。
| 価格階層 | 機能の説明 |
|---|---|
| Free | 現在のすべての AKS 機能が含まれています。 最大 1,000 ノードをサポートします。 金銭的保証のあるアップタイムSLAはありません。 |
| Standard | アップタイム SLA は既定で有効になっています。 高い信頼性プロファイル。 現在のすべての AKS 機能が含まれています。 最大 5,000 ノードをサポートします。 |
| Premium | 現在のすべての AKS 機能に加えて、[コミュニティ サポートを超えたMicrosoftメンテナンス][長期的なサポート]が含まれています。 |
注
Standard 価格レベルは、AKS Standard クラスター モードとは別です。
詳細については、AKS クラスター管理のための価格レベルに関するページをご覧ください。
AKS でサポートされている Kubernetes バージョン
AKS でサポートされている Kubernetes バージョン (バージョン サポート ポリシー、バージョン別の破壊的変更、非推奨ポリシーなど) については、 AKS でサポートされている Kubernetes バージョンに関するページを参照してください。
関連コンテンツ
AKS と AKS Automatic の詳細については、次のリソースを参照してください。