ユーザー クラスタでは、クラスタの構成ファイルで 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 --output wide
変更を元に戻す必要がある場合は、クラスタ構成ファイルを編集して gkectl update cluster
を実行します。
ノードプールを削除する
ユーザー クラスタからノードプールを削除するには:
ユーザー クラスタの構成ファイルの
nodePools
セクションからその定義を削除します。影響を受けるノードで実行中のワークロードがないことを確認します。
クラスタを更新します。
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…
から続行されません。ユーザー クラスタ内のノードプールの作成または更新には、時間がかかることがあります。ただし、待機時間が著しく長く、なんらかの障害が発生したと思われる場合は、次のコマンドを実行できます。
kubectl get nodes
を実行してノードの状態を取得します。- 準備ができていないノードについては、
kubectl describe node NODE_NAME
を実行して詳細を取得します。