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

Anthos Service Mesh コントロール プレーンのリビジョン

このページでは、コントロール プレーンのリビジョンの仕組みと、それを使用して安全なサービス メッシュのアップグレード(およびロールバック)を行う方法について説明します。バージョン 1.6.8 までは、Anthos Service Mesh のデフォルト インストール プロセスでコントロール プレーンのリビジョンは使用されていませんでした。リビジョンを初めて導入する場合、慣れるまでインストール手順に対する変更や変更が必要になる可能性がありますが、メリットが大きいことからリビジョンの使用を強くおすすめします。

サービス メッシュの基本

Anthos Service Mesh のインストールは 2 つの部分から構成されています。これらは通常、install_asm スクリプトで自動化されています。まず、istioctl コマンドライン ツールと IstioOperator YAML ファイルを使用して、コントロール プレーンとその構成をインストールします。コントロール プレーン(istiod とも呼ばれます)は、メッシュ構成を管理する一連のシステム サービスで構成されます。次に、特殊なサイドカー プロキシを環境全体にデプロイして、各ワークロードとネットワーク間の通信をインターセプトします。プロキシはコントロール プレーンと通信して構成を取得します。これにより、ワークロードを変更せずに、メッシュ間のトラフィック(データプレーン トラフィック)を誘導および制御できます。

プロキシをデプロイするには、自動サイドカー インジェクション(自動挿入)というプロセスを使用して、各ワークロード Pod で追加のサイドカー コンテナとしてプロキシを実行します。ワークロードのデプロイに使用する Kubernetes マニフェストを変更する必要はありませんが、名前空間にラベルを追加して Pod を再起動する必要があります。

Anthos Service Mesh 1.6 以前は、コントロール プレーンの新しいバージョンをインストールすることでアップグレードされ、すぐに古いバージョンが新しいバージョンに置き換えられていました。この手順はインプレース アップグレードと呼ばれ、障害が発生するとロールバックが困難なため、リスクが伴います。プロキシを再挿入して、新しいコントロール プレーン バージョンと通信するには、すべての名前空間内のすべてのワークロードを再起動する必要があります。メッシュ内のワークロードと名前空間の数によっては、アップグレード プロセス全体に 1 時間以上かかることもあります。インプレース アップグレードはダウンタイムを伴う可能性があるため、メンテナンスの時間枠でスケジュールする必要があります。

リビジョンを使用してメッシュを安全にアップグレードする

トラフィックの制御機能は、サービス メッシュを使用する主なメリットの 1 つです。たとえば、アプリケーションを本番環境に最初にデプロイするときに、トラフィックを新しいバージョンのアプリケーションに段階的にシフトできます。アップグレード中に問題が検出された場合、トラフィックを元のバージョンに戻すことができるため、シンプルでリスクの低い方法でロールバックできます。この手順はカナリア リリースと呼ばれ、これにより新しいデプロイに伴うリスクが大幅に軽減されます。

同様に、サービス メッシュ自体のアップグレードに伴うリスクを最小限に抑えることもできます。Anthos Service Mesh 1.6 以降では、コントロール プレーンのリビジョンを使用したカナリア アップグレードがサポートされています。カナリア アップグレードでは、既存のコントロール プレーンと一緒に新しいコントロール プレーンとその構成をインストールします。インストーラは、新しいコントロール プレーンを識別するために revision という文字列を割り当てます。まず、サイドカー プロキシが以前のバージョンのコントロール プレーンから構成を受信します。名前空間のラベルを新しいコントロール プレーンのリビジョンに付けることで、ワークロードを新しいコントロール プレーンに段階的に関連付けます。新しいリビジョンで名前空間に名前を付けたら、ワークロード Pod を再起動します。新しいサイドカーが挿入され、その構成を新しいコントロール プレーンから受け取ります。問題がある場合は、ワークロードを元のコントロール プレーンに関連付けることで、簡単にロールバックできます。

自動挿入の仕組み

自動挿入では、アドミッション コントロールと呼ばれる Kubernetes 機能を使用します。新たに作成された Pod を監視するために、変更用アドミッション Webhook が登録されます。Webhook は、特定のラベルを持つ Namespace にデプロイされている Pod のみと一致するように、名前空間セレクタを使用して構成されています。Pod が一致すると、Webhook は istio から提供されたインジェクション サービスをコンサルトして、Pod の変更済みの新しい構成を取得します。これには、サイドカーの実行に必要なコンテナと Volume が含まれます。

サイドカー インジェクタ

  1. インストール中に Webhook 構成が作成されます。Kubernetes API サーバーに Webhook を登録します。
  2. Kubernetes API サーバーは、Webhook namespaceSelector に一致する名前空間で Pod のデプロイを監視します。
  3. 名前空間にラベルが付けられ、namespaceSelector で照合されます。
  4. 名前空間にデプロイされた Pod が Webhook をトリガーします。
  5. istiod 提供の inject サービスは、Pod を変化させてサイドカーを挿入します。

リビジョンとは

自動挿入に使用されるラベルは、他のユーザー定義の Kubernetes ラベルに似ています。ラベルは基本的に、タグのコンセプトをサポートするために使用できる Key-Value ペアです。ラベルはタグ付けやリビジョンに広く使用されています(例: Git タグ、Docker タグ、Knative のリビジョン)。

Anthos Service Mesh バージョン 1.6.8 までは、デフォルトのインストール手順では、ラベル istio-injection=enabled を使用するように Webhook の名前空間セレクタを構成するための規則が確立されていました。

現在の Anthos Service Mesh のインストール プロセスでは、インストール済みのコントロール プレーンをリビジョン文字列でタグ付けできます。これは、istioctl コマンドへの revision 引数として、そして IstioOperator カスタム リソース内のフィールドとしても使用できます。インストーラは、istiod Service と Deployment を含む、すべてのコントロール プレーン オブジェクトにリビジョンのラベルを付けます。リビジョンはサービス名の一部になります(例: istiod-asm-173-6.istio-system)。

名前空間に対応するラベルキーは istio.io/rev です。この値は通常、メッシュのバージョンを示すように設定されています。たとえば、リビジョン asm-173-6 のコントロール プレーンは、ラベル istio.io/rev=asm-173-6 の名前空間の Pod を選択し、サイドカーを挿入します。

カナリア アップグレード プロセス

リビジョン ラベルを使用すると、コントロール プレーンのカナリア アップグレードと簡単なロールバックを実行できます。

カナリア アップグレード

以下の手順ではプロセスについて説明します。

  1. 既存の Anthos Service Mesh またはオープンソースの Istio インストールから始めます。名前空間でリビジョン ラベルと istio-injection=enabled ラベルのどちらを使用していても問題ありません。
  2. 新しいバージョンのコントロール プレーンをインストールする場合は、リビジョン文字列を使用します。リビジョン文字列により、既存のバージョンと一緒に新しいコントロール プレーンがインストールされます。新しいインストールには、特定のリビジョン ラベルで名前空間を監視するように構成された namespaceSelector を使用した新しい Webhook 構成が含まれています。
  3. サイドカー プロキシを新しいコントロール プレーンに移行するには、Namespace から古いラベルを削除し、新しいリビジョン ラベルを追加してから、Pod を再起動します。Anthos Service Mesh でリビジョンを使用する場合は、istio-injection=enabled ラベルの使用を停止する必要があります。リビジョンを使用したコントロール プレーンは、リビジョン ラベルがあっても、istio-injection のラベルが付いた名前空間内の Pod を選択しません。新しいコントロール プレーンの Webhook は、Pod にサイドカーを挿入します。
  4. アップグレードされたコントロール プレーンに関連付けられているワークロードを十分にテストし、アップグレードをロールアウトするか、元のコントロール プレーンにロールバックします。

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 で istiod によって公開されます。

rules セクションでは、Webhook を Pod の作成に適用するように指定します。

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

概要

Namespace でリビジョン ラベルを使用して自動挿入を有効にするには、多少の慣れが必要になる場合もありますが、安全なカナリア アップグレードを可能にするリビジョンにはその努力に見合うメリットがあります。

次のステップ