このページでは、コントロール プレーンのリビジョンの仕組みと、それを使用して安全なサービス メッシュのアップグレード（およびロールバック）を行う方法について説明します。バージョン 1.6.8 までは、Anthos Service Mesh のデフォルト インストール プロセスでコントロール プレーンのリビジョンは使用されていませんでした。リビジョンを初めて導入する場合、慣れるまでインストール手順に対する変更や変更が必要になる可能性がありますが、メリットが大きいことからリビジョンの使用を強くおすすめします。
サービス メッシュの基本
Anthos Service Mesh のインストールは、次の 2 つの主要部分で構成されています。まず、istioctl コマンドライン ツールまたは install_asm スクリプトを使用して、クラスタ内コントロール プレーンをインストールするか、Google が管理するコントロール プレーンを構成します。コントロール プレーンは、メッシュ構成を管理する一連のシステム サービスで構成されます。次に、各ワークロードとネットワーク間の通信をインターセプトする特殊なサイドカー プロキシを環境全体にデプロイします。プロキシはコントロール プレーンと通信して構成を取得します。これにより、ワークロードを変更せずに、メッシュ間のトラフィック（データプレーン トラフィック）を誘導および制御できます。
プロキシをデプロイするには、自動サイドカー インジェクション（自動挿入）というプロセスを使用して、各ワークロード Pod で追加のサイドカー コンテナとしてプロキシを実行します。ワークロードのデプロイに使用する Kubernetes マニフェストを変更する必要はありませんが、名前空間にラベルを追加して Pod を再起動する必要があります。
Anthos Service Mesh 1.6 以前は、コントロール プレーンの新しいバージョンをインストールすることでアップグレードされ、すぐに古いバージョンが新しいバージョンに置き換えられていました。この手順はインプレース アップグレードと呼ばれ、障害が発生するとロールバックが困難なため、リスクが伴います。プロキシを再挿入して、新しいコントロール プレーン バージョンと通信するには、すべての名前空間内のすべてのワークロードを再起動する必要があります。メッシュ内のワークロードと名前空間の数によっては、アップグレード プロセス全体に 1 時間以上かかることもあります。インプレース アップグレードはダウンタイムを伴う可能性があるため、メンテナンスの時間枠でスケジュールする必要があります。
リビジョンを使用してメッシュを安全にアップグレードする
トラフィックの制御機能は、サービス メッシュを使用する主なメリットの 1 つです。たとえば、アプリケーションを本番環境に最初にデプロイするときに、トラフィックを新しいバージョンのアプリケーションに段階的にシフトできます。アップグレード中に問題が検出された場合、トラフィックを元のバージョンに戻すことができるため、シンプルでリスクの低い方法でロールバックできます。この手順はカナリア リリースと呼ばれ、これにより新しいデプロイに伴うリスクが大幅に軽減されます。
同様に、サービス メッシュ自体のアップグレードに伴うリスクを最小限に抑えることもできます。Anthos Service Mesh 1.6 以降では、コントロール プレーンのリビジョンを使用したカナリア アップグレードがサポートされています。カナリア アップグレードでは、既存のコントロール プレーンと一緒に新しいコントロール プレーンとその構成をインストールします。インストーラは、新しいコントロール プレーンを識別するために revision という文字列を割り当てます。まず、サイドカー プロキシが以前のバージョンのコントロール プレーンから構成を受信します。名前空間のラベルを新しいコントロール プレーンのリビジョンに付けることで、ワークロードを新しいコントロール プレーンに段階的に関連付けます。新しいリビジョンで名前空間に名前を付けたら、ワークロード Pod を再起動します。新しいサイドカーが挿入され、その構成を新しいコントロール プレーンから受け取ります。問題がある場合は、ワークロードを元のコントロール プレーンに関連付けることで、簡単にロールバックできます。
自動挿入の仕組み
自動挿入では、アドミッション コントロールと呼ばれる Kubernetes 機能を使用します。新たに作成された Pod を監視するために、変更用アドミッション Webhook が登録されます。Webhook は、特定のラベルを持つ Namespace にデプロイされている Pod のみと一致するように、Namespace セレクタを使用して構成されています。Pod が一致すると、Webhook がコントロール プレーンから提供されたインジェクション サービスを利用して、Pod の変更済みの新しい構成を取得します。これには、サイドカーの実行に必要なコンテナとボリュームが含まれます。
- インストール中に Webhook 構成が作成されます。Kubernetes API サーバーに Webhook を登録します。
- Kubernetes API サーバーは、Webhook
namespaceSelectorに一致する名前空間で Pod のデプロイを監視します。 - 名前空間にラベルが付けられ、
namespaceSelectorで照合されます。 - 名前空間にデプロイされた Pod が Webhook をトリガーします。
- コントロール プレーンが提供する
injectサービスは、Pod 仕様を変化させてサイドカーを挿入します。
リビジョンとは
自動挿入に使用されるラベルは、他のユーザー定義の Kubernetes ラベルに似ています。ラベルは基本的に、タグのコンセプトをサポートするために使用できる Key-Value ペアです。ラベルはタグ付けやリビジョンに広く使用されています（例: Git タグ、Docker タグ、Knative のリビジョン）。
Anthos Service Mesh バージョン 1.6.8 までのデフォルトのインストール手順では、ラベル istio-injection=enabled を使用するように Webhook の名前空間セレクタを構成するための規則が確立されていました。
現在の Anthos Service Mesh のインストール プロセスでは、インストール済みのコントロール プレーンをリビジョン文字列でタグ付けできます。インストーラは、すべてのコントロール プレーン オブジェクトにリビジョンをラベル付けします。Key-Value ペアのキーは istio.io/rev ですが、リビジョン ラベルの値は Google が管理するコントロール プレーンとクラスタ内コントロール プレーンでは異なります。
クラスタ内コントロール プレーンの場合、
istiodService と Deployment には通常istio.io/rev=asm-198-6のようなリビジョン ラベルがあります。ここで、asm-198-6は Anthos Service Mesh のバージョンを表します。リビジョンはサービス名の一部になります（例:istiod-asm-198-6.istio-system）。Google が管理するコントロール プレーンの場合、リビジョン ラベルはリリース チャネルに対応します。
リビジョン ラベル チャネル istio.io/rev=asm-managed標準 istio.io/rev=asm-managed-rapid迅速 istio.io/rev=asm-managed-stableStable
自動挿入を有効にするには、コントロール プレーンのリビジョン ラベルと一致するリビジョンの名前空間を追加します。たとえば、リビジョン istio.io/rev=asm-198-6 のコントロール プレーンは、ラベル istio.io/rev=asm-198-6 の名前空間の Pod を選択し、サイドカーを挿入します。
カナリア アップグレード プロセス
リビジョン ラベルを使用すると、クラスタ内コントロール プレーンのカナリア アップグレードと簡単なロールバックを実行できます。Google が管理するコントロールは同様のプロセスを使用しますが、クラスタはそのチャネル内の最新バージョンに自動的にアップグレードされます。
以下の手順ではプロセスについて説明します。
- 既存の Anthos Service Mesh またはオープンソースの Istio インストールから始めます。名前空間でリビジョン ラベルと
istio-injection=enabledラベルのどちらを使用していても問題ありません。 - 新しいバージョンのコントロール プレーンをインストールする場合は、リビジョン文字列を使用します。リビジョン文字列により、既存のバージョンと一緒に新しいコントロール プレーンがインストールされます。新しいインストールには、特定のリビジョン ラベルで名前空間を監視するように構成された
namespaceSelectorを使用した新しい Webhook 構成が含まれています。 - サイドカー プロキシを新しいコントロール プレーンに移行するには、Namespace から古いラベルを削除し、新しいリビジョン ラベルを追加してから、Pod を再起動します。Anthos Service Mesh でリビジョンを使用する場合は、
istio-injection=enabledラベルの使用を停止する必要があります。リビジョンを使用したコントロール プレーンは、リビジョン ラベルがあっても、istio-injectionのラベルが付いた名前空間内の Pod を選択しません。新しいコントロール プレーンの Webhook は、Pod にサイドカーを挿入します。 - アップグレードされたコントロール プレーンに関連付けられているワークロードを十分にテストし、アップグレードをロールアウトするか、元のコントロール プレーンにロールバックします。
Pod を新しいコントロール プレーンに関連付けた後に、既存のコントロール プレーンと Webhook がインストールされます。古い Webhook は、新しいコントロール プレーンに移行された Namespace の Pod には影響しません。新しいリビジョン ラベルを削除し、元のラベルを追加して Pod を再起動することで、Namespace 内の Pod を元のコントロール プレーンにロールバックできます。アップグレードが完了したことを確認したら、古いコントロール プレーンを削除できます。
リビジョンを使用してアップグレードする方法については、アップグレード ガイドをご覧ください。
変更用 Webhook 構成の詳細
自動サイドカー インジェクション用の変更用 Webhook を理解するには、構成を自分で検査することをおすすめします。次のコマンドを使用します。
kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml
インストールしたコントロール プレーンごとに個別の構成が表示されます。リビジョンベースのコントロール プレーンの名前空間セレクタは次のようになります。
namespaceSelector:
matchExpressions:
- key: istio-injection
operator: DoesNotExist
- key: istio.io/rev
operator: In
values:
- asm-173-6
セレクタは、実行している Anthos Service Mesh または Istio のバージョンによって異なります。istio-injection ラベルが付いていない限り、このセレクタは特定のリビジョン ラベルを持つ Namespace に一致します。
セレクタに一致する名前空間に Pod がデプロイされると、その Pod の仕様はミューテーションのためにインジェクタ サービスに送信されます。呼び出されるインジェクタ サービスは次のとおりです。
service:
name: istiod-asm-173-6
namespace: istio-system
path: /inject
port: 443
サービスは、コントロール プレーンによって inject URL パスのポート 443 で公開されます。
rules セクションでは、Webhook を Pod の作成に適用するように指定します。
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
scope: '*'
概要
Namespace でリビジョン ラベルを使用して自動挿入を有効にするには、多少の慣れが必要になる場合もありますが、安全なカナリア アップグレードを可能にするリビジョンにはその努力に見合うメリットがあります。