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

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

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

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

Apigee ハイブリッド v1.11 からの変更

Apigee Hybrid バージョン 1.12 では、アップグレードプロセスに影響する次の変更が導入されています。v1.12 の機能の詳細については、ハイブリッド v1.12.0 リリースノートをご覧ください。

Cassandra 4.x: バージョン 1.12 以降、Apigee ハイブリッドは Cassandra バージョン 4 以降を使用します。
重要: データベースが変更されたため、アップグレードされた apigee-datastore コンポーネントをロールバックすることはできません。そのため、アップグレードする前に Cassandra データベースとハイブリッドインストールをバックアップすることが重要です。アップグレードをロールバックする必要がある場合は、次のシナリオを検討してください。
- Cassandra がまだアップグレードされていない場合: すべての変更をロールバックできます。
- Cassandra がアップグレードされ、すべての Cassandra Pod が正常な状態: apigee-datastore を除くすべてのコンポーネントの変更をロールバックできます。v1.11.x インストールは、Cassandra v4 を実行する apigee-datastore の v1.12 インスタンスで引き続き動作します。
- Cassandra がアップグレードされ、Cassandra Pod が異常な状態にある場合: ハイブリッド v1.12 をアンインストールし、バックアップから v.11 インストールを復元する必要があります。
apigeectl のサポートの終了: バージョン 1.12 以降、Apigee ハイブリッドはハイブリッドインストールのインストールと管理に Helm のみをサポートしています。
注意: apigeectl は 2024 年 4 月 17 日より非推奨になりました。apigeectl ツールは Apigee hybrid v1.12 ではサポートされていません。Apigee ハイブリッド v1.10 と v1.11 の apigeectl のサポートは 2025 年 4 月 17 日に終了します。詳細については、apigeectl のサポートの終了をご覧ください。
重要: apigeectl で v1.11 を管理している場合は、バージョン 1.12 にアップグレードする前に、まず v1.11 インストールを移行して Helm を使用する必要があります。apigeectl から Helm チャートへの Apigee ハイブリッドの移行の手順に沿って、移行します。
Apigee プロキシとターゲットエンドポイントをモニタリングするための新しい指標スイートが利用可能になりました。ハイブリッド v1.12 では、ProxyV2 と TargetV2 のモニタリングリソースはデフォルトで使用されなくなります。すべてのプロキシ指標とターゲット指標は、Proxy と Target のモニタリング対象リソースに公開されます。

引き続き ProxyV2 と TargetV2 のモニタリング対象リソースに指標を出力するには、overrides.yaml で metrics.disablePrometheusPipeline を true に設定します。
指標ベースのアラートを構成している場合は、ハイブリッドインストールに適した指標が使用されていることを確認します。詳細については、指標ベースのアラートをご覧ください。
クラスのインスタンス化チェックの厳格化: バージョン 1.12.4 から、Apigee ハイブリッドの JavaCallout ポリシーに、Java クラスのインスタンス化時の追加のセキュリティが組み込まれました。この強化されたセキュリティ対策により、許可されていない権限を必要とするアクションを直接または間接的に試行するポリシーのデプロイを防ぐことができます。
ほとんどの場合、既存のポリシーは引き続き問題なく機能します。ただし、サードパーティライブラリに依存するポリシーや、昇格された権限を必要とするオペレーションを間接的にトリガーするカスタムコードを含むポリシーは、影響を受ける可能性があります。

重要: インストールをテストするには、1.12.4 へのアップグレード後にポリシーを検証するの手順に沿ってポリシーの動作を検証します。

バージョン 1.12 へのアップグレードを開始する前に考慮すべき事項

Cassandra の考慮事項

Apigee ハイブリッドバージョン 1.11 からバージョン 1.12 へのアップグレードには、Cassandra データベースのバージョン 3.11.x からバージョン 4.x へのアップグレードが含まれます。Cassandra のアップグレードは Apigee ハイブリッドアップグレード手順の一部として処理されますが、次の点を考慮して計画してください。

Cassandra バージョンのアップグレードはバックグラウンドで行われ、一度に 1 つの Pod（または Cassandra ノード）で行われるため、アップグレード中のデータベース容量の減少を計画してください。
アップグレードを開始する前に、Cassandra の容量をスケーリングし、ディスク使用率が 50% 以下であることを確認します。
Cassandra のバックアップと復元の手順を検証してテストします。
アップグレードを開始する前に、ハイブリッドバージョン 1.11 インストールの Cassandra データをバックアップし、バックアップを検証します。
apigee-datastore をアップグレードすると、Cassandra によって実行されるアップグレード後タスクにより、CPU 使用量が一時的に増加します。
apigee-datastore（Cassandra）コンポーネントをアップグレードすると、そのコンポーネントを以前のバージョンにロールバックすることはできません。apigee-datastore コンポーネントをアップグレードした後、ハイブリッド v1.12 へのアップグレードをロールバックするシナリオは 2 つあります。
- apigee-datastore コンポーネントは正常な状態であるが、他のコンポーネントをロールバックする必要がある場合は、それらのコンポーネントを個別にロールバックできます。
  注: 異なるハイブリッドバージョンのコンポーネントを実行している間は、リージョンの追加や Cassandra ノードのスケーリングはできません。
- apigee-datastore コンポーネントが不正な状態の場合は、v1.11 バックアップから v1.11 インストールに復元する必要があります。
  注: 復元する際にバージョンを混在させることはできません。v1.11 インストールで作成したバックアップを v1.11 インストールに復元する必要があります。

単一リージョンのインストールをアップグレードする前の考慮事項

以前のバージョンの Apigee ハイブリッドにロールバックする必要がある場合、プロセスでダウンタイムが必要になることがあります。したがって、単一リージョンのインストールをアップグレードする場合は、2 つ目のリージョンを作成し、次の順序で一度に 1 つのリージョンのみをアップグレードすることをおすすめします。

同じハイブリッドバージョンを使用して、既存のインストールに 2 つ目のリージョンを追加します。バージョン 1.11 のドキュメントのマルチリージョンデプロイをご覧ください。
アップグレードを開始する前に、最初のリージョンのデータをバックアップして検証します。バージョン 1.11 のドキュメントの Cassandra のバックアップの概要をご覧ください。
新しく追加されたリージョンをハイブリッド 1.12 にアップグレードします。
トラフィックを新しいリージョンに切り替えて、トラフィックを検証します。
検証が完了したら、ハイブリッド 1.12 を使用して古いリージョンをアップグレードします。
すべてのトラフィックを以前のリージョンに戻し、トラフィックを検証します。
新しいリージョンを廃止します。

マルチリージョンインストールをアップグレードする前の考慮事項

Apigee では、マルチリージョンインストールのアップグレードには次の順序を推奨しています。

アップグレードを開始する前に、各リージョンのデータをバックアップして検証します。
1 つのリージョンで Hybrid バージョンをアップグレードし、すべての Pod が実行状態であることを確認して、アップグレードを検証します。
新しくアップグレードされたリージョンでトラフィックを検証します。
前のリージョンでトラフィックを検証した後でのみ、後続の各リージョンをアップグレードします。
マルチリージョンデプロイでアップグレードをロールバックする必要がある場合は、障害が発生したリージョンからトラフィックを切り替える準備をします。トラフィックを転送するリージョンに十分な容量を追加して、両方のリージョンのトラフィックを処理することを検討してください。

前提条件

ハイブリッドバージョン 1.12 にアップグレードする前に、インストールが次の要件を満たしていることを確認してください。

Helm で管理されている Apigee ハイブリッドバージョン 1.11 のインストール。
- apigeectl でハイブリッドインストールを管理している場合は、まずクラスタを Helm 管理に移行する必要があります。ハイブリッド v1.11 ドキュメントの Apigee ハイブリッドを apigeectl から Helm に移行するをご覧ください。
- ハイブリッドインストールで v1.11 より前のバージョンを実行している場合は、v1.12 にアップグレードする前にバージョン 1.11 にアップグレードする必要があります。Apigee ハイブリッドのバージョン 1.11 へのアップグレードをご覧ください。
Helm バージョン v3.14.2 以降。
kubectl バージョン 1.27、1.28、1.29（推奨）。
cert-manager バージョン v1.13.0。必要に応じて、後述のバージョンへのアップグレードの準備で cert-manager をアップグレードします。

制限事項

Apigee ハイブリッドバージョン 1.11 からバージョン 1.12 へのアップグレードを計画する際は、次の制限事項に注意してください。アップグレード後にロールバックまたは復元する必要がある場合、計画を立てておくとダウンタイムを短縮できます。

2 つのバージョン間の互換性がないために、Hybrid 1.12 のバックアップを Hybrid 1.11 で復元することはできません。また、その逆も同様です。
バージョン 1.12 へのアップグレード中にデータストア Pod をスケーリングすることはできません。ハイブリッドインストールのアップグレードを開始する前に、すべてのリージョンでスケーリングのニーズに対応してください。
単一リージョンのハイブリッドインストールでは、データストアアップグレードプロセスが完了すると、データストアコンポーネントをロールバックできなくなります。Cassandra 4.x データストアを Cassandra 3.x データストアにロールバックすることはできません。これには、Cassandra 3.x データの最新のバックアップ（ハイブリッドバージョン 1.11 のインストールから）からの復元が必要になります。
アップグレード中にリージョンを削除または追加することはできません。マルチリージョンアップグレードでは、リージョンを追加または削除するには、すべてのリージョンのアップグレードを完了する必要があります。

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

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

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

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

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

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

アップグレードを準備する。
- Cassandra をバックアップします。
- ハイブリッドインストールディレクトリをバックアップします。
ハイブリッドランタイムバージョン 1.12.4 をインストールする。

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

cassandra のバックアップ

アップグレードを開始する前に、該当するすべてのリージョンで Cassandra データベースをバックアップし、ハイブリッドバージョン 1.11 のインストールでデータを検証します。バージョン 1.11 のドキュメントのバックアップのモニタリングをご覧ください。

アップグレードプロセスを開始する前に、クラスタ内のすべての Cassandra Pod を再起動して、残っている問題を明らかにします。

Cassandra Pod を再起動してテストするには、各 Pod を 1 つずつ削除し、実行状態に戻り、readinessProbe が成功することを確認します。

Cassandra Pod を一覧取得します。

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

例:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Pod を削除します。

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

例:

kubectl delete pod -n apigee apigee-cassandra-default-0

Cassandra Pod を再度一覧表示して、ステータスを確認します。

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

例:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          16s
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

最後に認識されたオーバーライドファイルを再度適用し、同じ構成を使用してハイブリッドバージョン 1.12 にアップグレードできるように、変更がないことを確認します。

すべてのリージョンのすべての Cassandra ノードが UN（Up / Normal）状態であることを確認します。Cassandra ノードが異なる状態の場合は、アップグレードを開始する前にその状態に対処します。

Cassandra ノードの状態は、次のコマンドで確認できます。

Cassandra Pod を一覧取得します。

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

例:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

kubectl nodetool status コマンドを使用して、各 Cassandra Pod のノードの状態を確認します。

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool status

例:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

ハイブリッドインストールディレクトリをバックアップする

この手順では、ファイルシステム内で Helm チャートをインストールしたディレクトリに対し、環境変数 APIGEE_HELM_CHARTS_HOME を使用します。必要に応じてこのディレクトリに移動し、次のコマンドで変数を定義します。
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
macOS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
バージョン 1.11 の $APIGEE_HELM_CHARTS_HOME/ ディレクトリのバックアップを作成します。任意のバックアッププロセスを使用できます。たとえば、次のコマンドを使用して、ディレクトリ全体の tar ファイルを作成します。
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Cassandra のバックアップと復元の手順で Cassandra データベースをバックアップします。

オーバーライドでサービス証明書ファイル（.json）を使用してサービスアカウントを認証している場合は、サービスアカウント証明書ファイルが正しい Helm チャートディレクトリにあることを確認してください。Helm チャートは、各チャートディレクトリ外のファイルを読み取ることができません。

Kubernetes Secret または Workload Identity を使用してサービスアカウントを認証している場合は、この手順は必要ありません。

次の表に、インストールの種類に応じた各サービスアカウントファイルの移動先を示します。

本番環境

サービスアカウント	デフォルトのファイル名	Helm チャートのディレクトリ
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

非本番環境

次の各ディレクトリに、apigee-non-prod サービスアカウントファイルのコピーを作成します。

サービスアカウント	デフォルトのファイル名	Helm チャートのディレクトリ
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

TLS 証明書ファイルと鍵ファイル（.crt、.key、.pem）が $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/ ディレクトリにあることを確認します。

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

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

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

	1.10 ⁽³⁾	1.11	1.12
GKE on Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.25.x 1.26.x 1.27.x 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.26.x 1.27.x 1.28.x 1.29.x^{（≥ 1.12.1）}
GKE on AWS	1.13.x（K8s v1.24.x） 1.14.x（K8s v1.25.x） 1.26.x⁽¹²⁾ 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.14.x（K8s v1.25.x） 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{（≥ 1.12.1）}
Azure 上の GKE	1.13.x 1.14.x 1.26.x⁽¹²⁾ 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.14.x 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{（≥ 1.12.1）}
VMware 用 Google Distributed Cloud（ソフトウェアのみ）⁽¹⁾⁽¹³⁾	1.13.x 1.14.x 1.15.x（K8s v1.26.x） 1.16.x（K8s v1.27.x） 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.14.x 1.15.x（K8s v1.26.x） 1.16.x（K8s v1.27.x） 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.15.x（K8s v1.26.x） 1.16.x（K8s v1.27.x） 1.28.x⁽¹²⁾ 1.29.x^{（≥ 1.12.1）}
ベアメタル版 Google Distributed Cloud（ソフトウェアのみ）⁽¹⁾	1.13.x 1.14.x（K8s v1.25.x） 1.15.x（K8s v1.26.x） 1.16.x（K8s v1.27.x） 1.27.x⁽¹²⁾^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.14.x 1.15.x（K8s v1.26.x） 1.16.x（K8s v1.27.x） 1.28.x⁽¹²⁾^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.15.x（K8s v1.26.x） 1.16.x（K8s v1.27.x） 1.28.x⁽¹²⁾ 1.29.x^{（≥ 1.12.1）}
EKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.25.x 1.26.x 1.27.x 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.26.x 1.27.x 1.28.x 1.29.x^{（≥ 1.12.1）}
AKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	1.25.x 1.26.x 1.27.x 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	1.26.x 1.27.x 1.28.x 1.29.x^{（≥ 1.12.1）}
OpenShift⁽⁷⁾	4.11 4.12 4.14^{（≥ 1.10.5）} 4.15^{（≥ 1.10.5）}	4.12 4.13 4.14 4.15^{（≥ 1.11.2）} 4.16^{（≥ 1.11.2）}	4.12 4.13 4.14 4.15 4.16^{（≥ 1.12.1）}
Rancher Kubernetes Engine（RKE）	v1.26.2+rke2r1 1.27.x^{（≥ 1.10.5）} 1.28.x^{（≥ 1.10.5）}	v1.26.2+rke2r1 v1.27.x 1.28.x^{（≥ 1.11.2）} 1.29.x^{（≥ 1.11.2）}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{（≥ 1.12.1）}
VMware Tanzu	なし	なし	v1.26.x
コンポーネント	1.10	1.11	1.12
Cloud Service Mesh	1.17.x⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Secret Store CSI ドライバ		1.3.4	1.4.1
Vault		1.13.x	1.15.2
⁽¹⁾ Anthos オンプレミス（Google Distributed Cloud）バージョン 1.13 では、`cert-manager` との競合を回避するために、cert-manager のインストールの競合を回避するの手順を実施してください。 ⁽²⁾ Apigee ハイブリッドバージョン 1.7.2 以降でサポートされています。 ⁽³⁾ Apigee ハイブリッドバージョン 1.10 以前の正式なサポートが終了しました。今後、定期的な月次パッチは提供されません。サポートの継続が正式に提示されているお客様を除き、これらのリリースの正式なサポートは提供されません。他のお客様はアップグレードが必要です。 ⁽⁴⁾ Anthos on-premises（Google Distributed Cloud）の 1.12 以前のバージョンはサポートが終了しています。Distributed Cloud on bare metal のバージョンサポートポリシーと、Distributed Cloud on VMware のサポートされているバージョンのリストをご覧ください。 ⁽⁵⁾ ベアメタルまたは VMware 上の Google Distributed Cloud には、Cloud Service Mesh 1.14 以降が必要です。ハイブリッド v1.8 にアップグレードして Apigee Ingress ゲートウェイに切り替えることをおすすめします。これにより、ハイブリッドクラスタに Cloud Service Mesh をインストールする必要がなくなります。 ⁽⁶⁾ Apigee ハイブリッドバージョン 1.8.4 以降でサポートされています。 ⁽⁷⁾ Apigee ハイブリッドバージョン 1.8.4 以降ではサポートされていません。 ⁽⁸⁾ Apigee ハイブリッドバージョン 1.7.6 以降でサポートされています。 ⁽⁹⁾ Apigee ハイブリッドバージョン 1.8.5 以降ではサポートされていません。 ⁽¹⁰⁾ Cloud Service Mesh は Apigee ハイブリッド 1.9 以降で自動的にインストールされます。 ⁽¹¹⁾ Apigee ハイブリッドバージョン 1.9.2 以降でサポートされています。 ⁽¹²⁾ GKE on AWS のバージョン番号に Kubernetes のバージョンが反映されるようになりました。バージョンの詳細と推奨パッチについては、GKE Enterprise のバージョンとアップグレードのサポートをご覧ください。 ⁽¹³⁾ Vault は、Google Distributed Cloud for VMware で認定されていません。 ⁽¹⁴⁾ Apigee ハイブリッドバージョン 1.10.5 以降でサポートされています。 ⁽¹⁵⁾ Apigee ハイブリッドバージョン 1.11.2 以降でサポートされています。 ⁽¹⁶⁾ Apigee ハイブリッドバージョン 1.12.1 以降でサポートされています。

接続クラスタについて

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

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

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

Helm チャートのアップグレードを準備する

Apigee Helm チャートを pull します。

Apigee ハイブリッドチャートは Google Artifact Registry でホストされます。

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

次のコマンドで pull コマンドを使用して、すべての Apigee ハイブリッド Helm チャートをローカルストレージにコピーします。

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.12.4
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

必要に応じて cert-manager をアップグレードします。
cert-manager のバージョンをアップグレードする必要がある場合は、次のコマンドを使用して、新しいバージョンをインストールします。
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
```

更新された Apigee CRD をインストールします。

注: これは、Apigee CRD をインストールするためにサポートされている唯一の方法です。-k なしで kubectl apply を使用しないでください。--server-side は省略しないでください。

次のコマンドを実行して、kubectl ドライラン機能を使用します。

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run

dry-run コマンドで検証した後、次のコマンドを実行します。

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

kubectl get crds コマンドを使用してインストールを検証します。

kubectl get crds | grep apigee

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

apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z

クラスタノードの既存のラベルを確認します。デフォルトでは、Apigee はラベルが cloud.google.com/gke-nodepool=apigee-data のノードでデータ Pod をスケジューリングし、ランタイム Pod はラベルが cloud.google.com/gke-nodepool=apigee-runtime のノードでスケジューリングされます。ノードプールのラベルは、overrides.yaml ファイルでカスタマイズできます。

詳細については、専用ノードプールの構成をご覧ください。

Apigee ハイブリッド Helm チャートをインストールする

注: Helm のアップグレード / インストールコマンドを実行する前に、コマンドの末尾に --dry-run を追加して、Helm ドライラン機能を使用します。サポートされているコマンド、オプション、使用方法の一覧は、helm -h をご覧ください。

まだ行っていない場合は、APIGEE_HELM_CHARTS_HOME ディレクトリに移動します。このディレクトリから次のコマンドを実行します。

Apigee Operator/Controller をアップグレードします。

注: この手順では、クラスタの昇格権限が必要です。詳細については、helm -h または helm upgrade -h を実行します。

ドライランを実行します。

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE \
  --dry-run

チャートをアップグレードします。

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE

注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  --force \
  -f OVERRIDES_FILE

Apigee Operator のインストールを確認します。

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

可用性をチェックして、稼働していることを確認します。

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Apigee データストアをアップグレードします。

ドライランを実行します。

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

チャートをアップグレードします。

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

状態をチェックして、apigeedatastore が稼働していることを確認します。

kubectl -n apigee get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Apigee テレメトリーをアップグレードします。

ドライランを実行します。

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

チャートをアップグレードします。

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Apigee Redis をアップグレードします。

ドライランを実行します。

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

チャートをアップグレードします。

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Apigee Ingress Manager をアップグレードします。

ドライランを実行します。

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

チャートをアップグレードします。

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

可用性をチェックして、稼働していることを確認します。

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Apigee 組織をアップグレードします。

ドライランを実行します。

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

チャートをアップグレードします。

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

それぞれの組織の状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeeorg

NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d

環境をアップグレードします。
同時にインストールできる環境は 1 つだけです。--set env=ENV_NAME で環境を指定します。

ドライランを実行します。
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
- ENV_RELEASE_NAME は、以前に apigee-env チャートをインストールしたときに使用した名前です。ハイブリッド v1.10 では通常、apigee-env-ENV_NAME です。ハイブリッド v1.11 以降では、通常は ENV_NAME です。
- ENV_NAME はアップグレードする環境の名前です。
- OVERRIDES_FILE は、v.1.12.4 の新しいオーバーライドファイルです。
チャートをアップグレードします。
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
それぞれの環境の状態をチェックして、稼働していることを確認します。
```
kubectl -n apigee get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```
環境グループ（virtualhosts）をアップグレードします。
1. 一度にアップグレードできる環境グループ（virtualhost）は 1 つだけです。--set envgroup=ENV_GROUP_NAME を使用して環境グループを指定します。overrides.yaml ファイルに記載されている env グループごとに、次のコマンドを繰り返します。
  ドライランを実行します。
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
  ENV_GROUP_RELEASE_NAME は、以前に apigee-virtualhost チャートをインストールしたときに使用した名前です。ハイブリッド v1.10 では通常、apigee-virtualhost-ENV_GROUP_NAME です。ハイブリッド v1.11 以降では、通常は ENV_GROUP_NAME です。
  
  チャートをアップグレードします。
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  注: apigeectl から Helm に移行されたインストールの場合は、次のコマンドを使用します。
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  --force \
  -f OVERRIDES_FILE
```
  注: ENV_GROUP_RELEASE_NAME は apigee 名前空間内で一意である必要があります。
  たとえば、prod という名前の環境と、prod という名前の環境グループがある場合は、ENV_GROUP_RELEASE_NAME の値を prod-envgroup など、一意の値に設定してください。
2. ApigeeRoute（AR）の状態を確認します。
  virtualhosts をインストールすると、ApigeeRouteConfig（ARC）が作成されます。これにより、Apigee ウォッチャーがコントロールプレーンから env グループ関連の詳細を pull した時点で、ApigeeRoute（AR）が内部で作成されます。このため、対応する AR の状態が実行中であることを確認します。
```
kubectl -n apigee get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n apigee get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```

1.12.4 へのアップグレード後にポリシーを検証する

1.12.3 以前から 1.12.4 以降にアップグレードした後、以下の手順で JavaCallout ポリシーの動作を確認します。

Java JAR ファイルが不要な権限をリクエストしていないかどうかを確認する。
ポリシーがデプロイされたら、ランタイムログに "Failed to load and initialize class ..." というログメッセージがないか確認します。このメッセージがある場合は、デプロイされた JAR が不要な権限をリクエストしたことを示しています。この問題を解決するには、Java コードを調べて JAR ファイルを更新します。
Java コードを調べて更新する。
すべての Java コード（依存関係を含む）を見直して、許可されていない可能性のあるオペレーションの原因を特定します。原因が見つかったら、必要に応じてソースコードを変更します。
セキュリティチェックを有効にしてポリシーをテストする。
非本番環境でセキュリティチェックフラグを有効にし、更新された JAR を使用してポリシーを再デプロイします。フラグを設定する手順は次のとおりです。
- apigee-env/values.yaml ファイルで、runtime:cwcAppend: の下の conf_security-secure.constructor.only を true に設定します。次に例を示します。
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- 環境の apigee-env チャートを更新して、変更を適用します。次に例を示します。
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
ログメッセージ "Failed to load and initialize class ..." が引き続き記録される場合は、このメッセージが記録されなくなるまで JAR の変更とテストを繰り返します。
本番環境でセキュリティチェックを有効にする。
非本番環境での JAR ファイルの徹底的なテストと検証が済んだら、本番環境でセキュリティチェックを有効にします。そのためには、フラグ conf_security-secure.constructor.only を true に設定し、本番環境の apigee-env チャートを更新して変更を適用します。

以前のバージョンにロールバックする

このセクションは、Apigee ハイブリッドバージョン 1.12 にアップグレードした後の apigee-datastore コンポーネントの状態に応じて、複数のセクションに分かれています。apigee-datastore コンポーネントが正常な状態の場合の単一リージョンまたはマルチリージョンのロールバックの手順と、apigee-datastore が異常な状態の場合のバックアップからの復元またはリストアの手順があります。

単一リージョンのロールバックと復元

`apigee-datastore` が正常な状態の場合のロールバック

この手順では、すべての Apigee ハイブリッドコンポーネントを v1.12 から v1.11 にロールバックする方法について説明します（apigee-datastore を除く）。v1.12 apigee-datastore コンポーネントは、ハイブリッド v1.11 コンポーネントと下位互換性があります。

警告: apigee-datastore をロールバックすることはできません。異なるバージョンの Cassandra データベース間でデータの非互換性があるため、以前のバージョンにロールバックできません。

単一リージョンのインストールをバージョン 1.11 にロールバックするには:

ロールバックを開始する前に、すべての Pod が実行状態であることを確認します。
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Helm を使用してコンポーネントのリリースを検証します。

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

次に例を示します。

helm -n apigee list
NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0

次のコマンドを使用して、apigee-datastore を除く各コンポーネントをロールバックします。

次の環境変数を作成します。
- PREVIOUS_HELM_CHARTS_HOME: 以前の Apigee ハイブリッド Helm チャートがインストールされているディレクトリ。これはロールバックするバージョンです。
仮想ホストをロールバックします。オーバーライドファイルに記載されている環境グループごとに、次のコマンドを繰り返します。
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME は、以前に apigee-virtualhost チャートをインストールしたときに使用した名前です。ハイブリッド v1.10 では通常、apigee-virtualhost-ENV_GROUP_NAME です。ハイブリッド v1.11 以降では、通常は ENV_GROUP_NAME です。
環境をロールバックします。オーバーライドファイルに記載されている環境ごとに、次のコマンドを繰り返します。
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME は、以前に apigee-env チャートをインストールしたときに使用した名前です。ハイブリッド v1.10 では通常、apigee-env-ENV_NAME です。ハイブリッド v1.11 以降では、通常は ENV_NAME です。

それぞれの環境の状態をチェックして、稼働していることを確認します。
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

組織をロールバックします。

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

それぞれの組織の状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Ingress Manager をロールバックします。

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

可用性をチェックして、稼働していることを確認します。

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Redis をロールバックします。

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Apigee テレメトリーをロールバックします。

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Apigee コントローラをロールバックします。

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Apigee Operator のインストールを確認します。

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

可用性をチェックして、稼働していることを確認します。

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Apigee ハイブリッド CRD をロールバックします。

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

すべての Pod が実行中または完了状態であることを確認します。
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

すべてのコンポーネントのリリースを検証します。データストア以外のすべてのコンポーネントは、以前のバージョンにする必要があります。

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

次に例を示します。

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

`apigee-datastore` が良好な状態ではない場合に復元する

apigee-datastore コンポーネントのアップグレードが成功しなかった場合、apigee-datastore をバージョン 1.12 からバージョン 1.11 にロールバックすることはできません。代わりに、v1.11 インストールのバックアップから復元する必要があります。次の手順で以前のバージョンを復元します。

Apigee ハイブリッドバージョン 1.11 のアクティブなインストールがない場合は（別のリージョンなど）、バックアップしたチャートとオーバーライドファイルを使用して v1.11 の新しいインストールを作成します。Apigee ハイブリッドバージョン 1.11 のインストール手順をご覧ください。
次の手順に沿って、バックアップから v1.11 リージョン（または新しいインストール）を復元します。
- Cloud Storage Interface（CSI）バックアップ: Cassandra CSI のバックアップと復元。
- CSI 以外のバックアップ: 単一リージョンでの復元。
復元されたインストールへのトラフィックを検証する
省略可: ハイブリッドランタイムをアンインストールするの手順に沿って、バージョン 1.12 のインストールを削除します。

マルチリージョンのロールバックと復元

`apigee-datastore` が正常な状態の場合のロールバック

ロールバックを開始する前に、すべての Pod が実行状態であることを確認します。
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

すべてのリージョンのすべての Cassandra ノードが UN（Up / Normal）状態であることを確認します。Cassandra ノードが異なる状態の場合は、アップグレードプロセスを開始する前に、まずその状態に対処します。

Cassandra ノードの状態は、次のコマンドで確認できます。

Cassandra Pod を一覧取得します。

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

例:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

kubectl nodetool status コマンドを使用して、各 Cassandra Pod のノードの状態を確認します。

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

例:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

すべての Cassandra Pod が UN 状態でない場合は、Cassandra クラスタから DOWN ノードを削除するの手順を行います。

以前の Apigee ハイブリッド Helm チャートがインストールされているディレクトリに移動します。
コンテキストをアップグレードしたリージョンに変更します。
```
kubectl config use-context UPGRADED_REGION_CONTEXT
    
```

すべての Pod が実行状態であることを確認します。

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

helm コマンドを使用して、すべてのリリースが Hybrid v1.12 にアップグレードされていることを確認します。

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

次に例を示します。

helm -n apigee list
NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0

次のコマンドを使用して、apigee-datastore を除く各コンポーネントをロールバックします。

次の環境変数を作成します。
- PREVIOUS_HELM_CHARTS_HOME: 以前の Apigee ハイブリッド Helm チャートがインストールされているディレクトリ。これはロールバックするバージョンです。
仮想ホストをロールバックします。オーバーライドファイルに記載されている環境グループごとに、次のコマンドを繰り返します。
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME は、以前に apigee-virtualhost チャートをインストールしたときに使用した名前です。ハイブリッド v1.10 では通常、apigee-virtualhost-ENV_GROUP_NAME です。ハイブリッド v1.11 以降では、通常は ENV_GROUP_NAME です。
環境をロールバックします。オーバーライドファイルに記載されている環境ごとに、次のコマンドを繰り返します。
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME は、以前に apigee-env チャートをインストールしたときに使用した名前です。ハイブリッド v1.10 では通常、apigee-env-ENV_NAME です。ハイブリッド v1.11 以降では、通常は ENV_NAME です。

それぞれの環境の状態をチェックして、各環境が稼働していることを確認します。
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

組織をロールバックします。

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

それぞれの組織の状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Ingress Manager をロールバックします。

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

可用性をチェックして、稼働していることを確認します。

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Redis をロールバックします。

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Apigee テレメトリーをロールバックします。

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

状態をチェックして、稼働していることを確認します。

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Apigee コントローラをロールバックします。

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Apigee Operator のインストールを確認します。

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

可用性をチェックして、稼働していることを確認します。

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Apigee ハイブリッド CRD をロールバックします。

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

すべてのコンポーネントのリリースを検証します。すべてのコンポーネントは、datastore を除き、以前のバージョンである必要があります。

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

次に例を示します。

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

この時点で、datastore を除くすべてのリリースが以前のバージョンにロールバックされています。

マルチリージョンインストールを以前のバージョンに復元する

マルチリージョンアップグレードでアップグレードが失敗したリージョンを復元するには、複数のリージョンインストールからそのリージョンへの参照を削除します。この方法は、Hybrid 1.11 でライブリージョンが 1 つ以上ある場合にのみ使用できます。v1.12 データストアは v1.11 コンポーネントと互換性があります。

障害が発生したリージョンを正常なリージョンから復元するには、次の手順に沿います。

影響を受けたリージョンから正常に動作するリージョンに API トラフィックをリダイレクトします。障害が発生したリージョンから迂回されるトラフィックに対応できるよう容量を適宜計画します。
影響を受けたリージョンを廃止します。影響を受けた各リージョンに対して、ハイブリッドリージョンを廃止するで説明されている操作を行います。廃止が完了するまで待ってから次のステップに進みます。
アップグレードに失敗したリージョンを復元するの手順に沿って、障害が発生したリージョンをクリーンアップします。
影響を受けたリージョンを復元します。復元するには、GKE、GKE On-Prem、AKS でのマルチリージョンデプロイの説明に沿って、新しいリージョンを作成します。

`apigee-datastore` が不正な状態のバックアップからマルチリージョンインストールを復元する

apigee-datastore コンポーネントのアップグレードが成功しなかった場合、バージョン 1.12 からバージョン 1.11 にロールバックすることはできません。代わりに、v1.11 インストールのバックアップから復元する必要があります。次の手順で以前のバージョンを復元します。

Apigee ハイブリッドバージョン 1.11 のアクティブなインストールがない場合は（別のリージョンなど）、バックアップしたチャートとオーバーライドファイルを使用して v1.11 の新しいインストールを作成します。Apigee ハイブリッドバージョン 1.11 のインストール手順をご覧ください。
次の手順に沿って、バックアップから v1.11 リージョン（または新しいインストール）を復元します。
- Cloud Storage Interface（CSI）バックアップ: Cassandra CSI のバックアップと復元。
- CSI 以外のバックアップ: 複数のリージョンでの復元。
復元されたインストールへのトラフィックを検証する
マルチリージョンインストールの場合は、次のリージョンを再構築して復元します。複数のリージョンでの復元のバックアップからの復元の手順をご覧ください。
ハイブリッドランタイムをアンインストールするの手順に沿って、バージョン 1.12 のインストールを削除します。

付録: アップグレード失敗からのリージョンの復元

1.11 から 1.12 へのアップグレードが失敗した場合は、データセンターを削除します。

ライブリージョンから Cassandra クラスタのステータスを確認します。

kubectl コンテキストを削除するリージョンに切り替えます。
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

Cassandra Pod を一覧取得します。

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

例:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

いずれかの Cassandra Pod を実行します。

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Cassandra クラスタのステータスを確認します。

nodetool -u JMX_USER -pw JMX_PASSWORD status

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

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1

クラスタの説明を表示し、ライブリージョンの Cassandra Pod の IP アドレスのみが表示され、それらのすべてが同じスキーマバージョンにあることを確認します。
```
nodetool -u JMX_USER -pw JMX_PASSWORD describecluster
```
出力は次のようになります。
```
nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

Schema versions:
    4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]
```

Cassandra キースペースの複製をクリーンアップします。

user-setup ジョブを取得して削除します。新しい user-setup ジョブがすぐに作成されます。

kubectl get jobs -n APIGEE_NAMESPACE

例:

kubectl get jobs -n apigee
  NAME                                                           COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
  apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
 apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s

kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

出力には、新しいジョブの開始が表示されます。

kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee

  apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s

クライアントコンテナを作成するの手順に沿ってクライアントコンテナを作成して、Cassandra キースペースの複製設定を検証します。

すべてのキースペースを取得します。cassandra-client Pod を実行し、cqlsh クライアントを起動します。

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

次のコマンドを実行するために必要な権限がある ddl user を使用して、Cassandra サーバーに接続します。

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

キースペースを取得します。

select * from system_schema.keyspaces;

出力は次のようになります。ここで、dc-1 はライブ DC です。

select * from system_schema.keyspaces;

 keyspace_name            | durable_writes | replication
--------------------------+----------------+--------------------------------------------------------------------------------
   kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
 quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
 cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                   system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                   perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

なんらかの理由で user-setup ジョブがエラーになり、検証が失敗する場合は、次のコマンドを使用してキースペースのレプリケーションを修正します。

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

次のコマンドを実行するために必要な権限がある ddl user を使用して、Cassandra サーバーに接続します。

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

キースペースを取得します。

select * from system_schema.keyspaces;

上記のコマンドからキースペース名を使用して、次の例で置き換えます。

alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};

次の cqlsh コマンドを使用して、すべてのキースペースが正しいリージョンでレプリケーションされていることを確認します。

select * from system_schema.keyspaces;

例:

select * from system_schema.keyspaces;

 keyspace_name           | durable_writes | replication
-------------------------+----------------+--------------------------------------------------------------------------------
kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
          system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
               perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

この時点で、Cassandra クラスタから障害が発生した DC のすべての参照が完全に削除されています。

付録: Cassandra クラスタから DOWN ノードを削除する

マルチリージョンインストールをロールバックするときに、すべての Cassandra Pod が Up / Normal（UN）状態ではない場合は、この手順を使用します。

いずれかの Cassandra Pod を実行します。

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Cassandra クラスタのステータスを確認します。
```
nodetool -u JMX_USER -pw JMX_PASSWORD status
```

ノードが実際にダウン状態（DN）であることを確認します。Cassandra Pod が起動できないリージョンの Cassandra Pod に対して実行します。

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

ダウン（DN）ノードへの参照を削除します。上記の例では、ホスト 10.8.4.4 の参照を削除します。

kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
 nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID

参照が削除されたら、Pod を終了します。新しい Cassandra Pod が起動し、クラスタに参加します。
```
kubectl delete pod -n POD_NAME
```

新しい Cassandra Pod がクラスタに参加したことを確認します。

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

この時点で、クラスタの残りのリージョンのアップグレードまたはロールバックを続行できます。

付録: トラブルシューティング: ロールバック後に `apigee-datastore` がスタック状態になる

アップグレード後に apigee-datastore をハイブリッド 1.11 にロールバックし、停止状態の場合は、この手順を使用します。

データストアコントローラの状態を再度修正する前に、それが releasing 状態であることと、Pod が Cassandra クラスタの状態とともに起動していないことを確認します。

Helm コマンドを使用して、データストアがロールバックされたことを確認します。

helm -n APIGEE_NAMESPACE list

例:

helm -n apigee list
NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0

Cassandra Pod のステータスを取得します。

kubectl get pods -n APIGEE_NAMESPACE

例:

kubectl get pods -n apigee
NAME                         READY   STATUS             RESTARTS      AGE
apigee-cassandra-default-0   1/1     Running            0             2h
apigee-cassandra-default-1   1/1     Running            0             2h
apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s

apigeeds コントローラがリリース状態のまま停止していることを確認します。

kubectl get apigeeds -n APIGEE_NAMESPACE

例:

kubectl get apigeeds -n apigee
NAME      STATE       AGE
default   releasing   46h

Cassandra ノードのステータスを確認します（1 つのノードが DN 状態にあり、CrashLoopBackOff 状態にスタックしていることに注意してください）。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

例:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1

1.12 のグラフを使用してデータストアをアップグレードします。
注: コントローラは再び releasing 状態になりますが、今回は Hybrid 1.12 のイメージを使用して Pod が作成され、Cassandra がクラスタに参加し、UN（UP/NORMAL）になります。
```
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
```

すべての Pod が Running であり、Cassandra クラスタが正常であることを確認します。

すべての Pod が READY であることを再度確認します。

kubectl get pods -n APIGEE_NAMESPACE

例:

kubectl get pods -n apigee
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29h
apigee-cassandra-default-1   1/1     Running   0          29h
apigee-cassandra-default-2   1/1     Running   0          60m

Cassandra クラスタのステータスを検証します。

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

例:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1

apigeeds コントローラのステータスを検証します。

kubectl get apigeeds -n APIGEE_NAMESPACE

例:

kubectl get apigeeds -n apigee
NAME      STATE     AGE
default   running   2d1h

これでデータストアが修正され、running 状態になっているはずです。

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

Apigee ハイブリッド v1.11 からの変更

バージョン 1.12 へのアップグレードを開始する前に考慮すべき事項

Cassandra の考慮事項

単一リージョンのインストールをアップグレードする前の考慮事項

マルチリージョン インストールをアップグレードする前の考慮事項

前提条件

制限事項

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

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

cassandra のバックアップ

ハイブリッド インストール ディレクトリをバックアップする

Linux

macOS

Windows

本番環境

非本番環境

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

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

コンポーネント

接続クラスタについて

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

Helm チャートのアップグレードを準備する

Apigee ハイブリッド Helm チャートをインストールする

1.12.4 へのアップグレード後にポリシーを検証する

以前のバージョンにロールバックする

単一リージョンのロールバックと復元

apigee-datastore が正常な状態の場合のロールバック

apigee-datastore が良好な状態ではない場合に復元する

マルチリージョンのロールバックと復元

apigee-datastore が正常な状態の場合のロールバック

マルチリージョン インストールを以前のバージョンに復元する

apigee-datastore が不正な状態のバックアップからマルチリージョン インストールを復元する

付録: アップグレード失敗からのリージョンの復元

付録: Cassandra クラスタから DOWN ノードを削除する

付録: トラブルシューティング: ロールバック後に apigee-datastore がスタック状態になる

マルチリージョンインストールをアップグレードする前の考慮事項

ハイブリッドインストールディレクトリをバックアップする

`apigee-datastore` が正常な状態の場合のロールバック

`apigee-datastore` が良好な状態ではない場合に復元する

`apigee-datastore` が正常な状態の場合のロールバック

マルチリージョンインストールを以前のバージョンに復元する

`apigee-datastore` が不正な状態のバックアップからマルチリージョンインストールを復元する

付録: トラブルシューティング: ロールバック後に `apigee-datastore` がスタック状態になる