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 ラベルを適用します。

詳しくは、手動で正規サービスを定義するをご覧ください。