正規サービス
注: 正規サービスは Cloud Service Mesh バージョン 1.6.8 以降で自動的にサポートされます。
このページでは、Cloud Service Mesh にある正規サービスについて説明します。
正規サービスとは
Cloud Service Mesh 1.6.8 では、正規サービスのサポートが導入されました。正規サービスとは、監視と管理が容易になる単一のサービスとしての本番環境ワークロードを表すコンセプトおよびアーキテクチャ モデルです。これらのワークロードは、複数のクラスタ、異種のバックエンド プラットフォーム、異なるスキーマと構成にまたがることができます。
Kubernetes ユーザーの場合: 正規サービスは、Kubernetes の「app」コンセプトとアプリケーション CRD によく似ています。
サーバーレス ユーザーの場合: 正規サービスは App Engine サービスや Cloud Run サービスのコンセプトとよく似ています。唯一の違いは、Google のサーバーレス サービスは本質的にリージョン単位であって、正規サービスはグローバル / マルチリージョンの抽象化である点です。
たとえば、次の場合はすべて、正規サービスに言及している可能性があります。
- サービスが停止している。
- サービスがオンプレミスとパブリック クラウドの両方で実行されている。
- サービスの新しいリビジョンをデプロイしている。
- サービス Foo の送信トラフィックが多すぎるため、上限を超える可能性がある。
正規サービスは単一のメッシュ内に存在します。つまり、Cloud Service Mesh においてはフリートと Google Cloud プロジェクト内で一意でもあります（すべてが Mesh で 1 対 1 です）。
特定のワークロードは、1 つの正規サービスの一部としてのみ許可されます。
正規サービスのスコープ全体は、そのサービスを定義する次のようなワークロードのグループから判断できます。
- ホスト名と IP アドレス
- ネットワーク
- ネットワークとセキュリティ ポリシー
- ルーティングとロード バランシング
- VM とコンテナ イメージ
- 物理インフラストラクチャまたは仮想インフラストラクチャ
- 地理的リージョン
- CI / CD システム
- ソースコード
- テレメトリー
- サービスレベル目標とアラート
各サービスのオペレーションの詳細を示すダッシュボードは、[サービス] ページで確認できます。
正規サービスの要件と制限事項
正規サービスは、Cloud Service Mesh バージョン 1.6.8 以降でのみ使用できます。
それぞれの正規サービスは、単一の Kubernetes Namespace または Istio Namespace 内に存在し、Namespace の境界を越えることはできません。
正規サービスには、親 Namespace 内で一意の名前を付与する必要があります。詳細については、正規サービスの定義をご覧ください。
正規サービスは、複数のクラスタとリージョンにまたがって存在できます。クラスタやリージョンごとにリソースやテレメトリーを分割することも可能ですが、それらはサービスの範囲や一意性を決定する要因ではありません。
したがって、正規サービスの一意の ID は次の方法で決定されます。
mesh id + namespace + canonical name.
リビジョン
リビジョンはサービスの増分変更を指し、サービスのさまざまな「バージョン」または「リリース」を区別して識別できます。
正規ワークロードのリビジョンを区別するために、個々のワークロードに「正規リビジョン」のラベルを付けます。このラベルは任意に定義できる文字列です。場合によってラベルが自動的に設定されることもありますが、サービスをデプロイするユーザーまたは CI / CD システムによりラベルが適用される必要があります。このラベルの設定方法については、正規サービスの定義をご覧ください。
複数のリビジョンが同時に本番環境にある可能性があります。次を実現するには複数のリビジョンを一度に実行するのが最も一般的です。
- 新しいバイナリ、新しい構成、またはその両方について、あるサービスのインスタンス全体への段階的なロールアウト。この場合、移行中に古いリビジョンと新しいリビジョンの両方が稼働しています。
- 「A/B テスト」または「ライブテスト」。変更の影響をテストするため、2 つのバージョンのサービスがダウンストリームの呼び出し元のサブセットに公開されます。