このページでは、コントロール プレーンのリビジョンの仕組みと、それを使用してサービス メッシュのアップグレード(およびロールバック)を安全に行う方法について説明します。
サービス メッシュ インストールの基礎
Anthos Service Mesh のインストールは、大きく分けて 2 つのフェーズから構成されます。
まず、
asmcli
ツールを使用して、クラスタ内コントロール プレーンをインストールするか、Google が管理するコントロール プレーンを構成します。コントロール プレーンは、メッシュ構成を管理する一連のシステム サービスで構成されます。次に、特殊なサイドカー プロキシを環境全体にデプロイして、各ワークロードとネットワーク間の通信をインターセプトします。プロキシはコントロール プレーンと通信して構成を取得します。これにより、ワークロードを変更せずに、メッシュ間のトラフィック(データプレーン トラフィック)を誘導および制御できます。
プロキシをデプロイするには、自動サイドカー インジェクション(自動挿入)というプロセスを使用して、各ワークロード Pod で追加のサイドカー コンテナとしてプロキシを実行します。ワークロードのデプロイに使用する Kubernetes マニフェストを変更する必要はありませんが、名前空間にラベルを追加して Pod を再起動する必要があります。
リビジョンを使用してメッシュを安全にアップグレードする
トラフィックの制御機能は、サービス メッシュを使用する主なメリットの 1 つです。たとえば、アプリケーションを本番環境に最初にデプロイするときに、トラフィックを新しいバージョンのアプリケーションに段階的にシフトできます。アップグレード中に問題が検出された場合、トラフィックを元のバージョンに戻すことができるため、シンプルでリスクの低い方法でロールバックできます。この手順はカナリア リリースと呼ばれ、これにより新しいデプロイに伴うリスクが大幅に軽減されます。
カナリア アップグレードでは、コントロール プレーンのリビジョンを使用して、既存のコントロール プレーンと一緒に新しいコントロール プレーンとその構成をインストールします。インストーラは、新しいコントロール プレーンを識別するために revision という文字列を割り当てます。まず、サイドカー プロキシが以前のバージョンのコントロール プレーンから構成を受信します。名前空間のラベルを新しいコントロール プレーンのリビジョンに付けることで、ワークロードを新しいコントロール プレーンに段階的に関連付けます。新しいリビジョンで名前空間に名前を付けたら、ワークロード Pod を再起動します。新しいサイドカーが自動挿入され、その構成を新しいコントロール プレーンから受け取ります。問題がある場合は、ワークロードを元のコントロール プレーンに関連付けることで、簡単にロールバックできます。
自動挿入の仕組み
自動挿入では、アドミッション コントロールと呼ばれる Kubernetes 機能を使用します。新たに作成された Pod を監視するために、変更用アドミッション Webhook が登録されます。Webhook は、特定のラベルを持つ Namespace にデプロイされている Pod のみと一致するように、Namespace セレクタを使用して構成されています。Pod が一致すると、Webhook がコントロール プレーンから提供されたインジェクション サービスを利用して、Pod の変更済みの新しい構成を取得します。これには、サイドカーの実行に必要なコンテナとボリュームが含まれます。
- インストール中に Webhook 構成が作成されます。Webhook は Kubernetes API サーバーに登録されます。
- 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 が管理するコントロール プレーンとクラスタ内コントロール プレーンでは異なります。
クラスタ内コントロール プレーンの場合、
istiod
Service と Deployment には通常istio.io/rev=asm-1129-3
のようなリビジョン ラベルがあります。ここで、asm-1129-3
は Anthos Service Mesh のバージョンを表します。リビジョンはサービス名の一部になります(例:istiod-asm-1129-3.istio-system
)。Google が管理するコントロール プレーンの場合、リビジョン ラベルはリリース チャネルに対応します。
リビジョン ラベル チャネル istio.io/rev=asm-managed
標準 istio.io/rev=asm-managed-rapid
迅速 istio.io/rev=asm-managed-stable
Stable
自動挿入を有効にするには、コントロール プレーンのリビジョン ラベルと一致するリビジョンの名前空間を追加します。たとえば、リビジョン istio.io/rev=asm-1129-3
のコントロール プレーンは、ラベル istio.io/rev=asm-1129-3
の名前空間の 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: '*'