Anthos Service Mesh 1.12 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

用語集

このページでは、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

カナリアクラスタの移行

カナリアクラスタの移行は、Istio から Anthos Service Mesh への移行に使用される一般的な移行戦略です。この場合、別の新しいクラスタで Anthos Service Mesh を有効にします。カナリアクラスタの移行戦略については、チュートリアル Istio 1.11 以降をマネージド Anthos Service Mesh に移行するで説明しています。クラスタ内の Anthos Service Mesh からマネージド Anthos Service Mesh に移行する場合にも、カナリアクラスタの移行を使用できます。もう一つの一般的な移行戦略としては、カナリアコントロールプレーンの移行があります。

カナリアコントロールプレーンの移行

カナリアコントロールプレーンの移行は、Istio から Anthos Service Mesh への移行に使用される一般的な移行戦略です。この場合、Anthos Service Mesh は、Istio がインストールされた既存のクラスタで有効になります。移行では、データプレーンが Anthos Service Mesh を使用するように名前空間の再ラベル付けが行われます。クラスタ内の Anthos Service Mesh からマネージド Anthos Service Mesh に移行する場合にも、カナリアクラスタの移行を使用できます。もう一つの一般的な移行戦略としては、カナリアクラスタの移行があります。

カナリアアップグレード

リビジョンベースのアップグレードをご覧ください。

正規サービス

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

コントロールプレーン

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

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

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

D

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

E

Egress ゲートウェイ: Egress ゲートウェイは Envoy プロキシです。このプロキシを使用すると、メッシュから送信されるトラフィック専用の exit ノードを構成できます。Gateway カスタムリソースを使用してプロキシを構成します。Egress ゲートウェイを使用すると、外部ネットワークにアクセスできるサービスやアクセスする必要があるサービスを制限できます。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。

F

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

H

ハイドレードマニフェスト: ターゲットにデプロイする準備ができているマニフェスト。マニフェストをハイドレートするには、通常、Helm、Kustomize、kpt などのツールを使用してマニフェストの変数の値を設定します。

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 ゲートウェイは、メッシュの外部からのトラフィックを処理するロードバランサとして機能する Envoy プロキシです。Gateway カスタムリソースを使用してロードバランサを構成し、仮想サービスと認証ポリシーを作成して、受信トラフィックの保護とワークロードへのルーティング方法を制御します。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。

インジェクション

インジェクション（自動インジェクション）とは、作成時に変更用 Webhook を使用して Pod の仕様を変更することです。インジェクションを使用して、メッシュサービスに Envoy プロキシサイドカー構成を追加し、ゲートウェイの Envoy プロキシを構成します。

インプレースアップグレード

インプレースアップグレードは、既存のコントロールプレーンを新しいリビジョンに置き換えます。ベストプラクティスとして、リビジョンベースのアップグレードをおすすめします。

istiod

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

IstioOperator

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

M

マネージドインスタンスグループ（MIG）

最小 MIG サイズである VM 1 個から開始して、複数の同じ VM でアプリケーションを実行できます。自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイメント、自動更新などの自動化 MIG サービスを活用することで、スケーラブルで可用性に優れたワークロード処理を実現します。詳細については、マネージドインスタンスグループ（MIG）をご覧ください。

マニフェスト

Pod、Deployment、Service、Ingress などの Kubernetes リソースの作成、変更、削除に使用される Kubernetes 構成オブジェクト。Anthos Service Mesh のドキュメントでは、コントロールプレーンの構成に使用するマニフェストをオーバーレイファイルと表記しています。

マニフェストは、レンダリング（ハイドレートとも呼ばれます）されているか、レンダリングされていないか、のいずれかの状態で存在します。レンダリングされていないマニフェストは、ターゲットにデプロイする準備ができていません。多くの場合、マニフェストへの特定の値の入力などを行うレンダリングプロセスは、Helm、Kustomize、kpt などのツールによって実行されます。

Mesh CA

mTLS 証明書を管理する、Google が管理する認証局の名前。Google Cloud の GKE クラスタに Anthos Service Mesh をインストールすると、Mesh CA がデフォルトで有効になります。また、Anthos Service Mesh 1.10 以降を GKE on VMware やベアメタル版 Anthos クラスタにインストールする場合、オプションで Mesh CA を有効にできます。詳細については、セキュリティの概要をご覧ください。

相互 TLS

Anthos Service Mesh は、メッシュ内のサービス間の認証と暗号化に相互 TLS（mTLS）を使用します。mTLS を使用すると、ワークロードが互いの ID を検証でき、相互に認証できます。HTTPS では、ブラウザがウェブサーバーを信頼し、暗号化されたデータを交換するためにシンプルな TLS が使用されています。シンプルな TLS では、クライアントは証明書を検証してサーバーが信頼できるかどうか確認します。mTLS は、クライアントとサーバーの両方が相互に証明書を提示し、互いの ID を検証します。

N

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

O

オーバーレイファイル: IstioOperator カスタムリソース（CR）を含む YAML ファイル。オーバーレイファイルを使用して、クラスタ内のコントロールプレーンを構成します。デフォルトのコントロールプレーン構成をオーバーライドし、asmcli install に渡す 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 の信頼ドメインとも呼ばれます。