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

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

マイナーバージョンのアップグレード（バージョン 1.13 から 1.14 へのアップグレードなど）とパッチリリースのアップグレード（1.14.0 から 1.14.1 へのアップグレードなど）のどちらにも同じ手順を使用します。

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

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

次の変更点にご注意ください。

バージョン 1.14 から、データプレーンコンポーネントはデフォルトでデータをコントロールプレーンに直接書き込むようになりました。これにより、アナリティクスデータとデバッグデータの信頼性とコンプライアンスが向上します。データ所在地によるアナリティクスデータとデバッグデータの収集をご覧ください。
Anthos（on bare metal または on VMware）は Google Distributed Cloud（for Bare Metal または for VMware）になりました。詳細については、Google Distributed Cloud for Bare Metal と Google Distributed Cloud for VMware のプロダクト概要をご覧ください。
クラスのインスタンス化チェックの厳格化: バージョン 1.14.1 から、Apigee ハイブリッドの JavaCallout ポリシーに、Java クラスのインスタンス化時の追加のセキュリティが組み込まれました。この強化されたセキュリティ対策により、許可されていない権限を必要とするアクションを直接または間接的に試行するポリシーのデプロイを防ぐことができます。
ほとんどの場合、既存のポリシーは引き続き問題なく機能します。ただし、サードパーティライブラリに依存するポリシーや、昇格された権限を必要とするオペレーションを間接的にトリガーするカスタムコードを含むポリシーは、影響を受ける可能性があります。

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

ハイブリッドバージョン 1.14 の機能の詳細については、Apigee ハイブリッド v1.14.0 リリースノートをご覧ください。

前提条件

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

ハイブリッドインストールで v1.13 より前のバージョンを実行している場合は、v1.14 にアップグレードする前にバージョン 1.13 にアップグレードする必要があります。Apigee ハイブリッドのバージョン 1.13 へのアップグレードをご覧ください。
Helm バージョン v3.14.2 以降。
kubectl: Kubernetes プラットフォームのバージョンに適した kubectl のサポート対象バージョン。サポートされているプラットフォームとバージョン: kubectl をご覧ください。
cert-manager: サポートされているバージョンの cert-manager。サポートされているプラットフォームとバージョン: cert-manager をご覧ください。必要に応じて、後述のバージョン 1.14 へのアップグレードを準備するセクションを参考に、cert-manager をアップグレードしてください。

1.14.1 にアップグレードする前に - 制限事項と重要な注意事項

Apigee ハイブリッド 1.14.1 では、環境ごとのプロキシの上限が強化され、単一の環境にデプロイできるプロキシと共有フローの数が増えました。環境ごとにデプロイできるプロキシと共有フローの数の上限については、上限: API プロキシをご覧ください。この機能は、新しく作成されたハイブリッド組織でのみ使用できます。アップグレードされた組織には適用できません。この機能を使用するには、ハイブリッド 1.14.1 を新規にインストールし、新しい組織を作成します。

この機能は 2024 サブスクリプションプランにご加入いただいた場合にのみ使用でき、そのサブスクリプションに付与されている利用資格の影響を受けます。この機能の詳細については、環境ごとのプロキシの上限の強化をご覧ください。
Apigee ハイブリッドのバージョン 1.14 へのアップグレード中は、ダウンタイムが発生する場合があります。

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

本番環境に影響する可能性を低減するため、アップグレードを開始した後できるだけ早くすべてのクラスタをアップグレードすることをおすすめします。最初のクラスタをアップグレードした後に、残りのすべてのクラスタをいつアップグレードする必要があるかについては、時間制限はありません。ただし、Cassandra のバックアップと復元はバージョンが混在している環境では機能しないため、残りのクラスタがすべてアップグレードされるまで使用できません。たとえば、ハイブリッド 1.13 のバックアップを使用してハイブリッド 1.14 のインスタンスを復元することはできません。
アップグレード中に管理プレーンの変更を完全に一時停止する必要はありません。管理プレーンの変更の一時停止が必要な場合は、以下のアップグレード手順に記載されています。

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

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

アップグレードを準備する。
ハイブリッドランタイムバージョン 1.14.1 をインストールする。

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

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

この手順では、ファイルシステム内で 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.13 の $APIGEE_HELM_CHARTS_HOME/ ディレクトリのバックアップを作成します。任意のバックアッププロセスを使用できます。たとえば、次のコマンドを使用して、ディレクトリ全体の tar ファイルを作成します。
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.13-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Cassandra のバックアップと復元の手順に沿って Cassandra データベースをバックアップします。
重要: バージョン 1.14 から以下のバックアップ関連のチェックがガードレールに追加され、これが Apigee ハイブリッドのアップグレード中に適用されます。
1. 必要な場合に以前のバージョンに復元できるようにするには、バックアップを有効にする必要があります。
2. CSI バックアップが有効になっている場合は、アップグレード前の 24 時間以内にバックアップを作成する必要があります。これにより、以前のバージョンへの復元が必要な場合にデータ損失の可能性を最小限に抑えることができます。
ガードレールのチェックの詳細については、ガードレールをご覧ください。

オーバーライドでサービス証明書ファイル（.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.13 とハイブリッド 1.14 の両方でサポートされているバージョンにアップグレードします。ヘルプが必要な場合は、プラットフォームのドキュメントをご覧ください。

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

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

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

データ収集パイプラインを構成する

ハイブリッド v1.14 では、データプレーンコンポーネントが Apigee のコントロールプレーンに直接書き込めるようにするため、次の newDataPipeline スタンザを overrides.yaml ファイルに追加する必要があります。
```
# Required
newDataPipeline:
  debugSession: true
  analytics: true
```
データ所在地によるアナリティクスデータとデバッグデータの収集: 構成の手順に沿って、認可フローを構成します。

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.14.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.15.1/cert-manager.yaml
```
サポートされているバージョンの一覧については、サポートされているプラットフォームとバージョン: cert-manager をご覧ください。
Apigee Namespace が apigee でない場合は、apigee-operator/etc/crds/default/kustomization.yaml ファイルを編集して、namespace 値を Apigee Namespace に置き換えます。
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE
```
Namespace として apigee を使用している場合は、ファイルを編集する必要はありません。

更新された 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                    2024-08-21T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2024-08-21T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2024-08-21T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2024-08-21T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2024-08-21T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2024-08-21T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2024-08-21T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2024-08-21T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2024-08-21T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2024-08-21T14:48:35Z

2 つのコントローラが調整されないように、apigee-system Namespace 内の既存の Apigee Operator デプロイのレプリカを 0（ゼロ）に更新します。
```
kubectl scale deployment apigee-controller-manager -n apigee-system --replicas=0
```
2 つのコントローラが調整されないように、apigee-system Namespace 内の既存の Apigee Operator デプロイのレプリカを 0（ゼロ）に更新します。
```
kubectl delete mutatingwebhookconfiguration apigee-mutating-webhook-configuration
kubectl delete validatingwebhookconfiguration apigee-validating-webhook-configuration
```
クラスタノードの既存のラベルを確認します。デフォルトでは、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 \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

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

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

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

helm ls -n APIGEE_NAMESPACE

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.14.1   1.14.1

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

kubectl -n APIGEE_NAMESPACE 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=server

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

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

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

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

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

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

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

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

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

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

kubectl -n APIGEE_NAMESPACE 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=server

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

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

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

kubectl -n APIGEE_NAMESPACE 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=server

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

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

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

kubectl -n APIGEE_NAMESPACE 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=server
```
チャートをアップグレードします。
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
それぞれの組織の状態をチェックして、稼働していることを確認します。
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
```
注: アップグレードコマンドがエラー Forbidden: state: releasing で失敗した場合、既存のコンポーネントは引き続きリリースステータスになります。現在の更新が完了するまで待ってから、もう一度お試しください。次のコマンドを使用して、リリースステータスを確認します。
```
kubectl get org -n APIGEE_NAMESPACE
```
環境をアップグレードします。
同時にインストールできる環境は 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=server
```
- ENV_RELEASE_NAME は、apigee-env チャートのインストールとアップグレードの追跡に使用する名前です。この名前は、インストール内の他の Helm リリース名と重複していない必要があります。通常、これは ENV_NAME と同じにします。ただし、環境と環境グループの名前が同じである場合は、環境と環境グループに対して異なるリリース名（dev-env-release と dev-envgroup-release など）を使用する必要があります。Helm でのリリースの詳細については、Helm ドキュメントの 3 つの大きなコンセプト class="external"をご覧ください。
- ENV_NAME はアップグレードする環境の名前です。
- OVERRIDES_FILE は、v.1.14.1 の新しいオーバーライドファイルです。
チャートをアップグレードします。
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
それぞれの環境の状態をチェックして、稼働していることを確認します。
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```

注: アップグレードコマンドがエラー Forbidden: state: releasing で失敗した場合、既存のコンポーネントは引き続きリリースステータスです。現在の更新が完了するまで待ってから、もう一度お試しください。次のコマンドを使用して、リリースステータスを確認します。

kubectl get env -n APIGEE_NAMESPACE

環境グループ（virtualhosts）をアップグレードします。
1. 一度にアップグレードできる環境グループ（virtualhost）は 1 つだけです。--set envgroup=ENV_GROUP_NAME を使用して環境グループを指定します。overrides.yaml ファイルに記載されている環境グループごとに、次のコマンドを繰り返します。
  ドライランを実行します。
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
  ENV_GROUP_RELEASE_NAME は、以前に apigee-virtualhost チャートをインストールしたときに使用した名前です。通常は ENV_GROUP_NAME です。
  
  チャートをアップグレードします。
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  注: ENV_GROUP_RELEASE_NAME は apigee Namespace 内で一意である必要があります。
  たとえば、prod という名前の環境と prod という名前の環境グループがある場合は、ENV_GROUP_RELEASE_NAME の値を prod-envgroup など一意の値に設定します。
2. ApigeeRoute（AR）の状態を確認します。
  virtualhosts をインストールすると、ApigeeRouteConfig（ARC）が作成されます。これにより、Apigee ウォッチャーがコントロールプレーンから環境グループ関連の詳細を pull した時点で、ApigeeRoute（AR）が内部で作成されます。このため、対応する AR の状態が実行中であることを確認します。
```
kubectl -n APIGEE_NAMESPACE get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n APIGEE_NAMESPACE get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```
すべてのインストールが正常にアップグレードされたことを確認したら、古い apigee-operator リリースを apigee-system Namespace から削除します。
1. 古い operator リリースをアンインストールします。
```
helm delete operator -n apigee-system
```
2. apigee-system Namespace を削除します。
```
kubectl delete namespace apigee-system
```
Apigee Namespace で operator を再度アップグレードして、削除されたクラスタスコープのリソースを再インストールします。
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml
```

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

1.14.0 以前から 1.14.1 以降にアップグレードした後、以下の手順に沿って 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-virtualhost から apigee-operator に戻り、CRD を元に戻します。

apigee-operator の Namespace が変更されたため、Validating と Mutating のアドミッションフックを削除するには追加の手順が必要です。これにより、apigee-operator を apigee-system Namespace に再インストールすると、正しい Apigee Operator エンドポイントを参照するように再作成されます。

ヒント: 最後のリリースバージョンがわかっている場合は、後述の helm upgrade コマンドではなく、helm rollback コマンドを使用できます。

Apigee で既存の Apigee Operator デプロイのレプリカを 0（ゼロ）に更新します。これにより、2 つのコントローラがカスタムリソースを調整しなくなり、apigee-system Namespace でロールバックするときに競合が発生しなくなります。

kubectl scale deployment apigee-controller-manager -n APIGEE_NAMESPACE --replicas=0

kubectl delete mutatingwebhookconfiguration \
  apigee-mutating-webhook-configuration-APIGEE_NAMESPACE

kubectl delete validatingwebhookconfiguration \
  apigee-validating-webhook-configuration-APIGEE_NAMESPACE

すべてのチャートを apigee-virtualhost から apigee-datastore に戻します。次のコマンドは、以前のバージョン（v1.13.x）のチャートを使用していることを前提としています。

環境グループごとに次のコマンドを実行します。

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.13_OVERRIDES_FILE

環境ごとに次のコマンドを実行します。

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f 1.13_OVERRIDES_FILE

apigee-operator を除く残りのチャートを元に戻します。

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.13_OVERRIDES_FILE

apigee-system Namespace を作成します。
```
kubectl create namespace apigee-system
```

リソースアノテーションを apigee-system Namespace に適用します。

kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'

リリース名も変更した場合は、operator リリース名でアノテーションを更新します。
```
kubectl annotate --overwrite cluseterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

apigee-operator を apigee-system Namespace に再インストールします。

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.13_OVERRIDES_FILE

古い CRD を再インストールして CRD を元に戻します。

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

APIGEE_NAMESPACE Namespace から apigee-operator リリースをクリーンアップして、ロールバックプロセスを完了します。
```
helm uninstall operator -n APIGEE_NAMESPACE
```
clusterIssuer などのクラスタスコープのリソースは、operator がアンインストールされると削除されます。次のコマンドを使用して再インストールします。
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.13_OVERRIDES_FILE
```

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

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

前提条件

1.14.1 にアップグレードする前に - 制限事項と重要な注意事項

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

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

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

Linux

macOS

Windows

本番環境

非本番環境

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

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

コンポーネント

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

データ収集パイプラインを構成する

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

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

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

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

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