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

Anthos clusters on VMware（GKE On-Prem）バージョン 1.3 以降では、クラスタの構成ファイルでノードプールを定義することで、すべて同じ構成を持つノードグループをユーザー クラスタ内に作成できます。これにより、クラスタ内の他のノードに影響を与えることなく、そのノードプールを個別に管理できるようになります。ノードプールの詳細を理解する。

1 つ以上のノードプールを任意のユーザー クラスタの構成ファイルで定義できます。ノードプールを作成すると、ユーザー クラスタにノードが追加で作成されます。ユーザー クラスタ内のノードプールの作成、更新、削除などのノードプール管理は、構成ファイルの nodePools セクションを変更し、その変更を gkectl update cluster コマンドで既存のクラスタにデプロイして行います。ノードプールを削除すると、ノードがワークロードを実行しているかどうかにかかわらず、関連するノードは直ちに削除されます。

ノードプールの例:

nodePools:
  - name: pool-1
    cpus: 4
    memoryMB: 8192
    replicas: 5

新規インストールのヒント: 最初のユーザー クラスタを作成し、そのクラスタ内にノードプールを定義します。次に、そのクラスタの構成ファイルを使用して、同じノードプール設定で追加のユーザー クラスタを作成します。

始める前に

  • サポート:

    • バージョン 1.3.0 以降のユーザー クラスタのみがサポートされます。

    • 管理クラスタ内のノードプールはサポートされていません。

    • 現在、gkectl update cluster コマンドはノードプールの更新と静的 IP の追加をサポートしています。また、Cloud Audit Logging の有効化と自動修復の有効化 / 無効化もサポートされます。構成ファイルにある他の変更はすべて無視されます。

    • ノードプール内のノードは他のノードとは別に管理できますが、クラスタのノードは個別にアップグレードできません。クラスタをアップグレードすると、すべてのノードがアップグレードされます。

  • 参考情報:

    • ノードのワークロードを中断することなく、変更のみをノードプール replicas にデプロイできます。

      重要: 他のノードプール構成の変更をデプロイすると、ノードプール内のノードが再作成されます。各ノードプールが、中断されてはいけないワークロードの実行中でないことを確認する必要があります。

    • ノードプールの変更をデプロイすると、必要なノードが作成または更新された後、不要なノードが削除されます。このポリシーの影響として、更新前と更新後のノードの総数が同じ場合でも、更新時により多くのリソース（IP アドレスなど）が必要になる可能性があります。

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

ノードプールの作成と更新

ノードプールを管理するには、ユーザー クラスタの構成ファイルを変更してデプロイします。ユーザー クラスタに 1 つ以上のノードプールを作成してデプロイできます。

ノードプールを作成または更新するには:

  1. エディタで、ノードプールを作成または更新するユーザー クラスタの構成ファイルを開きます。

  2. ユーザー クラスタ構成ファイルの nodePools セクションで 1 つ以上のノードプールを定義します。

    1. 最低限必要なノードプール属性を構成します。各ノードプールに次の属性を指定する必要があります。

      • nodePools.name: ノードプールの一意の名前を指定します。この属性を更新すると、ノードが再作成されます。例: - name: pool-1

      • nodePools.cpus: プール内の各ワーカーノードに割り当てられる CPU 数を指定します。この属性を更新すると、ノードが再作成されます。例: cpus: 4

      • nodePools.memoryMB: ユーザー クラスタの各ワーカーノードに割り当てられるメモリ量（メガバイト単位）を指定します。この属性を更新すると、ノードが再作成されます。例: memoryMB: 8192

      • nodePools.replicas: プール内のワーカーノードの合計数を指定します。ユーザー クラスタは、すべてのプールのノードを使用してワークロードを実行します。この属性は、ノードや実行中のワークロードに影響を与えることなく更新できます。例: replicas: 5

      ただし、一部の nodePools 属性は、古い構成ファイルの workernode（DHCP | 静的 IP）と同じですが、workernode セクションは、すべてのユーザー クラスタの古い構成ファイルに必要です。workernode セクションを削除する、または nodepools に置き換えることはできません。新しいユーザー クラスタの構成ファイルには、workernode セクションがなくなりました。ユーザー クラスタに対して少なくとも 1 つのノードプールを定義し、古い構成ファイル中に、デフォルトの workernode プールに代わる十分な数の無垢なノードがあることを確認する必要があります。

      例:

      nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 5

      複数のノードプールを含むユーザー クラスタ構成ファイルの例については、例をご覧ください。

    2. オプションのノードプール属性を構成します。ノードプール構成にラベルと taint を追加して、ノード ワークロードを実行できます。ノードプールで使用される vSphere Datastore を定義することもできます。

      • nodePools.labels: 1 つ以上の key : value ペアを指定して、ノードプールを一意に識別します。key と value は文字または数字で始まり、それぞれ最大 63 文字の文字、数字、ハイフン、ドット、アンダースコアを使用できます。

        構成の詳細については、ラベルをご覧ください。

        重要: Anthos clusters on VMware で使用するために予約されているキー（kubernetes.io、k8s.io、googleapis.com）は、ラベルに指定できません。

        例:

        labels:
  key1: value1
  key2: value2

      • nodePools.taints: ノードプールの taints を定義する key、value、effect を指定します。この taints は、Pod 用に構成した tolerations に対応しています。

        key は必須ですが、value は省略できます。どちらも文字または数字で始まる必要があり、文字、数字、ハイフン、ドット、アンダースコアを含めることができます。文字数は 253 文字以下である必要があります。必要に応じて、key の前に DNS サブドメインを付け、その後に / を付けることができます。例: example.com/my-app

        effect の有効な値は NoSchedule、PreferNoSchedule または NoExecute です。

        構成の詳細については、taint をご覧ください。

        例:

        taints:
  - key: key1
    value: value1
    effect: NoSchedule

      • nodePools.bootDiskSizeGB: プール内の各ワーカーノードに割り当てられるブートディスクのサイズ（ギガバイト単位）を指定します。この構成は、Anthos clusters on VMware バージョン 1.5.0 以降で利用できます。

        例:

        bootDiskSizeGB: 40

      • nodePools.vsphere.datastore: プール内の各ノードを作成する vSphere データストアを指定します。これにより、ユーザー クラスタのデフォルトの vSphere Datastore がオーバーライドされます。

        例:

        vsphere:
  datastore: datastore_name

    複数のノードプールを使用した構成の例については、例をご覧ください。

  3. gkectl update cluster コマンドを使用して、変更をユーザー クラスタにデプロイします。

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    ここで
    • [ADMIN_CLUSTER_KUBECONFIG]: 管理クラスタの kubeconfig ファイルを指定します。
    • [USER_CLUSTER_CONFIG_FILE]: ユーザー クラスタの configuration ファイルを指定します。
    • --dry-run: オプション フラグ。変更のみを表示するには、このフラグを追加します。ユーザー クラスタに変更はデプロイされません。
    • --yes: オプション フラグ。コマンドをサイレント モードで実行するには、このフラグを追加します。続行することを確認するプロンプトが無効になります。

    コマンドを途中で中止した場合は、同じコマンドをもう一度実行して操作を完了し、変更をユーザー クラスタにデプロイできます。

    変更を元に戻す必要がある場合は、構成ファイルの変更を元に戻し、ユーザー クラスタにそれらの変更を再デプロイします。

  4. すべてのノードを確認して、変更が完了したことを確認します。次のコマンドを実行して、ユーザー クラスタ内のすべてのノードを一覧表示します。

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide

    ここで、[USER_CLUSTER_KUBECONFIG] は、ユーザー クラスタの kubeconfig ファイルです。

ノードプールを削除する

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

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

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

  3. gkectl update cluster コマンドを実行して変更をデプロイします。

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    ここで
    • [ADMIN_CLUSTER_KUBECONFIG]: 管理クラスタの kubeconfig ファイルを指定します。
    • [USER_CLUSTER_CONFIG_FILE]: ユーザー クラスタの configuration ファイルを指定します。
    • --dry-run: オプション フラグ。変更のみを表示するには、このフラグを追加します。ユーザー クラスタに変更はデプロイされません。
    • --yes: オプション フラグ。コマンドをサイレント モードで実行するには、このフラグを追加します。続行することを確認するプロンプトが無効になります。

  4. すべてのノードを確認して、変更が完了したことを確認します。次のコマンドを実行して、ユーザー クラスタ内のすべてのノードを一覧表示します。

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide

    ここで、[USER_CLUSTER_KUBECONFIG] は、ユーザー クラスタの kubeconfig ファイルです。

例

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

  • pool-1: 必要最小限の属性のみが指定されています
  • pool-2: vSphere Datastore が含まれています
  • pool-3: bootDiskSizeGB が含まれています
  • pool-4: taint とラベルが含まれています
  • pool-5: すべての属性が含まれています
apiVersion: v1
kind: UserCluster
...
# (Required) List of node pools. The total un-tainted replicas across all node pools
# must be greater than or equal to 3
nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 5
- name: pool-2
  cpus: 8
  memoryMB: 16384
  replicas: 3
  vsphere:
    datastore: my_datastore
- name: pool-3
  cpus: 8
  memoryMB: 8192
  replicas: 3
  bootDiskSizeGB: 40
- name: pool-4
  cpus: 4
  memoryMB: 8192
  replicas: 5
  taints:
    - key: "example-key"
      effect: NoSchedule
  labels:
    environment: production
    app: nginx
- name: pool-5
  cpus: 8
  memoryMB: 16384
  replicas: 3
  taints:
    - key: "my_key"
      value: my_value1
      effect: NoExecute
  labels:
    environment: test
  vsphere:
    datastore: my_datastore
  bootDiskSizeGB: 60
...

トラブルシューティング

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

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

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

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

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

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