クラスターの削除
仮想プライベート・クラウド クラシック・インフラストラクチャー
有料アカウントで作成したクラスターが不要になったら、リソースが消費されないように手動で削除する必要があります。
クラスターを削除すると、すべてのワーカー・ノード、アプリ、およびコンテナーが完全に削除されます。 このアクションは元に戻すことができません。 先に進む前に、必要なすべてのデータおよび構成ファイルをバックアップしてください。
永続ストレージ内のクラスターやデータのバックアップは作成されません。 クラスターを削除するときに、永続ストレージも削除することができます。 永続ストレージを削除する場合、delete
ストレージ・クラスを使用してプロビジョンした永続ストレージは、IBM Cloud インフラストラクチャーで完全に削除されます。 retain
ストレージ・クラスを使用してプロビジョンした永続ストレージを削除する場合、クラスター、PV、および PVC
は削除されますが、IBM Cloud インフラストラクチャー・アカウント内の永続ストレージ・インスタンスは残ります。
クラシック・クラスターのみ: クラスターを削除するときには、クラスターの作成時に自動的にプロビジョニングされたサブネットと、ibmcloud ks cluster subnet create
コマンドを使用して作成したサブネットもすべて削除します。 ただし、ibmcloud ks cluster subnet add
コマンドを使用して既存のサブネットをクラスターに手動で追加した場合、これらのサブネットは
IBM Cloud インフラストラクチャー・アカウントから削除されず、他のクラスターで再利用できます。
始める前に:
- クラスター ID をメモします。 クラスターで自動的に削除されない IBM Cloud インフラストラクチャー関連リソースを調査および削除するために、クラスター ID が必要になる場合があります。
- 管理者の IBM Cloud IAM プラットフォーム・アクセス役割があることを確認してください。
- 永続ストレージ内のデータを削除する場合は、使用しているストレージ・タイプの削除オプションを確認してください。
- ファイル・ストレージ
- クラシック・クラスターのブロック・ストレージ
- VPC クラスターのブロック・ストレージ
- オブジェクト・ストレージ
- Portworx
クラスターを削除するには、以下のようにします。
- オプション: CLI から、クラスター内のすべてのデータのコピーをローカルの YAML ファイルに保存します。
kubectl get all --all-namespaces -o yaml
- クラスターを削除します。
-
IBM Cloud コンソールから
- クラスターを選択し、 「その他のアクション」 メニューから 「削除」 をクリックします。
-
IBM Cloud CLI から
-
使用可能なクラスターをリストします。
ibmcloud ks cluster ls
-
クラスターを削除します。
ibmcloud ks cluster rm --cluster <cluster_name_or_ID>
-
-
- プロンプトに従って、コンテナー、ポッド、バインドされたサービス、永続ストレージ、およびシークレットを含むクラスター・リソースを削除するかどうかを選択します。
-
永続ストレージ:
reclaimPolicy: Delete
を設定するストレージ・クラスを使用してストレージを動的にプロビジョンした場合、クラスターを削除すると、永続ボリューム要求 (PVC)、永続ボリューム (PV)、およびストレージ・インスタンスが自動的に削除されます。 ただし、クラスターを削除するタイミングによっては、最大で 72 時間、または新しい課金サイクルが開始するまで、IBM Cloud コンソールに引き続きそのストレージ・インスタンスが表示される可能性があります。 VPC ブロック・ストレージは、Delete
ストレージ・クラスを使用した場合でも、自動的には削除されません。静的にプロビジョンされたストレージ、または
reclaimPolicy: Retain
を設定するストレージ・クラスを使用してプロビジョンしたストレージの場合、クラスターを削除すると PVC と PV は削除されますが、ストレージ・インスタンスとデータは残ります。 ストレージ・インスタンスは引き続き課金されます。ストレージを手動で削除したり、ストレージの削除に関するよくある質問を調べたりするには、**「始める前に」**セクションにあるリンクから各ストレージ・タイプの資料を確認してください。
-
Satellite のワーカー・ノードまたはクラスターの削除
Red Hat OpenShift のクラスター、またはクラスター内のワーカー・ノードを削除しても、ワーカー・ノードにコンピュート容量を提供するホストが自動的に削除されるわけではありません。 そうではなく、ホストは Satellite ロケーションに接続されたままになります。ただし、このホストを他の Satellite リソースに再び割り当てるには、ホストの再ロードが必要になります。
-
ワーカー・ノードまたはクラスターにある保存対象データをバックアップします。 例えば、クラスター内のすべてのデータのコピーを保存し、それらのファイルを IBM Cloud Object Storage などの永続ストレージ・ソリューションにアップロードすることができます。
oc get all --all-namespaces -o yaml
-
クラスター内の各ホストの**ワーカー ID ** を取得します。
ibmcloud sat host ls --location <satellite_location_name_or_ID>
出力例
Retrieving hosts... OK Name ID State Status Cluster Worker ID Worker IP machine-name-1 aaaaa1a11aaaaaa111aa assigned Ready infrastructure sat-virtualser-4d7fa07cd3446b1f9d8131420f7011e60d372ca2 169.xx.xxx.xxx machine-name-2 bbbbbbb22bb2bbb222b2 assigned Ready infrastructure sat-virtualser-9826f0927254b12b4018a95327bd0b45d0513f59 169.xx.xxx.xxx machine-name-3 ccccc3c33ccccc3333cc assigned Ready mycluster12345 sat-virtualser-948b454ea091bd9aeb8f0542c2e8c19b82c5bf7a 169.xx.xxx.xxx
-
以下の選択肢を参照して、ワーカー・ノードまたはクラスターを削除します。 Satellite ロケーションに存在する対応ホストの割り当てが解除されます。これらのホストを他の Satellite リソースで使用するためには、再ロードが必要になります。
- クラスター内のワーカー・ノード数を減らすために、ワーカー・プールのサイズを変更します。
- クラスターから個々のワーカー・ノードを削除します。
- クラスターを削除します。
-
削除したワーカー・ノードごとに、Satellite ロケーションに存在する対応ホストの処理を決定します。
- ホスト・オペレーティング・システムを再ロードして、ロケーション・コントロール・プレーンやその他のクラスターなどの他の Satellite リソースにホストを接続して割り当てることができるようにします。 詳しくは、Satellite ロケーション・コントロール・プレーンのホストの更新で更新プロセスを参照してください。
- 基礎のインフラストラクチャー・プロバイダーからホストを削除します。 詳しくは、インフラストラクチャー・プロバイダーの資料を参照してください。
次のステップ
ibmcloud ks cluster ls
コマンドを実行したときにクラスターがリストされなくなったら、削除したクラスターの名前を再利用できます。- クラシック・クラスターのみ: サブネットを残した場合は、それらを新しいクラスターで再利用することも、後で IBM Cloud インフラストラクチャー・ポートフォリオから手動で削除することもできます。
- VPC クラスターのみ: 不要になったインフラストラクチャー・リソース (VPC やサブネットなど) があれば、VPC ポータルで削除します。
- 永続ストレージ: 永続ストレージを保持していた場合、対応するストレージ・サービスの IBM Cloud コンソールを使用して、後でストレージを削除できます。