バージョン 1.3このバージョンは、Anthos バージョンサポートポリシーに記載のとおり、サポートを終了しています。Anthos clusters on VMware (GKE on-prem) に影響するセキュリティの脆弱性、露出、問題に対する最新のパッチとアップデートを適用するには、サポート対象のバージョンにアップグレードしてください。最新バージョンはこちらで確認できます。

利用可能なバージョン

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

GKE On-Prem バージョン 1.3 以降では、ノードプールを作成し、ユーザークラスタ内とユーザークラスタ間ですべてが同じ構成を持つノードのグループを定義できます。これにより、各クラスタ内の他のノードに影響を与えることなく、そのノードプールを個別に管理できるようになります。ノードプールの詳細についてご確認ください。

1 つ以上のノードプールをユーザークラスタの構成ファイルで定義できます。ノードプールを作成すると、各クラスタに追加のノードが作成されます。ノードプールの作成、更新、削除を含め、ノードプールの管理は、ユーザークラスタの構成ファイルを通じて行います。構成ファイルでノードプールを定義したら、gkectl update cluster コマンドを使用して変更をクラスタにデプロイします。デプロイした変更は、各ユーザークラスタにすぐに反映されます。たとえば、クラスタからノードプールを削除すると、そのノードがワークロードを実行しているかどうかにかかわらず、それらのノードは直ちに削除されます。

ノードプールの例:

nodepools:
  - name: pool-1
    cpus: 4
    memorymb: 8192
    replicas: 5

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

始める前に

サポート:
- バージョン 1.3.0 以降のユーザークラスタのみがサポートされます。
- 管理クラスタ内のノードプールはサポートされていません。
- 現在、gkectl update cluster コマンドはノードプール管理のみをサポートしています。構成ファイルにある他の変更はすべて無視されます。
- ノードプール内のノードは各ユーザークラスタ内の他のノードとは別に管理できますが、クラスタのノードは個別にアップグレードできません。クラスタをアップグレードすると、すべてのノードがアップグレードされます。
参考情報:
- ノードのワークロードを中断することなく、変更のみをノードプール replicas にデプロイできます。
  
  重要: 他のノードプール構成の変更をデプロイすると、ノードプール内のノードが再作成されます。各ノードプールが、中断されてはいけないワークロードの実行中でないことを確認する必要があります。
- ノードプールの変更をデプロイすると、一時的なノードが作成されることがあります。この一時的なノードで IP アドレスが使用可能であることを確認する必要があります。

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

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

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

エディタで、ノードプールを作成または更新するユーザークラスタの構成ファイルを開きます。
構成ファイルの usercluster の下にある nodepools セクションで、1 つ以上のノードプールを定義します。
1. 最低限必要なノードプール属性を構成します。各ノードプールに次の属性を指定する必要があります。
  - usercluster.nodepools.name: ノードプールの一意の名前を指定します。この属性を更新すると、ノードが再作成されます。例: name: pool-1
  - usercluster.nodepools.cpus: ユーザークラスタの各ワーカーノードに割り当てる CPU の数を指定します。この属性を更新すると、ノードが再作成されます。例: cpus: 4
  - usercluster.nodepools.memorymb: ユーザークラスタの各ワーカーノードに割り当てられるメモリ量（メガバイト単位）を指定します。この属性を更新すると、ノードが再作成されます。例: memorymb: 8192
  - usercluster.nodepools.replicas: ユーザークラスタがワークロードの実行に使用するワーカーノードの合計数を指定します。この属性は、ノードや実行中のワークロードに影響を与えることなく更新できます。例: replicas: 5
  一部の nodepools 属性は、workernode（DHCP | 静的 IP）と同じですが、workernode セクションはすべてのユーザークラスタに必要です。workernode を削除することや、nodepools に置き換えることはできません。
  
  例:
```
nodepools:
  - name: pool-1
    cpus: 4
    memorymb: 8192
    replicas: 5
```
  複数のノードプールを使用した構成の例については、例をご覧ください。
2. オプションのノードプール属性を構成します。ノードプール構成にラベルと taint を追加して、ノードワークロードを実行できます。ノードプールで使用される vSphere Datastore を定義することもできます。
  - usercluster.nodepools.labels: 1 つ以上の key : value ペアを指定して、ノードプールを一意に識別します。key と value は文字または数字で始まり、それぞれ最大 63 文字の文字、数字、ハイフン、ドット、アンダースコアを使用できます。
    
    構成の詳細については、ラベルをご覧ください。
    
    重要: GKE On-Prem で使用するために予約されているキー（kubernetes.io、k8s.io、googleapis.com）はラベルに指定できません。
    
    例:
```
labels:
  key1: value1
  key2: value2
```
  - usercluster.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
```
  - usercluster.nodepools.vsphere.datastore: ノードプールで使用する vSphere Datastore を指定します。これにより、ユーザークラスタのデフォルトの vSphere Datastore がオーバーライドされます。
    
    例:
```
vsphere:
  datastore: datastore_name
```
複数のノードプールを使用した構成の例については、例をご覧ください。
gkectl update cluster コマンドを使用して、変更をユーザークラスタにデプロイします。

注: gkectl update cluster はノードプール管理のみをサポートします。nodepools セクションの変更のみがデプロイされます。構成ファイル内の他の変更はすべて無視されます。
```
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config config.yaml --dry-run --yes
```
ここで
- [ADMIN_CLUSTER_KUBECONFIG]: 管理クラスタの kubeconfig ファイルを指定します。
- config.yaml: ユーザークラスタの編集済み configuration file を指定します。このファイルに別の名前を付けている可能性があります。
- --dry-run: オプションフラグ。変更のみを表示するには、このフラグを追加します。ユーザークラスタに変更はデプロイされません。
- --yes: オプションフラグ。コマンドをサイレントモードで実行するには、このフラグを追加します。続行することを確認するプロンプトが無効になります。
コマンドを途中で中止した場合は、同じコマンドをもう一度実行して操作を完了し、変更をユーザークラスタにデプロイできます。

変更を元に戻す必要がある場合は、構成ファイルの変更を元に戻し、ユーザークラスタにそれらの変更を再デプロイします。
すべてのノードを確認して、変更が完了したことを確認します。次のコマンドを実行して、ユーザークラスタ内のすべてのノードを一覧表示します。
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
```
ここで、[USER_CLUSTER_KUBECONFIG] は、ユーザークラスタの kubeconfig ファイルです。

ノードプールの削除

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

ユーザークラスタの構成ファイルからすべての nodepools 設定を削除します。複数のノードプールがある場合は、すべての設定を削除する必要があります。
実行中のワークロードがないことを確認します。影響を受けるすべてのノードが削除されます。
gkectl update cluster コマンドを実行して変更をデプロイします。
```
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config config.yaml --dry-run --yes
```
ここで
- [ADMIN_CLUSTER_KUBECONFIG]: 管理クラスタの kubeconfig ファイルを指定します。
- config.yaml: ユーザークラスタの編集済み configuration file を指定します。このファイルに別の名前を付けている可能性があります。
- --dry-run: オプションフラグ。変更のみを表示するには、このフラグを追加します。ユーザークラスタに変更はデプロイされません。
- --yes: オプションフラグ。コマンドをサイレントモードで実行するには、このフラグを追加します。続行することを確認するプロンプトが無効になります。
すべてのノードを確認して、変更が完了したことを確認します。次のコマンドを実行して、ユーザークラスタ内のすべてのノードを一覧表示します。
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
```
ここで、[USER_CLUSTER_KUBECONFIG] は、ユーザークラスタの kubeconfig ファイルです。

例

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

pool-1: 必要最小限の属性のみが指定されています
pool-2: vSphere Datastore が含まれています
pool-3: taint とラベルが含まれています
pool-4: すべての属性が含まれています

...
usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3
  # (Optional) Node pools with customizable labels, taints, etc.
  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: 4
      memorymb: 8192
      replicas: 5
      taints:
        - key: "example-key"
          effect: NoSchedule
      labels:
        environment: production
        app: nginx
    - name: pool-4
      cpus: 8
      memorymb: 16384
      replicas: 3
      taints:
        - key: "my_key"
          value: my_value1
          effect: NoExecute
      labels:
        environment: test
      vsphere:
        datastore: my_datastore
...

ユーザークラスタ構成ファイルの全体の例を確認します。

トラブルシューティング

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

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