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

ユーザークラスタを作成する場合は、少なくとも 1 つのノードプールを構成する必要があります。ノードプールとはすべて同じ構成を持つノードのグループです。クラスタを作成した後は、新しいノードプールの追加、ノードプールの設定の更新、ノードプールの削除を行えます。

ノードプールの作成、更新、削除の方法は、クラスタが Anthos On-Prem API によって管理されているかどうかによって異なります。次のいずれかに該当する場合は、ユーザークラスタが Anthos On-Prem API によって管理されています。

クラスタは Google Cloud コンソールで作成されたものである。この場合、Anthos On-Prem API がクラスタを管理するように自動的に構成されます。
ユーザークラスタでコマンド gkectl enroll cluster が実行済みである。この場合、Anthos On-Prem API で管理されるように構成されています。

Anthos On-Prem API がユーザークラスタを管理している場合は、Google Cloud コンソールを使用してノードプールを管理できます。ユーザークラスタが Anthos On-Prem API で管理されていない場合は、管理ワークステーションのコマンドラインで gkectl を使用してノードプールを管理します。

ノードプールを追加する

Google Cloud コンソールでクラスタを作成した場合は、Google Cloud コンソールを使用してノードプールを追加できます。ただし、コマンドラインを使用して次のノードプール設定を構成する必要があります。

OS イメージタイプのウィンドウ
vSphere データストア
vSphere タグ。ノードプール内のすべての VM にタグを追加する場合は、vCenter ユーザーアカウントに次の vSphere のタグ付け権限が必要です。
- vSphere Tagging.Assign または vSphere タグ付け解除
- vSphere Tagging.Assign またはオブジェクトに対する vSphere タグ付け解除（vSphere 7）
ノードプールの自動スケーリング

別のノードプールを追加する前に、クラスタで十分な IP アドレスが使用可能であることを確認してください。

Console

Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。

[Anthos クラスタ] ページに移動
ユーザークラスタが存在するクラウドプロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[ノードプールを追加] をクリックします。
ノードプールを構成します。
1. [ノードプール名] を入力します。
2. プール内の各ノードの vCPU の数（ユーザークラスタワーカーあたりの最小値は 4）を入力します。
3. プール内の各ノードのメモリサイズをメガバイト（MiB）単位で入力します（ユーザークラスタのワーカーノードあたり最小 8192 MiB、4 の倍数でなければなりません）。
4. [ノード] フィールドにプール内のノードの数（3 以上）を入力します。
5. OS イメージタイプ（[Ubuntu Containerd]、[Ubuntu]、または [COS]）を選択します。
  
  注: ノードプールの Ubuntu OS イメージタイプは、VMware バージョン 1.12 の Anthos クラスタでは非推奨になり、バージョン 1.13 ではサポートされなくなります。OS イメージタイプに Ubuntu Containerd または COS を使用するように今すぐノードプールを変更することを検討してください。
6. [ブートディスクサイズ] をギガバイト（GiB）で入力します（デフォルトは 40 GiB）。
[ノードプールのメタデータ（省略可） セクションで、Kubernetes ラベルおよび taint を追加する場合、次の操作を行います。
1. [+ Add Kubernetes Labels] をクリックします。ラベルの [キー] と [値] を入力します。以上の手順を必要なだけ繰り返してください。
2. [+ taint を追加] をクリックします。taint の [キー]、[値]、[効果] を入力します。以上の手順を必要なだけ繰り返してください。
[作成] をクリックします。
Google Cloud コンソールに「クラスタのステータス: 変更中」と表示されます。[詳細を表示] をクリックすると、[リソースステータス条件] と [ステータスメッセージ] が表示されます。

コマンドライン

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

次のフィールドを指定する必要があります。
- nodePools.[i].name
- nodePools[i].cpus
- nodePools.[i].memoryMB
- nodePools.[i].replicas
次のフィールドは省略可能です。nodePools[i].bootDiskSizeGB または nodePools[i].osImageType が含まれない場合は、デフォルト値が使用されます。
- nodePools[i].labels
- nodePools[i].taints
- nodePools[i].bootDiskSizeGB
- nodePools[i].osImageType
- nodePools[i].vsphere.datastore
- nodePools[i].vsphere.tags
注: ノードプールの Ubuntu OS イメージタイプは、VMware バージョン 1.12 の Anthos クラスタで非推奨になり、1.13 ではサポートされなくなります。OS イメージタイプに Ubuntu Containerd または COS を使用するように今すぐノードプールを変更することを検討してください。
次のコマンドを実行します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
```
以下を置き換えます。
- [ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスに置き換えます。
- [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

ノードプールの更新

コマンドラインを使用して、ユーザークラスタ構成ファイルの nodePools セクションにあるすべてのフィールドを更新できます。現在、Google Cloud コンソールを使用して更新できるノードプールフィールドは、次のフィールドに限定されています。

レプリカの数
メモリ
vCPU 数

レプリカの数を増やすと、Anthos clusters on VMware によって必要なノードがユーザークラスタに追加され、レプリカの数を減らすとノードが削除されます。ノードプールのレプリカの数を変更しても、ワークロードは中断されません。レプリカの数を増やす場合は、IP アドレスが使用可能であることを確認してください。

他のノードプールフィールドを更新すると、クラスタ上でローリングアップデートがトリガーされます。ローリングアップデートでは、Anthos clusters on VMware によって新しいノードが作成され、古いノードが削除されます。このプロセスは、古いノードがすべて新しいノードに置き換えられるまで繰り返されます。このプロセスではダウンタイムは発生しませんが、クラスタには更新中に使用できる追加の IP アドレスが必要です。

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

ユーザークラスタのノードプールを更新するには:

Console

Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。

[Anthos クラスタ] ページに移動
ユーザークラスタが存在するクラウドプロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[ノード] タブをクリックします。
変更するノードプールの名前をクリックします。
変更するフィールドの横にある [編集] をクリックし、[完了] をクリックします。
をクリックして前のページに戻ります。
Google Cloud コンソールに「クラスタのステータス: 変更中」と表示されます。[詳細を表示] をクリックすると、[リソースステータス条件] と [ステータスメッセージ] が表示されます。

コマンドライン

ユーザークラスタ構成ファイルの nodePools セクションで、変更したいフィールドの値を変更します。
クラスタを更新します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
```
以下を置き換えます。
- [ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスに置き換えます。
- [USER_CLUSTER_CONFIG] は、ユーザークラスタの構成ファイルのパスに置き換えます。

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

別の osImageType を使用するようにノードプールを更新するには、コマンドラインを使用する必要があります。ノードプールで使用される osImageType を変更するには、次の例のようにノードプールの構成ファイルを更新し、gkectl update cluster を実行します。

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

変更を確認する

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

Console

Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。

[Anthos クラスタ] ページに移動
ユーザークラスタが存在するクラウドプロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[ノード] タブをクリックします。
表示するノードプールの名前をクリックします。

コマンドライン

次のコマンドを実行します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes -o wide

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

ノードプールの削除

ノードプールは削除できますが、ユーザークラスタには少なくとも 1 つのノードプールが必要です。ノードプールを削除すると、ノードがワークロードを実行しているかどうかにかかわらず、プールのノードが直ちに削除されます。

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

Console

影響を受けるノードで実行中のワークロードがないことを確認します。
Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。

[Anthos クラスタ] ページに移動
ユーザークラスタが存在するクラウドプロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[ノード] タブをクリックします。
削除するノードプールの名前をクリックします。
[削除] をクリックします。
をクリックして前のページに戻ります。
Google Cloud コンソールに「クラスタのステータス: 変更中」と表示されます。[詳細を表示] をクリックすると、[リソースステータス条件] と [ステータスメッセージ] が表示されます。

コマンドライン

影響を受けるノードで実行中のワークロードがないことを確認します。
ユーザークラスタの構成ファイルの nodePools セクションからその定義を削除します。
クラスタを更新します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
```
以下を置き換えます。
- [ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスに置き換えます。
- [USER_CLUSTER_CONFIG] は、ユーザークラスタの構成ファイルのパスに置き換えます。

トラブルシューティング

通常、gkectl update cluster コマンドは失敗した場合に詳細を示します。コマンドが完了し、ノードが表示されない場合は、クラスタの問題の診断ガイドを使用してトラブルシューティングできます。
ノードプールの作成または更新中に使用可能な IP アドレスが不足しているなど、クラスタのリソースが不足している可能性があります。IP アドレスが使用可能かどうかを確認する方法については、ユーザークラスタのサイズ変更をご覧ください。
一般的なトラブルシューティングガイドもご覧ください。
Creating node MachineDeployment(s) in user cluster… から続行されません。

ユーザークラスタ内のノードプールの作成または更新には、時間がかかることがあります。ただし、待機時間が著しく長く、なんらかの障害が発生したと思われる場合は、次のコマンドを実行できます。
1. kubectl get nodes を実行してノードの状態を取得します。
2. 準備ができていないノードについては、kubectl describe node NODE_NAME を実行して詳細を取得します。

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

ノードプールを追加する

Console

コマンドライン

構成の例

ノードプールの更新

Console

コマンドライン

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

変更を確認する

Console

コマンドライン

ノードプールの削除

Console

コマンドライン

トラブルシューティング

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