このページでは、GKE On-Prem 管理クラスタを削除する方法について説明します。
始める前に
管理クラスタを削除する前に、次の手順を行います。
- ユーザー クラスタを削除します。ユーザー クラスタの削除をご覧ください。
- 管理クラスタから PodDisruptionBudgets（PDB）を使用するワークロードをすべて削除します。
- 管理クラスタから PersistentVolumes などの外部オブジェクトをすべて削除します。
削除する管理クラスタの kubeconfig を指す、
KUBECONFIG環境変数を設定します。export KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]
ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。
Logging と Monitoring の削除
StatefulSet からデプロイされた GKE On-Prem の Logging および Monitoring Pod は、ノードの適切なドレインを妨げる PDB を使用します。管理クラスタを適切に削除するには、こうした Pod を削除する必要があります。
Logging および Monitoring Pod を削除するには、次のコマンドを実行します。
kubectl delete monitoring --all -n kube-system kubectl delete stackdriver --all -n kube-system
Monitoring を削除すると、StatefulSet に関連付けられた PersistentVolume（PV）が消去されますが、Stackdriver の PersistentVolume は個別に削除する必要があります。
Stackdriver PV の削除はオプションです。PV を削除しない場合は、関連付けられた PV の場所と名前をユーザー クラスタ外の場所に記録します。
Persistent Volume Claim（PVC）を削除すると、PV も削除されます。
Stackdriver PVC を見つけるには、次のコマンドを実行します。
kubectl get pvc -n kube-system
PVC を削除するには、次のコマンドを実行します。
kubectl delete pvc -n kube-system [PVC_NAME]
Logging と Monitoring の削除の確認
Logging と Monitoring が削除されたことを確認するには、次のコマンドを実行します。
kubectl get pvc -n kube-system kubectl get statefulsets -n kube-system
管理クラスタの F5 パーティションのクリーンアップ
管理クラスタから gke-system Namespace を削除すると、F5 パーティションが適切にクリーンアップされ、パーティションを別の管理クラスタに再利用できます。
gke-system Namespace を削除するには次のコマンドを実行します。
kubectl delete ns gke-system
次に、LoadBalancer タイプの残りの Service をすべて削除します。すべての Service を一覧表示するには、次のコマンドを実行します。
kubectl get services --all-namespaces
LoadBalancer タイプの Service ごとに、次のコマンドを実行して削除します。
kubectl delete service [SERVICE_NAME] -n [SERVICE_NAMESPACE]
次に、F5 BIG-IP コンソールから次の手順を実行します。
- コンソールの右上で、パーティションに切り替えてクリーンアップします。
- [Local Traffic] > [Virtual Servers] > [Virtual Server List] の順に選択します。
- [Virtual Servers] メニューで、すべての仮想 IP を削除します。
- [Pools] を選択し、すべてのプールを削除します。
- [Nodes] を選択し、すべてのノードを削除します。
F5 パーティションがクリーンであることを確認する
CLI
次のコマンドを実行して、VIP が停止していることを確認します。
ping -c 1 -W 1 [F5_LOAD_BALANCER_IP]; echo $?
VIP が停止している場合は 1 が返されます。
F5 UI
F5 ユーザー インターフェースからパーティションがクリーンアップされたことを確認するには、次の手順を行います。
- 右上の [Partition] プルダウン メニューをクリックします。管理クラスタのパーティションを選択します。
- 左側の [Main] メニューから [Local Traffic] > [Network Map] を選択します。Local Traffic Network Map の下には何も表示されません。
- [Local Traffic] > [Virtual Servers] > [Nodes] の順にクリックし、[Nodes List] を選択します。ここにも何も表示されません。
エントリが残っている場合は、UI から手動で削除します。
管理ノードマシンの電源の切断
管理コントロール プレーンのノードマシンを削除するには、vSphere リソースプール内の残りの管理 VM の電源を切る必要があります。
vSphere UI
次の手順を行います。
- vSphere のメニューの Vsphere リソースプールから VM を選択します。
- VM メニューの上部にある [Actions] をクリックします。
- [Power] > [Power Off] を選択します。VM の電源がオフになるまで数分かかることがあります。
管理ノードマシンの削除
VM の電源が切れたら、VM を削除できます。
vSphere UI
次の手順を行います。
- vSphere のメニューの Vsphere リソースプールから VM を選択します。
- VM メニューの上部にある [Actions] をクリックします。
- [Delete from Disk] をクリックします。
完了後
管理クラスタの削除が完了したら、その 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 コントローラのログを調べてデバッグを試すことができます。
kube-systemNamespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、
grepまたは同様のツールを使用してエラーを検索します。kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager