バージョン 1.8

正規サービス

注: 正規サービスは Anthos Service Mesh バージョン 1.6.8 以降のみにあります。

このページでは、Anthos Service Mesh にある正規サービスについて説明します。

正規サービスとは

Anthos Service Mesh 1.6.8 では、本番環境ワークロードを監視と管理が容易な単一サービスとして表現する概念的なアーキテクチャ モデルとして、正規サービスのサポートが導入されています。これらのワークロードは、複数のクラスタ、異なるバックエンド プラットフォーム、異なるスキーマと構成にまたがることができます。

Compute Engine ユーザーの場合: 正規サービスはマネージド インスタンス グループと似ていますが、正規サービスはマルチリージョンである可能性があります。

Kubernetes ユーザーの場合: 正規サービスは、Kubernetes の「app」コンセプトとアプリケーション CRD によく似ています。

サーバーレス ユーザーの場合: 正規サービスは App Engine サービスCloud Run サービスのコンセプトとよく似ています。唯一の違いは、Google のサーバーレス サービスは本質的にリージョンがあって、正規サービスはグローバル / マルチリージョンの抽象化である点です。

たとえば、次のシナリオはすべて、正規サービスを参照する方法を示しています。

  • サービスが停止している。
  • サービスがオンプレミスとパブリック クラウドの両方で実行されている。
  • サービスの新しいリビジョンをデプロイしている。
  • サービス Foo の送信トラフィックが多すぎるため、上限を超える可能性があります。

正規サービスは単一のメッシュ内に存在します。つまり、Anthos Service Mesh においては Environ と Google Cloud プロジェクト内で一意でもあります(すべてが Mesh で 1 対 1 です)。

特定のワークロードは、1 つの正規サービスの一部としてのみ許可されます。

正規サービスのスコープ全体は、そのサービスを定義する次のようなワークロードのグループから判断できます。

  • ホスト名と IP アドレス
  • ネットワーク
  • ネットワークとセキュリティ ポリシー
  • ルーティングと負荷分散
  • VM とコンテナ イメージ
  • 物理インフラストラクチャまたは仮想インフラストラクチャ
  • 地域
  • CI / CD システム
  • ソースコード
  • テレメトリー
  • サービスレベル目標とアラート

各サービスのオペレーションの詳細を示すダッシュボードは、Anthos Services ページで確認できます。

正規サービスの要件と制限事項

正規サービスは、Anthos Service Mesh バージョン 1.6.8 以降でのみ使用できます。

それぞれの正規サービスは、単一の Kubernetes Namespace または Istio Namespace 内に存在し、Namepace の境界を越えることはできません。

正規サービスは親の Namespace 内で一意の名前にする必要があります。詳細については、正規サービスの定義をご覧ください。

正規サービスは、複数のクラスタとリージョンにまたがって存在することがあります。クラスタやリージョンごとにリソースやテレメトリーを分割することも可能ですが、それらはサービスの範囲や一意性を決定する要因ではありません。

したがって、正規サービスの一意の ID は次の方法で決定されます。

mesh id + namespace + canonical name.

変更内容

リビジョンはサービスの増分変更を指し、サービスのさまざまな「バージョン」または「リリース」を区別して識別できます。

個々のワークロードに「正規リビジョン」のラベルを付けて、正規サービスのリビジョンを区別します。このラベルは定義できる任意の文字列です。場合によってラベルが自動的に設定されることもありますが、サービスをデプロイする CI / CD システムはラベルを適用する必要があります。このラベルの設定方法については、正規サービスの定義をご覧ください。

複数のリビジョンが同時に本番環境にある可能性があります。次を実現するには複数のリビジョンを一度に実行するのが最も一般的です。

  • 1 つのサービスのすべてのインスタンスでの、新しいバイナリの段階的なロールアウト、新しい構成、またはその両方。この場合、移行中に古いリビジョンと新しいリビジョンの両方が稼働しています。
  • 「A/B テスト」または「ライブテスト」。変更の影響をテストするため、2 つのバージョンのサービスがダウンストリームの呼び出し元のサブセットに公開されます。

次のステップ