ユーザー クラスタのサイズ変更

このページでは、GKE On-Prem ユーザー クラスタのサイズを変更する方法について説明します。ユーザー クラスタのサイズ変更とは、そのクラスタからノードを追加または削除することです。クラスタからノードを削除すると、そのクラスタの IP アドレスが解放され、他のノードで使用できるようになります。ノードを追加するには、そのノードで IP アドレスを使用できるようにする必要があります。

構成ファイルの nodePools セクションの replicas フィールドを変更し、gkectl update cluster コマンドを使用して既存のクラスタに変更をデプロイすることで、ユーザー クラスタのサイズを変更します。

ユーザー クラスタの上限と下限については、割り当てと上限をご覧ください。

gkectl update cluster を使用してノードプールを管理する方法については、ノードプールの作成と管理をご覧ください。

十分な IP アドレスが使用可能であることを確認する

クラスタにノードを追加する場合は、クラスタに十分な IP アドレスがあることを確認してください。十分な IP アドレスがあるかを確認する方法は、クラスタが DHCP サーバーと静的 IP のどちらを使用しているかによって異なります。

DHCP

クラスタが DHCP を使用している場合、ノードを作成するネットワーク内の DHCP サーバーに十分な IP アドレスがあることを確認します。ユーザー クラスタで実行されるノードよりも多くの IP アドレスが必要です。

静的 IP

クラスタで静的 IP が使用されている場合は、まず gkectl update cluster を実行して、そのクラスタに十分な IP アドレスが割り振られていることを確認します。そうしない場合は、更新オペレーションに必要な追加 IP アドレスの数は、エラー メッセージで確認できます。

ユーザー クラスタに IP アドレスを追加する必要がある場合は、次の手順を行います。

  1. hostconfig ファイルを編集用に開きます。

  2. ユーザー クラスタ用に予約されたアドレスを表示するには:

    kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] 
    
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

ここで

  • [ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig を使用するよう kubectl に指示します。これは、ユーザー クラスタ構成の表示や変更に使用されます。
  • -n [USER_CLUSTER_NAME] は、ユーザー クラスタに基づいて名付けられた Namespace を検索するよう kubectl に指示します。
  • [USER_CLUSTER_NAME] -o yaml は、どのユーザー クラスタに対してコマンドを実行するか kubectl に指示します。-o yaml は、ユーザー クラスタの構成を表示します。

  1. ユーザー クラスタ用に予約されているアドレスのいずれかが hostconfig ファイルに含まれている場合は、netmask と gateway に基づいて、それらを対応するブロックに追加します。

  2. 対応するブロックに静的 IP アドレスを必要な数だけ追加し、gkectl update cluster を実行します。

4 つの静的 IP ブロックがハイライト表示された hostconfig ファイル フィールドの例を、次に示します。

hostconfig:
  dns: 172.16.255.1
  tod: 216.239.35.0
blocks:
- netmask: 255.255.248.0
  gateway: 21.0.135.254
  ips:
    - ip: 21.0.133.41
      hostname: user-node-1
    - ip: 21.0.133.50
      hostname: user-node-2
    - ip: 21.0.133.56
      hostname: user-node-3
    - ip: 21.0.133.47
      hostname: user-node-4

ユーザー クラスタのサイズ変更

1.5.0 以降、クラスタのサイズを変更するには、構成ファイルの nodePools セクションにある replicas フィールドを変更し、gkectl update cluster コマンドを使用して、既存のクラスタに変更をデプロイます。

サイズ変更を確認する

サイズ変更が完了したことを確認するには、次のコマンドを実行します。

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] describe machinedeployments [NODE_POOL_NAME] | grep Replicas

ここで、[USER_CLUSTER_KUBECONFIG] は、ユーザー クラスタの kubeconfig ファイルです。選択したノードの数が、これらのコマンド出力に反映されています。

トラブルシューティング

詳しくは、トラブルシューティングを参照してください。

ユーザー クラスタのサイズ変更に失敗する

現象

ユーザー クラスタのサイズ変更操作が失敗します。

考えられる原因

サイズ変更操作が失敗する原因はいくつかあります。

解決策

サイズ変更が失敗する場合は、次の手順に従います。

  1. クラスタの MachineDeployment ステータスをチェックして、イベントやエラー メッセージがあるかどうかを確認します。

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

  2. 新しく作成したマシンにエラーがあるかどうかを確認します。

    kubectl describe machine [MACHINE_NAME]

エラー: 「アドレスを割り振ることができません」

現象

ユーザー クラスタのサイズを変更すると、kubectl describe machine [MACHINE_NAME] が次のエラーを表示します。

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
考えられる原因

ユーザー クラスタで使用可能な IP アドレスが不足しています。

解決策

クラスタに追加の IP アドレスを割り振ります。次に、影響を受けたマシンを削除します。

kubectl delete machine [MACHINE_NAME]

クラスタが正しく構成されている場合は、IP アドレスを使用して代替マシンが作成されます。

十分な数の IP アドレスが割り振られているが、クラスタにマシンを登録できない

現象

ネットワークには十分なアドレスが割り振られていますが、ユーザー クラスタへのマシンの登録が失敗します。

考えられる原因

IP が競合している可能性があります。対象の IP が別のマシンまたはロードバランサによって使用されている場合があります。

解決策

登録に失敗するマシンの IP アドレスが使用されていないことを確認します。競合がある場合は、環境内の競合を解消する必要があります。

gkectl を使用してクラスタの問題を診断する

クラスタの問題を特定し、クラスタの情報を Google と共有するために、gkectl diagnose コマンドを使用します。クラスタの問題を診断するをご覧ください。

デフォルトのロギング動作

gkectl と gkeadm では、デフォルトのロギング設定を使用するだけで十分です。

  • デフォルトでは、ログエントリは次のように保存されます。

    • gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカル ディレクトリの logs/gkectl-$(date).log ファイルにシンボリック リンクされます。
    • gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカル ディレクトリの logs/gkeadm-$(date).log です。
  • すべてのログエントリは、ターミナルに出力されていない場合（--alsologtostderr が false の場合）でもログファイルに保存されます。
  • -v5 詳細レベル（デフォルト）は、サポートチームが必要とするログエントリすべてを対象としています。
  • ログファイルには、実行されたコマンドと失敗メッセージも含まれます。

サポートが必要な場合は、サポートチームにログファイルを送信することをおすすめします。

ログファイルにデフォルト以外の場所を指定する

gkectl ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。指定したログファイルは、ローカル ディレクトリにシンボリック リンクされません。

gkeadm ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。

管理クラスタで Cluster API ログを見つける

管理コントロール プレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラのログを調べてデバッグを試すことができます。

  1. kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、grep または同様のツールを使用してエラーを検索します。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

更新コマンドの失敗

gkectl update を実行してクラスタを更新すると、次のエラー メッセージが表示されることがあります。 
Failed to update the cluster: failed to begin updating user cluster "CLUSTER_NAME": timed out waiting for the condition
このエラー メッセージをさらに調査するには、次のコマンドを実行します。 
kubectl get --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] onpremusercluster
次の出力が表示され、更新が有効になると、エラー メッセージは無視できます。 
cluster [CLUSTER_NAME] is READY=true