Azure Kubernetes Service (AKS) の主要な Kubernetes の概念

この記事では、コンテナ化されたアプリケーションを Azure に大規模にデプロイして運用するために使用できるマネージド Kubernetes サービスである Azure Kubernetes Service (AKS) の主要な概念について説明します。 これは、Kubernetes のインフラストラクチャ コンポーネントについて学習し、AKS での Kubernetes のしくみをより深く理解するのに役立ちます。

Kubernetes とは

Kubernetes は、コンテナー ベース アプリケーションとそれに関連するネットワークおよびストレージ コンポーネントを管理するプラットフォームであり、急速に進化しています。 Kubernetes では、基になるインフラストラクチャ コンポーネントではなく、アプリケーション ワークロードに重点が置かれています。 Kubernetes は、管理操作のための一連の堅牢な API によって支援され、デプロイに対して宣言型のアプローチを提供しています。

アプリケーション コンポーネントの可用性を調整して管理する Kubernetes の機能を使用して、モダンかつポータブルなマイクロサービス ベースのアプリケーションを構築して実行できます。 Kubernetes では、ステートレスおよびステートフルの両方のアプリケーションがサポートされます。

Kubernetes はオープン プラットフォームとして、使いたいプログラミング言語、OS、ライブラリ、またはメッセージング バスでアプリケーションを開発することを可能にします。 既存の継続的インテグレーションと継続的デリバリー (CI/CD) ツールは、リリースをスケジュール設定してデプロイするために、Kubernetes と連携できます。

AKS は、デプロイおよびコア管理タスクの複雑さを軽減する、マネージド Kubernetes サービスを提供します。 AKS コントロール プレーンは Azure プラットフォームによって管理され、お使いのアプリケーションを実行する AKS ノードに対してのみ課金されます。

Kubernetes クラスターのアーキテクチャ

Kubernetes クラスターは、次の 2 つのコンポーネントに分割されています。

• コントロール プレーン。中心的な Kubernetes サービスと、アプリケーションのオーケストレーションを提供します。
• "ノード"。アプリケーション ワークロードを実行します。

コントロール プレーン

AKS クラスターを作成すると、Azure プラットフォームによって関連するコントロール プレーンが自動的に作成されて構成されます。 このシングルテナント コントロール プレーンは、ユーザーから抽象化されたマネージド Azure リソースとして無料で提供されます。 AKS クラスターに接続されているノードに対してのみ課金されます。 コントロール プレーンとそのリソースは、クラスターを作成したリージョンにのみ存在します。

コントロール プレーンには、次の主要な Kubernetes コンポーネントが含まれます。

コンポーネント	説明
kube-apiserver	API サーバーは、基になる Kubernetes API を公開し、kubectl や Kubernetes ダッシュボードなどの管理ツールの対話を提供します。
etcd	etcd は、Kubernetes クラスターと構成の状態を維持するのに役立つ、Kubernetes 内の高可用性を備えたキー値ストアです。
kube-scheduler	スケジューラでは、アプリケーションを作成またはスケーリングするときに、どのノードがワークロードを実行し、識別されたノードを開始できるかを判断します。
kube-controller-manager	コントローラー マネージャーでは、ポッドのレプリケートやノード調整の処理などのアクションを実行する、より小規模な多数のコントローラーを監視します。

コントロール プレーンには直接アクセスできないので注意してください。 Kubernetes のコントロール プレーンとノードのアップグレードは、Azure CLI または Azure portal を使用して調整されます。 発生する可能性のある問題のトラブルシューティングを行うために、Azure Monitor を使用してコントロール プレーンのログを確認できます。

Nodes

アプリケーションとサポート対象のサービスを実行するには、Kubernetes のノードが必要です。 各 AKS クラスターには少なくとも 1 つのノードがあり、これは Kubernetes ノードのコンポーネントとコンテナー ランタイムを実行する Azure Vrtual Machine (VM) となります。

ノードには、次の主要な Kubernetes コンポーネントが含まれます。

コンポーネント	説明
kubelet	コントロール プレーンからのオーケストレーション要求を、要求されたコンテナーのスケジュール設定と実行と共に処理する Kubernetes エージェントです。
kube-proxy	プロキシは、各ノードの仮想ネットワークを処理し、ネットワーク トラフィックをルーティングし、サービスとポッドの IP アドレス指定を管理します。
コンテナー ランタイム	コンテナー ランタイムを使用すると、コンテナ化されたアプリケーションが仮想ネットワークやストレージなどのほかのリソースを実行して操作できるようになります。 詳細については、「コンテナー ランタイム構成」を参照してください。

ノードの Azure VM サイズでは、CPU、メモリ、サイズ、使用可能なストレージの種類 (高性能の SSD や通常の HDD など) を定義します。 お使いのアプリケーションで大容量の CPU やメモリ、または高性能ストレージが必要かどうかに応じてノード サイズを計画してください。 お使いの AKS クラスター内のノード数は、需要に合わせてスケールアウトしてください。 スケーリングの詳細については、AKS でのアプリケーションのスケーリング オプションに関する記事を参照してください。

AKS では、クラスターのノードの VM イメージは、Ubuntu Linux、Azure Linux、または Windows Server 2022 に基づいています。 AKS クラスターを作成したり、ノード数をスケールアウトしたりすると、Azure プラットフォームによって、要求された数の VM が作成され構成されます。 エージェント ノードは標準の VM として課金されるので、VM サイズの割引 (Azure の予約など) はすべて自動的に適用されます。

マネージド ディスクの場合、既定では、ディスク サイズとパフォーマンスは、選択された VM SKU と vCPU の数に従って割り当てられます。 詳細については、「既定の OS ディスクのサイズ設定」を参照してください。

OS 構成

AKS では、Kubernetes 1.25 以降のクラスターの唯一のノード オペレーティング システム (OS) として Ubuntu 22.04 と Azure Linux 2.0 がサポートされています。 Kubernetes バージョン 1.24 以下のノードプール作成時には、Ubuntu 18.04 を指定することもできます。

AKS では、Kubernetes 1.25 以降のクラスター内の Windows ノード プールの既定の OS として Windows Server 2022 がサポートされています。 Kubernetes バージョン 1.32 以下のノードプール作成時には、Windows Server 2019 を指定することもできます。 Windows Server 2019 は、Kubernetes バージョン 1.32 がサポート終了に達した後に廃止され、将来のリリースではサポートされません。 この廃止の詳細については、AKS リリース ノートを参照してください。

コンテナー ランタイム構成

コンテナー ランタイムは、ノードでコンテナーを実行し、コンテナー イメージを管理するソフトウェアです。 ランタイムにより、Linux または Windows 上でコンテナーを実行するためのシステム コールや OS 固有の機能の抽象化が容易になります。 Linux ノード プールの場合、containerd は Kubernetes バージョン 1.19 以降で使用されます。 Windows Server 2019 および 2022 ノード プールで、containerd は一般提供されており、Kubernetes バージョン 1.23 以降で唯一のコンテナー ランタイム オプションです。 2023 年 5 月時点で Docker は廃止され、サポートされなくなりました。 この廃止の詳細については、AKS リリース ノートを参照してください。

Containerd は、OCI (Open Container Initiative) 準拠のコア コンテナー ランタイムです。ノードでコンテナーを実行してイメージを管理するために必要な最小限の機能セットを提供します。 containerd ベースのノードとノード プールでは、kubelet は CRI (コンテナー ランタイム インターフェイス) プラグインを使用して containerd と直接通信するので、Docker CRI 実装と比較して、データ フローの余分なホップが排除されます。 そのため、ポッドの起動時の待ち時間が短縮され、リソース (CPU とメモリ) 使用量が削減されます。

Containerd では、AKS のすべての GA バージョンの Kubernetes と、v1.19 以降のすべての Kubernetes バージョンで動作し、Kubernetes と AKS のすべての機能がサポートされています。

containerd の制限事項と相違点

• containerd では、"Kubernetes ノード上のポッド、コンテナー、コンテナー イメージのトラブルシューティング" に、Docker CLI の代わりに crictl を使用することをお勧めします。 crictl の詳細については、「一般的な使用」と「クライアントの構成オプション」を参照してください。

  • Containerd では、Docker CLI の完全な機能は提供されません。 トラブルシューティングでのみ使用できます。
  • crictl では、ポッドなどの概念が存在する、Kubernetes により適したコンテナー ビューが提供されます。

• Containerd は、標準化された cri ログ形式を使用してログ記録を設定します。 ログ ソリューションでは、Azure Monitor for Containers のように cri ログ形式をサポートする必要があります。

• Docker エンジン (/var/run/docker.sock) にアクセスすることも、Docker-in-Docker (DinD) を使用することもできなくなります。

  • 現在、アプリケーション ログや監視データを Docker エンジンから抽出している場合は、代わりに Container insights を使用します。 AKS では、不安定になる可能性のある、エージェント ノードでの帯域外コマンドの実行はサポートされていません。
  • イメージをビルドしたり、Docker エンジンを直接使用したりすることはお勧めしません。 Kubernetes では、使用されたリソースが完全に認識されるわけではなく、これらの方法では、こちらとこちらで詳述されている多くの問題が生じます。

• イメージをビルドする際に、現在の Docker ビルド ワークフローを引き続き通常どおり使用できますが、AKS クラスター内でイメージをビルドする場合は除きます。 この場合は、ACR タスクを使ったイメージのビルドの推奨される方法、または docker buildx のようなより安全なクラスター内オプションに切り替えることを検討してください。

リソース予約

AKS では、ノード リソースを使用して、お使いのクラスターの一部としてノードを機能させることができます。 このような使い方では、お使いのノードの合計リソースと AKS での割り当て可能リソースが一致しなくなることがあります。 ユーザーがデプロイするポッドに要求と上限を設定するときは、この情報を念頭に置いてください。

ノードの割り当て可能なリソースを見つけるには、kubectl describe node コマンドを使用します。

kubectl describe node [NODE_NAME]

ノードのパフォーマンスと機能を維持するために、AKS では各ノード上で 2 つのタイプのリソース (CPU とメモリ) を予約します。 あるノードでリソース数が増えると、ユーザーがデプロイするポッドの管理の必要性が高くなるため、リソース予約が増大します。 リソースの予約を変更することはできないので注意してください。

CPU

予約された CPU は、ノードの種類とクラスター構成に依存します。追加の機能が実行されている場合は、割り当て可能な CPU が少なくなることがあります。 次の表は、CPU 予約を示しています (ミリコア単位)。

ホスト上の CPU コア数	1	2	4	8	16	32	64
Kube 予約 (ミリコア)	60	100	140	180	260	420	740

メモリ

AKS の予約済みメモリには、2 つの値の合計が含まれます。

AKS 1.29 以降

1. kubelet デーモンには、既定で memory.available<100Mi 削除規則があります。 この規則により、ノードでは常に少なくとも 100Mi が割り当て可能な状態であることが保証されます。 ホストがその使用可能メモリのしきい値を下回ると、kubelet が実行中のいずれかのポッドの終了をトリガーして、ホスト マシン上のメモリを解放します。

2. 次のいずれか小さい方の値に従って設定されるメモリ予約の比率: "20 MB * ノードでサポートされている最大ポッド数 + 50 MB" または "システム全体のメモリ リソースの 25 %"。

   例:

   • VM が 8 GB のメモリを提供し、ノードが最大 30 個のポッドをサポートしている場合、AKS は kube 予約用に "20 MB * 最大ポッド数 30 + 50 MB = 650 MB" を予約します。 Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • VM が 4 GB のメモリを提供し、ノードが最大 70 個のポッドをサポートしている場合、AKS は kube 予約用に 25% * 4GB = 1000MB を予約します。これは "20 MB * 最大ポッド数 70 + 50 MB = 1450 MB" 未満であるためです。

   詳細については、「AKS クラスター内のノードあたりの最大ポッド数の構成」を参照してください。

1.29 より前の AKS バージョン

1. kubelet デーモンには、既定で memory.available<750Mi 削除規則があります。 この規則により、ノードでは常に少なくとも 750Mi が割り当て可能な状態であることが保証されます。 ホストがその使用可能メモリのしきい値を下回ると、kubelet が実行中のいずれかのポッドの終了をトリガーして、ホスト マシン上のメモリを解放します。
2. kubelet デーモンが適切に機能するための予約されているメモリの回帰率 (kube-reserved)。
   • メモリの最初の 4 GB の 25%
   • メモリの次の 4 GB の 20% (8 GB まで)
   • メモリの次の 8 GB の 10% (16 GB まで)
   • メモリの次の 112 GB の 6% (128 GB まで)
   • 128 GB を超えるメモリの 2%

メモリと CPU の割り当て規則は、次のことを行うように設計されています。

• エージェント ノードを正常な状態に保ちます (クラスターの正常性に不可欠ないくつかのホスティング システム ポッドを含む)。
• ノードが Kubernetes クラスターの一部でない場合、それが報告する割り当て可能なメモリと CPU は、より少なくなります。

たとえば、ノードで 7 GB が提供される場合、750Mi のハード削除しきい値を含めて、メモリの 34% が割り当て不可として報告されます。

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Kubernetes 自体の予約に加えて、基になるノード OS も OS 機能を維持するための CPU とメモリ リソースの量を予約します。

関連付けられているベスト プラクティスについては、AKS の基本的なスケジューラ機能のベスト プラクティスに関するページを参照してください。

ノード プール

同じ構成のノードは、ノード プールにグループ化できます。 各 Kubernetes クラスターには、少なくとも 1 つのノード プールが含まれています。 ノードとサイズの最初の数は、"既定のノード プール" の作成が行われる AKS クラスターの作成時に定義します。 AKS のこの既定のノード プールには、お使いのエージェント ノードを実行する基本の VM が含まれています。

AKS クラスターのスケーリングまたはアップグレードは既定のノード プールに対して行います。 特定のノード プールのスケーリングまたはアップグレードを選択できます。 アップグレード操作では、すべてのノードが正常にアップグレードされるまで、実行中のコンテナーはノード プ―ル内の他のノード上にスケジュールされます。

詳細については、「ノード プールの作成」および「ノード プールの管理」参照してください。

既定の OS ディスクのサイズ設定

新しいクラスターを作成する、または既存のクラスターに新しいノード プールを追加する場合、既定では vCPU の数に応じて OS ディスク サイズが決まります。 vCPU の数は、VM SKU に基づきます。 次の表は、各 VM SKU の既定の OS ディスク サイズをリストしています。

VM SKU コア (vCPU)	既定の OS ディスクの層	プロビジョニングされた IOPS	プロビジョニングされたスループット (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

ノードのセレクター

複数のノード プールを含む AKS クラスターでは、特定のリソースに使用するノード プールを、Kubernetes スケジューラに指示することが必要になる場合があります。 たとえば、Windows Server ノード上でイングレス コントローラーを実行することはできません。 ノード セレクターを使用して、ノード OS などのさまざまなパラメーターを定義し、ポッドがスケジュールされる場所を制御します。

次の基本的な例は、ノード セレクター "beta.kubernetes.io/os": linux を使用して Linux ノード上の NGINX インスタンスをスケジュールします。

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

詳細については、AKS の高度なスケジューラ機能のベスト プラクティスに関するページを参照してください。

ノード リソース グループ

AKS クラスターの作成時に、クラスター リソースを作成する Azure リソース グループを指定します。 このリソース グループに加えて、AKS リソース プロバイダーでは、ノード リソース グループと呼ばれる別のリソース グループが作成および管理されます。 "ノード リソース グループ" には次のインフラストラクチャ リソースが含まれています。

• ノード プール内のすべてのノードの仮想マシン スケール セットと VM
• クラスターの仮想ネットワーク
• クラスターのストレージ

ノード リソース グループには、既定で次の形式の名前が割り当てられます: MC_resourceGroupName_clusterName_location。 クラスターの作成時に、ノード リソース グループに割り当てる名前を指定できます。 Azure Resource Manager テンプレートを使用する場合は、nodeResourceGroup プロパティを使用して名前を定義できます。 Azure CLI を使用する場合は、次の例に示すように、az aks create コマンドで --node-resource-group パラメータを使用します。

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

AKS クラスターを削除すると、AKS リソース プロバイダーによってノード リソース グループが自動的に削除されます。

ノード リソース グループには、次の制限があります。

• ノード リソース グループに対して既存のリソース グループを指定することはできません。
• ノード リソース グループに対して異なるサブスクリプションを指定することはできません。
• クラスターが作成された後で、ノード リソース グループ名を変更することはできません。
• ノード リソース グループ内の管理対象リソースに名前を指定することはできません。
• ノード リソース グループ内の管理対象リソースの Azure で作成されたタグを変更または削除することはできません。

AKS クラスター内のノード リソース グループにあるリソース上で Azure によって作成されたタグを変更することは、サポートされていないアクションであり、サービス レベル目標 (SLO) が損なわれます。 ノード リソース グループ内の Azure で作成されたタグやほかのリソース プロパティを変更または削除する場合、スケーリングやアップグレードのエラーなど、予期しない結果になる可能性があります。 ノード リソース グループ内のインフラストラクチャのライフサイクルは AKS によって管理されているため、何らかの変更を行うと、クラスターはサポートされていない状態に移行します。 詳細については、「AKS でサービス レベル アグリーメントは提供されますか?」を参照してください。

AKS を使用すると、ノード リソース グループ内のリソースに反映されるタグを作成および変更でき、クラスターを作成または更新するときにそれらのタグを追加できます。 たとえば、ビジネス単位やコスト センターを割り当てるために、カスタム タグを作成または変更することがあります。 また、マネージド リソース グループ上にスコープがある Azure ポリシーを作成することもできます。

クラスターに影響を与えるノード リソース グループの変更の可能性を減らすために、"ノード リソース グループのロックダウン" を有効にして、AKS リソースに拒否割り当てを適用できます。 詳細については、「フル マネージド リソース グループ (プレビュー)」を参照してください。

ポッド

Kubernetes は、"ポッド" を使用してアプリケーションのインスタンスを実行します。 単一のポッドは、アプリケーションの単一のインスタンスを表します。

通常、ポッドにはコンテナーとの 1 対 1 のマッピングがあります。 高度なシナリオでは、1 つのポッドに複数のコンテナーが含まれる場合があります。 マルチコンテナー ポッドは、同じノード上にまとめてスケジュールされ、関連するリソースをコンテナーで共有できるようにします。

ポッドを作成する場合、一定量の CPU やメモリに対する "リソース要求" を定義できます。 Kubernetes スケジューラでは、利用可能なリソースを備えたノード上で実行されるようにポッドをスケジュールして、その要求を満たそうとします。 また、あるポッドで基になるノードからのコンピューティング リソース消費量が過大にならないように、リソースの上限を指定することもできます。 推奨されるベスト プラクティスは、必要な許可されているリソースを Kubernetes スケジューラで特定できるように、すべてのポッドにリソース制限を組み入れることです。

詳細については、Kubernetes ポッドと Kubernetes ポッドのライフサイクルに関するページをご覧ください。

ポッドは論理リソースですが、アプリケーション ワークロードはコンテナー上で実行されます。 ポッドは通常、短期間の破棄可能なリソースです。 個々にスケジュール設定されたポッドには、Kubernetes の機能である高可用性および冗長性の一部がありません。 代わりに、デプロイ コントローラーなどの Kubernetes の "コントローラー" によって、ポッドがデプロイおよび管理されます。

デプロイと YAML マニフェスト

デプロイは、Kubernetes デプロイ コントローラーによって管理される同一のポッドを表します。 デプロイでは、作成するポッドの "レプリカ " の数が定義されます。 Kubernetes スケジューラでは、ポッドまたはノードで問題が発生した場合に追加のポッドが正常なノード上にスケジュールされるようにします。 デプロイを更新して、ポッド、コンテナー イメージ、またはアタッチされたストレージの構成を変更できます。

デプロイ コントローラーは、デプロイのライフサイクルを管理し、次のアクションを実行します。

• 指定された数のレプリカをドレインして終了します。
• 新しいデプロイ定義からレプリカを作成します。
• デプロイ内のすべてのレプリカが更新されるまで、プロセスを続行します。

AKS にある最もステートレスなアプリケーションでは、個々のポッドをスケジュール設定するのではなく、デプロイ モデルを使用する必要があります。 Kubernetes では、必要な数のレプリカがクラスター内で確実に実行されるように、デプロイの正常性と状態を監視できます。 個々にスケジュール設定すると、ポッドは問題が発生した場合に再起動されず、その現在のノードで問題が発生した場合に正常なノード上に再スケジュールされません。

お使いのアプリケーションで最低限の数の利用可能なインスタンスが必要とされる場合、管理上の判断が更新プロセスによって中断されることは望ましくありません。 "ポッドの中断バジェット" では、更新やノードのアップグレードの期間中にデプロイ内で停止できるレプリカの数を定義します。 たとえば、デプロイ内に 5 つのレプリカがある場合、ポッド中断数を 4 と定義して、一度に削除または再スケジュールできるレプリカを 1 つのみにすることが可能です。 ポッドのリソース制限と同様に、推奨されるベスト プラクティスは、最低限の数のレプリカが常に存在する必要があるアプリケーション上に、ポッドの中断バジェットを定義することです。

デプロイは通常、kubectl create または kubectl apply で作成および管理されます。 YAML 形式のマニフェスト ファイルを定義することで、デプロイを作成できます。 次の例は、NGINX Web サーバーの基本的な配置マニフェスト ファイルを示しています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

YAML マニフェスト ファイルのデプロイ仕様の内訳は次のとおりです。

仕様	説明
.apiVersion	リソースの作成時に使用する API グループと API リソースを指定します。
.kind	作成するリソースの種類を指定します。
.metadata.name	展開の名前を指定します。 この YAML ファイルの例では、Docker Hub から nginx イメージを実行します。
.spec.replicas	作成するポッドの数を指定します。 この YAML ファイルの例では、3 つの重複するポッドを作成します。
.spec.selector	このデプロイの影響を受けるポッドを指定します。
.spec.selector.matchLabels	作成済みのポッドをデプロイが検索して管理できるようにする "{key, value}" ペアのマップが含まれています。
.spec.selector.matchLabels.app	.spec.template.metadata.labels と一致する必要があります。
.spec.template.labels	オブジェクトにアタッチされた {key, value} ペアを指定します。
.spec.template.app	.spec.selector.matchLabels と一致する必要があります。
.spec.spec.containers	ポッドに属するコンテナーの一覧を指定します。
.spec.spec.containers.name	DNS ラベルとして指定されたコンテナーの名前を指定します。
.spec.spec.containers.image	コンテナー イメージ名を指定します。
.spec.spec.containers.ports	コンテナーから公開するポートの一覧を指定します。
.spec.spec.containers.ports.containerPort	ポッドの IP アドレスで公開するポートの数を指定します。
.spec.spec.resources	コンテナーに必要なコンピューティング リソースを指定します。
.spec.spec.resources.requests	必要なコンピューティング リソースの最小量を指定します。
.spec.spec.resources.requests.cpu	必要な CPU の最小量を指定します。
.spec.spec.resources.requests.memory	必要なメモリの最小量を指定します。
.spec.spec.resources.limits	許可されるコンピューティング リソースの最大量を指定します。 kubelet によってこの制限が適用されます。
.spec.spec.resources.limits.cpu	許可される CPU の最大量を指定します。 kubelet によってこの制限が適用されます。
.spec.spec.resources.limits.memory	許可されるメモリの最大量を指定します。 kubelet によってこの制限が適用されます。

YAML マニフェスト内にサービス (ロード バランサーなど) を含めると、より複雑なアプリケーションを作成できます。

詳細については、Kubernetes のデプロイに関するページをご覧ください。

Helm によるパッケージの管理

Kubernetes では、アプリケーションの管理に Helm がよく使用されます。 リソースをデプロイするには、アプリケーション コードのパッケージ化バージョンと、Kubernetes YAML マニフェストを含む既存のパブリック Helm Chart を構築して使用します。 Helm Chart はローカルにも、リモート リポジトリ (Azure Container Registry の Helm Chart リポジトリなど) 内にも保存できます。

Helm を使用するには、コンピューターに Helm クライアントをインストールするか、Azure Cloud Shell で Helm クライアントを使用します。 Helm Chart を検索または作成してから、お使いの Kubernetes クラスターにインストールします。 詳細については、「AKS で Helm を使用して既存のアプリケーションをインストールする」を参照してください。

StatefulSet と DaemonSet

デプロイ コントローラーでは、Kubernetes スケジューラを使用して、利用可能なリソースを備えた利用可能な任意のノード上でレプリカを実行します。 ステートレス アプリケーションにはこの方法で十分ですが、次の仕様を必要とするアプリケーションにはデプロイ コントローラーは適していません。

• 永続的な名前付け規則またはストレージ。
• クラスター内の各選択ノード上にレプリカが存在する。

ただし、StatefulSet および DaemonSet の 2 つの Kubernetes リソースを使用すると、このようなタイプのアプリケーションを管理できます。

StatefulSet は、個々のポッド ライフサイクルを超えて、アプリケーションの状態を保守します。 DaemonSet は、Kubernetes ブートストラップ プロセスの初期段階で、各ノード上で実行されるインスタンスを確保します。

StatefulSet

モダン アプリケーション開発は、多くの場合、ステートレス アプリケーションを対象としています。 ステートフル アプリケーション (データベース コンポーネントを含むものなど) には、StatefulSets を使用できます。 デプロイと同様に、StatefulSet では少なくとも 1 つの同一ポッドを作成して管理します。 デプロイ、スケーリング、アップグレード、および強制終了の各操作において、StatefulSet 内のレプリカは、適切な順序付けの手法に従います。 StatefulSet でレプリカが再スケジュールされるときに、名前付け規則、ネットワーク名、およびストレージが永続化されます。

kind: StatefulSet を使用して、アプリケーションを YAML 形式で定義できます。 そこから、StatefulSet コントローラーによって、必要なレプリカのデプロイと管理が処理されます。 データは、Azure Managed Disks または Azure Files によって提供された永続的なストレージに書き込まれます。 複数の StatefulSet を使用すると、StatefulSet が削除されても、基になる永続化ストレージは残ります。

詳細については、Kubernetes の StatefulSet に関するページを参照してください。

DaemonSet

特定のログ収集や監視のために、すべてのノードまたは選択されたノードのセットに対して 1 つのポッドを実行することが必要になる場合があります。 1 つ以上の同一ポッドにデプロイするために、DaemonSets を使用できます。 DaemonSet コントローラーは、指定された各ノードがポッドのインスタンスを実行するようにします。

DaemonSet コントローラーでは、既定の Kubernetes スケジューラが開始される前に、クラスターのブート プロセスの初期段階でノード上にポッドをスケジュール設定できます。 この機能によって、1 つのデプロイまたは StatefulSet 内の従来のポッドがスケジュールされる前に、確実に DaemonSet 内のポッドが開始されます。

StatefulSet と同様に、kind: DaemonSet を使用して、YAML 定義の一環として DaemonSet を定義できます。

詳細については、Kubernetes の DaemonSet に関するページを参照してください。

名前空間

AKS クラスターを分割し、リソースへのアクセス権の作成、表示、管理を制限するために、ポッドやデプロイなどの Kubernetes リソースは、論理的に 1 つの "名前空間" にグループ化されます。 たとえば、名前空間を作成して業務グループを分けることができます。 ユーザーは、割り当てられている名前空間内のリソースのみを操作できます。

AKS クラスターを作成すると、次の名前空間を使用できます。

名前空間	説明
default	何も指定しない場合に、既定でポッドやデプロイが作成される場所です。 より小規模な環境では、追加の論理分割を作成せずに、既定の名前空間にアプリケーションを直接デプロイできます。 kubectl get pods などの Kubernetes API を操作する場合、何も指定しないと、既定の名前空間が使用されます。
kube-system	DNS やプロキシのようなネットワーク機能、または Kubernetes ダッシュボードなど、コア リソースが置かれている場所です。 通常は、この名前空間に独自のアプリケーションをデプロイしません。
kube-public	通常は使用されませんが、クラスター全体でリソースを表示可能にして、ユーザーが確認できるようにするために使用できます。

詳細については、Kubernetes の名前空間 に関するページを参照してください。

次のステップ

Kubernetes と AKS の中心概念の詳細については、次の記事を参照してください。

• AKS のアクセスと ID
• AKS のセキュリティ
• AKS 仮想ネットワーク
• AKS ストレージ
• AKS スケール