ここでは、Apigee ハイブリッド バージョン 1.11.x から Apigee ハイブリッド バージョン 1.12.1 へのアップグレードについて説明します。
Apigee ハイブリッド v1.11 からの変更
Apigee Hybrid バージョン 1.12 では、アップグレード プロセスに影響する次の変更が導入されています。v1.12 の機能の詳細については、ハイブリッド v1.12.0 リリースノートをご覧ください。
- Cassandra 4.x: バージョン 1.12 以降、Apigee ハイブリッドは Cassandra バージョン 4 以降を使用します。
-
apigeectl
のサポートの終了: バージョン 1.12 以降、Apigee ハイブリッドはハイブリッド インストールのインストールと管理に Helm のみをサポートしています。 -
Apigee プロキシとターゲット エンドポイントをモニタリングするための新しい指標スイートが利用可能になりました。ハイブリッド v1.12 では、
ProxyV2
とTargetV2
のモニタリング リソースはデフォルトで使用されなくなります。すべてのプロキシ指標とターゲット指標は、Proxy
とTarget
のモニタリング対象リソースに公開されます。引き続き
ProxyV2
とTargetV2
のモニタリング対象リソースに指標を出力するには、overrides.yaml
でmetrics.disablePrometheusPipeline
をtrue
に設定します。指標ベースのアラートを構成している場合は、ハイブリッド インストールに適した指標が使用されていることを確認します。詳細については、指標ベースのアラートをご覧ください。
バージョン 1.12 へのアップグレードを開始する前に考慮すべき事項
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
コンポーネントは正常な状態であるが、他のコンポーネントをロールバックする必要がある場合は、それらのコンポーネントを個別にロールバックできます。apigee-datastore
コンポーネントが不正な状態の場合は、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.10 以降。
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.1 へのアップグレードの概要
以降のセクションでは、Apigee Hybrid のアップグレード手順を次の順番で説明します。
バージョン 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 . . .
-
Cassandra Pod を一覧表示します。
- 最後に認識されたオーバーライド ファイルを再度適用し、同じ構成を使用してハイブリッド バージョン 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
- Cassandra Pod を一覧表示します。
ハイブリッド インストール ディレクトリをバックアップする
- この手順では、ファイル システム内で 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.12.1 ランタイムをインストールする
Helm チャートのアップグレードを準備する
apigee-operator
チャートで正しいタグ1.12.1-hotfix.1
を使用できるように、overrides.yaml ファイルを次のように変更します。ao: image: url: "gcr.io/apigee-release/hybrid/apigee-operators" tag: "1.12.1-hotfix.1"
Apigee 1.12.1-hotfix.1 リリースノートをご覧ください。
- 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.1
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 をインストールします。
-
次のコマンドを実行して、
kubectl
ドライラン機能を使用します。kubectl apply -k apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server
-
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 チャートをインストールする
- まだ行っていない場合は、
APIGEE_HELM_CHARTS_HOME
ディレクトリに移動します。このディレクトリから次のコマンドを実行します。 - Apigee Operator/Controller をアップグレードします。
ドライランを実行します。
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
Apigee オペレーターのインストールを確認します。
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.1 1.12.1
可用性をチェックして、稼働していることを確認します。
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
状態をチェックして、
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
状態をチェックして、稼働していることを確認します。
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
状態をチェックして、稼働していることを確認します。
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
可用性をチェックして、稼働していることを確認します。
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
それぞれの組織の状態をチェックして、稼働していることを確認します。
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.1 の新しいオーバーライド ファイルです。
チャートをアップグレードします。
helm upgrade ENV_RELEASE_NAME apigee-env/ \ --install \ --namespace APIGEE_NAMESPACE \ --set env=ENV_NAME \ -f OVERRIDES_FILE
それぞれの環境の状態をチェックして、稼働していることを確認します。
kubectl -n apigee get apigeeenv
NAME STATE AGE GATEWAYTYPE apigee-org1-dev-xxx running 2d
- ENV_RELEASE_NAME は、以前に
-
環境グループ(
virtualhosts
)をアップグレードします。- 一度にアップグレードできる環境グループ(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
- 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
- 一度にアップグレードできる環境グループ(virtualhost)は 1 つだけです。
以前のバージョンにロールバックする
このセクションは、Apigee ハイブリッド バージョン 1.12 にアップグレードした後の apigee-datastore
コンポーネントの状態に応じて、複数のセクションに分かれています。apigee-datastore
コンポーネントが正常な状態の場合の単一リージョンまたはマルチリージョンのロールバックの手順と、apigee-datastore
が異常な状態の場合のバックアップからの復元またはリストアの手順があります。
単一リージョンのロールバックと復元
apigee-datastore
が正常な状態の場合のロールバック
この手順では、すべての Apigee ハイブリッド コンポーネントを v1.12 から v1.11 にロールバックする方法について説明します(apigee-datastore
を除く)。v1.12 apigee-datastore
コンポーネントは、ハイブリッド v1.11 コンポーネントと下位互換性があります。
単一リージョンのインストールをバージョン 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 オペレーターのインストールを確認します。
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.1 1.12.1
可用性をチェックして、稼働していることを確認します。
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
が正常な状態の場合のロールバック
この手順では、すべての Apigee ハイブリッド コンポーネントを v1.12 から v1.11 にロールバックする方法について説明します(apigee-datastore
を除く)。v1.12 apigee-datastore
コンポーネントは、ハイブリッド v1.11 コンポーネントと下位互換性があります。
-
ロールバックを開始する前に、すべての 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 ノードを削除するの手順を行います。 - Cassandra Pod を一覧表示します。
- 以前の 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 オペレーターのインストールを確認します。
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.1 1.12.1
可用性をチェックして、稼働していることを確認します。
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]
-
kubectl コンテキストを削除するリージョンに切り替えます。
-
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 21skubectl 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
-
Helm コマンドを使用して、データストアがロールバックされたことを確認します。
-
1.12 のグラフを使用してデータストアをアップグレードします。
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
-
すべての Pod が
これでデータストアが修正され、running
状態になっているはずです。