IBM Cloud Docs
クラスターの削除

クラスターの削除

仮想プライベート・クラウド クラシック・インフラストラクチャー

有料アカウントで作成したクラスターが不要になったら、リソースが消費されないように手動で削除する必要があります。

クラスターを削除すると、すべてのワーカー・ノード、アプリ、およびコンテナーが完全に削除されます。 このアクションは元に戻すことができません。 先に進む前に、必要なすべてのデータおよび構成ファイルをバックアップしてください。

永続ストレージ内のクラスターやデータのバックアップは作成されません。 クラスターを削除するときに、永続ストレージも削除することができます。 永続ストレージを削除する場合、delete ストレージ・クラスを使用してプロビジョンした永続ストレージは、IBM Cloud インフラストラクチャーで完全に削除されます。 retain ストレージ・クラスを使用してプロビジョンした永続ストレージを削除する場合、クラスター、PV、および PVC は削除されますが、IBM Cloud インフラストラクチャー・アカウント内の永続ストレージ・インスタンスは残ります。

クラシック・クラスターのみ: クラスターを削除するときには、クラスターの作成時に自動的にプロビジョニングされたサブネットと、ibmcloud ks cluster subnet create コマンドを使用して作成したサブネットもすべて削除します。 ただし、ibmcloud ks cluster subnet add コマンドを使用して既存のサブネットをクラスターに手動で追加した場合、これらのサブネットは IBM Cloud インフラストラクチャー・アカウントから削除されず、他のクラスターで再利用できます。

始める前に:

クラスターを削除するには、以下のようにします。

  1. オプション: CLI から、クラスター内のすべてのデータのコピーをローカルの YAML ファイルに保存します。
    kubectl get all --all-namespaces -o yaml
    
  2. クラスターを削除します。
    • IBM Cloud コンソールから

      1. クラスターを選択し、 「その他のアクション」 メニューから 「削除」 をクリックします。
    • IBM Cloud CLI から

      1. 使用可能なクラスターをリストします。

        ibmcloud ks cluster ls
        
      2. クラスターを削除します。

        ibmcloud ks cluster rm --cluster <cluster_name_or_ID>
        
  3. プロンプトに従って、コンテナー、ポッド、バインドされたサービス、永続ストレージ、およびシークレットを含むクラスター・リソースを削除するかどうかを選択します。
    • 永続ストレージ: reclaimPolicy: Delete を設定するストレージ・クラスを使用してストレージを動的にプロビジョンした場合、クラスターを削除すると、永続ボリューム要求 (PVC)、永続ボリューム (PV)、およびストレージ・インスタンスが自動的に削除されます。 ただし、クラスターを削除するタイミングによっては、最大で 72 時間、または新しい課金サイクルが開始するまで、IBM Cloud コンソールに引き続きそのストレージ・インスタンスが表示される可能性があります。 VPC ブロック・ストレージは、Delete ストレージ・クラスを使用した場合でも、自動的には削除されません。

      静的にプロビジョンされたストレージ、または reclaimPolicy: Retain を設定するストレージ・クラスを使用してプロビジョンしたストレージの場合、クラスターを削除すると PVC と PV は削除されますが、ストレージ・インスタンスとデータは残ります。 ストレージ・インスタンスは引き続き課金されます。

      ストレージを手動で削除したり、ストレージの削除に関するよくある質問を調べたりするには、**「始める前に」**セクションにあるリンクから各ストレージ・タイプの資料を確認してください。

Satellite のワーカー・ノードまたはクラスターの削除

Red Hat OpenShift のクラスター、またはクラスター内のワーカー・ノードを削除しても、ワーカー・ノードにコンピュート容量を提供するホストが自動的に削除されるわけではありません。 そうではなく、ホストは Satellite ロケーションに接続されたままになります。ただし、このホストを他の Satellite リソースに再び割り当てるには、ホストの再ロードが必要になります。

  1. ワーカー・ノードまたはクラスターにある保存対象データをバックアップします。 例えば、クラスター内のすべてのデータのコピーを保存し、それらのファイルを IBM Cloud Object Storage などの永続ストレージ・ソリューションにアップロードすることができます。

    oc get all --all-namespaces -o yaml
    
  2. クラスター内の各ホストの**ワーカー 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       
    
  3. 以下の選択肢を参照して、ワーカー・ノードまたはクラスターを削除します。 Satellite ロケーションに存在する対応ホストの割り当てが解除されます。これらのホストを他の Satellite リソースで使用するためには、再ロードが必要になります。

  4. 削除したワーカー・ノードごとに、Satellite ロケーションに存在する対応ホストの処理を決定します。

    • ホスト・オペレーティング・システムを再ロードして、ロケーション・コントロール・プレーンやその他のクラスターなどの他の Satellite リソースにホストを接続して割り当てることができるようにします。 詳しくは、Satellite ロケーション・コントロール・プレーンのホストの更新で更新プロセスを参照してください。
    • 基礎のインフラストラクチャー・プロバイダーからホストを削除します。 詳しくは、インフラストラクチャー・プロバイダーの資料を参照してください。

次のステップ

  • ibmcloud ks cluster ls コマンドを実行したときにクラスターがリストされなくなったら、削除したクラスターの名前を再利用できます。
  • クラシック・クラスターのみ: サブネットを残した場合は、それらを新しいクラスターで再利用することも、後で IBM Cloud インフラストラクチャー・ポートフォリオから手動で削除することもできます。
  • VPC クラスターのみ: 不要になったインフラストラクチャー・リソース (VPC やサブネットなど) があれば、VPC ポータルで削除します。
  • 永続ストレージ: 永続ストレージを保持していた場合、対応するストレージ・サービスの IBM Cloud コンソールを使用して、後でストレージを削除できます。