このページでは、Apigee ハイブリッド組織を Kubernetes クラスタ間で移行する方法について説明します。以下のように、組織を別のクラスタに移行することが必要になる場合があります。
- 既存のクラスタをホストするデータセンターの容量が不足しているか、データセンターが廃止される。
- クラスタで古いインフラストラクチャまたは古いバージョンの Kubernetes が実行されているため、新しいインフラストラクチャを持つクラスタに移行する必要がある。
- 組織を複数の組織で構成されるクラスタから個別のクラスタに移行する必要がある。
組織を別のハイブリッド クラスタに移行する場合、リスクと制限事項があります。移行する前に、制限事項セクションの詳細をご確認ください。
制限事項
ハイブリッド組織を別の Kubernetes クラスタに移行する場合は、以下の制限事項が適用されます。
- 組織のデータを新しい Kubernetes クラスタに移動する場合は、データ損失のリスクがあります。組織を移行する前に、ハイブリッド バックアップ手順に沿って Kubernetes クラスタ内のすべての組織のデータをバックアップしてください。
- 組織の移行でサポートされる最大データサイズは、組織のすべてのキースペースで 5 GB です(キャッシュと割り当てを除く)。
- キャッシュ データは移行されません。ハイブリッドでは、キャッシュ データは再構築されます。
- 割り当てデータは移行されません。ハイブリッドでは、割り当てデータはリセットされます。
- 組織は、既存のハイブリッド デプロイを含まない Kubernetes クラスタにのみ移行できます。既存のハイブリッド デプロイによるクラスタへの移行はサポート対象外です。
- 移行対象の組織は、単一のリージョン デプロイで新しいクラスタにのみ移動できます。単一のリージョン デプロイが実行されたら、マルチリージョン デプロイで説明されているリージョン拡張プロセスに従って他のリージョンに拡張できます。
- Cassandra クラスタは、すべてのリージョンで正常に動作している必要があります。
組織の移行
以下の手順で、ハイブリッド組織を Kubernetes クラスタ間で移行します。
- 有効になっていない場合は、移行するハイブリッド組織を含む Kubernetes クラスタでバックアップを有効にします。ハイブリッド バックアップについては、Cassandra のバックアップの概要をご覧ください。
- 次のコマンドを使用して、ハイブリッド バックアップ ジョブを開始します。
kubectl create job -n apigee --from=cronjob/apigee-cassandra-backup <backup job name>
<backup job name>
は、任意の有効なコンテナの名前です。 - バックアップ ジョブが完了したら、バックアップのモニタリングの以下のセクションに示された手順に沿って、バックアップが正常に完了したことを確認します。
- 「バックアップ ジョブのステータスを確認する」
- 「バックアップ ログを確認する」
- バックアップが正常に完了したことを確認したら、バックアップ ログの末尾にある ID 番号をメモします。たとえば、正常なバックアップ ログには次のような行が表示されます。
行の末尾にある複数桁の番号をメモしておきます。この番号は後で必要になります。INFO: completed upload for 20230207004250
- Kubernetes コンテキストを移行先の Kubernetes クラスタに切り替えます。
kubectl config use-context <destination cluster name> # <destination cluster name>
ここで、
<destination cluster name>
は移行先の Kubernetes クラスタの名前です。 - 単一リージョンでの復元の手順に沿って、バックアップ データを移行先の Kubernetes クラスタに復元します。
- 移行する組織の overrides.yaml ファイルを移行先のハイブリッド デプロイに使用します。
restore:snapshotTimestamp
の値を、手順 4 でバックアップ ログに表示された複数桁の番号に設定します。単一リージョンでの復元をご覧ください。
- 復元が完了したら、移行する組織以外のデータを移行先の Kubernetes クラスタから削除します。ハイブリッド バックアップ ファイルには、移行する必要がない組織を含むすべての組織のデータが含まれています。移行先のハイブリッド デプロイが復元されたら、デプロイにコピーされた余分な組織のデータを次の手順に沿って削除する必要があります。
- 現在のコンテキストが、移行先の Kubernetes クラスタの正しいコンテキストであることを確認します。
kubectl config current-context
apigee-cassandra-default-0
Pod を実行します。kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- 次のコマンドを実行します。
find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2 -printf "%f\n"
<migrated org name>
を確認する手順については、移行した組織の名前を取得するをご覧ください。出力に表示されるすべての名前のリストをコピーします。このリストは手順 7 の f で必要になります。
apigee-cassandra-default-0
Pod を終了します。- デバッグ用のクライアント コンテナを作成する手順に沿って、Cassandra のデバッグ クライアント Pod を作成します。
cqlsh
プロンプトが表示されたら、次の手順に進みます。 cqlsh
プロンプトで次のコマンドを実行します。-
desc keyspaces;
このコマンドがエラーを返さないことを確認します。
- 手順 7 の c で作成したリストの名前ごとに、次のコマンドを実行します。
drop keyspace <name>
-
- Cassandra デバッグ クライアント Pod を終了します。
cqlsh
コマンドの実行後、移行先の Kubernetes クラスタ内のすべての Cassandra Pod で次のコマンドを実行します。kubectl exec -it -n apigee
-- /bin/bash find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*<migrated org name>*' -type d -maxdepth 2
<migrated org name>
を確認する手順については、移行した組織の名前を取得するをご覧ください。find /opt/apigee/data/apigee-cassandra/ -iname '*_hybrid' -not -iname '*
*' -type d -maxdepth 2 -exec rm -rf {} +
- Cassandra Pod を終了します。
- 現在のコンテキストが、移行先の Kubernetes クラスタの正しいコンテキストであることを確認します。
- Kubernetes コンテキストを移行元の Kubernetes クラスタに切り替えます。
kubectl config use-context <source cluster name>
ここで、
<source cluster name>
は移行元の Kubernetes クラスタの名前です。 - 移行した組織を移行元の Kubernetes クラスタから削除します。削除コマンドでは、必ず組織の
overrides.yaml
ファイルを使用してください。- 現在のコンテキストが移行元の Kubernetes クラスタの正しいコンテキストであることを確認します。
kubectl config current-context
必要に応じて、Kubernetes コンテキストをクラスタに設定し、組織を廃止する必要があります。
現在のコンテキストを一覧表示して、各クラスタのコンテキスト名を確認します。
kubectl config get-contexts
廃止するクラスタとリージョンにコンテキストを設定します。
kubectl config use-context CONTEXT_NAME
ここで、CONTEXT_NAME はクラスタとリージョンのコンテキスト名です。
次に例を示します。
kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE gke_example-org-1_us-central1_example-cluster-1 gke_example-org-1_us-central1_example-cluster-1 gke_example-org-1_us-central1_example-cluster-1 apigee * gke_example-org-1_us-central1_example-cluster-2 gke_example-org-1_us-central1_example-cluster-2 gke_example-org-1_us-central1_example-cluster-2 apigee gke_example-org-1_us-west1_example-cluster-2 gke_example-org-1_us-west1_example-cluster-2 gke_example-org-1_us-west1_example-cluster-2 apigeekubectl config use-context gke_example-org-1_us-west1_example-cluster-2
- 仮想ホストを削除します。
Helm
この手順を環境グループごとに繰り返します。
helm -n apigee delete ENV_GROUP_NAME
apigeectl
$APIGEECTL_HOME/apigeectl delete --settings virtualhost -f OVERRIDES_FILE.yaml
- 環境を削除します。
Helm
この手順を環境ごとに繰り返します。
helm -n apigee delete ENV_NAME
apigeectl
$APIGEECTL_HOME/apigeectl delete --all-envs -f OVERRIDES_FILE.yaml
- Apigee 組織を削除します。
Helm
helm -n apigee delete ORG_NAME
apigeectl
$APIGEECTL_HOME/apigeectl delete -f OVERRIDES_FILE.yaml --org
- apigee-cassandra-default-0 Pod に次のコマンドを実行します。
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- 次のコマンドを実行します。
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -printf "%f\n"
<migrated org name>
を確認する手順については、移行した組織の名前を取得するをご覧ください。出力に表示されるすべての名前のリストをコピーします。このリストは、手順 9 の j で必要になります。
apigee-cassandra-default-0
Pod を終了します。- デバッグ用のクライアント コンテナを作成する手順に沿って、Cassandra のデバッグ クライアント Pod を作成します。
cqlsh
プロンプトが表示されたら、次の手順に進みます。 cqlsh
プロンプトで次のコマンドを実行します。desc keyspaces;
このコマンドがエラーを返さないことを確認します。
- 手順 10 の f で作成したリストの名前ごとに、次のコマンドを実行します。
drop keyspace <name>;
- Cassandra デバッグ クライアント Pod を終了します。
-
kubectl exec -it -n apigee <cassandra pod name> -- /bin/bash
-
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2
<migrated org name>
を確認する手順については、移行した組織の名前を取得するをご覧ください。 -
find /opt/apigee/data/apigee-cassandra/ -iname '*<migrated org name>_hybrid' -type d -maxdepth 2 -exec rm -rf {} +
- Cassandra Pod を終了します。
cqlsh
コマンドの実行後、移行元の Kubernetes クラスタ内のすべての Cassandra Pod で次のコマンドを実行します。 - 現在のコンテキストが移行元の Kubernetes クラスタの正しいコンテキストであることを確認します。
移行した組織の名前を取得する
前のセクションで説明した手順の一部では、移行した組織の名前が必要です。移行した組織の名前を取得するには、次の操作を行います。
- 組織の overrides.yaml ファイルから組織名を取得します。移行する組織の overrides.yaml ファイルを必ず確認してください。
- 組織名にダッシュ「-」が含まれている場合は、すべてのダッシュ「-」をアンダースコア「_」に置き換えます。