このページでは、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 ファイルを必ず確認してください。
- 組織名にダッシュ「-」が含まれている場合は、すべてのダッシュ「-」をアンダースコア「_」に置き換えます。