異なる仮想マシン タイプのノード プールの管理

このトピックでは、ワークロード クラスタでノード プールを作成、更新、および削除する方法について説明します。ノード プールを使用すると、単一のワークロード クラスタにさまざまなタイプのノードを含めて管理し、異なるアプリケーションのさまざまなニーズをサポートできます。

たとえば、クラスタはストレージ容量の大きいノードを使用してデータストアを実行し、ストレージ容量の小さいノードを使用してアプリケーション要求を処理できます。

注

単一ノード クラスタにノード プールを作成することはできません。
vSphere with Tanzu によって作成されたワークロード クラスタでノード プールを作成して使用するには、v7.0 U3 以降の vSphere を実行している必要があります。
vSphere with Tanzu を使用する場合、vSphere with Tanzu クラスタは v1alpha2 API を使用して node-pool コマンドを正常に実行する必要があります。詳細については、vSphere with Tanzu ドキュメントを参照してください。

ノード プールについて

ノード プールは、ワークロード クラスタで使用されるワーカー ノードのセットのプロパティを定義します。

一部のノード プール プロパティは基盤となるインフラストラクチャで使用可能な仮想マシン オプションに依存しますが、すべてのクラウド インフラストラクチャのすべてのノード プールは次のプロパティを共有します。

  • name：更新や削除などの操作に使用されるノード プールの一意の識別子。
  • replicas：プール内のノードの数。すべて同じプロパティを共有します。
  • labels：ノード上でメタデータとして設定されたキー/値ペア。ワークロードをプール内のノードと一致させます。詳細について、およびラベルの例については、Kubernetes ドキュメントの「ラベルとセレクタ」を参照してください。

vSphere 上のワークロード クラスタの場合、スタンドアローン管理クラスタはデフォルトで非アフィニティ ルールに従って、ノード プール ワーカーと制御プレーン ノードを異なる ESXi ホストに展開します。ノード配置の非アフィニティ ルールを無効にするには、「非アフィニティ ルールの無効化」を参照してください。

すべてのワークロード クラスタは最初の元のノード プールを使用して作成されます。以下で説明するようにクラスタに追加のノード プールを作成する場合、最初のノード プールは新しいノード プール定義で設定されていないプロパティのデフォルト値を提供します。

ノード プールの一覧表示

クラスタで現在使用可能なノード プールを調べるには、以下を実行します。

tanzu cluster node-pool list CLUSTER-NAME

このコマンドで、クラスタ内のすべてのノード プールのリストと、各ノード プール内のレプリカの状態が返されます。

ノード プールの作成

クラスタにノード プールを作成するには：

  1. ノード プールの構成ファイルを作成します。構成ファイルの例については、「サンプル構成」を参照してください。

    構成プロパティの完全なリストについては、「構成プロパティ」を参照してください。

  2. 構成ファイルで定義されたノード プールを作成します。

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    オプション:

    • --namespace はクラスタの名前空間を指定します。デフォルト値は default です。
    • （レガシー クラスタ）--base-machine-deployment は、新しいノード プールを作成するベースとなる MachineDeployment オブジェクトを指定します。
      • Details の下の tanzu cluster get の出力に一覧表示されているように、この値を MachineDeployment 識別子として設定します。
      • デフォルト値は、クラスタのワーカー ノード MachineDeployment オブジェクトの配列の最初にあり、内部では workerMDs[0] として表されます。

サンプル構成

次に、基盤となるインフラストラクチャの構成例を示します。

vSphere の構成
必須の name、 replicas、および labels プロパティに加え、vSphere のノード プールの構成ファイルに vsphere ブロックを含めて、vSphere 上の仮想マシンの構成に固有の、オプションのプロパティを定義できます。

vSphere クラスタのノード プール定義の例：

    name: tkg-wc-oidc-md-1
    replicas: 4
    labels:
      key1: value1
      key2: value2
    vsphere:
      memoryMiB: 8192
      diskGiB: 64
      numCPUs: 4
      datacenter: dc0
      datastore: iscsi-ds-0
      storagePolicyName: name
      folder: vmFolder
      resourcePool: rp-1
      vcIP: 10.0.0.1
      template: templateName
      cloneMode: clone-mode
      network: network-name

vsphere ブロックで設定されていない値は、クラスタの最初のノード プールの値から継承されます。

vcIP 値の場合、ワークロード クラスタ ノード プールは、クラスタの制御プレーンと同じ vCenter Server で実行する必要があります。

vSphere with Tanzu スーパーバイザーによって展開されたクラスタの場合は、storageClass、tkr、および vmClass を定義します。これらのプロパティの詳細については、vSphere with Tanzu ドキュメントの「TanzuKubernetesCluster v1alpha3 API – 注釈付き」を参照してください。

デフォルトでは、vSphere のワークロード クラスタは、各ノード プール内の制御プレーン ノードとワーカー ノードを複数の ESXi ホストに分散する非アフィニティ ルールに従って展開されます。非アフィニティ ルールを無効または再度有効にするには、以下の「非アフィニティ ルールの無効化 (vSphere)」を参照してください。

AWS 構成
必須の name、 replicas、および labels プロパティに加え、AWS のノード プールの構成ファイルでは、次のオプションのプロパティがサポートされます。
  • az：アベイラビリティ ゾーン
  • nodeMachineType：インスタンス タイプ

これらの設定は省略できます。その場合、値はクラスタの最初のノード プールから継承されます。

AWS クラスタのノード プール定義の例：

name: tkg-aws-wc-np-1
replicas: 2
az: us-west-2b
nodeMachineType: t3.large
labels:
  key1: value1
  key2: value2
注

AWS のワークロード クラスタ ノード プールは、スタンドアローン管理クラスタと同じアベイラビリティ ゾーンにある必要があります。

Azure 構成
前述の、必須の name、 replicas、および labels プロパティに加え、Microsoft Azure のノード プールの構成ファイルでは、次のオプションのプロパティがサポートされます。
  • az：アベイラビリティ ゾーン
  • nodeMachineType：インスタンス タイプ

設定を省略すると、その値はクラスタの最初のノード プールから継承されます。

Azure クラスタのノード プール定義の例：

name: tkg-azure-wc-np-1
replicas: 2
az: 2
nodeMachineType: Standard_D2s_v3
labels:
  key1: value1
  key2: value2

構成プロパティ

次の表に、ワークロード クラスタのノード プール構成ファイルで定義できるすべてのプロパティを示します。

注

既存のノード プールの labels、az、nodeMachineType または vSphere プロパティは、追加したり変更したりすることはできません。これらのプロパティを変更するには、目的のプロパティを使用してクラスタに新しいノード プールを作成し、ワークロードを新しいノード プールに移行して、元のノード プールを削除する必要があります。

名前 タイプ クラスタ オブジェクト プロバイダ メモ
name 文字列 任意 すべて 作成または更新するノード プールの名前。
replicas 整数型 任意 すべて ノード プール内のノード数。
az 文字列 任意 AWS または Azure 上の TKG ノードを配置する AZ。
nodeMachineType 文字列 任意 AWS または Azure 上の TKG AWS および Azure のノードにそれぞれ instanceType または vmSize。
labels map[string]string 任意 すべて kubeletExtraArgs (‐‐node-labels) を使用してノードに設定するラベル。
vmClass 文字列 任意 すべて Kubernetes vmClass の名前。TKC クラスタで定義されている vmClass と一致します。このクラスは、ノードで使用可能な CPU とメモリを設定します。使用可能な仮想マシン クラスを一覧表示するには、kubectl describe virtualmachineclasses を実行します。
storageClass 文字列 任意 すべて ノード プールに使用する Kubernetes StorageClass の名前。このクラスは、ノードのルート ファイルシステムを格納するディスクに適用されます。使用可能なストレージ クラスを一覧表示するには、kubectl describe storageclasses を実行します。
volumes：
  • name、文字列
  • mountPath、文字列
  • capacity、corev1.ResourceList
  • storageClass、文字列
 []object 任意 すべて ノードに使用するボリューム。
tkr：
  • reference、文字列
 オブジェクト TKC ベース すべて ノード プールに使用する TKR の名前。たとえば、v1.26.8---vmware.2-tkg.2 です。
tkrResolver 文字列 クラスベース すべて クラスベースのクラスタに必要です。Cluster リソースからの run.tanzu.vmware.com/resolve-os-image 注釈の値。
nodeDrainTimeout metav1.Duration 任意 すべて ノードのドレイン タイムアウト。
vsphere オブジェクト 任意 すべて 「構成プロパティ（vSphere のみ）」(#vsphere-properties) を参照してください。
workerClass 文字列 クラスベース すべて クラスベースのクラスタに必要です。ノード プールで使用するクラスタの ClusterClass からの workerClass。

構成プロパティ（vSphere のみ）

VSPHERE_* 構成変数の詳細については、「構成ファイル変数リファレンス」の「vSphere」を参照してください。

名前 タイプ 管理クラスタ タイプ メモ
cloneMode 文字列 スタンドアローン VSPHERE_CLONE_MODE と同じです。
datacenter 文字列 スタンドアローン VSPHERE_DATACENTER と同じです。
datastore 文字列 スタンドアローン VSPHERE_DATASTORE と同じです。
storagePolicyName 文字列 スタンドアローン VSPHERE_STORAGE_POLICY_NAME と同じです。
taints []corev1.Taint スーパーバイザー ノードに適用するテイント。
folder 文字列 スタンドアローン VSPHERE_FOLDER と同じです。
network 文字列 スタンドアローン VSPHERE_NETWORK と同じです。
nameservers [] 文字列 スタンドアロン VSPHERE_WORKER_NAMESERVERS と同じです。
tkgIPFamily 文字列 スタンドアローン TKG_IP_FAMILY と同じです。
resourcePool 文字列 スタンドアローン VSPHERE_RESOURCE_POOL と同じです。
vcIP 文字列 スタンドアローン VSPHERE_SERVER と同じです。
template 文字列 スタンドアローン VSPHERE_TEMPLATE と同じです。
memoryMiB 整数型 スタンドアロン VSPHERE_WORKER_MEM_MIB と同じです。
diskGiB 整数型 スタンドアロン VSPHERE_WORKER_DISK_GIB と同じです。
numCPUs 整数型 スタンドアロン VSPHERE_WORKER_NUM_CPUS と同じです。

ノード プールへのワークロードの割り当て

ワークロードをノード プールに割り当てるには、次の手順を実行します。

  1. Kubernetes ワークロード リソースまたはポッドを管理するリソースで、nodeSelector を、ノード プール構成ファイルで定義した labels の値に設定します。Kubernetes ワークロード リソースの詳細については、Kubernetes ドキュメントの「Workloads」を参照してください。
  2. kubectl apply -f コマンドを実行して、構成を適用します。

ワークロードを別のノード プールに再割り当てするには、次の手順を実行します。

  1. Kubernetes ワークロード リソースまたはポッドを管理するリソースで、nodeSelector の値を新しい値に更新します。
  2. kubectl apply -f コマンドを実行して、構成の更新内容を適用します。

ノード プールの更新

ノード プール内のノード数のみを変更する必要がある場合は「ノードのみをスケーリング」の Tanzu CLI コマンドを使用します。ラベルを追加する場合は、「ラベルの追加とノードのスケーリング」の手順に従います。

注意

これらの手順では、ノード プールの既存のラベル、アベイラビリティ ゾーン、ノード インスタンス タイプ（AWS または Azure）、または仮想マシンのプロパティ（vSphere）を変更しないでください。変更すると、実行中のワークロードに深刻な悪影響が及ぶことがあります。これらのプロパティを変更するには、元のプロパティを削除する前に、これらのプロパティを使用して新しいノード プールを作成し、ワークロードを新しいノード プールに再割り当てします。手順については、上記の「ノード プールへのワークロードの割り当て」を参照してください。

ノードのみをスケーリング

ノード プール内のノード数を変更するには、次を実行します。

tanzu cluster scale CLUSTER-NAME -p NODE-POOL-NAME -w NODE-COUNT

ここで、

  • CLUSTER-NAME はワークロード クラスタの名前です。
  • NODE-POOL-NAME はノード プールの名前です。
  • NODE-COUNT は、このノード プールに属するノードの数を整数で表したものです。

ラベルの追加とノードのスケーリング

ノード プールの構成ファイルを使用して、ノード プールにラベルを追加し、そのノードを同時にスケーリングできます。

  1. 更新するノード プールの構成ファイルを開きます。

  2. このノード プール内のノード数を変更する場合は、replicas の後の数値を更新します。

  3. ラベルを追加する場合は、labels の下でインデントします。例：

    labels:
  key1: value1
  key2: value2

  4. ノード プールの構成ファイルを保存します。

  5. ターミナルで、以下を実行します。

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    コマンドの CLUSTER-NAME および構成ファイルの name がクラスタ内のノード プールと一致する場合、このコマンドは新しいノード プールを作成せずに既存のノード プールを更新します。

ノード プールの削除

ノード プールを削除するには、以下を実行します。

tanzu cluster node-pool delete CLUSTER-NAME -n NODE-POOL-NAME

ここで、CLUSTER-NAME はワークロード クラスタの名前で、NODE-POOL-NAME はノード プールの名前です。

必要に応じて、--namespace を使用してクラスタの名前空間を指定します。デフォルト値は default です。

注意

この操作を実行する前に、これらのノードのワークロードを他のノード プールに再割り当てします。tanzu cluster node-pool delete は、ワークロードを削除する前にノードから移行しません。手順については、上記の「ノード プールへのワークロードの割り当て」を参照してください。

非アフィニティ ルールの無効化 (vSphere)

デフォルトでは、vSphere のワークロード クラスタは、各ノード プール内の制御プレーン ノードとワーカー ノードを複数の ESXi ホストに分散する非アフィニティ ルールに従って展開されます。クラスタの作成中に非アフィニティ ルールを無効または再度有効にするには、次の手順を実行します。

  1. kubectl コンテキストを管理クラスタに設定します。

    kubectl config use-context MGMT-CLUSTER-NAME-admin@MGMT-CLUSTER-NAME

    ここで、MGMT-CLUSTER-NAME はクラスタの名前です。

  2. CAPV コントローラで kubectl get deployment を実行して、manager コンテナの args 値を収集します。次に例を示します。

    kubectl get deployment -n capv-system capv-controller-manager -o=json | jq '.spec.template.spec.containers[] | select(.name=="manager") | .args'
[
  "--leader-elect",
  "--logtostderr",
  "--v=4",
  "--feature-gates=NodeAntiAffinity=true,NodeLabeling=true"
]

  3. 前の手順からコピーした出力を使用して、--feature-gates 値を変更し、引数リストをオブジェクト内の値を修正する kubectl patch コマンドに渡します。たとえば、NodeAntiAffinity および NodeLabeling フィーチャー ゲートを false に設定すると、ノードの非アフィニティ ルールが無効になります。

    kubectl patch deployment -n capv-system capv-controller-manager --type=json -p '[{"op":"replace", "path":"/spec/template/spec/containers/0/args", "value": [
"--leader-elect",
"--logtostderr",
"--v=4",
"--feature-gates=NodeAntiAffinity=false,NodeLabeling=false"
]}]'
check-circle-line exclamation-circle-line close-line
Scroll to top icon