以前のバージョンの GKE On-Prem のドキュメントを表示しています。最新のドキュメントをご覧ください

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

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

ユーザー クラスタのサイズを変更するには、クラスタの MachineDeployment 構成の replicas フィールドを変更します。kubectl patch を使用してコマンドラインから構成にパッチを適用できます。

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

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

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

DHCP

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

静的 IP

クラスタで静的 IP が使用されている場合は、そのクラスタに十分な IP アドレスが割り当てられていることを確認します。

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] は、ユーザー クラスタに基づいて名づけられた名前空間を検索するよう kubectl に指示します。
  • [USER_CLUSTER_NAME] -o yaml は、どのユーザー クラスタに対してコマンドを実行するか kubectl に指示します。-o yaml は、ユーザー クラスタの構成を表示します。

コマンドの出力で、reservedAddresses フィールドを探します。このフィールドの IP アドレスが、ユーザー クラスタで実行されているノードよりも多くなっている必要があります。

reservedAddresses フィールドにアドレスを追加する必要がある場合は、次の手順を実行します。

  1. ユーザー クラスタのクラスタ リソースを開いて編集します。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
    -n [USER_CLUSTER_NAME]
    

    クラスタ構成は、シェルのデフォルト エディタで開かれます。

  2. 静的 IP ブロックを必要な数だけ追加します。IP ブロックは、gatewayhostnameipnetmask フィールドで構成されています。

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

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

始める前に

サイズを変更するユーザー クラスタの kubeconfig を指す、KUBECONFIG 環境変数をエクスポートします。

export KUBECONFIG=[USER_CLUSTER_KUBECONFIG]

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

クラスタのサイズを変更するには、ユーザー クラスタの MachineDeployment リソースを編集します。ユーザー クラスタの MachineDeployment リソースの名前を確認するには、次のコマンドを実行します。

kubectl get machinedeployments

ユーザー クラスタの MachineDeployment には、ユーザー クラスタの名前が含まれています。

ユーザー クラスタのサイズを変更するには、クラスタの MachineDeployment 構成にパッチを適用する必要があります。構成の replicas フィールドの値を変更します。これは、クラスタを実行するノードの数を示します。

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p "{\"spec\": {\"replicas\": [INT] }}" --type=merge

[INT] は、ユーザー クラスタを実行するノードの数です。

サイズ変更を確認する

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

kubectl get nodes
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME] | grep Replicas

選択したノードの数が、これらのコマンド出力に反映されています。

トラブルシューティング

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

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

現象

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

考えられる原因

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

解決策

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

  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 アドレスが使用されていないことを確認します。競合がある場合は、環境内の競合を解消する必要があります。

新しいノードを作成したが、正常でない

現象

手動負荷分散モードの使用時、新しいノードが自分自身をユーザー クラスタ制御プレーンに登録しない。

考えられる原因

ノードの Ingress 検証が有効になり、ノードの起動プロセスがブロックされている可能性があります。

解決策

検証を無効にするには、次のコマンドを実行します。

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

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

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

gkectl コマンドを詳細に実行する

-v5

stderr に対する gkectl エラーのロギング

--alsologtostderr

管理ワークステーションの gkectl ログを見つける

デバッグフラグを渡さない場合でも、次の管理ワークステーション ディレクトリで gkectl ログを表示できます。

/home/ubuntu/.config/syllogi/logs

管理クラスタで 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