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 が含まれます。

サイドカーインジェクタ

インストール中に Webhook 構成が作成されます。Kubernetes API サーバーに Webhook を登録します。
Kubernetes API サーバーは、Webhook namespaceSelector に一致する名前空間で Pod のデプロイを監視します。
名前空間にラベルが付けられ、namespaceSelector で照合されます。
名前空間にデプロイされた Pod が Webhook をトリガーします。
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 を選択し、サイドカーを挿入します。

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

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

カナリアアップグレード

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

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

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

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

概要

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

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

サービス メッシュの基本