Azure Kubernetes Service (AKS) のクラスターで複数のノード プールを作成および管理する

Azure Kubernetes Service (AKS) で同じ構成のノードは、ノード プールにグループ化できます。 これらのノード プールには、お使いのアプリケーションを実行する基になる VM が含まれています。 最初のノード数とそのサイズ (SKU) は、"システム ノード プール" が作成される AKS クラスターの作成時に定義します。 コンピューティングまたは記憶域の要件が異なるアプリケーションをサポートするには、追加の "ユーザー ノード プール" を作成します。 システム ノード プールは、CoreDNS や tunnelfront などの重要なシステム ポッドをホストするという主要な目的を果たします。 ユーザー ノード プールは、アプリケーション ポッドをホストするという主要な目的を果たします。 ただし、AKS クラスター内のプールを 1 つだけにする場合は、システム ノード プールでアプリケーション ポッドをスケジュールすることができます。 ユーザー ノード プールは、お使いのアプリケーションに固有のポッドを配置する場所です。 たとえば、これらの追加のユーザー ノード プールを使用すると、コンピューティング集約型のアプリケーションに GPU を提供したり、高パフォーマンスな SSD ストレージにアクセスを提供したりできます。

注意

この機能を使用すると、複数のノード プールを作成および管理する方法をより細かく制御できます。 そのため、作成/更新/削除には個別のコマンドが必要です。 以前は、az aks create または az aks update を介したクラスター操作は、managedCluster API を使用するものであり、コントロール プレーンと単一ノード プールを変更する唯一の方法でした。 この機能は、agentPool API を介した、エージェント プールに対する個別の操作セットを公開するものであり、個々のノード プールに対して操作を実行するには az aks nodepool コマンド セットを使用する必要があります。

この記事では、AKS クラスターで複数のノード プールを作成および管理する方法について説明します。

開始する前に

Azure CLI バージョン 2.2.0 以降がインストールされて構成されている必要があります。 バージョンを確認するには、az --version を実行します。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。

制限事項

複数のノード プールをサポートする AKS クラスターを作成および管理する場合には、次の制限があります。

  • Azure Kubernetes Service (AKS) のクォータ、仮想マシンのサイズの制限、およびリージョンの可用性」を参照してください。
  • 別のシステム ノード プールが AKS クラスター内にあり、それが代わりをする場合に、システム ノード プールを削除できる。
  • システム プールには少なくとも 1 つのノードを含める必要があり、ユーザー ノード プールには 0 以上のノードを含めることができます。
  • AKS クラスターが複数のノード プールを使用するためには、Standard SKU のロード バランサーを使用する必要があります。Basic SKU のロード バランサーでは、この機能がサポートされません。
  • AKS クラスターでは、ノードに仮想マシン スケール セットを使用する必要があります。
  • VM を作成した後にノード プールの VM サイズを変更することはできません。
  • ノード プールの名前は、小文字の英数字のみを含めることができ、小文字で始める必要があります。 Linux ノード プールの場合、長さは 1 から 12 文字である必要があります。Windows ノード プールの場合、長さは 1 から 6 文字である必要があります。
  • すべてのノード プールは、同じ仮想ネットワーク内に存在する必要があります
  • クラスターの作成時に複数のノード プールを作成する場合は、ノード プールで使用されるすべての Kubernetes のバージョンが、コントロール プレーンに設定されたバージョンと一致している必要があります。 これは、ノード プールごとの操作を使用してクラスターがプロビジョニングされた後で更新できます。

AKS クラスターを作成する

重要

運用環境内のお使いの AKS クラスターで 1 つのシステム ノード プールを実行する場合、そのノード プールには少なくとも 3 つのノードを使用することをお勧めします。

まず、1 つのノード プールで AKS クラスターを作成開始します。 次の例では、az group create コマンドを使用して、myResourceGroup という名前のリソース グループを eastus リージョンに作成しています。 次いで、myAKSCluster という名前の AKS クラスターを az aks create コマンドを使用して作成しています。

Note

複数のノード プールを使用する場合、Basic ロード バランサー SKU はサポートされません。 既定では、AKS クラスターが、Azure CLI および Azure portal から Standard ロード バランサー SKU で作成されます。

# Create a resource group in East US
az group create --name myResourceGroup --location eastus

# Create a basic single-node pool AKS cluster
az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --vm-set-type VirtualMachineScaleSets \
    --node-count 2 \
    --generate-ssh-keys \
    --load-balancer-sku standard

クラスターの作成には数分かかります。

Note

重要なシステム サービスが既定のノード プールで実行されるため、クラスターを確実に動作させるには、このノード プールで少なくとも 2 つのノードを実行する必要があります。

クラスターの準備ができたら、az aks get-credentials コマンドを使用して、kubectl で使用するクラスターの資格情報を取得します。

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

ノード プールの追加

前の手順で作成したクラスターには、ノード プールが 1 つあります。 az aks nodepool add コマンドを使用して、2 番目のノード プールを追加しましょう。 次の例では、3 つのノードを実行する mynodepool という名前のノード プールを作成します。

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3

Note

ノード プールの名前は、小文字で始める必要があり、英数字のみを含めることができます。 Linux ノード プールの場合、長さは 1 から 12 文字である必要があります。Windows ノード プールの場合、長さは 1 から 6 文字である必要があります。

お使いのノード プールの状態を確認するには、az aks node pool list コマンドを使用し、次のようにお使いのリソース グループとクラスター名を指定します。

az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster

次の出力例では、mynodepool がノード プール内に 3 つのノードと共に正常に作成されたことを示しています。 前の手順で AKS クラスターを作成したとき、既定の nodepool1 がノード数 2 で作成されました。

[
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

ヒント

ノード プールを追加するときに VmSize を指定しなかった場合、既定のサイズは、Windows ノード プールの場合は Standard_D2s_v3、Linux ノード プールの場合は Standard_DS2_v2 になります。 OrchestratorVersion が指定されていない場合、コントロール プレーンと同じバージョンが既定値になります。

ARM64 ノード プールを追加する

ARM64 プロセッサは、Kubernetes ワークロードに低電力コンピューティングを提供します。 ARM64 ノード プールを作成するには、Dpsv5Dplsv5、または Epsv5 シリーズの仮想マシンを選択する必要があります。

ARM64 ノード プールを追加するには、az aks nodepool add コマンドを使用します。

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name armpool \
    --node-count 3 \
    --node-vm-size Standard_Dpds_v5

Mariner ノード プールを追加する

Mariner は、AKS コンテナー ホストとして使用できるオープンソースの Linux ディストリビューションです。 高い信頼性、セキュリティ、整合性を提供します。 Mariner には、コンテナー ワークロードの実行に必要な最小限のパッケージ セットのみが含まれているため、ブート時間と全体的なパフォーマンスが向上します。

az aks nodepool add コマンドを使用し、--os-sku CBLMariner を指定して、既存のクラスターに Mariner ノード プールを追加できます。

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-sku CBLMariner

Ubuntu ノードを Mariner に移行する

Ubuntu ノードを Mariner ノードに移行するには、次の手順に従います。

  1. az aks nodepool add コマンドを使用し、--os-sku CBLMariner を指定して、既存のクラスターに Mariner ノード プールを追加します。

注意

新しい Mariner ノード プールを追加する場合は、--mode System として 少なくとも 1 つを追加する必要があります。 そうしないと、AKS では既存の Ubuntu ノード プールを削除できません。

  1. 既存の Ubuntu ノードを切断します
  2. 既存の Ubuntu ノードをドレインします
  3. az aks delete コマンドを使用して既存の Ubuntu ノードを削除します。
az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name myNodePool

一意のサブネットを持つノード プールを追加する

ワークロードでは、クラスターのノードを論理的に分離するために個別のプールに分割することが必要になる場合があります。 この分離は、クラスター内の各ノード プール専用の個別のサブネットによってサポートできます。 これにより、ノード プール間で分割するための連続しない仮想ネットワーク アドレス空間などの要件に対応できます。

注意

必ず Azure CLI バージョン 2.35.0 以降を使用してください。

制限事項

  • ノード プールに割り当てられるサブネットはすべて、同じ仮想ネットワークに属している必要があります。
  • DNS 解決や kubectl logs/exec/port-forward プロキシのトンネリングなど、重要な機能を提供するために、システム ポッドはクラスター内のすべてのノードとポッドにアクセスできる必要があります。
  • クラスター作成後、VNet を拡張する場合、元の cidr の外でサブネットを追加する前に、クラスターを更新する必要があります (マネージド クラスター操作があれば、それを実行しますが、ノード プール操作は数に入りません)。 元々は許可していましたが、エージェント プールを追加すると AKS でエラーが出るようになっています。 aks-preview Azure CLI 拡張機能 (バージョン 0.5.66 以降) では、省略可能な引数を指定せずに az aks update -g <resourceGroup> -n <clusterName> を実行できるようになりました。 このコマンドは、変更を加えることなく更新操作を実行します。これにより、障害が発生した状態で停止しているクラスターを復旧できます。
  • Kubernetes バージョン < 1.23.3 のクラスターでは、kube-proxy によって新しいサブネットからのトラフィックが SNAT されるため、Azure ネットワーク ポリシーによってパケットがドロップされる可能性があります。
  • Windows ノードでは、ノード プールが再イメージ化されるまで、新しいサブネットへのトラフィックを SNAT します。
  • 内部ロード バランサーは、既定でいずれかのノード プール サブネット (通常、クラスター作成時のノード プールの最初のサブネット) に設定されます。 この動作をオーバーライドするには、注釈を使用してロード バランサーのサブネットを明示的に指定することができます。

専用サブネットを持つノード プールを作成するには、ノード プールを作成する際に、サブネットのリソース ID を追加パラメーターとして渡します。

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3 \
    --vnet-subnet-id <YOUR_SUBNET_RESOURCE_ID>

ノード プールのアップグレード

Note

クラスターまたはノード プールでは、アップグレードやスケーリングの操作を同時に実行することはできず、実行を試みた場合には、エラーが返されます。 代わりに、ターゲット リソースに対する次の要求を行う前に、各操作の種類をその同じリソースで完了する必要があります。 詳細については、トラブルシューティング ガイドを参照してください。

このセクションのコマンドからは、1 つの特定のノード プールをアップグレードする方法が説明されます。 コントロール プレーンとノード プールの Kubernetes バージョンをアップグレードするとき、両者の関係については、下のセクションで説明します。

Note

ノード プールの OS イメージのバージョンは、クラスターの Kubernetes バージョンに関連付けられています。 OS イメージは、クラスターのアップグレードの後でのみアップグレードされます。

この例には 2 つのノード プールがあるため、az aks nodepool upgrade を使用してノード プールをアップグレードする必要があります。 使用可能なアップグレードを確認するには、az aks get-upgrades を使用します。

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

mynodepool をアップグレードしましょう。 次の例のように、az aks node pool upgrade コマンドを使用してノード プールをアップグレードします。

az aks nodepool upgrade \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --kubernetes-version KUBERNETES_VERSION \
    --no-wait

az aks node pool list コマンドを使用し、再度お使いのノード プールの状態を一覧表示します。 次の例では、mynodepoolKUBERNETES_VERSION への Upgrading 状態であることを示しています。

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "KUBERNETES_VERSION",
    ...
    "provisioningState": "Upgrading",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

ノードを指定したバージョンにアップグレードするには数分かかります。

AKS クラスター内のノード プールは、すべて同じ Kubernetes のバージョンにアップグレードするのがベスト プラクティスです。 az aks upgrade の既定の動作では、この配置を実現するために、すべてのノード プールがコントロール プレーンと共にアップグレードされます。 個々のノード プールをアップグレードできる機能によりローリング アップグレードの実行が可能になり、アプリケーションのアップタイムを維持するノード プール間のポッドを前述の制約内でスケジュールできます。

複数のノード プールを使用するでクラスターのコントロール プレーンをアップグレードする

Note

Kubernetes は、標準のセマンティック バージョニングのバージョン管理スキームを使用します。 バージョン番号は x.y.z として表されます。ここで、x はメジャー バージョン、y はマイナー バージョン、z は修正プログラムのバージョンです。 たとえば、バージョン 1.12.6 の場合は、1 がメジャー バージョン、12 がマイナー バージョン、6 が修正プログラムのバージョンです。 コントロール プレーンの Kubernetes バージョンと初期ノード プールは、クラスター作成時に設定されます。 その他のすべてのノード プールには、クラスターに追加されるときに Kubernetes バージョンが設定されます。 Kubernetes バージョンは、ノード プール間、およびノード プールとコントロール プレーン間では異なる場合があります。

AKS クラスターには、Kubernetes バージョンが関連付けられている 2 つのクラスター リソース オブジェクトがあります。

  1. クラスターのコントロール プレーンの Kubernetes バージョン。
  2. Kubernetes バージョンのノード プール。

コントロール プレーンは、1 つまたは複数のノード プールにマップされます。 アップグレード操作の動作は、どの Azure CLI コマンドを使用するかによって異なります。

AKS コントロール プレーンをアップグレードするには、az aks upgrade を使用する必要があります。 このコマンドにより、コントロール プレーンのバージョンとクラスター内のすべてのノード プールがアップグレードされます。

--control-plane-only フラグを使用して az aks upgrade コマンドを実行すると、クラスターのコントロール プレーンのみがアップグレードされます。 クラスター内の関連付けられているノード プールは一切変更されません。

個々のノード プールをアップグレードするには、az aks nodepool upgrade を使用する必要があります。 このコマンドでは、指定した Kubernetes バージョンのターゲット ノード プールのみがアップグレードされます

アップグレードの検証規則

クラスターのコントロール プレーンおよびノード プールに対して有効な Kubernetes のアップグレードは、次の規則のセットによって検証されます。

  • ノード プールをアップグレードするための有効なバージョンの規則:

    • ノード プールのバージョンは、コントロール プレーンと同じ "メジャー" バージョンである必要があります。
    • ノード プールの "マイナー" バージョンは、コントロール プレーンのバージョンの 2 つ以内の "マイナー" バージョンでなければなりません。
    • ノード プールのバージョンを、コントロールの major.minor.patch バージョンよりも大きくすることはできません。
  • アップグレード操作を送信するための規則:

    • コントロール プレーンでも、ノード プールでも、Kubernetes バージョンをダウングレードすることはできません。
    • ノード プールの Kubernetes バージョンが指定されていない場合、動作は使用中のクライアントによって異なります。 Resource Manager テンプレートの宣言は、ノード プールに対して定義されている既存のバージョンが使用される場合、そのバージョンにフォールバックします。何も設定されていない場合、フォールバックのためにコントロール プレーン バージョンが使用されます。
    • 特定の時点でコントロール プレーンまたはノード プールのアップグレードまたはスケーリングのどちらかを行うことはできますが、単一のコントロール プレーンまたはノード プール リソースに対して複数の操作を同時に送信することはできません。

ノード プールの手動でのスケーリング

お使いのアプリケーションのワークロードに対する需要の変化に伴い、ノード プール内のノード数をスケーリングしなければならなくなる場合があります。 ノード数は増やすことも減らすことも可能です。

ノード プール内のノード数をスケーリングするには、az aks node pool scale コマンドを使用します。 次の例では、mynodepool 内のノード数を 5 にスケーリングしています。

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5 \
    --no-wait

az aks node pool list コマンドを使用し、再度お使いのノード プールの状態を一覧表示します。 次の例では、mynodepool が新しいノード数の 5Scaling の状態であることを示しています。

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Scaling",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

スケーリングの操作の完了には、数分かかります。

クラスター オートスケーラーを有効にすることで特定のノード プールを自動的にスケーリングする

AKS には、クラスター オートスケーラーと呼ばれる機能を使用してノード プールを自動的にスケーリングするための独立した機能が用意されています。 この機能は、ノード プールごとに一意の最小および最大スケール カウントを使用して、ノード プールごとに有効にすることができます。 ノード プールごとのクラスター オートスケーラーを使用する方法を参照してください。

ノード プールの削除

プールが不要になったら、それを削除して、基になっている VM を削除します。 ノード プールを削除するには、az aks node pool delete コマンドを使用し、ノード プール名を指定します。 次の例では、前の手順で作成した mynoodepool を削除します。

注意事項

ノード プールを削除しても、AKS では切断とドレインは実行されません。また、ノード プールを削除したときに実行できる、データ損失の回復オプションもありません。 他のノード プールでポッドをスケジュールできない場合、それらのアプリケーションは利用できなくなります。 使用中のアプリケーションにデータ バックアップがない場合や、お使いのクラスター内の他のノード プールで実行する機能がない場合は、ノード プールは削除しないでください。 削除するノード プールで現在実行されているポッドの再スケジュールの中断を最小限に抑えるために、削除する前にノード プール内のすべてのノードで cordon と drain を実行します。 詳しくは、ノード プールの切断とドレインに関するページを参照してください。

az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name mynodepool --no-wait

次の az aks node pool list コマンドでの出力例では、mynodepoolDeleting の状態であることを示しています。

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Deleting",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

ノードおよびノード プールの削除には数分かかります。

容量予約グループをノード プールに関連付ける (プレビュー)

重要

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。 詳細については、次のサポート記事を参照してください。

アプリケーションのワークロード要求数に応じて、以前作成した容量予約グループにノード プールを関連付けることができます。 これにより、ノード プールに対して容量が確実に割り当てられます。

容量予約グループの詳細については、「容量予約グループ」を参照してください。

ノードプールを既存の容量予約グループに関連付けるには、az aks nodepool add コマンドを使用し、容量予約グループを「--capacityReservationGroup」フラグで指定する必要があります。指定する容量予約グループはすでに存在している必要があります。存在しない場合は警告の表示とともにクラスターに追加され、容量予約グループは関連付けられません。

az aks nodepool add -g MyRG --cluster-name MyMC -n myAP --capacityReservationGroup myCRG

システムノードプールを既存の容量予約グループに関連付けるには、az aks create コマンドを使用します。 指定された容量予約グループが存在しない場合は、警告が発行され、容量予約グループが関連付けられることなくクラスターが作成されます。

az aks create -g MyRG --cluster-name MyMC --capacityReservationGroup myCRG

ノード プールのコマンドを削除すると、そのノード プールが削除される前に、関連付けられている容量予約グループからノード プールが暗黙的に解除されます。

az aks nodepool delete -g MyRG --cluster-name MyMC -n myAP

クラスターのコマンドを削除すると、クラスター内のすべてのノード プールが、関連付けられている容量予約グループから暗黙的に関連付け解除されます。

az aks delete -g MyRG --cluster-name MyMC

ノード プールの VM サイズの指定

前のノード プールの作成例では、クラスターに作成したノードに、既定の VM サイズを使用しました。 より一般的なシナリオでは、さまざまなサイズおよび性能の VM のノード プールが作成されます。 たとえば、大きな CPU またはメモリのノードが含まれるノード プール、または GPU をサポートするノード プールが作成されます。 次の手順では、taints と tolerations を使用して、Kubernetes スケジューラにこれらのノードで実行されるポッドに対するアクセスを制限する方法を通知します。

次の例では、Standard_NC6 の VM サイズを使用する GPU ベースのノード プールを作成します。 これらの VM は NVIDIA Tesla K80 カードを搭載しています。 使用可能な VM サイズの詳細については、「Azure での Linux VM のサイズ」を参照してください。

再度 az aks node pool add コマンドを使用して、ノード プールを作成します。 今回は、次のように gpunodepool を名前として指定し、Standard_NC6 サイズを --node-vm-size パラメーターを使用して指定します。

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name gpunodepool \
    --node-count 1 \
    --node-vm-size Standard_NC6 \
    --no-wait

az aks node pool list コマンドの次の出力例では、gpunodepool によって指定した VmSize を使用してノードが Creating されていることを示しています。

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 1,
    ...
    "name": "gpunodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "vmSize": "Standard_NC6",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

gpunodepool が正常に作成されるには、数分かかります。

テイント、ラベル、またはタグをノード プールに指定する

ノード プールを作成するときに、テイント、ラベル、タグをそのノード プールに追加できます。 テイント、ラベル、タグを追加すると、そのノード プール内のすべてのノードもそのテイント、ラベル、タグを取得します。

重要

ノードへの テイント、ラベル、タグの追加は、az aks nodepool を使用してノードプール全体に対して行う必要があります。 kubectl を使用して、テイント、ラベル、またはタグをノード プール内の個々のノードに適用することはお勧めしません。

ノード プールのテイントの設定

テイントが指定されたノード プールを作成するには、az aks nodepool add を使用します。 名前 taintnp を指定し、--node-taints パラメーターを使用してテイントに sku=gpu:NoSchedule を指定します。

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-count 1 \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

az aks nodepool list コマンドからの次の出力例では、taintnp によって、指定した nodeTaints でノードが "作成されている" ことが示されています。

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 1,
    ...
    "name": "taintnp",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "nodeTaints":  [
      "sku=gpu:NoSchedule"
    ],
    ...
  },
 ...
]

テイントの情報は、ノードのスケジューリング規則を処理するために Kubernetes に表示されます。 Kubernetes スケジューラでは、テイントと容認を使用して、ノードで実行できるワークロードを制限できます。

  • テイントは、ノードに適用されて、特定のポッドのみをそのノードでスケジュールできることを示します。
  • 容認は、ポッドに適用されて、ポッドがノードのテイントを "許容する" ことを許可します。

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

前の手順では、ノード プールの作成時に sku=gpu:NoSchedule テイントを適用しました。 次の YAML マニフェストの基本例では、Kubernetes スケジューラがそのノードプール内のノードで NGINX ポッドを実行できるように toleration を使用しています。

nginx-toleration.yaml という名前のファイルを作成し、次の例の YAML にコピーします。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine
    name: mypod
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 1
        memory: 2G
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

kubectl apply -f nginx-toleration.yaml コマンドを使用してポッドをスケジュールします。

kubectl apply -f nginx-toleration.yaml

ポッドのスケジュールおよび NGINX イメージのプルには、数秒かかります。 kubectl describe pod コマンドを使用して、ポッドの状態を参照します。 次の縮約された出力例では、sku = gpu:NoSchedule toleration を適用しています。 イベント セクションで、スケジューラによってポッドが aks-taintnp-28993262-vmss000000 ノードに割り当てられています。

kubectl describe pod mypod
[...]
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
                 sku=gpu:NoSchedule
Events:
  Type    Reason     Age    From                Message
  ----    ------     ----   ----                -------
  Normal  Scheduled  4m48s  default-scheduler   Successfully assigned default/mypod to aks-taintnp-28993262-vmss000000
  Normal  Pulling    4m47s  kubelet             pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Pulled     4m43s  kubelet             Successfully pulled image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Created    4m40s  kubelet             Created container
  Normal  Started    4m40s  kubelet             Started container

taintnp のノードでスケジュールできるのは、この toleration が適用されているポッドのみです。 その他のポッドは、nodepool1 ノード プールにスケジュールされます。 ノード プールを追加作成した場合、追加の taints と tolerations を使用して、それらのノード リソースにどのようなポッドをスケジュールするか制限できます。

ノード プールのラベルの設定

ノード プールでのラベルの使用について詳しくは、「Azure Kubernetes Service (AKS) クラスターでのラベルの使用」を参照してください。

ノード プールの Azure タグの設定

ノードプールでの Azure タグの使用の詳細については、「Azure Kubernetes Service (AKS) での Azure タグの使用」を参照してください。

FIPS 対応ノード プールを追加する

AKS クラスターで連邦情報処理規格 (FIPS) を有効にする方法の詳細については、「Azure Kubernetes Service (AKS) ノード プールの連邦情報処理規格 (FIPS) を有効にする」を参照してください。

Resource Manager テンプレートを使用したノード プールの管理

作成する Azure Resource Manager テンプレートと管理対象リソースを使用する場合、通常、テンプレート内の設定を更新し、再デプロイしてリソースを更新できます。 AKS 内のノード プールでは、AKS クラスターが作成されると、初期ノード プール プロファイルは更新できません。 この動作は、既存の Resource Manager テンプレートの更新、ノード プールへの変更、再デプロイが行えないことを意味します。 代わりに、既存の AKS クラスターのノード プールのみを更新する別の Resource Manager テンプレートを作成する必要があります。

aks-agentpools.json などのテンプレートを作成し、次のマニフェスト例を貼り付けます。 このテンプレートの例は、次の設定を構成します。

  • 3 つのノードを実行するように、myagentpool という Linux ノード プールを更新します。
  • Kubernetes バージョン 1.15.7 を実行するように、ノード プール内のノードを設定します。
  • Standard_DS2_v2 とノード サイズを定義します。

必要に応じてこれらの値を編集し、ノード プールを更新、追加、または削除します。

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "clusterName": {
            "type": "string",
            "metadata": {
                "description": "The name of your existing AKS cluster."
            }
        },
        "location": {
            "type": "string",
            "metadata": {
                "description": "The location of your existing AKS cluster."
            }
        },
        "agentPoolName": {
            "type": "string",
            "defaultValue": "myagentpool",
            "metadata": {
                "description": "The name of the agent pool to create or update."
            }
        },
        "vnetSubnetId": {
            "type": "string",
            "defaultValue": "",
            "metadata": {
                "description": "The Vnet subnet resource ID for your existing AKS cluster."
            }
        }
    },
    "variables": {
        "apiVersion": {
            "aks": "2020-01-01"
        },
        "agentPoolProfiles": {
            "maxPods": 30,
            "osDiskSizeGB": 0,
            "agentCount": 3,
            "agentVmSize": "Standard_DS2_v2",
            "osType": "Linux",
            "vnetSubnetId": "[parameters('vnetSubnetId')]"
        }
    },
    "resources": [
        {
            "apiVersion": "2020-01-01",
            "type": "Microsoft.ContainerService/managedClusters/agentPools",
            "name": "[concat(parameters('clusterName'),'/', parameters('agentPoolName'))]",
            "location": "[parameters('location')]",
            "properties": {
                "maxPods": "[variables('agentPoolProfiles').maxPods]",
                "osDiskSizeGB": "[variables('agentPoolProfiles').osDiskSizeGB]",
                "count": "[variables('agentPoolProfiles').agentCount]",
                "vmSize": "[variables('agentPoolProfiles').agentVmSize]",
                "osType": "[variables('agentPoolProfiles').osType]",
                "storageProfile": "ManagedDisks",
                "type": "VirtualMachineScaleSets",
                "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
                "orchestratorVersion": "1.15.7"
            }
        }
    ]
}

次の例に示すように、az deployment group create コマンドを使用してこのテンプレートをデプロイします。 既存の AKS クラスターの名前と場所を求められます。

az deployment group create \
    --resource-group myResourceGroup \
    --template-file aks-agentpools.json

ヒント

次の例に示すように、テンプレートに tag プロパティを追加することで、ノード プールにタグを追加できます。

...
"resources": [
{
  ...
  "properties": {
    ...
    "tags": {
      "name1": "val1"
    },
    ...
  }
}
...

Resource Manager テンプレートで定義するノード プール設定および操作に応じて、AKS クラスターの更新には数分かかる場合があります。

ノード プールのノードごとにパブリック IP を割り当てる

AKS ノードは、通信用に独自のパブリック IP アドレスを必要としません。 ただし、シナリオでは、ノード プール内のノードが専用のパブリック IP アドレスを受け取ることが必要な場合があります。 一般的なシナリオとしては、ゲームのワークロードがあります。この場合、ホップを最小限に抑えるために、コンソールをクラウド仮想マシンに直接接続する必要があります。 このシナリオは、ノード パブリック IP を使用することにより、AKS で実現することができます。

最初に、新しいリソース グループを作成します。

az group create --name myResourceGroup2 --location eastus

新しい AKS クラスターを作成し、ノードのパブリック IP を接続します。 ノード プール内の各ノードは、一意のパブリック IP を受け取ります。 これを確認するには、仮想マシン スケール セットのインスタンスを参照します。

az aks create -g MyResourceGroup2 -n MyManagedCluster -l eastus  --enable-node-public-ip

既存の AKS クラスターの場合は、新しいノード プールを追加し、ノードのパブリック IP を接続することもできます。

az aks nodepool add -g MyResourceGroup2 --cluster-name MyManagedCluster -n nodepool2 --enable-node-public-ip

パブリック IP プレフィックスを使用する

パブリック IP プレフィックスを使用することには、多くの利点があります。 AKS は、新しいクラスターの作成時またはノード プールの追加時にリソース ID をフラグ node-public-ip-prefix と共に渡すことによって、ノードの既存のパブリック IP プレフィックスからのアドレスの使用をサポートします。

まず、az network public-ip prefix create を使用してパブリック IP プレフィックスを作成します。

az network public-ip prefix create --length 28 --location eastus --name MyPublicIPPrefix --resource-group MyResourceGroup3

出力を表示し、プレフィックスの id を確認します。

{
  ...
  "id": "/subscriptions/<subscription-id>/resourceGroups/myResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix",
  ...
}

最後に、新しいクラスターを作成するとき、または新しいノード プールを追加するときに、フラグ node-public-ip-prefix を使用して、プレフィックスのリソース ID を渡します。

az aks create -g MyResourceGroup3 -n MyManagedCluster -l eastus --enable-node-public-ip --node-public-ip-prefix /subscriptions/<subscription-id>/resourcegroups/MyResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix

ノードのパブリック IP を検索する

ノードのパブリック IP は、さまざまな方法で見つけることができます。

重要

ノード リソース グループには、ノードとそのパブリック IP が含まれています。 ノードのパブリック IP を検索するコマンドを実行するときは、ノード リソース グループを使用します。

az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName

リソースをクリーンアップする

この記事では、GPU ベースのノードを含む AKS クラスターを作成しました。 不要なコストを減らすには、gpunodepool、または AKS クラスター全体を削除してください。

GPU ベースのノード プールを削除するには、次の例のように az aks nodepool delete コマンドを使用します。

az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name gpunodepool

クラスター自体を削除するには、az group delete コマンドを使用して AKS リソース グループを削除します。

az group delete --name myResourceGroup --yes --no-wait

また、ノード プールのパブリック IP のシナリオで作成した追加のクラスターを削除することもできます。

az group delete --name myResourceGroup2 --yes --no-wait

次のステップ