Anthos Service Mesh 1.11 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

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

利用可能なバージョン

Mesh CA に移行する

Istio CA（Citadel）から Anthos Service Mesh 認証局（Mesh CA）に移行するには、ルートオブトラストを移行する必要があります。Anthos Service Mesh 1.10 より前では、Google Kubernetes Engine（GKE）の Istio から Mesh CA を使用する Anthos Service Mesh に移行する場合、Anthos Service Mesh で複数のルート証明書を読み込むことができないため、ダウンタイムのスケジューリングが必要になりました。したがって、移行中、新しくデプロイされたワークロードは新しいルート証明書を信頼しますが、他のワークロードは古いルート証明書を信頼します。異なるルート証明書で署名された証明書を使用するワークロードは相互に認証できません。つまり、移行中は相互 TLS（mTLS）トラフィックが中断されます。クラスタ全体は、コントロールプレーンとすべての名前空間のすべてのワークロードが Mesh CA の証明書で再デプロイされたときにのみに完全復旧します。複数のクラスタがあり、ワークロードが他のクラスタにリクエストを送信している場合は、これらのクラスタのすべてのワークロードも更新する必要があります。

このページでは、ダウンタイムを最小限に抑えながら Istio CA から Mesh CA に移行する方法について説明します。このガイドでは、次のユースケースについて説明します。

GKE の Istio から Mesh CA を使用する Anthos Service Mesh 1.11.8-asm.4 クラスタ内コントロールプレーンに移行する。
Istio CA を使用する Anthos Service Mesh 1.9 or a 1.10 patch release から Mesh CA を使用する Anthos Service Mesh 1.11.8-asm.4 クラスタ内コントロールプレーンにアップグレードする。

制限事項

Mesh CA は GKE でのみサポートされています。
すべての GKE クラスタが同じ Google Cloud プロジェクト内にある必要があります。

前提条件

スタートガイドの手順に沿って、以下を行ってください。

必要なツール

移行中に、Google 提供のツール migrate_ca を実行して、クラスタ内の各 Pod に対して次のことを確認します。

Istio CA と Mesh CA のルート証明書。
Istio CA と Mesh CA によって発行されたワークロード mTLS 証明書。
Istio CA と Mesh CA によって構成された信頼ドメイン。

このツールには、次の依存関係があります。

awk
grep
istioctl install_asm ツールを実行すると、インストールする Anthos Service Mesh のバージョンと一致する istioctl のバージョンがダウンロードされます。
jq
kubectl
openssl

移行の概要

Mesh CA に移行するには、リビジョンベースの移行プロセス（カナリアアップグレードとも呼ばれます）を行います。リビジョンベースの移行では、既存のコントロールプレーンと一緒に新しいコントロールプレーンのリビジョンがデプロイされます。その後、ワークロードを新しいリビジョンに段階的に移行します。これにより、移行プロセスの結果をモニタリングできます。移行プロセス中は、Mesh CA を使用するワークロードと Istio CA を使用するワークロードの間で認証と認可が完全に機能します。

Mesh CA への移行の概要は次のとおりです。

Mesh CA のルートオブトラストを配布します。
1. Mesh CA ルートオブトラストを配布するオプションを使用して、Istio CA を使用する新しいコントロールプレーンのリビジョンをインストールします。
2. 名前空間ごとにワークロードを新しいコントロールプレーンに移行し、アプリケーションをテストします。すべてのワークロードが新しいコントロールプレーンに正常に移行されたら、古いコントロールプレーンを削除します。
Mesh CA に移行します。すべてのサイドカープロキシが古いルートオブトラストと Mesh CA のルートオブトラストで構成されたので、ダウンタイムなしで Mesh CA に移行できます。前述のとおり、リビジョンベースの移行プロセスを行います。
1. Mesh CA を有効にしてコントロールプレーンのリビジョンをインストールします。
2. 名前空間ごとにワークロードを新しいコントロールプレーンリビジョンに移行し、アプリケーションをテストします。すべてのワークロードが新しいコントロールプレーンに正常に移行されたら、古いコントロールプレーンを削除します。
3. 古い CA に関連付けられているクラスタの CA Secret を削除し、新しいコントロールプレーンを再起動します。

Mesh CA ルートオブトラストを配布する

Mesh CA に移行する前に、メッシュ内のすべての GKE クラスタに Anthos Service Mesh 1.10 以降が必要です。また、クラスタ内のすべてのワークロードのプロキシへの Mesh CA ルートオブトラストの配布をトリガーするコントロールプレーンオプションをすべてのクラスタに構成します。このプロセスが完了すると、各プロキシは古いルートと新しいルートオブトラストの両方を使用して構成されます。このスキームでは、Mesh CA に移行すると、Mesh CA を使用するワークロードは古い CA を使用するワークロードで認証できるようになります。

新しいコントロールプレーンリビジョンをインストールする

Mesh CA ルートオブトラストの配布オプションを使用して、コントロールプレーンのリビジョンをインストールします。

スタートガイドの手順に沿って、Google 提供のツール asmcli を使用して新しいコントロールプレーンのリビジョンをインストールする準備を行います。
Anthos Service Mesh 1.11 以降をインストールする asmcli のバージョンがあることを確認します。
```
./asmcli --version
```

asmcli install を実行します。次のコマンドのプレースホルダは実際の値に置き換えます。

 ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH \
   --option ca-migration-citadel \
   --revision_name REVISION_1 \
   --output_dir DIR_PATH

--fleet_id: フリートホストプロジェクトのプロジェクト ID。
--kubeconfig: kubeconfig ファイルのパス。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
--output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
--enable_all ツールを使用して次のことができます。
- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- フリートにクラスタを登録する（まだ登録されていない場合）。
-ca citadel: ダウンタイムを回避するには、Istio CA を指定します（citadel オプションは Istio CA に対応します）。この時点では、まだ Mesh CA に切り替えないでください。
--ca_cert: 中間証明書
--ca_key: 中間証明書の鍵
--root_cert: ルート証明書
--cert_chain: 証明書チェーン
--option ca-migration-citadel: ワークロードを再デプロイするすると、このオプションにより、ワークロードのサイドカープロキシへの新しいルートオブトラストの配布がトリガーされます。
REVISION_1: 推奨。リビジョンラベルは、コントロールプレーンで設定されている Key-Value ペアです。リビジョンラベルキーは常に istio.io/rev になります。デフォルトでは、スクリプトは Anthos Service Mesh のバージョンに基づいてリビジョンラベルの値を設定します（例: asm-1118-4）。このオプションを指定して、REVISION_1 をインストールの名前（asm-1118-4-distribute-root など）に置き換えることをおすすめします。名前は DNS-1035 のラベルにします。ラベルには小文字の英数字または - を使用し、ラベルの先頭は英字に、ラベルの末尾は英数字にする必要があります（例: my-name、abc-123）。

ワークロードを新しいコントロールプレーンに移行する

新しいルートオブトラストの配布を終了するには、リビジョンラベル istio.io/rev=<var>REVISION_1</var>-distribute-root を使用して名前空間にラベルを設定し、ワークロードを再起動する必要があります。再起動後にワークロードをテストするには、ツールを実行して、サイドカープロキシに Mesh CA の新旧両方のルートオブトラストが構成されていることを確認します。

kubectl の現在のコンテキストを設定します。シングルゾーンクラスタの場合は、次のコマンドの --region を --zone に変更します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION
```

検証ツールをダウンロードします。

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca

ツールで実行可能ビットを設定します。
```
chmod +x migrate_ca
```
migrate_ca ツールは、バージョンに依存する istioctl を呼び出します。asmcli ツールは、--output_dir に指定したディレクトリの istioctl にシンボリックリンクを追加します。ディレクトリがパスの先頭にあることを確認します。次のコマンドで、ISTIOCTL_PATH はツールがダウンロードした istioctl を含むディレクトリに置き換えます。
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

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

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

出力は次のようになります。

NAME                                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

出力の REV 列で、新しいリビジョンのリビジョンラベルの値をメモします。この値は、asmcli install を実行したときに指定したリビジョンラベルと一致します。この例の値は asm-1118-4-distribute-root です。
ワークロードを新しいリビジョンに移行したら、istiod の古いリビジョンを削除する必要があります。古い istiod リビジョンのリビジョンラベルの値をメモします。この出力例は、default リビジョンを使用している Istio からの移行を示しています。

リビジョンラベルを名前空間に追加し、istio-injection ラベルを削除します（ある場合）。次のコマンドで、NAMESPACE はラベルを付ける名前空間に置き換えます。
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
```
出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。
Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n NAMESPACE
```
アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
クラスタ上のすべてのワークロードのサイドカープロキシが、古いルート証明書と新しいルート証明書の両方で構成されていることを確認します。
```
./migrate_ca check-root-cert
```
予想される出力:
```
Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
```
ゲートウェイを移行する必要がある場合は、カナリアアップグレード（高度）の手順に沿って新しいゲートウェイデプロイをインストールします。その際、以下の点にご注意ください。
- リビジョンラベルとして REVISION_1 を使用します。
- 以前インストールしたゲートウェイと同じ名前空間にゲートウェイリソースをデプロイして、ゼロダウンタイムでの移行を実行します。古いゲートウェイを指すサービスリソースに、新しいデプロイも含めるようにしてください。
- アプリケーションが正常に動作していることを確認する（次のステップの後）まで、古いゲートウェイデプロイを削除しないでください。
アプリケーションが想定どおりに動作していることを確認したら、istiod の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。
移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロールプレーンを削除して新しいバージョンへの移行を完了します。
1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。
2. 新しいコントロールプレーンを使用するように検証 Webhook を構成します。
  kubectl apply -f asm/istio/istiod-service.yaml
3. 古い 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 から移行した場合、古い istio-ingressgateway にはリビジョンラベルがありません。
  
  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. ステップ 11 の一部としてインストールした新しいゲートウェイデプロイを削除します。
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 Deployment を削除します。
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
6. istiod の新しいリビジョンを削除します。
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
7. 新しい IstioOperator 構成を削除します。
  kubectl delete IstioOperator installed-state-asm-1118-4-distribute-root -n istio-system
  予想される出力は次のようになります。
  istiooperator.install.istio.io "installed-state-asm-1118-4-distribute-root" deleted