ユーザー クラスタを作成する場合は、少なくとも 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 の [クラスタ] ページに移動します。
ユーザー クラスタが存在するクラウド プロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[
ノードプールを追加] をクリックします。ノードプールを構成します。
- [ノードプール名] を入力します。
- プール内の各ノードの vCPU の数(ユーザー クラスタ ワーカーあたりの最小値は 4)を入力します。
- プール内の各ノードのメモリサイズをメガバイト(MiB)単位で入力します(ユーザー クラスタのワーカーノードあたり最小 8192 MiB、4 の倍数でなければなりません)。
- [ノード] フィールドにプール内のノードの数(3 以上)を入力します。
OS イメージタイプ([Ubuntu Containerd]、[Ubuntu]、または [COS])を選択します。
[ブートディスク サイズ] をギガバイト(GiB)で入力します(デフォルトは 40 GiB)。
[ノードプールのメタデータ(省略可) セクションで、Kubernetes ラベルおよび taint を追加する場合、次の操作を行います。
- [+ Add Kubernetes Labels] をクリックします。ラベルの [キー] と [値] を入力します。以上の手順を必要なだけ繰り返してください。
- [+ 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
次のコマンドを実行します。
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 の [クラスタ] ページに移動します。
ユーザー クラスタが存在するクラウド プロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[ノード] タブをクリックします。
変更するノードプールの名前をクリックします。
変更するフィールドの横にある
[編集] をクリックし、[完了] をクリックします。をクリックして前のページに戻ります。
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 の [クラスタ] ページに移動します。
ユーザー クラスタが存在するクラウド プロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[ノード] タブをクリックします。
表示するノードプールの名前をクリックします。
コマンドライン
次のコマンドを実行します。
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes -o wide
変更を元に戻す必要がある場合は、クラスタ構成ファイルを編集して gkectl update cluster
を実行します。
ノードプールの削除
ノードプールは削除できますが、ユーザー クラスタには少なくとも 1 つのノードプールが必要です。ノードプールを削除すると、ノードがワークロードを実行しているかどうかにかかわらず、プールのノードが直ちに削除されます。
ユーザー クラスタからノードプールを削除するには:
Console
影響を受けるノードで実行中のワークロードがないことを確認します。
Google Cloud コンソールで、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…
から続行されません。ユーザー クラスタ内のノードプールの作成または更新には、時間がかかることがあります。ただし、待機時間が著しく長く、なんらかの障害が発生したと思われる場合は、次のコマンドを実行できます。
kubectl get nodes
を実行してノードの状態を取得します。- 準備ができていないノードについては、
kubectl describe node NODE_NAME
を実行して詳細を取得します。