クラスタ内 Cloud Service Mesh をアンインストールする

注: このガイドは、Istio API を使用する Cloud Service Mesh のみに対応しており、 Google Cloud API には対応していません。詳細については、Cloud Service Mesh の概要をご覧ください。

注意: Google Cloud 上の GKE で ISTIOD コントロール プレーンを使用するクラスタ内 Cloud Service Mesh は非推奨になりました。Google Distributed Cloud（ソフトウェアのみ）のクラスタ内コントロール プレーンを使用する Cloud Service Mesh は、サポートされているプラットフォームで説明されているとおり、引き続きサポートされます。

このページでは、Istio API を使用している場合にクラスタ内 Cloud Service Mesh をアンインストールする方法について説明します。Compute Engine API を使用している場合は、何も行う必要はありません。違いについては、Cloud Service Mesh の概要をご覧ください。

以下の手順でクラスタ内 Cloud Service Mesh をアンインストールすると、すべての構成が削除されます。

マネージド Cloud Service Mesh をアンインストールする場合は、代わりにマネージド アンインストール ガイドの手順に沿って操作します。

クラスタ内からマネージドに移行する場合は、代わりに移行ガイドに従ってください。

Cloud Service Mesh を削除した場合の影響

Cloud Service Mesh をアンインストールする前に、クラスタとワークロードから削除される機能について検討してください。ワークロードから Cloud Service Mesh プロキシを削除して再起動すると、アプリケーションは標準の Kubernetes ネットワーキング動作に戻ります。

セキュリティ

Cloud Service Mesh を削除すると、次のセキュリティ機能が失われます。

• 相互 TLS（mTLS）暗号化: サービス間のトラフィックは、メッシュで管理される mTLS 証明書を使用して転送中に暗号化されなくなります。
• 認可ポリシー: Mesh AuthorizationPolicy カスタム リソースは適用されなくなります。トラフィックを制限するには、Kubernetes NetworkPolicy リソースまたはアプリケーション レベルの認証と認可を構成する必要があります。

オブザーバビリティ

Cloud Service Mesh を削除すると、次のオブザーバビリティ機能が失われます。

• テレメトリーと指標: レイヤ 7 の指標（リクエスト率、エラー率、レイテンシなど）の自動収集が停止します。メッシュ テレメトリーは、Cloud Monitoring に自動的に取り込まれなくなりました。標準の GKE 指標は影響を受けません。
• ダッシュボードと SLO:Google Cloud コンソールで事前構成された Cloud Service Mesh ダッシュボードとサービスレベル目標（SLO）のモニタリングは、データが入力されなくなります。
• アクセス ロギングとトレース: クライアント mTLS ID と自動化された分散トレースを含むサイドカー プロキシ アクセスログは生成されなくなります。

サービス ディスカバリとネットワーキングの復元性

Cloud Service Mesh を削除すると、次のネットワーキング機能と復元機能が失われます。

• ネットワークの復元力: ワークロードは、自動再試行、構成可能なリクエスト タイムアウト、サーキット ブレーカー、外れ値検出、接続プール管理などのサイドカーレベルの復元力機能を失います。アプリケーションは、接続の失敗と再試行を直接管理する必要があります。
• マルチクラスタ サービス ディスカバリ: フリート内の複数のクラスタにまたがるクラスタ間のエンドポイント検出とルーティングが、メッシュを介して機能しなくなります。サービスは、標準 DNS を使用してローカル クラスタ内のエンドポイントのみを検出できます。

Cloud Service Mesh をアンインストールする

次のコマンドを使用して、Cloud Service Mesh のすべてのコンポーネントをアンインストールします。

1. アプリケーション トラフィックが中断されないようにするには:

   • STRICT mTLS ポリシーを PERMISSIVE にダウングレードします。
   • トラフィックをブロックする可能性のある AuthorizationPolicy をすべて削除します。

2. 名前空間でサイドカーの自動挿入機能が有効になっている場合は、これを無効にします。次のコマンドを実行して、名前空間ラベルを表示します。

    kubectl get namespace YOUR_NAMESPACE --show-labels
   

   出力は次のようになります。

    NAME   STATUS   AGE     LABELS
    demo   Active   4d17h   istio.io/rev=asm-181-5

   出力の LABELS 列の下に istio.io/rev= が表示されている場合は、削除します。

    kubectl label namespace YOUR_NAMESPACE istio.io/rev-
   

   出力の LABELS 列の下に istio-injection が表示されている場合は、削除します。

    kubectl label namespace YOUR_NAMESPACE istio-injection-
   

   istio.io/rev ラベルまたは istio-injection ラベルが表示されていない場合、名前空間で自動挿入が有効になっていません。

   注: Deployment、StatefulSet、ReplicaSet、DaemonSet、Job、CronJob などのリソースもインジェクションの対象として確認する必要があります。

3. サイドカーが挿入されたワークロードを再起動してプロキシを削除します。

4. クラスタに validatingwebhooksconfiguration と mutatingwebhookconfiguration が存在する場合は、それらを削除します。

     kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot,istio.io/owned-by!=mesh.googleapis.com
   

5. すべてのワークロードが稼働し、プロキシが確認されなくなったら、クラスタ内コントロール プレーンを安全に削除して課金を停止できます。

   クラスタ内コントロール プレーンを削除するには、次のコマンドを実行します。

   istioctl uninstall --purge
   

   コントロール プレーンが他にない場合は、istio-system 名前空間を削除して、すべての Cloud Service Mesh リソースを削除できます。他のコントロール プレーンがある場合は、Cloud Service Mesh のリビジョンに対応するサービスを削除します。これにより、CRD などの共有リソースの削除を回避できます。

6. 必要に応じて、Istio CR、Istio CRD、istio-(revision) configmap、asm-options configmap、istio-system 名前空間、asm-system 名前空間を削除して、クラスタからサービス メッシュを削除するか、別の Istio API 互換サービス メッシュで使用します。

   1. Istio CR を削除します。

      kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespaces
      

   2. Istio CRD を削除します。

      kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl delete
      

   3. istio-(リビジョン) configmap を削除します。istio-system Namespace を削除する場合は、この手順をスキップできます。

      kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
      

      RELEASE_CHANNEL は、リリース チャンネルに置き換えます

   4. istio-system Namespace を削除します。

      kubectl delete namespace istio-system --ignore-not-found=true
      

   5. asm-system Namespace を削除します。

      kubectl delete namespace asm-system --ignore-not-found=true
      

      1. 削除が成功したかどうかを確認します。

          kubectl get ns
          ```
         
         The output should indicate a `Terminating` state and return as shown,
         otherwise you might have to manually delete any remaining resources in
         the namespaces and try again.
         
         ```sh
          NAME                 STATUS       AGE
          istio-system         Terminating  71m
          asm-system           Terminating  71m
          ```
         

7. クラスタを削除する場合、またはすでに削除している場合は、各クラスタがフリートから登録解除されていることを確認してください。

8. フリートレベルで Cloud Service Mesh の使用を停止する場合は、フリート ホスト プロジェクトのサービス メッシュ機能を無効にします。

    gcloud container hub mesh disable --project FLEET_PROJECT_ID
   

   ここで、FLEET_PROJECT_ID はフリート ホスト プロジェクトの ID です。

これらの手順を完了すると、プロキシ、クラスタ内認証局、RBAC のロールとバインディングを含むすべての Cloud Service Mesh コンポーネントが、クラスタから体系的に削除されます。インストール プロセス中に、Google 所有のサービス アカウントに、クラスタ内のサービス メッシュ リソースを確立するために必要な権限が付与されます。これらのアンインストール手順を実行しても、これらの権限は取り消されないため、今後 Cloud Service Mesh をシームレスに再有効化できます。