用語集
このページでは、Anthos Service Mesh のドキュメントで使用されている用語の簡単な定義と詳細情報へのリンクをまとめています。
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 Cloud サービスであり、信頼性、アップグレード、スケーリング、セキュリティに関することは Google が行います。お客様は構成を行うだけです。マネージド Anthos Service Mesh は、マネージド コントロール プレーンとオプションのマネージド データプレーンで構成されます。
クラスタ内コントロール プレーン: クラスタにインストールされる
istiod
です。これは Google がサポートするディストリビューションです。istiod
を使用して Anthos Service Mesh をインストールする場合は、セキュリティとスケーリングのアップグレードと構成はユーザーの責任となります。
コントロール プレーンは構成をサイドカー プロキシに配信しますが、コントロール プレーンはメッシュ内のワークロードのトラフィックを直接処理しません。
D
- データプレーン
- データプレーンは、ワークロード インスタンス間の通信を直接制御するメッシュの一部です。Anthos Service Mesh のデータプレーンは、サイドカーとしてデプロイされたプロキシを使用して、メッシュ サービスが送受信するすべての TCP トラフィックを仲介および制御します。マネージド Anthos Service Mesh はマネージド データプレーンを提供します。
E
- Egress ゲートウェイ
- Egress ゲートウェイは Envoy プロキシです。このプロキシを使用すると、メッシュから送信されるトラフィック専用の exit ノードを構成できます。Gateway カスタム リソースを使用してプロキシを構成します。Egress ゲートウェイを使用すると、外部ネットワークにアクセスできるサービスやアクセスする必要があるサービスを制限できます。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。
F
- フリート
- フリートを使用してクラスタを整理すると、複数のクラスタを簡単に管理できます。フリートにクラスタを登録すると、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 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
trust domain
、namespace
、service account
のタプル。ワークロードの x509 証明書内では、SPIFFE ID の形式(spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount>
)になります。その他の認証情報タイプ(OIDC トークンなど)では形式が異なる場合があります。- Workload Identity プール
- 信頼境界線。Anthos Service Mesh の信頼ドメインとも呼ばれます。