ノードプールの作成と管理

Version 1.9 

• Latest version
• Version 1.16
• Earlier versions (unsupported)

ユーザー クラスタでは、クラスタの構成ファイルで nodePools セクションに入力することで、すべて同じ構成を持つノードのグループを作成できます。これにより、クラスタ内の他のノードに影響を与えることなく、ノードプールを管理できます。ノードプールの詳細を理解する。

ノードプールを更新して、別の osImageType を指定することもできます。

始める前に

ノードプールを削除すると、ノードがワークロードを実行しているかどうかにかかわらず、プールのノードが直ちに削除されます。

ワークロードを中断することなく、nodePool セクションの replicas フィールドを更新できます。ただし、他のフィールドを更新すると、プール内のノードが削除され、再作成されます。

ノードプール内のすべての VM にタグを追加する場合は、vCenter ユーザー アカウントに次の vSphere のタグ付け権限が必要です。

• vSphere Tagging.Assign または vSphere タグ付け解除
• vSphere Tagging.Assign またはオブジェクトに対する vSphere タグ付け解除（vSphere 7）

nodePool セクションを更新すると、Anthos clusters on VMware は新しいノードを作成し、古いノードを削除します。古いノードがすべて新しいノードに置き換えられるまで、このプロセスが繰り返されます。つまり、更新時に使用できる追加の IP アドレスがクラスタに必要です。

更新の終了時にノードプールには N 個のノードがあるとします。この場合、そのプール内のノードに使用可能な少なくとも N + 1 個の IP アドレスが必要です。つまり、1 つ以上のプールにノードを追加してクラスタのサイズを変更する場合は、サイズ変更の最後にクラスタのノードプールのすべてに含まれるノードの総数よりすくなくとも 1 つ多い IP アドレスが必要になります。詳細については、十分な IP アドレスが使用可能であることを確認するをご覧ください。

クラスタ構成ファイルの nodePools セクションに入力

ユーザー クラスタの構成ファイルで、nodePools セクションに入力します。

ノードプールごとに、次のフィールドを指定する必要があります。

• nodePools.[i].name
• nodePools[i].cpus
• nodePools.[i].memoryMB
• nodePools.[i].replicas

次のフィールドは省略可能です。

• nodePools[i].labels
• nodePools[i].taints
• nodePools[i].bootDiskSizeGB
• nodePools[i].osImageType
• nodePools[i].vsphere.datastore
• nodePools[i].vsphere.tags

新しいクラスタにノードプールを作成

ユーザー クラスタの構成ファイルの nodePools セクションに入力し、クラスタを作成します。

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

以下を置き換えます。

• ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイル

• USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイル

既存のクラスタのノードプールの更新

ユーザー クラスタの構成ファイルで nodePools セクションを編集し、クラスタを更新します。

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

変更を確認する

ノードプールが想定通りに作成または更新されたことを確認するには、クラスタノードを調べます。

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG get nodes -o wide

変更を元に戻す必要がある場合は、クラスタ構成ファイルを編集して gkectl update cluster を実行します。

ノードプールを削除する

ユーザー クラスタからノードプールを削除するには:

1. ユーザー クラスタの構成ファイルの nodePools セクションからその定義を削除します。

2. 影響を受けるノードで実行中のワークロードがないことを確認します。

3. クラスタを更新します。

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
   

例

次の構成の例では、属性が異なるノードプールが 4 つあります。

• pool-1: 必要最小限の属性のみが指定されています
• （pool-2: vsphere.datastore、vsphere.tags を含む）
• （pool-3: taints、labels を含む）
• （pool-4: osImageType、bootDiskSizeGB を含む）

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 5
- name: pool-2
  cpus: 8
  memoryMB: 16384
  replicas: 3
  vsphere:
    datastore: my_datastore
    tags:
    - category: "purpose"
      name: "testing"
- name: pool-3
  cpus: 4
  memoryMB: 8192
  replicas: 5
  taints:
    - key: "example-key"
      effect: NoSchedule
  labels:
    environment: production
    app: nginx
- name: pool-4
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: cos
  bootDiskSizeGB: 40

ノードプールで使用される osImageType を更新する

別の osImageType を使用するようにノードプールを更新できます。次の例に示すように、ノードプールの構成ファイルを更新し、gkectl update cluster を実行します。

nodePools:
- name: np-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd

トラブルシューティング

• 通常、gkectl update cluster コマンドは失敗した場合に詳細を示します。コマンドが完了し、ノードが表示されない場合は、クラスタの問題の診断ガイドを使用してトラブルシューティングできます。

• ノードプールの作成または更新中に使用可能な IP アドレスが不足しているなど、クラスタのリソースが不足している可能性があります。IP アドレスが使用可能かどうかを確認する方法については、ユーザー クラスタのサイズ変更をご覧ください。

• 一般的なトラブルシューティング ガイドもご覧ください。

• Creating node MachineDeployment(s) in user cluster… から続行されません。

  ユーザー クラスタ内のノードプールの作成または更新には、時間がかかることがあります。ただし、待機時間が著しく長く、なんらかの障害が発生したと思われる場合は、次のコマンドを実行できます。

  1. kubectl get nodes を実行してノードの状態を取得します。
  2. 準備ができていないノードについては、kubectl describe node NODE_NAME を実行して詳細を取得します。