Istio からの移行

このページでは、スクリプトを実行して同じ Google Cloud プロジェクト内にある 1 つ以上のクラスタを含むメッシュの GKE クラスタ上で、Istio から1.7 or 1.8 Anthos Service Mesh 1.8.6へ移行する方法について説明します。

クラスタが異なるプロジェクトにあるマルチクラスタ メッシュについては、マルチクラスタ / マルチ プロジェクト インストールと GKE の移行をご覧ください。

このページでは、Istio から Anthos Service Mesh への移行について説明します。新しいインストールやアップグレード用のスクリプトの実行については、以下をご覧ください。

始める前に

移行を開始する前に、次のことが完了していることを確認してださい。

このスクリプトを使用するには、必要な権限が付与されているか、スクリプトが権限を有効にできるように --enable_all フラグまたは --enable_gcp_iam_roles フラグを追加する必要があります。同様に、スクリプトで必要な API を有効にしてクラスタを更新できるようにするには、--enable_all フラグを指定するか、よりきめ細かい有効化フラグを指定します。

移行の準備

Istio からの移行の準備を必ずご確認ください。

以前のインストールをカスタマイズした場合は、Anthos Service Mesh バージョンにアップグレードするか、Istio から移行する際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、それらの設定をオーバーレイ ファイルと呼ばれる IstioOperator YAML ファイルに追加する必要があります。オーバーレイ ファイルを指定するには、スクリプトの実行時にファイル名で --custom_overlay オプションを使用します。このスクリプトは、オーバーレイ ファイルを istioctl install に渡します。

スクリプトは、リビジョン アップグレード プロセス（Istio ドキュメントでは「カナリア」アップグレード）に沿って実行されます。リビジョン ベースのアップグレードでは、スクリプトは既存のコントロール プレーンを残しながら、コントロール プレーンの新しいリビジョンをインストールします。新しいバージョンをインストールすると、新しいコントロール プレーンを識別する revision ラベルがスクリプトに追加されます。

新しいバージョンへの移行では、ワークロードにこれと同じ revision ラベルを設定し、ローリング再起動を実行してプロキシを再挿入することで、新しい Anthos Service Mesh のバージョンと構成が使用されるようになります。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。この手法は、前のバージョンを新しいコントロール プレーン コンポーネントに置き換えるインプレース アップグレードよりも安全です。

Anthos Service Mesh への移行

  1. オプションを設定し、スクリプトの実行フラグを指定します。常に project_id、cluster_name、cluster_location、mode のオプションを含めます。

    次のセクションでは、スクリプトを実行するための一般的な例について説明します。例の一覧については、右側のナビゲーション バーをご覧ください。スクリプトの引数の詳細については、オプションとフラグをご覧ください。

  2. Anthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。

例

このセクションでは、移行のためにスクリプトを実行する例を、よく使用される引数とともに説明します。例の一覧については、右側のナビゲーション バーをご覧ください。

検証のみ

次の例は、--only_validate オプションを使用してスクリプトを実行する方法を示しています。このオプションを使用すると、プロジェクトやクラスタは変更されず、Anthos Service Mesh はインストールされません。--only_validate を指定した場合、--enable_* フラグのいずれかがあると、スクリプトは失敗します。

このスクリプトは以下のことを検証します。

  • 環境に必要なツールがある。
  • 指定されたプロジェクトに対する必要な権限がある。
  • クラスタが最小要件を満たしている。
  • プロジェクトで必要な Google API がすべて有効になっている。

デフォルトでは、このスクリプトでインストール ファイルをダウンロードして抽出し、GitHub から asm 構成パッケージを一時ディレクトリにダウンロードします。終了する前に、このスクリプトで一時ディレクトリの名前を指定するメッセージが出力されます。--output_dir DIR_PATH オプションを使用して、ダウンロード用の既存のディレクトリを指定できます。--output_dir オプションを使用すると、必要に応じて istioctl コマンドライン ツールを使用できます。また、オプションの機能を有効にする構成ファイルが asm/istio/options ディレクトリにあります。

次のコマンドを実行して構成を検証し、インストール ファイルと asm パッケージを OUTPUT_DIR ディレクトリにダウンロードします。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --output_dir DIR_PATH \
  --only_validate

成功すると、以下が出力されます。

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

いずれかのテストで検証が失敗した場合、エラー メッセージが出力されます。たとえば、プロジェクトで必要な Google API が有効になっていない場合は、次のエラーが表示されます。

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

有効化フラグを使用してスクリプトを実行する必要があるというエラー メッセージが表示された場合は、--only_validate を使用せずにスクリプトを実行するときに、エラー メッセージにある特定のフラグまたは --enable_all フラグを追加できます。必要に応じて、スクリプトを実行する前に、プロジェクトとクラスタを自分で更新することもできます。詳細については、マルチ プロジェクト インストール ガイドのプロジェクトの設定とクラスタの設定セクションをご覧ください。

Citadel を使用した Istio からの移行

CA として Citadel を使用して Istio を移行すると、Anthos Service Mesh に移行した後も引き続き Citadel を使用できます。次のコマンドでは、移行用のスクリプトを実行し、Citadel を CA として有効にします。この移行では、コントロール プレーンのみがデプロイされます。ルート CA を変更することはなく、既存のワークロードに影響が及ぶことはありません。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --option revisioned-istio-ingressgateway \
  --enable_all

オーバーレイ ファイルを使用した移行

オーバーレイ ファイルは IstioOperator カスタム リソース（CR）を含む YAML ファイルです。install_asm に渡してコントロール プレーンを構成します。YAML ファイルを install_asm に渡すことで、デフォルトのコントロール プレーン構成をオーバーライドし、オプション機能を有効にできます。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。

YAML ファイルで複数の CR を指定した場合、install_asm は、ファイルを CR ごとに一時的な YAML ファイルに分割します。istioctl install は、複数の CR を含む YAML ファイルの最初の CR のみを適用するため、このスクリプトは CR を別個のファイルに分割します。

次の例では、移行を行い、オーバーレイ ファイルを含めてコントロール プレーン構成をカスタマイズします。次のコマンドでは、OVERLAY_FILE を YAML ファイルの名前に変更します。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --custom_overlay OVERLAY_FILE

オプションを使用した移行

次の例では、移行を行い、asm パッケージの egressgateways.yaml ファイルを含め、Egress ゲートウェイを有効にします。.yaml 拡張子は含めないように注意してください。スクリプトによってファイルが取得されるため、最初に asm パッケージをダウンロードする必要はありません。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --option egressgateways

--option を使用すると、オプション機能を有効にできます。asm パッケージの asm/istio/options ディレクトリにあるファイルのいずれかを変更する必要がある場合は、asm パッケージをダウンロードして変更し、--custom_overlay を使用してファイルを含めます。

asm パッケージを現在の作業ディレクトリにダウンロードしてファイルを変更するには:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm

--output_dir オプションを指定した検証のみの例を実行した場合、構成ファイルは asm/istio/options の下の指定した出力ディレクトリにあります。

ワークロードのデプロイと再デプロイ

自動サイドカー プロキシ インジェクション（自動挿入）を有効にするまで、インストールは完了しません。OSS Istio からの移行とアップグレードは、リビジョン ベースのアップグレード プロセスに沿って進めます（Istio ドキュメントでは「カナリア アップグレード」と呼ばれます）。リビジョンベースのアップグレードでは、既存のコントロール プレーンに並ぶ形で新しいバージョンのコントロール プレーンがインストールされます。次に、一部のワークロードを新しいバージョンに移行します。これにより、すべてのトラフィックを新しいバージョンに移行する前に、ワークロードのごく一部でアップグレードの影響をモニタリングできます。

このスクリプトは、リビジョン ラベルを istio.io/rev=asm-186-8 形式で istiod に設定します。自動挿入を有効にするには、一致するリビジョン ラベルを名前空間に追加します。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入するために名前空間内の Pod を再起動します。

また、スクリプトによって、リビジョンされた istio-ingressgateway Deployment も作成されます。これにより、新しいバージョンに切り替えるタイミングを管理できます。

  1. istiod と istio-ingressgateway のリビジョン ラベルを取得します。

    kubectl get pod -n istio-system -L istio.io/rev

    このコマンドからの出力は、次のようになります。

    NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-186-8
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-186-8
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-178-10
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-178-10
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-186-8
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-186-8

    1. istio-ingressgateway の古いバージョンと新しいバージョンの両方があることを確認します。

      • アップグレード時に revisioned-istio-ingressgateway オプションを含めた場合は、istio-ingressgateway のカナリア アップグレードは完了です。この場合、出力には istio-ingressgateway の古いバージョンと新しいバージョンの両方が含まれます。

      • アップグレード時に revisioned-istio-ingressgateway を含めなかった場合、istio-ingressgateway のインプレース アップグレードが行われています。この場合、出力には新しいバージョンのみが含まれます。

    2. 出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-186-8 です。

    3. 古い istiod バージョンのリビジョン ラベルの値もメモしてください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この出力例では、古いバージョンのリビジョン ラベルの値は asm-178-10 です。

  2. istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、istio-ingressgateway を新しいリビジョンに切り替えます。次のコマンドで、REVISION を新しいバージョンのリビジョン ラベルと一致する値に変更します。

    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    予想される出力: service/istio-ingressgateway patched

  3. リビジョン ラベルを名前空間に追加し、istio-injection ラベルを削除します（ある場合）。次のコマンドで、REVISION を istiod の新しいリビジョンと一致する値に変更します。

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

    出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

  4. Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE

  5. Pod が新しいバージョンの istiod を指すように構成されていることを確認します。

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  6. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

  7. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。

  8. アプリケーションが想定どおりに動作していることを確認したら、istiod の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。

  9. 次のコマンドをもう一度実行して、istio-ingressgateway の古いバージョンと新しいバージョンの両方が存在するか、新しいバージョンのみであることを確認します。これにより、istio-ingressgateway の新しいバージョンへの移行または古いバージョンへのロールバックの処理方法が決まります。

    kubectl get pod -n istio-system -L istio.io/rev

    移行を完了させる

    アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除して新しいバージョンへの移行を完了します。

    1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。

    2. 新しいコントロール プレーンを使用するように検証 Webhook を構成します。

      kubectl apply -f asm/istio/istiod-service.yaml

    3. istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、古い istio-ingressgateway Deployment を削除します。実行するコマンドは、Istio から移行するか、以前のバージョンの Anthos Service Mesh からアップグレードするかによって異なります。

      移行

      Istio から移行した場合、古い istio-ingressgateway にはリビジョン ラベルがありません。

      kubectl delete deploy/istio-ingressgateway -n istio-system

      アップグレード

      以前の Anthos Service Mesh バージョンからアップグレードした場合は、次のコマンドで、OLD_REVISION を以前のバージョンの istio-ingressgateway のリビジョン ラベルに置き換えます。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. 古いバージョンの istiod を削除します。使用するコマンドは、Istio から移行するか、以前のバージョンの Anthos Service Mesh からアップグレードするかによって異なります。

      移行

      Istio から移行した場合、古い istiod にはリビジョン ラベルがありません。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

      アップグレード

      以前の Anthos Service Mesh バージョンからアップグレードした場合は、次のコマンドで、OLD_REVISION が以前のバージョンの istiod のリビジョン ラベルと一致することを確認します。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true

    5. 古いバージョンの IstioOperator 構成を削除します。

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      想定される出力は次のようになります。

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    ロールバック

    新しいバージョンの istiod でアプリケーションをテストしたときに問題が発生した場合、以前のバージョンにロールバックする手順は次のとおりです。

    1. istio-ingressgateway を古いバージョンに戻します。使用するコマンドは、istio-ingressgateway の古いバージョンと新しいバージョンの両方が存在するのか、新しいバージョンのみが存在するのかによって異なります。

      • 古いバージョンと新しいバージョンの istio-ingressgateway がある場合は、kubectl patch service コマンドを実行し、OLD_REVISION を古いリビジョンに置き換えます。

        kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'

      • 新しいバージョンの istio-ingressgateway のみが存在する場合は、kubectl rollout undo コマンドを実行します。

        kubectl -n istio-system rollout undo deploy istio-ingressgateway

    2. 以前のバージョンの istiod で自動挿入を有効にする場合は、名前空間に再びラベルを付けます。使用するコマンドは、リビジョン ラベルと以前のバージョンの istio-injection=enabled のどちらを使用するかによって異なります。

      • 自動挿入にリビジョン ラベルを使用した場合:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      • istio-injection=enabled を使用した場合:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

      予想される出力:

      namespace/NAMESPACE labeled

    3. 名前空間のリビジョン ラベルが、以前のバージョンの istiod のリビジョン ラベルと一致していることを確認します。

      kubectl get ns NAMESPACE --show-labels

    4. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n NAMESPACE

    5. istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、新しい istio-ingressgateway Deployment を削除します。次のコマンドの REVISION の値が正しいことを確認します。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true

    6. istiod の新しいバージョンを削除します。次のコマンドの REVISION の値が正しいことを確認します。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

    7. 新しいバージョンの IstioOperator 構成を削除します。

      kubectl delete IstioOperator installed-state-REVISION -n istio-system

      予想される出力は次のようになります。

      istiooperator.install.istio.io "installed-state-REVISION" deleted

    8. --disable_canonical_service フラグを含めなかった場合、スクリプトで Canonical Service コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービス コントローラの有効化と無効化をご覧ください。

Anthos Service Mesh ダッシュボードの表示

サイドカー プロキシが挿入されたクラスタにワークロードをデプロイすると、Google Cloud コンソールの Anthos の [サービス メッシュ] ページで、Anthos Service Mesh が提供するすべてのオブザーバビリティ機能を確認できます。ワークロードをデプロイした後、Google Cloud コンソールにテレメトリー データが表示されるまでに 1～2 分ほどかかることがあります。

Google Cloud コンソールでの Anthos Service Mesh へのアクセスは、Identity and Access Management（IAM）によって制御されます。Anthos Service Mesh ページにアクセスするには、プロジェクト オーナーがユーザーに対して、プロジェクト編集者または閲覧者のロール、または、より限定的なロール（Google Cloud コンソールでの Anthos Service Mesh に対するアクセス制御を参照）を付与する必要があります。

  1. Google Cloud コンソールで、[Anthos Service Mesh] に移動します。

    Anthos の [サービス メッシュ] に移動する

  2. メニューバーのプルダウン リストから Google Cloud プロジェクトを選択します。

  3. 複数のサービス メッシュがある場合は、[サービス メッシュ] プルダウン リストからメッシュを選択します。

詳細については、Google Cloud コンソールでの Anthos Service Mesh の確認をご覧ください。

Anthos Service Mesh ページに加えて、サービスに関連する指標（特定のサービスで受信したリクエストの数など）が Cloud Monitoring に送信され、Metrics Explorer に表示されます。

指標を表示するには:

  1. Google Cloud コンソールで、[Monitoring] ページに移動します。

    [Monitoring] に移動

  2. [リソース] > [Metrics Explorer] を選択します。

指標の完全なリストについては、Cloud Monitoring のドキュメントの Istio 指標をご覧ください。

次のステップ