Cloud Service Mesh での正規サービスの問題の解決
注: 正規サービスは Cloud Service Mesh バージョン 1.6.8 以降で自動的にサポートされます。
このセクションでは、Cloud Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。
メッシュ内のクラスタが古いバージョンの Cloud Service Mesh を実行している
いずれかのクラスタで以前のバージョンの Cloud Service Mesh（1.6.8 より前のバージョン）が実行されている場合、または正規サービス コントローラが無効である Cloud Service Mesh がクラスタで実行されている場合は、それらのクラスタ（およびそれらで実行されているサービス）は Service Mesh UI に表示されません。正規サービスを使用するには、各クラスタを Cloud Service Mesh 1.6.8 以降にアップグレードし、正規サービス コントローラを含むデフォルトのインストール オプションを使用する必要があります。詳細については、Cloud Service Mesh の最新バージョンへのアップグレード（クラスタが GKE にある場合）、またはオンプレミスの Cloud Service Mesh のアップグレードをご覧ください。
また、クラスタにコントローラをインストールしない場合は、メッシュのマネージド正規サービス コントローラ（現在プレビュー版）を有効にできます。
正規サービス コントローラを有効にするための詳細情報については、正規サービス コントローラの有効化と無効化をご覧ください。
クラスタに Cloud Service Mesh がインストールされていない
クラスタに Cloud Service Mesh がインストールされていない場合、そのクラスタは Service Mesh UI に表示されません。Cloud Service Mesh のインストール方法については、Cloud Service Mesh のドキュメントをご覧ください。
オンプレミス クラスタにログインしていない
メッシュ内にオンプレミス クラスタがある場合、そのクラスタにログインしないと、クラスタに対応するサービスは表示されません。これらのサービスをダッシュボードに表示するには、クラスタにログインする必要があります。クラスタへのログインの詳細については、Cloud Console からのクラスタへのログインをご覧ください。
オンプレミス クラスタにアクセスできない
メッシュ内にオンプレミス クラスタがあり、そのクラスタに Connect Agent を介して到達できない場合、クラスタに対応するサービスは表示されません。これらのサービスをダッシュボードに表示するには、クラスタが実行中で、Google Cloud に接続していることを確認してください。クラスタを Google Cloud に接続する方法については、Connect の概要をご覧ください。
定義された SLO を持つサービスが、正規サービスと 1 対 1 の対応でマッピングされていない
正規サービスに移行される前、Cloud Service Mesh では Kubernetes Services のダッシュボードが表示されていました。Kubernetes Services とデフォルトの正規サービスが整合することがほとんどですが、Kubernetes Service が対応する正規サービスと自動的に一致しないことや、デフォルトの正規サービスの境界が望ましいものにならないこともあります。
既存のサービスにサービスレベル目標（SLO）を設定していて、それをデフォルトの正規サービスと自動的に対応させられない場合、それらのサービスを移行することはできません。正規サービスの使用を開始するには、問題のあるサービスの SLO を削除する必要があります。また、古い SLO を削除する前に、そのサービスに最も近い正規サービスの新しい SLO を作成することもできます。
ダッシュボードに表示されるはずのコンテンツが表示されない
サービス メッシュのサービス ダッシュボードはそれぞれ、サービス メッシュ内の正規サービスにスコープされます。正規サービスは、関連するすべてのワークロード、リージョンなどにまたがる高レベルの論理サービス コンセプトです。
デフォルトでは、各ワークロード インスタンスの既存のラベル（Pod または WorkloadEntry）が正規サービスを定義し、優先度を下げる際に次のルールに従います。
service.istio.io/canonical-nameラベルはすでに明示的に設定されています。これ以上の対応は不要です。- それ以外の場合は、
service.istio.io/canonical-nameラベルが追加され、その値にはapp.kubernetes.io/nameラベルのものが設定されます。 - それ以外の場合は、
service.istio.io/canonical-nameラベルが追加され、その値にはappラベルのものが設定されます。 - それ以外の場合、
service.istio.io/canonical-nameラベルが追加され、その値には所有ワークロードのnameが設定されます。ここでの「所有ワークロード」は、Pod、Deployment、StatefulSet などが単独でデプロイされている場合、またはより高いレベルのオーケストレーションを使用している場合です。
Kubernetes と KubeRun / Knative のほとんどの慣用的なユーザーの場合、これらのルールは、サービスとワークロードをすでに管理している方法に直接マッピングされます。
ただし、一部のカスタム ユースケースや複雑なユースケースでは、デフォルトのヒューリスティックによりサービスが適切にキャプチャされないため、表示される Cloud Service Mesh ダッシュボードに表示されるはずのコンテンツが含まれません。
この問題は、正規サービスの範囲を手動で定義することで解決できます。
サービスの範囲を手動で定義する
可能な限り、自動のデフォルト グループ化メカニズムを使用することをおすすめします。ただし、これらのデフォルト グループをオーバーライドする場合は、Kubernetes Pod と WorkloadEntry の構成に service.istio.io/canonical-name Kubernetes ラベルを適用します。
詳しくは、手動で正規サービスを定義するをご覧ください。