ユーザー クラスタの削除

このページでは、GKE On-Prem ユーザー クラスタを削除する方法について説明します。

概要

GKE On-Prem は、gkectl を介したユーザー クラスタの削除をサポートしています。クラスタが正常でない場合（たとえば、コントロール プレーンがアクセス不可能な場合や、クラスタのブートストラップに失敗した場合）は、正常でないユーザー クラスタの削除をご覧ください。

ユーザー クラスタの削除

ユーザー クラスタを削除するには、次のコマンドを実行します。

gkectl delete cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--cluster [CLUSTER_NAME]

ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイル、[CLUSTER_NAME] は削除するユーザー クラスタの名前です。

正常でないユーザー クラスタを削除する

クラスタが正常ではない場合、--force を渡して、ユーザー クラスタを削除できます。コントロール プレーンにアクセスできない、クラスタのブートストラップに失敗する、または gkectl delete cluster がクラスタを削除できない場合、ユーザー クラスタは正常でない可能性があります。

クラスタを強制的に削除するには:

gkectl delete cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--cluster [CLUSTER_NAME] \
--force

ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイル、[CLUSTER_NAME] は削除するユーザー クラスタの名前です。

外部リソースをクリーンアップする

強制削除を行うと、F5 または vSphere に一部のリソースが残ることがあります。以下のセクションでは、こうした残されたリソースをクリーンアップする方法について説明します。

vSphere でユーザー クラスタの VM をクリーンアップする

ユーザー クラスタの VM が削除されたことを確認するには、次の手順を行います。

  1. vSphere Web Client の左側の [ナビゲータ] メニューで、[ホストとクラスタ] メニューをクリックします。
  2. リソースプールを見つけます。
  3. ユーザー クラスタ名を使用して接頭辞が付けられている VM があるかどうかを確認します。

残りのユーザー クラスタ VM がある場合は、VM ごとに次の手順を行います。

  1. vSphere Web Client で、ユーザー クラスタ VM を右クリックし、[Power] > [Power Off] を選択します。
  2. VM の電源が切れたら、VM を右クリックして、[Delete from Disk] を選択します。

ユーザー クラスタの F5 パーティションをクリーンアップする

ユーザー クラスタのパーティションにエントリが残っている場合は、次の手順を行います。

  1. F5 BIG-IP コンソールの右上で、クリーンアップするユーザー クラスタ パーティションに切り替えます。
  2. [Local Traffic] > [Virtual Servers] > [Virtual Server List] の順に選択します。
  3. [Virtual Servers] メニューで、すべての仮想 IP を削除します。
  4. [Pools] を選択し、すべてのプールを削除します。
  5. [Nodes] を選択し、すべてのノードを削除します。

完了後

gkectl でユーザー クラスタの削除を完了すると、ユーザー クラスタの kubeconfig を削除できます。

トラブルシューティング

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

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