Apigee ハイブリッドのバージョン 1.8 へのアップグレード

注: この手順では、Apigee ハイブリッドバージョン 1.7.x または Apigee ハイブリッドバージョン 1.8.x の以前のリリースから、Apigee ハイブリッドバージョン 1.8.8 へのアップグレードについて説明します。

マイナーバージョンのアップグレード（バージョン 1.7 から 1.8 など）とパッチリリースアップグレード（1.8.0 から 1.8.8 など）に同じ手順を使用します。

Apigee ハイブリッドのバージョン 1.6 以前からアップグレードする場合は、まずバージョン 1.7 にアップグレードした後、ハイブリッドのバージョン 1.8.8 にアップグレードする必要があります。Apigee ハイブリッドバージョン 1.7 へのアップグレードの手順をご覧ください。

すでにハイブリッド v1.8.0 を使用していて、Anthos Service Mesh から Apigee Ingress ゲートウェイに移行する場合は、Apigee Ingress ゲートウェイへの移行をご覧ください。

Apigee Ingress ゲートウェイの概要

バージョン 1.8 以降の Apigee ハイブリッドでは、ハイブリッドインストールの Ingress ゲートウェイ（Apigee Ingress ゲートウェイ）を管理する新機能を備えています。Anthos Service Mesh は、ハイブリッドインストールの前提条件ではなくなりました。Apigee Ingress ゲートウェイを使用すると、Apigee は Anthos Service Mesh へのルーティング構成の提供を停止します。アップグレード後、この機能の使用を開始するには、トラフィックを新しい Apigee Ingress ゲートウェイに移行する必要があります。

Apigee では、Ingress ゲートウェイに Anthos Service Mesh 機能の小さなサブセットを使用します。ハイブリッドバージョン 1.8 以降の Apigee ハイブリッドには Ingress ゲートウェイが含まれており、Apigee ハイブリッドのアップグレードの一環としてインストールおよびアップグレードされます。そのため、Apigee ハイブリッドをインストール、アップグレード、管理するために Anthos Service Mesh に関する専門知識を身に付ける必要はありません。Ingress ゲートウェイのバージョンと Apigee ハイブリッドリリースとの互換性に関する問題は自動的に処理されます。

移行には 2 つのシナリオがあります。

マルチクラスタまたはマルチリージョンの移行（推奨）:
Apigee 用の新しい Ingress に切り替える前に、移行するクラスタから別のクラスタまたはリージョンにすべてのトラフィックをドレインします。これにより、新しい Apigee Ingress ゲートウェイが期待どおりに動作しているかどうかテストできます。その後、アップグレードしたクラスタにトラフィックを戻します。
インプレースアップグレード（本番環境ではおすすめしません）:
アップグレード中、Apigee は指定された IP アドレスで新しい Ingress ゲートウェイを起動します。その後、新しい Apigee Ingress ゲートウェイが期待どおりに動作しているかどうかをテストして、トラフィックを新しい Ingress に移行できます。このアップグレード中にダウンタイムが発生する可能性があります。

Apigee ハイブリッドをバージョン 1.8 にアップグレードする場合は、オーバーライドファイルで Apigee Ingress ゲートウェイを構成する必要があります。アップグレード後、登録事業者の A または CNAME レコードを Apigee Ingress ゲートウェイまたは Anthos Service Mesh の IP アドレスに転送することで、クラスタで使用する Ingress ゲートウェイのタイプを制御します。

バージョン 1.8.8 へのアップグレードの概要

Apigee ハイブリッドのバージョン 1.8 へのアップグレードでダウンタイムが発生する場合があります。

Apigee コントローラをバージョン 1.8.8 にアップグレードすると、すべての Apigee デプロイでローリング再起動が行われます。本番環境ハイブリッド環境のダウンタイムを最小限に抑えるには、少なくとも 2 つのクラスタ（同じまたは異なるリージョン / データセンター）を実行している必要があります。本番環境のすべてのトラフィックを 1 つのクラスタに戻し、オフラインでアップグレードしようとしているクラスタを取得して、アップグレードプロセスを続行します。この手順をクラスタごとに繰り返します。

Apigee では、本番環境への影響の可能性を軽減するため、すべてのクラスタをできるだけ早くアップグレードすることをおすすめします。最初のクラスタをアップグレードした後に、残りのすべてのクラスタをいつアップグレードする必要があるかについては、時間制限はありません。ただし、残りのクラスタがすべてアップグレードされるまで、次に示すオペレーションが影響を受けます。

Cassandra のバックアップと復元は、混在バージョンでは使用できません。たとえば、ハイブリッド 1.7 のバックアップは、ハイブリッド 1.8 インスタンスの復元に使用できません。
Cassandra データストリーミングは、ハイブリッドの混合バージョンでは機能しません。したがって、Cassandra クラスタを水平スケーリングすることはできません。
リージョンの拡張とデコミッションが影響を受けます（これらのオペレーションは Cassandra データストリーミングに依存しています）。

以降のセクションでは、Apigee Hybrid のアップグレード手順を次の順番で説明します。

アップグレードを準備する。
ハイブリッドランタイムバージョン 1.8.8 をインストールする。
Ingress ゲートウェイの場合は、次のいずれかのオプションを選択します。
- （推奨）新しい Apigee Ingress ゲートウェイを使用して、Anthos Service Mesh から Apigee Ingress ゲートウェイにトラフィックを切り替えるの手順を行います。
- Ingress ゲートウェイで引き続き Anthos Service Mesh を使用します。

前提条件

以下のアップグレード手順では、Apigee ハイブリッドバージョン 1.7.x またはバージョン 1.8.x の以前のパッチリリースがインストールされており、バージョン 1.8.8 にアップグレードすることを前提としています。以前のバージョンから更新する場合は、Apigee ハイブリッドバージョン 1.7 へのアップグレードをご覧ください。

Anthos Service Mesh を引き続き使用する場合は、Anthos Service Mesh をサポート対象バージョンにアップグレードする必要があります。Anthos Service Mesh のサポートされているバージョンについては、サポートされているプラットフォームの表をご覧ください。

バージョン 1.8 へのアップグレードを準備する

ハイブリッドインストールをバックアップする（推奨）

この手順では、apigeectl をインストールしたファイルシステム内のディレクトリを環境変数 APIGEECTL_HOME で表しています。必要に応じて、ディレクトリを apigeectl ディレクトリに変更し、次のコマンドで変数を定義します。
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
macOS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
バージョン 1.7 の $APIGEECTL_HOME/ ディレクトリのバックアップを作成します。次に例を示します。
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Cassandra のバックアップと復元の手順で Cassandra データベースをバックアップします。

Apigee ランタイムのサービスアカウントに Cloud Trace エージェントロールを追加します。（省略可）

省略可: Cloud Trace を使用する予定で、ハイブリッド v1.7 のインストールでこの手順をまだ実行していない場合は、Apigee ランタイムサービスのサービスアカウントに Cloud Trace エージェントの Google ロール（roles/cloudtrace.agent）が付与されていることを確認します。

本番環境の場合、通常これは apigee-runtime サービスアカウントです。非本番環境の場合、通常これは apigee-non-prod サービスアカウントです。

ロールを追加するには、UI の [Cloud コンソール] > [IAM と管理] > [サービスアカウント] か、次のコマンドを使用します。

次のコマンドでサービスアカウントのメールアドレスを取得します。
本番環境
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
パターン apigee-runtime@$ORG_NAME.iam.gserviceaccount.com と一致する場合、そのパターンは次のステップで使用できます。
非本番環境
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
パターン apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com と一致する場合、そのパターンは次のステップで使用できます。

サービスアカウントに Cloud Trace エージェントのロールを割り当てます。

本番環境

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

非本番環境

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

例

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

ここで、$PROJECT_ID は Apigee ハイブリッドがインストールされている Google Cloud プロジェクトの名前です。

注: インストールでサービスアカウントにカスタム名を使用している場合は、コマンドで apigee-runtime または apigee-non-prod の代わりにその名前を使用します。

Apigee Ingress ゲートウェイのインストールを準備する

アップグレードの一環として Apigee Ingress ゲートウェイをインストールするには、次の ingressGateways プロパティをオーバーライドファイルに追加する必要があります。

構文

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

例

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

INGRESS_NAME は、Ingress Deployment の名前です。次の要件を満たす任意の名前を使用できます。
- 17 文字以下にする
- 小文字の英数字またはハイフン（-）のみを使用する
- 先頭が英数字である
- 末尾が英数字である
構成プロパティリファレンスの ingressGateways[].name をご覧ください。
REPLICAS_MIN と REPLICAS_MAX は、インストールにおける Apigee Ingress ゲートウェイの最小レプリカ数と最大レプリカ数です。詳細とデフォルト設定については、構成プロパティリファレンスの ingressGateways[].replicaCountMin と ingressGateways[].replicaCountMax をご覧ください。
CPU_COUNT_REQ と MEMORY_REQ は、インストール環境における Apigee Ingress ゲートウェイの各レプリカに対する CPU とメモリのリクエストです。
すでに overlay.yaml ファイルなどで Anthos Service Mesh Ingress ゲートウェイに設定している場合は、これらのプロパティを設定するだけです。
詳細とデフォルト設定については、構成プロパティリファレンスの ingressGateways[].resources.requests.cpu と ingressGateways[].resources.requests.memory をご覧ください。
CPU_COUNT_LIMIT と MEMORY_LIMIT: インストール環境での Apigee Ingress ゲートウェイの各レプリカに対する最大 CPU とメモリの上限。
すでに overlay.yaml ファイルなどで Anthos Service Mesh Ingress ゲートウェイに設定している場合は、これらのプロパティを設定するだけです。
詳細とデフォルト設定については、構成プロパティリファレンスの ingressGateways[].resources.limits.cpu と ingressGateways[].resources.limits.memory をご覧ください。
SVC_ANNOTATIONS_KEY SVC_ANNOTATIONS_VALUE（省略可）:
注: overrides.yaml の ingressGateways[].svcAnnotations フィールドは期待どおりに機能しません。既知の問題 243599452 をご覧ください。
これは、デフォルトの Ingress サービスのアノテーションを提供する Key-Value ペアです。アノテーションは、ハイブリッドインストールの構成をサポートするために、クラウドプラットフォームによって使用されます。たとえば、ロードバランサのタイプを内部または外部に設定する場合などです。次に例を示します。
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
アノテーションは、プラットフォームによって異なります。必須アノテーションと推奨アノテーションについては、プラットフォームのドキュメントをご覧ください。

注: Apigee Ingress ゲートウェイを公開するに記載のように、ingress Deployment に独自の Kubernetes Service を作成する場合、Annotations を設定する必要はありません。
構成プロパティリファレンスの ingressGateways[].svcAnnotations をご覧ください。
SVC_LOAD_BALANCER_IP（省略可）ロードバランサに静的 IP アドレスを割り当てることができます。ロードバランサの IP アドレスの指定をサポートするプラットフォームでは、この IP アドレスを使用してロードバランサが作成されます。ロードバランサの IP アドレスを指定できないプラットフォームでは、このプロパティは無視されます。
ロードバランサに静的 IP アドレスが割り振られていない場合は、このプロパティをオーバーライドファイルを含めないでください。

注意: 現在の istio-ingressgateway と同じ IP アドレスは指定しないでください。指定すると、サービスがクラスタで実行されているときに問題が発生する可能性があります。

注: Apigee Ingress ゲートウェイの公開に記載のように、Ingress Deployment 用に独自の Kubernetes Service を作成する場合、LoadBalancerIP を設定する必要はありません。
構成プロパティリファレンスの ingressGateways[].svcLoadBalancerIP をご覧ください。

オーバーライドファイルをさらに変更して、オプションの v1.8 機能を有効または無効にします。

ハイブリッド v1.8 の新機能を有効にするには、次のプロパティを overrides.yaml ファイルに追加します。これらの機能はオプションです。

組織をスコープとする UDCA がデフォルトで有効になりました。単一の UDCA デプロイを使用してすべての環境のトラフィックを処理することで、UDCA Pod の使用率低下は防止され、他の Apigee コンポーネントでノードリソースの可用性が向上します。組織をスコープとする UDCA は、すべての環境で単一のサービスアカウント apigee-udca を使用します。
さまざまな環境で UDCA に異なるサービスアカウントを使用している場合は、envs:udca:serviceAccountPath を使用して環境レベルで指定されたものではなく、udca:serviceAccountPath を使用してオーバーライドファイル内の組織レベルで指定されたサービスアカウントを使用することに注意してください。

Apigee ハイブリッド v1.8 は、環境をスコープとする UDCA をサポートしています。環境ごとの UDCA を維持するには、orgScopedUDCA: false を設定します。

注: 環境をスコープとする UDCA は、Apigee ハイブリッドの今後のリリースではサポートされなくなります。
構成プロパティリファレンスの orgScopedUDCA をご覧ください。
validateOrg を有効にして、Apigee 組織と環境がアクティブであり、overrides ファイルで指定された Google Cloud Platform プロジェクトとの連携を厳格に検証することを必須にします。
```
validateOrg: true
```
注: Apigee ハイブリッドでは、厳格な組織検証の使用はサポートされていません。この機能をオフにするには、validateOrg: false を設定します。

構成プロパティリファレンスの validateOrg をご覧ください。

ハイブリッド 1.8.8 ランタイムをインストールする

現在のディレクトリがハイブリッドベースディレクトリ（apigeectl 実行可能ファイルが配置されているディレクトリの親）であることを確認します。
```
cd $APIGEECTL_HOME/..
```

次のコマンドを使用して、ご使用のオペレーティングシステムに対応したリリースパッケージをダウンロードします。ご利用のプラットフォームを次の表から選択します。

Linux

Linux 64 ビット:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

macOS

Mac 64 ビット:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows 64 ビット:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

現在の apigeectl/ ディレクトリをバックアップディレクトリ名に変更します。次に例を示します。
Linux
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/
```
macOS
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/ 
```
Windows
```
rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7 
```
ダウンロードした gzip ファイルの内容をハイブリッドのベースディレクトリに展開します。ハイブリッドのベースディレクトリは、名前を変更した apigeectl-v1.7 ディレクトリのあるディレクトリです。
Linux
```
tar xvzf filename.tar.gz -C ./
```
macOS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
デフォルトでは、tar の内容が展開されるディレクトリの名前には、バージョンとプラットフォームが含まれています。たとえば、./apigeectl_1.8.8-xxxxxxx_linux_64 となります。次のコマンドを使用して、このディレクトリの名前を apigeectl に変更します。
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
macOS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
apigeectl ディレクトリに移動します。
```
cd ./apigeectl
```
このディレクトリは apigeectl ホームディレクトリになります。apigeectl 実行可能コマンドはこのディレクトリに配置されます。
この手順では、apigeectl ユーティリティがインストールされているファイルシステムのディレクトリを環境変数 $APIGEECTL_HOME で表しています。必要に応じて、ディレクトリを apigeectl ディレクトリに変更し、次のコマンドで変数を定義します。
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
macOS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
version コマンドで apigeectl のバージョンを確認します。
```
./apigeectl version
```
```
Version: 1.8.8
```
hybrid-base-directory/hybrid-files ディレクトリに移動します。hybrid-files ディレクトリには、オーバーライドファイル、証明書、サービスアカウントなどの構成ファイルがあります。次に例を示します。
```
cd $APIGEECTL_HOME/../hybrid-files
```
次のコマンドを使用して、kubectl が正しいコンテキストに設定されていることを確認します。現在のコンテキストは、Apigee ハイブリッドをアップグレードするクラスタに設定する必要があります。
```
kubectl config get-contexts | grep \*
```
hybrid-files ディレクトリ:
1. 以下の $APIGEECTL_HOME へのシンボリックリンクを更新します。このリンクを使用すると、hybrid-files ディレクトリ内から新しくインストールされた apigeectl コマンドを実行できます。
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. シンボリックリンクが正しく作成されたことを確認するには、次のコマンドを実行してリンクパスが正しい場所を指していることを確認します。
```
ls -l | grep ^l
```
ドライランの初期化を行ってエラーを確認します。
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
ここで、OVERRIDES_FILE はオーバーライドファイルの名前です（例: ./overrides/overrides.yaml）。

ヒント: 上記のコードサンプルの OVERRIDES_FILE をオーバーライドファイルの名前とパスに置き換えると、このページのすべてのインスタンスが置き換えられます。
エラーがなければ、ハイブリッド 1.8.8 を初期化します。このコマンドは、Apigee Ingress ゲートウェイもインストールして構成します。
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
初期化のステータスを確認します。
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
成功すると、「All containers ready.」と出力されます。

既知の問題: init を実行して check-ready が成功したことを確認した後、Pod を見ると Cassandra スキーマ検証がエラー状態であることがわかります。この状態は既知の問題（#245664917）で、害のあるものではありません。エラーを無視して次の手順 apigeectl apply に進んでください。
さらに、次のコマンドを実行して ApigeeDataStore のステータスを確認することもできます。
```
kubectl describe apigeeds -n apigee
```
出力で「State: running」を探します。
--dry-run フラグを使用して、apply コマンドのドライランでエラーを確認します。
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
エラーがない場合、オーバーライドを適用します。インストールに応じて、本番環境または非本番環境用の手順を実施します。
アップグレードプロセスの間、各コンポーネントはローリング再起動を実行します。そのため、本番環境では一度に 1 つずつコンポーネントをアップグレードすることをおすすめします。
本番環境

本番環境では、ハイブリッドコンポーネントを個別にアップグレードし、アップグレードされたコンポーネントのステータスを確認してから次のコンポーネントに進んでください。
1. 現在のディレクトリが hybrid-files ディレクトリであることを確認します。
2. オーバーライドを適用して Cassandra をアップグレードします。
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. 完了を確認します。
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  ヒント: check-ready が失敗した場合は、次のコマンドで Pod に関する詳細情報を取得できます。
  kubectl -n NAMESPACE get pods
  
  ここで、NAMESPACE は Apigee ハイブリッドの名前空間です。
  Pod の準備ができた場合にのみ、次の手順に進みます。
4. オーバーライドを適用してテレメトリーコンポーネントをアップグレードし、完了を確認します。
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Redis コンポーネントを起動します。
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. オーバーライドを適用して、組織レベルのコンポーネント（MART、Watcher、Apigee Connect）をアップグレードし、完了を確認します。
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. オーバーライドを適用して環境をアップグレードします。次の 2 つの選択肢があります。
  - 環境ごと: 一度に 1 つの環境にオーバーライドを適用して、完了を確認します。この手順を環境ごとに繰り返します。
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    ここで、ENV_NAME はアップグレードする環境の名前です。
  - 一度にすべての環境: すべての環境にオーバーライドを一度に適用して、完了を確認します。
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. オーバーライドを適用して virtualhosts コンポーネントをアップグレードし、完了を確認します。
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
非本番環境

非本番環境、デモ環境、試験運用版環境の大半では、すべてのコンポーネントに同時にオーバーライドを適用できます。非本番環境が大規模で複雑な場合や、本番環境とよく似ている場合は、本番環境をアップグレードするための手順の実施をおすすめします。
1. 現在のディレクトリが hybrid-files ディレクトリであることを確認します。
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. ステータスを確認します。
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Kubernetes のバージョンをアップグレードする

Kubernetes プラットフォームをハイブリッド 1.8 でサポートされているバージョンにアップグレードします。ヘルプが必要な場合は、プラットフォームのドキュメントをご覧ください。

クリックして、サポートされているプラットフォームのリストを開く

	Apigee ハイブリッドのバージョン
プラットフォーム	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8 ⁽³⁾	1.9	1.10
Anthos（Google Cloud - GKE）	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
Anthos（AWS）	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos（Azure）	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos（オンプレミス - VMware）⁽¹⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos（ベアメタル）^（1）	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS^（7）	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine（RKE）⁽⁷⁾	なし	なし	なし	1.3.8	v1.26.2+rke2r1
コンポーネント	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8	1.9	1.10
Anthos Service Mesh（ASM）	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ Anthos バージョン 1.8、1.9、1.10 では、`cert-manager`との競合を回避するために、次のドキュメントに記載されている手順を実施してください。 Anthos 1.8.2 以降: バージョン 1.8.2 以降にアップグレードすると `cert-manager` と競合する。 Anthos 1.9: バージョン 1.9.0 または 1.9.1 にアップグレードすると `cert-manager` と競合する。 Anthos 1.10 以降: `cert-manager` のインストールが競合している。 ⁽²⁾ Apigee ハイブリッドバージョン 1.7.2 以降でサポートされています。 ⁽³⁾ Apigee ハイブリッドバージョン 1.8 以前の正式なサポートが終了しました。今後、定期的な月次パッチは提供されません。サポートの継続が正式に提示されているお客様を除き、これらのリリースの正式なサポートは提供されません。他のお客様はアップグレードが必要です。 ⁽⁴⁾ Anthos on bare metal と VMWare の 1.12 以前のバージョンは、サポートが終了しています。Anthos on bare metal バージョンサポートポリシーと Anthos clusters on VMware のバージョンをご覧ください。 ⁽⁵⁾ Anthos on bare metal と VMWare には ASM 1.14 が必要です。ハイブリッド v1.8 にアップグレードして Apigee Ingress ゲートウェイに切り替えることをおすすめします。これにより、ハイブリッドクラスタに ASM をインストールする必要がなくなります。 ⁽⁶⁾ Apigee ハイブリッドバージョン 1.8.4 以降でサポートされています。 ⁽⁷⁾ Apigee Ingress ゲートウェイを使用する Apigee ハイブリッド v1.8 以降では、接続クラスタを使用する必要はありません。 ⁽⁸⁾ Apigee ハイブリッドバージョン 1.8.4 以降ではサポートされていません。 ⁽⁹⁾ Apigee ハイブリッドバージョン 1.7.6 以降でサポートされています。 ⁽¹⁰⁾ Apigee ハイブリッドバージョン 1.8.5 以降ではサポートされていません。 ⁽¹¹⁾ ASM は Apigee ハイブリッド 1.9 以降で自動的にインストールされます。 ⁽¹²⁾Apigee ハイブリッドバージョン 1.9.2 以降でサポートされています。 ⁽¹³⁾ Anthos clusters on AWS（マルチクラウド）のバージョン番号に Kubernetes のバージョンが反映されるようになりました。バージョンの詳細と推奨パッチについては、Anthos のバージョンとアップグレードのサポートをご覧ください。

接続クラスタについて

Apigee ハイブリッドバージョン 1.7.x 以前で、Elastic Kubernetes Service（EKS）、Azure Kubernetes Service（AKS）、またはサポートされているサードパーティの Kubernetes サービスプロバイダのマルチクラウドコンテキストで Apigee ハイブリッドを実行する場合は、Anthos 接続クラスタを使用する必要があります。Google では、クラスタアタッチメントを使用して Anthos Service Mesh（ASM）の使用状況を測定しています。サードパーティクラスタの登録は任意です。Google Cloud コンソールで接続クラスタを表示する場合にのみ登録が必要になります。詳細については、サードパーティの Kubernetes クラスタを Google Cloud に接続するをご覧ください。

Apigee ハイブリッドバージョン 1.8.x で Ingress ゲートウェイに Anthos Service Mesh を使用する場合、Anthos に関連付けられたクラスタが必要です。Apigee Ingress ゲートウェイを使用している場合、Anthos 接続クラスタはオプションです。

トラフィックを Anthos Service Mesh から Apigee Ingress ゲートウェイに切り替える

トラフィックを Apigee Ingress ゲートウェイに切り替えるには:

Apigee Ingress ゲートウェイを公開します。Apigee Ingress ゲートウェイの公開の手順を実施します。
プロキシを呼び出して、新しい Ingress ゲートウェイをテストします。現在デプロイされている重要なプロキシをすべてテストするのが理想的です。
トラフィックを切り替えるには、新しい Apigee Ingress ゲートウェイの IP アドレスを指すように DNS レコードを更新します。DNS プロバイダによっては、トラフィックを新しいエンドポイントに段階的にシフトできる可能性があります。
ヒント: Apigee Ingress ゲートウェイの外部 IP アドレスは、次のコマンドを使用して確認できます。
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
出力は次のようになります。
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
ダッシュボードをモニタリングして、すべてのランタイムトラフィックが機能していることを確認します。すべてが想定どおりに動作している場合にのみ、次の手順に進みます。DNS キャッシュが原因で DNS 更新の伝播に時間がかかることがあるため、古い Ingress ゲートウェイ（Anthos Service Mesh）を経由するトラフィックがないことを確認します。
Apigee から Anthos Service Mesh への構成の提供を停止するには、Apigee Ingress ゲートウェイの管理ガイドの ASM への構成の提供を停止するの手順を実施します。
API プロキシトラフィックを再度テストしてモニタリングします。
Anthos Service Mesh のドキュメントの手順に沿って、クラスタから Anthos Service Mesh をアンインストールします。

Anthos Service Mesh をバージョン 1.15 にアップグレードする

この操作は、使用しているプラットフォームに適した Anthos Service Mesh のドキュメントを使用して行ってください。

Anthos Service Mesh をインストールして構成する手順は、プラットフォームによって異なります。プラットフォームは、次のカテゴリに分類されます。

GKE: Google Cloud で実行されている Google Kubernetes Engine クラスタ。
Google Cloud 以外: 次の場所で実行されている Anthos clusters。
- Anthos clusters on VMware（GKE On-Pprem）
- Anthos on bare metal
- Anthos clusters on AWS
- Amazon EKS
その他の Kubernetes プラットフォーム: 以下で作成され、実行される正規のクラスタ。
- AKS
- EKS
- OpenShift

GKE

ハイブリッドインストール用に Anthos Service Mesh をバージョン 1.13.9 にアップグレードする手順は次のとおりです。

アップグレードの準備を行います。
新しいバージョンの Anthos Service Mesh をインストールします。
現在のインストールから以前の Anthos Service Mesh バージョンの Deployment、Service、Webhook を削除します。
ゲートウェイをアップグレードして新しい Webhook を構成します。

Anthos Service Mesh をバージョン 1.13.9にアップグレードするための準備

Anthos Service Mesh のアップグレードの要件を確認します。ただし、まだアップグレードは行わないでください。
新しいバージョンをインストールする前に、現在のリビジョンを確認します。この情報は、現在のインストールから以前の Anthos Service Mesh バージョンの Deployment、Service、Webhook を削除する際に必要になります。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
出力は 1.12.9-asm.2 のようになります。
注: 複数の値が返される場合は、DELETE_REV の値を最も古いバージョンに設定し、手順を沿って最も古いバージョンを削除します。すべてのバージョンを削除するまで処理を続行できません。

新しい overlay.yaml ファイルを作成するか、既存の overlay.yaml に次の内容が含まれていることを確認します。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Anthos Service Mesh ドキュメントの次のセクションにある手順を実施します。
重要: この手順に沿って、オプション機能を使用して Anthos Service Mesh をアップグレードしてください。また、overlay.yaml を含めてください。
1. asmcli をダウンロードする
2. クラスタ管理者の権限を付与する
3. プロジェクトとクラスタを検証する
4. オプション機能を使用してアップグレードする。「Gateway をアップグレードする」には、まだ進まないでください。
新しいコントロールプレーンに切り替えます。
1. istiod のリビジョンラベルを取得します。
```
kubectl get pod -n istio-system -L istio.io/rev
```
  このコマンドからの出力は、次のようになります。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 新しいリビジョンラベルを環境変数に割り当てます。
  出力の REV 列にある新しいバージョンのリビジョンラベルの値をメモします。この例では asm-1139-10 です。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 次のコマンドを使用して、リビジョンラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します（存在する場合）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  出力に "istio-injection not found" がある場合は、無視してかまいません。これは、Namespace に istio-injection ラベルが追加されていなかったことを意味します。Namespace に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh のドキュメントでは、すべての kubectl label コマンドの説明に istio-injection ラベルの削除が含まれています。
4. Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n istio-system
```
5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
6. 他の Namespace にワークロードがある場合は、手順を繰り返して Namespace にラベルを付け、Pod を再起動します。

以前のバージョンを削除します。

asmcli をインストールしたディレクトリに移動します。
Anthos Service Mesh インストールの出力ディレクトリを DIR_PATH 環境変数に保存します。これは、オプション機能を使用したアップグレードの手順で指定したディレクトリと同じです。
```
export DIR_PATH=OUTPUT_DIR
```

次のコマンドを含むシェルスクリプトを作成します。

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

スクリプトを実行して、以前のバージョンを削除します。

Google Cloud 以外

ここでは、Anthos Service Mesh のアップグレードについて説明します。

Anthos clusters on VMware（GKE on-prem）
Anthos on bare metal
Anthos clusters on AWS
Amazon EKS

ハイブリッドインストール用に Anthos Service Mesh をバージョン 1.13.9 にアップグレードする手順は次のとおりです。

アップグレードの準備を行います。
新しいバージョンの Anthos Service Mesh をインストールします。
現在のインストールから以前の Anthos Service Mesh バージョンの Deployment、Service、Webhook を削除します。
ゲートウェイをアップグレードして新しい Webhook を構成します。

Anthos Service Mesh をバージョン 1.13.9にアップグレードするための準備

Anthos Service Mesh のアップグレードの要件を確認します。ただし、まだアップグレードは行わないでください。
新しいバージョンをインストールする前に、現在のリビジョンを確認します。この情報は、現在のインストールから以前の Anthos Service Mesh バージョンの Deployment、Service、Webhook を削除する際に必要になります。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
出力は 1.12.9-asm.2 のようになります。
注: 複数の値が返される場合は、DELETE_REV の値を最も古いバージョンに設定し、手順を沿って最も古いバージョンを削除します。すべてのバージョンを削除するまで処理を続行できません。

新しい overlay.yaml ファイルを作成するか、既存の overlay.yaml に次の内容が含まれていることを確認します。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Anthos Service Mesh ドキュメントの次のセクションにある手順を実施します。
重要: この手順に沿って、オプション機能を使用して Anthos Service Mesh をアップグレードしてください。また、overlay.yaml を含めてください。
1. asmcli をダウンロードする
2. クラスタ管理者の権限を付与する
3. プロジェクトとクラスタを検証する
4. オプション機能を使用してアップグレードする。「Gateway をアップグレードする」には、まだ進まないでください。
新しいコントロールプレーンに切り替えます。
1. istiod のリビジョンラベルを取得します。
```
kubectl get pod -n istio-system -L istio.io/rev
```
  このコマンドからの出力は、次のようになります。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 新しいリビジョンラベルを環境変数に割り当てます。
  出力の REV 列にある新しいバージョンのリビジョンラベルの値をメモします。この例では asm-1139-10 です。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 次のコマンドを使用して、リビジョンラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します（存在する場合）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  出力に "istio-injection not found" がある場合は、無視してかまいません。これは、Namespace に istio-injection ラベルが追加されていなかったことを意味します。Namespace に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh のドキュメントでは、すべての kubectl label コマンドの説明に istio-injection ラベルの削除が含まれています。
4. Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n istio-system
```
5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
6. 他の Namespace にワークロードがある場合は、手順を繰り返して Namespace にラベルを付け、Pod を再起動します。

以前のバージョンを削除します。

asmcli をインストールしたディレクトリに移動します。
Anthos Service Mesh インストールの出力ディレクトリを DIR_PATH 環境変数に保存します。これは、オプション機能を使用したアップグレードの手順で指定したディレクトリと同じです。
```
export DIR_PATH=OUTPUT_DIR
```

次のコマンドを含むシェルスクリプトを作成します。

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

スクリプトを実行して、以前のバージョンを削除します。

AKS / EKS

Anthos 接続クラスタで Anthos Service Mesh（ASM）バージョン istio-1.13.9-asm.10 をアップグレードする以下のプロセスは、新規のインストールを実行する場合と同じです。

Anthos Service Mesh のインストールの準備

新しいバージョンをインストールする前に、現在のリビジョンを確認します。現在の Anthos Service Mesh インストールから検証 Webhook と変更 Webhook を削除するには、この情報が必要です。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
出力は 1.12.9-asm.2 のようになります。

注: 複数の値が返される場合は、DELETE_REV の値を最も古いバージョンに設定し、手順を沿って最も古いバージョンを削除します。すべてのバージョンを削除するまで処理を続行できません。

Linux

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリに内容を抽出するには、次のコマンドを実行します。

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

このコマンドにより、現在の作業ディレクトリに istio-1.13.9-asm.10 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。

samples ディレクトリにあるサンプルアプリケーション。
Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。

cd istio-1.13.9-asm.10

利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

export PATH=$PWD/bin:$PATH

Mac OS

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

tar xzf istio-1.13.9-asm.10-osx.tar.gz

samples ディレクトリにあるサンプルアプリケーション。
Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。

cd istio-1.13.9-asm.10

利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

export PATH=$PWD/bin:$PATH

Windows

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

tar xzf istio-1.13.9-asm.10-win.zip

samples ディレクトリにあるサンプルアプリケーション。
Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
Anthos Service Mesh 構成プロファイルは manifests\profiles ディレクトリにあります。

Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。

cd istio-1.13.9-asm.10

利便性を考えて、\bin ディレクトリ内のツールを PATH に追加します。

set PATH=%CD%\bin:%PATH%

Anthos Service Mesh Istio がインストールされているので、istioctl のバージョンを確認します。
```
istioctl version
```
コントロールプレーンコンポーネント用に istio-system という Namespace を作成します。
```
kubectl create namespace istio-system
```

Anthos Service Mesh のインストール

overlay.yaml ファイルを編集するか、次の内容の新しいファイルを作成します。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

asm-multicloud プロファイルを使用して、istioctl を使用して Anthos Service Mesh をインストールします。
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlay.yaml
```
出力は次のようになります。
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
--set revision 引数は、istio.io/rev=asm-1139-10 形式のリビジョンラベルを istiod に追加します。リビジョンラベルは、自動サイドカーインジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。Namespace のサイドカー自動挿入を有効にするには、istiod のラベルと一致するリビジョンのラベルを付ける必要があります。

インストールが完了したことを確認します。

kubectl get svc -n istio-system

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

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

新しいコントロールプレーンに切り替えます。
1. istiod のリビジョンラベルを取得します。
```
kubectl get pod -n istio-system -L istio.io/rev
```
  このコマンドからの出力は、次のようになります。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 新しいリビジョンラベルを環境変数に割り当てます。
  出力の REV 列にある新しいバージョンのリビジョンラベルの値をメモします。この例では asm-1139-10 です。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 次のコマンドを使用して、リビジョンラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します（存在する場合）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  出力に "istio-injection not found" がある場合は、無視してかまいません。これは、Namespace に istio-injection ラベルが追加されていなかったことを意味します。Namespace に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh のドキュメントでは、すべての kubectl label コマンドの説明に istio-injection ラベルの削除が含まれています。
4. Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n istio-system
```
5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
6. 他の Namespace にワークロードがある場合は、手順を繰り返して Namespace にラベルを付け、Pod を再起動します。

以前のバージョンを削除します。

asmcli をインストールしたディレクトリに移動します。

次のコマンドを含むシェルスクリプトを作成します。

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

スクリプトを実行して、以前のバージョンを削除します。

OpenShift

Anthos Service Mesh のインストールの準備

新しいバージョンをインストールする前に、現在のリビジョンを確認します。現在の Anthos Service Mesh インストールから検証 Webhook と変更 Webhook を削除するには、この情報が必要です。現在の istiod リビジョンを環境変数に格納するには、次のコマンドを使用します。
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
出力は 1.12.9-asm.2 のようになります。

注: 複数の値が返される場合は、DELETE_REV の値を最も古いバージョンに設定し、手順を沿って最も古いバージョンを削除します。すべてのバージョンを削除するまで処理を続行できません。

Linux

次の OpenShift CLI（oc）コマンドを使用して、anyuid セキュリティコンテキスト制約（SCC）を istio-system に付与します。

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

samples ディレクトリにあるサンプルアプリケーション。
Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。

cd istio-1.13.9-asm.10

利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

export PATH=$PWD/bin:$PATH

Mac OS

次の OpenShift CLI（oc）コマンドを使用して、anyuid セキュリティコンテキスト制約（SCC）を istio-system に付与します。

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

tar xzf istio-1.13.9-asm.10-osx.tar.gz

samples ディレクトリにあるサンプルアプリケーション。
Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。

cd istio-1.13.9-asm.10

利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

export PATH=$PWD/bin:$PATH

Windows

次の OpenShift CLI（oc）コマンドを使用して、anyuid セキュリティコンテキスト制約（SCC）を istio-system に付与します。

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

署名ファイルをダウンロードし、OpenSSL を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

tar xzf istio-1.13.9-asm.10-win.zip

samples ディレクトリにあるサンプルアプリケーション。
Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
Anthos Service Mesh 構成プロファイルは manifests\profiles ディレクトリにあります。

Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。

cd istio-1.13.9-asm.10

利便性を考えて、\bin ディレクトリ内のツールを PATH に追加します。

set PATH=%CD%\bin:%PATH%

Anthos Service Mesh Istio がインストールされているので、istioctl のバージョンを確認します。
```
istioctl version
```
コントロールプレーンコンポーネント用に istio-system という Namespace を作成します。
```
kubectl create namespace istio-system
```

検証 Webhook を構成する

Anthos Service Mesh をインストールするときに、istiod にリビジョンラベルを設定します。検証 Webhook に同じリビジョンを設定する必要があります。

次の内容のファイルを istiod-service.yaml という名前で作成します。

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1139-10
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1139-10
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

kubectl を使用して検証 Webhook 構成を適用します。
```
kubectl apply -f istiod-service.yaml
```

構成が適用されたことを確認します。

kubectl get svc -n istio-system

レスポンスは次のようになります。

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Anthos Service Mesh のインストール

overlay.yaml ファイルを編集するか、次の内容の新しいファイルを作成します。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

asm-multicloud プロファイルを使用して、istioctl を使用して Anthos Service Mesh をインストールします。
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlayfile.yaml
```
出力は次のようになります。
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
--set revision 引数は、istio.io/rev=1.6.11-asm.1 形式のリビジョンラベルを istiod に追加します。リビジョンラベルは、自動サイドカーインジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。Namespace のサイドカー自動挿入を有効にするには、istiod のラベルと一致するリビジョンのラベルを付ける必要があります。

インストールが完了したことを確認します。

kubectl get svc -n istio-system

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

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

新しいコントロールプレーンに切り替えます。
1. istiod のリビジョンラベルを取得します。
```
kubectl get pod -n istio-system -L istio.io/rev
```
  このコマンドからの出力は、次のようになります。
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 新しいリビジョンラベルを環境変数に割り当てます。
  出力の REV 列にある新しいバージョンのリビジョンラベルの値をメモします。この例では asm-1139-10 です。
```
export UPGRADE_REV="REVISION_LABEL"
```
3. 次のコマンドを使用して、リビジョンラベルを istio-system Namespace に追加し、istio-injection ラベルを削除します（存在する場合）。
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  出力に "istio-injection not found" がある場合は、無視してかまいません。これは、Namespace に istio-injection ラベルが追加されていなかったことを意味します。Namespace に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh のドキュメントでは、すべての kubectl label コマンドの説明に istio-injection ラベルの削除が含まれています。
4. Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n istio-system
```
5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
6. 他の Namespace にワークロードがある場合は、手順を繰り返して Namespace にラベルを付け、Pod を再起動します。

以前のバージョンを削除します。

asmcli をインストールしたディレクトリに移動します。

次のコマンドを含むシェルスクリプトを作成します。

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

スクリプトを実行して、以前のバージョンを削除します。

アップグレードのロールバック

以前のアップグレードをロールバックする手順は次のとおりです。

ハイブリッドランタイムの名前空間に対して、完了したジョブのクリーンアップを行います。ここで、名前空間を指定した場合、NAMESPACE はオーバーライドファイルで指定した名前空間になります。指定しない場合、デフォルトの名前空間は apigee です。
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

apigee-system 名前空間で完了したジョブをクリーンアップします。

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

以前のバージョンの apigeectl を含むディレクトリを指すように APIGEECTL_HOME 変数を変更します。次に例を示します。
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
overrides ファイルに加えた変更を元に戻します。
1. ingressGateways とそのすべてのプロパティを削除するか、コメントアウトします。
2. virtualhosts.selector.app の値を前の値に設定します。次に例を示します。
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. ao.args.disableIstioConfigInAPIServer を削除するか、コメントアウトします。
ロールバックするインストールのルートディレクトリで、apigeectl apply を実行し、Pod のステータスを確認してから apigeectl init を実行します。ロールバックするバージョンの元のオーバーライドファイルを必ず使用してください。
1. ハイブリッドファイルディレクトリで apigeectl apply を実行します。
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  ここで、ORIGINAL_OVERRIDES_FILE は、以前のバージョンのハイブリッドインストールのオーバーライドファイルの相対パスとファイル名です（例: ./overrides/overrides1.7.yaml）。
2. Pod のステータスを確認します。
```
kubectl -n NAMESPACE get pods
```
  ここで、NAMESPACE は Apigee ハイブリッドの名前空間です。
3. apigeeds のステータスを確認します。
```
kubectl describe apigeeds -n apigee
```
  出力は次のようになります。
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  apigeeds Pod が実行されている場合にのみ、次の手順に進みます。
4. 次のコマンドを実行して、アップグレード後に Message Processor の新しいレプリカ数の値をメモします。これらの値が、以前に設定した値と一致しない場合は、オーバーライドファイルの値を以前の構成と一致するように変更します。
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  出力は次のようになります。
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. ハイブリッド v1.8.4 以前にロールバックする場合は、ハイブリッド v1.8.5 以降で使用されるコントローラデプロイを削除します。
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. apigeectl init を実行します。
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Apigee Ingress ゲートウェイマネージャーのデプロイを削除します。このコンポーネントは、Apigee ハイブリッドバージョン 1.8 以降にのみ関連します。
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
ここで、NAMESPACE は Apigee ハイブリッドの Namespace です。

Apigee ハイブリッドのバージョン 1.8 へのアップグレード

Apigee Ingress ゲートウェイの概要

バージョン 1.8.8 へのアップグレードの概要

前提条件

バージョン 1.8 へのアップグレードを準備する

ハイブリッド インストールをバックアップする（推奨）

Linux

macOS

Windows

Apigee ランタイムのサービス アカウントに Cloud Trace エージェント ロールを追加します。（省略可）

本番環境

非本番環境

本番環境

非本番環境

例

Apigee Ingress ゲートウェイのインストールを準備する

構文

例

オーバーライド ファイルをさらに変更して、オプションの v1.8 機能を有効または無効にします。

ハイブリッド 1.8.8 ランタイムをインストールする

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

本番環境

非本番環境

Kubernetes のバージョンをアップグレードする

クリックして、サポートされているプラットフォームのリストを開く

プラットフォーム

コンポーネント

接続クラスタについて

トラフィックを Anthos Service Mesh から Apigee Ingress ゲートウェイに切り替える

Anthos Service Mesh をバージョン 1.15 にアップグレードする

GKE

Anthos Service Mesh をバージョン 1.13.9にアップグレードするための準備

Google Cloud 以外

Anthos Service Mesh をバージョン 1.13.9にアップグレードするための準備

AKS / EKS

Anthos Service Mesh のインストールの準備

Linux

Mac OS

Windows

Anthos Service Mesh のインストール

OpenShift

Anthos Service Mesh のインストールの準備

Linux

Mac OS

Windows

検証 Webhook を構成する

Anthos Service Mesh のインストール

アップグレードのロールバック

ハイブリッドインストールをバックアップする（推奨）

Apigee ランタイムのサービスアカウントに Cloud Trace エージェントロールを追加します。（省略可）

オーバーライドファイルをさらに変更して、オプションの v1.8 機能を有効または無効にします。