用語集

このページでは、Anthos Service Mesh のドキュメントで使用されている用語の簡単な定義と詳細情報へのリンクをまとめています。

A

Anthos Workload Identity: trust domain、namespace、service account のタプル。Anthos ワークロード x509 証明書内の spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> の SPIFFE ID 形式です。その他の認証情報タイプ（OIDC トークンなど）では、形式が異なる場合があります。

C

正規サービス

Anthos Service Mesh のワークロードに適用されるラベル。サービスメッシュ内の 1 つ以上のワークロードを論理サービスとしてグループ化できます。ワークロードは 1 つの正規サービスに属しますが、複数の Kubernetes Service に属していてもかまいません。正規サービスは名前と名前空間で識別されます。さらに 1 つ以上の正規リビジョンにさらに分割できます。

コントロールプレーン

コントロールプレーンは、メッシュまたはメッシュのサブセットを構成する一連のシステムサービスで、内部のワークロードインスタンス間の通信を管理します。Anthos Service Mesh 1.9 以降には、次の 2 つのコントロールプレーンが用意されています。

Google 管理のコントロールプレーン: Google が信頼性、アップグレード、スケーリング、セキュリティに対応しますが、構成に必要なものはフルマネージド Google Cloud サービスのみです。
クラスタ内コントロールプレーン: クラスタにインストールされる istiod です。これは Google がサポートするディストリビューションです。istiod を使用して Anthos Service Mesh をインストールする場合は、セキュリティとスケーリングのアップグレードと構成はユーザーの責任となります。

コントロールプレーンは構成をサイドカープロキシに配信しますが、コントロールプレーンはメッシュ内のワークロードのトラフィックを直接処理しません。

D

データプレーン: データプレーンは、ワークロードインスタンス間の通信を直接制御するメッシュの一部です。Anthos Service Mesh のデータプレーンは、サイドカーとしてデプロイされたプロキシを使用して、メッシュサービスが送受信するすべての TCP トラフィックを仲介および制御します。

F

フリート: フリート（旧称 environ）を使用してクラスタを整理すると、複数クラスタの管理が容易になります。フリートにクラスタを登録すると、ID、名前空間、サービスに関して「同一性」というコンセプトを導入して、マルチクラスタメッシュの管理を簡素化できます。複数のプロジェクトにクラスタがある場合は、クラスタが属しているプロジェクトではなく、フリートのホストプロジェクトにクラスタを登録する必要があります。フリートの詳細については、フリートの概要をご覧ください。

I

ID

ID はセキュリティインフラストラクチャの基本コンセプトです。Anthos Service Mesh ID モデルは、トップクラスのワークロード ID に基づいています。サービス間通信の開始時、相互認証の目的で ID 情報とともに認証情報が両当事者間で交換されます。

クライアントは、サーバー ID と安全な命名に関する情報をチェックして、サーバーがサービスを実行する権限を持っているかどうかを確認します。

サーバーはクライアントの ID を確認し、クライアントがアクセスできる情報を判断します。サーバーは、構成された認証ポリシーに基づいてアクセスを許可するかどうかを決定します。

サーバーは ID を使用して、特定のクライアントが情報にアクセスした時刻と、アクセスした情報の内容をモニタリングできます。また、使用するサービスに基づいてクライアントに課金し、支払いに失敗したクライアントをサービスにアクセスできないように拒否することもできます。

Anthos Service Mesh ID モデルは、人間のユーザー、個々のサービス、サービスのグループを表すのに十分な柔軟性と粒度を備えています。最高レベルのサービス ID を持たないプラットフォームでは、サービス名などのサービスインスタンスをグループ化できる ID を使用できます。

Anthos Service Mesh は、さまざまなプラットフォームで次のサービス ID をサポートします。

Kubernetes: Kubernetes サービスアカウント
Google Kubernetes Engine: Google Cloud サービスアカウント
Google Cloud: Google Cloud サービスアカウント

Ingress ゲートウェイ

Ingress ゲートウェイは、メッシュ外部からの受信トラフィックを処理するロードバランサを表します。Istio Gateway リソースを使用してロードバランサを構成し、仮想サービスと認証ポリシーを作成して、受信トラフィックの保護とワークロードへのルーティング方法を制御します。

istiod

istiod（「d」は「daemon」を意味します）はコントロールプレーンサービスを提供する統合されたモノリシックバイナリです。Anthos Service Mesh 1.5 より前では、コントロールプレーンサービスは Pilot、Citadel、Mixer、Galley という個別のコンポーネントで提供されていました。

IstioOperator

クラスタ内コントロールプレーンの構成に使用するカスタムリソース。詳細については、オプション機能の有効化をご覧ください。

M

マネージドインスタンスグループ（MIG）: 最小 MIG サイズである VM 1 個から開始して、複数の同じ VM でアプリケーションを実行できます。自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイメント、自動更新などの自動化 MIG サービスを活用することで、スケーラブルで可用性に優れたワークロード処理を実現します。詳細については、マネージドインスタンスグループ（MIG）をご覧ください。
Mesh CA: mTLS 証明書を管理する、Google が管理する認証局の名前。Anthos Service Mesh をインストールすると、Mesh CA がデフォルトでインストールされます。
相互 TLS: Anthos Service Mesh は、メッシュ内のサービス間の認証と暗号化に相互 TLS（mTLS）を使用します。mTLS を使用すると、ワークロードが互いの ID を検証でき、相互に認証できます。HTTPS では、ブラウザがウェブサーバーを信頼し、暗号化されたデータを交換するためにシンプルな TLS が使用されています。シンプルな TLS では、クライアントは証明書を検証してサーバーが信頼できるかどうか確認します。mTLS は、クライアントとサーバーの両方が相互に証明書を提示し、互いの ID を検証します。

N

ネットワーク: Anthos Service Mesh では、一般的な接続に基づいて、簡素化されたネットワーク定義を使用しています。ワークロードインスタンスは、ゲートウェイなしで直接通信できる場合は同じネットワーク上に存在します。

O

オーバーレイファイル: IstioOperator カスタムリソース（CR）を含む YAML ファイル。オーバーレイファイルを使用してコントロールプレーンを構成します。デフォルトのコントロールプレーン構成をオーバーライドし、istioctl install または install_asm スクリプトに渡す YAML ファイルでサポートされているオプション機能を有効にできます。複数のオーバーレイを重ねることができます。各オーバーレイファイルは、以前のレイヤの構成をオーバーライドします。デフォルトで有効になっていない機能を有効化するための YAML については、オプション機能の有効化をご覧ください。

P

プライマリクラスタ: プライマリクラスタは、コントロールプレーンを含むクラスタです。1 つのメッシュで複数のプライマリクラスタを使用することで、高可用性の実現やレイテンシの短縮が可能です。Istio 1.7 ドキュメントでは、マルチプライマリデプロイはレプリケートされたコントロールプレーンと呼ばれます。

R

リモートクラスタ: リモートクラスタは、クラスタの外部に存在するコントロールプレーンに接続するクラスタです。リモートクラスタは、プライマリクラスタで実行されているコントロールプレーンまたは外部コントロールプレーンに接続できます。
リビジョン: リビジョンは、アプリケーションコードのバージョンと構成のその時間のスナップショットを表します。Anthos Service Mesh をインストールまたはアップグレードする際、リビジョンラベルがコントロールプレーンに追加されます。自動サイドカーインジェクションを有効にするには、名前空間にリビジョンラベルを追加して Pod を再起動します。リビジョンラベルを使用して、名前空間内の Pod を特定のコントロールプレーンに関連付けます。
リビジョンベースのアップグレード: OSS Istio からの移行とアップグレードは、リビジョンベースのアップグレードプロセスに沿って進めます（Istio ドキュメントでは「カナリアアップグレード」と呼ばれます）。リビジョンベースのアップグレードでは、既存のコントロールプレーンに並ぶ形で新しいバージョンのコントロールプレーンがインストールされます。次に、一部のワークロードを新しいバージョンに移行します。これにより、すべてのトラフィックを新しいバージョンに移行する前に、ワークロードのごく一部でアップグレードの影響をモニタリングできます。

S

安全な命名: サーバー ID は証明書にエンコードされますが、サービス名は検出サービスまたは DNS を介して取得されます。安全な命名に関する情報は、サーバー ID をサービス名にマッピングします。ID A からサービス名 B へのマッピングは、「A はサービス B を実行する権限を持つ」ことを意味します。コントロールプレーンは apiserver を監視し、安全な命名のマッピングを生成して、サイドカープロキシに安全に配布します。
サービスメッシュ: サービスメッシュ（または単にメッシュ）は、管理され、監視可能で安全な通信をワークロードインスタンス間で可能にするインフラストラクチャレイヤです。
サイドカー: ワークロードとともにユーティリティまたはヘルパーを実行するためのパターン。Kubernetes の場合、サイドカーは Pod のワークロードコンテナとともに実行されます。サービスメッシュに関する文脈ではプロキシの意味で使用されます。

T

信頼ドメイン

信頼ドメインはシステムのルートオブトラストに対応し、ワークロード ID の一部です。

Anthos Service Mesh は、信頼ドメインを使用してメッシュ内のすべての ID を作成します。たとえば、SPIFFE ID spiffe://mytrustdomain.com/ns/default/sa/myname では、部分文字列 mytrustdomain.com は、ワークロードが mytrustdomain.com と呼ばれる信頼ドメインからのものであることを指定します。

Mesh CA を使用すると、Anthos Service Mesh によって信頼ドメインが自動的に生成されます。これは、クラスタのワークロードプールに基づいています。

クラスタが同じルートオブトラストを共有している限り、マルチクラスタメッシュ内に 1 つ以上の信頼ドメインを含めることができます。

W

ワークロード: ワークロードとは、プラットフォームで実行されるバッチジョブやデーモンなど、コンテナ化されたアプリケーション、サービス、その他のプログラムのことです。このプラットフォームは、Kubernetes クラスタ、仮想マシン、または Google Distributed Cloud Virtual for Bare Metal などの他の環境です。ワークロードには名前、名前空間、一意の ID があります。Kubernetes では、ワークロードは通常 Deployment に対応しますが、他の種類のワークロード（StatefulSet など）もあります。
WorkloadEntry: を使用すると、メッシュの一部にする必要がある Kubernetes 以外の Pod エンドポイントを記述し、Kubernetes Pod と同様に扱うことができます。ここでは、各 VM はメッシュ内で WorkloadEntry として登録されています。詳細については、https://istio.io/latest/blog/2020/workload-entry/ をご覧ください。
WorkloadGroup: ワークロードインスタンスのコレクションを記述します。WorkloadGroup をご覧ください。
Workload Identity プール: 信頼境界線。Anthos Service Mesh の信頼ドメインとも呼ばれます。