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

ユーザー クラスタの削除

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

概要

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

ユーザー クラスタの削除

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

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

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

既知の問題

バージョン 1.1.2 では、vSAN データベースを使用している場合にこのエラーが発生する既知の問題があります。

Error deleting machine object xxx; Failed to delete machine xxx: failed
  to ensure disks detached: failed to convert disk path "" to UUID path:
  failed to convert full path "ds:///vmfs/volumes/vsan:52ed29ed1c0ccdf6-0be2c78e210559c7/":
  ServerFaultCode: A general system error occurred: Invalid fault

リリースノートの回避策をご覧ください。

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

クラスタが正常ではない場合、--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. [ノード] を選択し、すべてのノードを削除します。

完了後

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

トラブルシューティング

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

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