このガイドでは、Google Distributed Cloud（GDC）エアギャップ スタンダード クラスタに高可用性マルチゾーン Oracle Data Guard 構成をデプロイする方法について説明します。 この設定では、Oracle Database Enterprise Edition を使用し、GDC の既存のストレージ機能とネットワーク機能を利用します。
このデプロイでは、データベースのライフサイクル管理を自動化する Oracle Database Operator for Kubernetes を使用します。
アーキテクチャ
このアーキテクチャは、GDC スタンダード クラスタ内の Oracle Database オペレーターによって管理される高可用性 Oracle Database デプロイについて説明しています。高可用性デプロイは、レプリケーションとフェイルオーバー用に Data Guard で構成されたプライマリ データベースとスタンバイ データベースで構成されます。
主なコンポーネントは次のとおりです。
- GDC プロジェクト: リソースの プロジェクト コンテナ。
- スタンダード Kubernetes クラスタ: コンピューティング リソースを提供するスタンダード クラスタ 。
- Oracle Database オペレーター: Oracle データベースの プロビジョニング、ライフサイクル管理、オブザーバビリティを自動化する Kubernetes オペレーター。 パッチ適用、バックアップ、復元などの複雑なタスクを簡素化し、コンテナ化された環境でステートフル Oracle ワークロードを簡単に実行できるようにします。
- プライマリ データベース: アクティブな読み取り / 書き込みコンテナ化データベース インスタンス。
- スタンバイ データベース: レプリカの読み取り専用（またはフェイルオーバー時の読み取り / 書き込み） データベース インスタンス。
- Data Guard ブローカー: データベース間の構成とロールの切り替え （スイッチオーバー/フェイルオーバー）を調整します。
- Harbor: エアギャップ環境内でデータベース、 オペレーター、クライアント イメージをホストするために使用されるプライベート コンテナ レジストリ。
- Cert-manager: オペレーターは、Webhook 証明書の管理に
cert-managerを使用します。cert-managerは、GDC スタンダード クラスタにプリインストールされています。
このガイドでは、オペレーターを独自の Namespace（oracle-database-operator-system）にデプロイし、データベース インスタンスを別の Namespace（oracle-dbs）にデプロイします。これらの Namespace は、アーキテクチャ図で破線のボックスで示されています。
明確さと管理しやすさのために、この分離をおすすめします。ただし、データベースの構成方法はユーザーが決定します。たとえば、ワークロードのニーズ、チームの所有権、セキュリティ仕様に基づいて、特定のデータベースを異なる Namespace にグループ化して、きめ細かいアクセス制御（RBAC）を管理できます。
始める前に
デプロイを開始する前に、環境が次の要件を満たしていることを確認する必要があります。
- このプロジェクト は、この ガイド全体で生成されるすべてのリソースのホルダーとして機能します。
プロジェクトのクラスタ管理者ロールとスタンダード クラスタ管理者ロールをユーザーに付与します。これにより、スタンダード Kubernetes クラスタを作成して、そのリソースを管理できます。
export PROJECT_ID=PROJECT_ID export USER_NAME=USER_NAME gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=cluster-admin gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=standard-cluster-adminこのガイドに必要なコンテナ イメージをホストする Harbor インスタンス と Harbor プロジェクト を作成します。
Harbor インスタンスにイメージをアップロードできるように、Harbor インスタンス管理者ロールをユーザーに付与します。
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=harbor-instance-adminHarbor プロジェクトに Harbor ロボット アカウント を作成します。このガイドの後半で、ロボット アカウントの認証情報が Kubernetes Secret に保存され、コンテナのインスタンス化時にクラスタが Harbor からイメージを pull できるようになります。
少なくとも 2 つのワーカーノードを持つスタンダード Kubernetes クラスタを作成します。各ワーカーノードには、16 GB 以上のメモリが必要です。次に例を示します。
kubectl --kubeconfig MGMT_API_KUBECONFIG create -f - <<EOF apiVersion: cluster.gdc.goog/v1 kind: Cluster metadata: name: ${CLUSTER_NAME} namespace: ${PROJECT_ID} spec: nodePools: - machineTypeName: n3-standard-8-gdc nodeCount: 2 name: ${CLUSTER_NAME}-node-pool EOF環境変数を設定します。これらは、ガイド全体でリソースの作成と参照に使用されます。
注:
- このガイドでは、2 つのデータベース インスタンスに
blueとgreenという名前を付けています。最初は、blueインスタンスがプライマリで、greenがスタンバイです。
# General info export PROJECT_ID="PROJECT_ID" export ZONE="ZONE" export ORG_NAME="ORG_NAME" export CLUSTER_NAME="CLUSTER_NAME" # Software versions export ORACLE_OPERATOR_VERSION="2.1.0" export ORACLE_DB_VERSION="21.3.0.0" # Namespaces export ORACLE_OPERATOR_NAMESPACE="ORACLE_OPERATOR_NAMESPACE" export DB_NAMESPACE="DATABASE_NAMESPACE" # Harbor config export HARBOR_INSTANCE_PROJECT_ID="HARBOR_PROJECT_ID" export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME" export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL" export HARBOR_PROJECT="HARBOR_PROJECT" export HARBOR_PULL_SECRET_NAME="HARBOR_PULL_SECRET_NAME" export HARBOR_ROBOT_ACCOUNT="robot\$HARBOR_PROJECT+ROBOT_NAME" export HARBOR_ROBOT_SECRET="HARBOR_ROBOT_SECRET" # Oracle database config export ADMIN_PASSWORD="ADMIN_PASSWORD" export ADMIN_PASSWORD_SECRET_NAME="ADMIN_PASSWORD_SECRET_NAME" # Database names export DB_NAME_BLUE="database-blue" export DB_NAME_GREEN="database-green"- このガイドでは、2 つのデータベース インスタンスに
ネットワークに関する注意: このガイドでは、GDC API にアクセスできると同時に、インターネットにアクセスして Oracle オペレーターのマニフェストとコンテナ イメージをダウンロードできる要塞ノードから実行することを前提としています。インターネットにアクセスできないマシンから実行する場合は、これらのアセットを個別に取得（たとえば、
docker saveを使用して接続されたマシンからイメージをエクスポートし、docker loadを使用してインポートする）し、続行する前に環境に安全にアップロードする必要があります。続行する前に、 container-registry.oracle.com でアカウントを作成して API トークンを取得し、 Oracle Database Enterprise Edition イメージと Oracle Instant Client イメージの両方の使用許諾契約に同意する必要があります。
Harbor にイメージを読み込む
Google Distributed Cloud エアギャップ内のクラスタは外部レジストリにアクセスできないため、必要なイメージをプライベート Harbor インスタンスにミラーリングする必要があります。
Oracle Container Registry にログインする
ベースイメージを pull するには、まず公式の Oracle レジストリで認証する必要があります。
docker --config=./docker-oracle login container-registry.oracle.com
ログインに成功すると、認証情報は ./docker-oracle/config.json に保存されます。
Harbor にログインする
プライベート Harbor インスタンスで認証します。
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
-u ${HARBOR_ROBOT_ACCOUNT} \
-p ${HARBOR_ROBOT_SECRET}
ログインに成功すると、ロボット アカウントの認証情報が ./docker-harbor/config.json に保存されます。
イメージを pull、タグ付け、push する
公式の Oracle コンテナ レジストリからイメージをダウンロードし、内部の Harbor プロジェクトに push します。テスト用に、オペレーター、エンタープライズ データベース、インスタント クライアントをミラーリングします。
Oracle Database オペレーター イメージをミラーリングします。
docker --config=./docker-oracle pull \ container-registry.oracle.com/database/operator:${ORACLE_OPERATOR_VERSION} \ --platform linux/amd64 docker tag container-registry.oracle.com/database/operator:${ORACLE_OPERATOR_VERSION} \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-operator:${ORACLE_OPERATOR_VERSION} docker --config=./docker-harbor push \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-operator:${ORACLE_OPERATOR_VERSION}Oracle Database Enterprise イメージをミラーリングします。
docker --config=./docker-oracle pull \ container-registry.oracle.com/database/enterprise:${ORACLE_DB_VERSION} \ --platform linux/amd64 docker tag container-registry.oracle.com/database/enterprise:${ORACLE_DB_VERSION} \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION} docker --config=./docker-harbor push \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION}Oracle Instant Client イメージをミラーリングします。
docker --config=./docker-oracle pull \ container-registry.oracle.com/database/instantclient:latest \ --platform linux/amd64 docker tag container-registry.oracle.com/database/instantclient:latest \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest docker --config=./docker-harbor push \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest
クラスタ アクセスを構成する
リソースをデプロイする前に、スタンダード クラスタの認証情報を取得して便利なエイリアスを作成します。
スタンダード クラスタの kubeconfig ファイルを取得します。
KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \ get-credentials ${CLUSTER_NAME} \ --standard \ --project ${PROJECT_ID} \ --zone ${ZONE}後続のコマンドを簡略化するために、
kkエイリアスを作成します。alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
Secret を作成する
ローカルの ./docker-harbor/config.json に保存されている認証情報を使用して、クラスタが Harbor からイメージを pull できるように、Kubernetes Secret を作成します。この Secret は、オペレーターの Namespace（オペレーター イメージを pull するため）とデータベースの Namespace（データベース イメージを pull するため）の両方に必要です。
オペレーターの Namespace を作成します。
kk create ns ${ORACLE_OPERATOR_NAMESPACE}オペレーターの pull Secret を作成します。
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${ORACLE_OPERATOR_NAMESPACE}データベースの Namespace を作成します。
kk create ns ${DB_NAMESPACE}データベース コンテナのイメージ pull Secret を作成します。
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${DB_NAMESPACE}データベースの管理パスワードの Secret を作成します。
kk create secret generic ${ADMIN_PASSWORD_SECRET_NAME} \ --from-literal=password=${ADMIN_PASSWORD} \ -n ${DB_NAMESPACE}
Oracle Database オペレーターをインストールする
次に、3 つのマニフェストを適用して、Oracle Database オペレーターをクラスタにインストールします。
クラスタロール バインディング: オペレーターがクラスタ全体で機能するために必要な権限を設定します。
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/cluster-role-binding.yamlノード RBAC: 正しい Pod スケジューリングに不可欠なノード トポロジを読み取る権限を付与します。
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/node-rbac.yamlオペレーターのデプロイ: オペレーター Pod とカスタム リソース定義をデプロイします。このコマンドは、公式マニフェストをダウンロードし、イメージパスを Harbor URL に置き換え、Kubernetes が Harbor で認証できるように
imagePullSecrets構成を挿入して、結果を適用します。curl -L https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/oracle-database-operator.yaml \ | sed "s|container-registry.oracle.com/database/operator:latest|${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-operator:${ORACLE_OPERATOR_VERSION}|g" \ | awk "/terminationGracePeriodSeconds: 10/{print; print \" imagePullSecrets:\n - name: ${HARBOR_PULL_SECRET_NAME}\"; next}1" \ | kk apply -f -オペレーター Pod が実行されるまで待ちます。
kk get pods -n ${ORACLE_OPERATOR_NAMESPACE} --watch出力は次のようになります。
NAME READY STATUS RESTARTS AGE oracle-database-operator-controller-manager-5f7b56874d-k9v4z 1/1 Running 0 45s oracle-database-operator-controller-manager-5f7b56874d-n2x8m 1/1 Running 0 45s oracle-database-operator-controller-manager-5f7b56874d-r6z7q 1/1 Running 0 45s
プライマリ データベースとスタンバイ データベースをデプロイする
同じ Namespace に 2 つのデータベース インスタンスを順番にデプロイします。
プライマリ インスタンスをデプロイする
次のコマンドを実行して、プライマリ データベース インスタンスを作成します。
apiVersion: database.oracle.com/v4 kind: SingleInstanceDatabase metadata: name: ${DB_NAME_BLUE} namespace: ${DB_NAMESPACE} spec: replicas: 1 edition: enterprise image: pullFrom: "${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION}" pullSecrets: ${HARBOR_PULL_SECRET_NAME} prebuiltDB: true sid: ORCLBLUE pdbName: ORCLPDB1 archiveLog: true flashBack: true forceLog: true adminPassword: secretName: "${ADMIN_PASSWORD_SECRET_NAME}" secretKey: "password" persistence: size: "50Gi" storageClass: "standard-rwo" accessMode: "ReadWriteOnce" resources: requests: memory: "4Gi"主な構成パラメータ:
sid/pdbName: システム ID（SID）とプラガブル データベース（PDB）名を定義します。edition: データベース エディション（この場合はenterprise）を指定します。image: プライベート Harbor レジストリ イメージを指します。persistence:standard-rwoStorageClass を使用して 50 Gi の永続ボリュームをリクエストします。これにより、GDC にゾーン永続ディスクが作成されます。replicas: インスタンスの Pod 数を 1 に設定します。archiveLog: Data Guard に必要なアーカイブ ログモードを有効にします。flashBack: フラッシュバック データベースを有効にして、データベースを以前の時点に戻せるようにします。forceLog: 強制ロギングを有効にして、通常はロギングをバイパスするオペレーションでもすべての変更がログに記録されるようにします。
カスタム初期化パラメータ やリソース上限など、構成オプションの完全なリストについては、公式 ドキュメントをご覧ください。
データベースの作成はリソースを大量に消費するため、10 ～ 20 分かかることがあります。
データベースの準備が完了するまで待ってから次に進みます。スタンバイ データベースでは、レプリケーションを確立するためにプライマリ データベースにアクセスできる必要があるため、これは重要です。
データベース Pod が
Runningになるまで待ちます。kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -w出力は次のようになります。
NAME READY STATUS RESTARTS AGE database-blue-i5xdj 0/1 Pending 0 0s database-blue-i5xdj 0/1 Pending 0 0s database-blue-i5xdj 0/1 Pending 0 1s database-blue-i5xdj 0/1 Init:0/1 0 1s database-blue-i5xdj 0/1 PodInitializing 0 98s database-blue-i5xdj 0/1 Running 0 99s database-blue-i5xdj 1/1 Running 0 99s次に、ログを監視して
DATABASE IS READY TO USE!メッセージが表示されるまで待ちます。kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -f出力には次のものが含まれます。
######################### DATABASE IS READY TO USE! #########################ステータスが
Healthyで、ロールがPRIMARYであることを確認します。kk get sidb -n ${DB_NAMESPACE} ${DB_NAME_BLUE}出力は次のようになります。
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY
スタンバイ インスタンスをデプロイする
プライマリが正常になったら、スタンバイ インスタンスをデプロイします。Data Guard パラメータ（archiveLog、flashBack、forceLog）はプライマリから継承され、スタンバイ マニフェストで指定してはならないことに注意してください。
スタンバイ インスタンスをデプロイします。
apiVersion: database.oracle.com/v4 kind: SingleInstanceDatabase metadata: name: ${DB_NAME_GREEN} namespace: ${DB_NAMESPACE} spec: replicas: 1 edition: enterprise image: pullFrom: "${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION}" pullSecrets: ${HARBOR_PULL_SECRET_NAME} prebuiltDB: true sid: ORCLGREEN pdbName: ORCLPDB1 adminPassword: secretName: "${ADMIN_PASSWORD_SECRET_NAME}" secretKey: "password" createAs: standby primaryDatabaseRef: ${DB_NAME_BLUE} persistence: size: "50Gi" storageClass: "standard-rwo" accessMode: "ReadWriteOnce" resources: requests: memory: "4Gi"データベース Pod が
Runningになるまで待ちます。kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -w出力は次のようになります。
NAME READY STATUS RESTARTS AGE database-green-q1gur 0/1 Pending 0 0s database-green-q1gur 0/1 Pending 0 0s database-green-q1gur 0/1 Pending 0 1s database-green-q1gur 0/1 Init:0/1 0 1s database-green-q1gur 0/1 PodInitializing 0 98s database-green-q1gur 0/1 Running 0 99s database-green-q1gur 1/1 Running 0 99s次に、ログを監視して
DATABASE IS READY TO USE!メッセージが表示されるまで待ちます。kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -f出力には次のものが含まれます。
######################### DATABASE IS READY TO USE! #########################ステータスが
Healthyで、ロールがPHYSICAL_STANDBYであることを確認します。kk get sidb -n ${DB_NAMESPACE}出力は次のようになります。
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY database-green Healthy PHYSICAL_STANDBY
Data Guard ブローカーを構成する
DataguardBrokerをデプロイして、Data Guard 構成を管理します。apiVersion: database.oracle.com/v4 kind: DataguardBroker metadata: name: broker-blue-green namespace: ${DB_NAMESPACE} spec: primaryDatabaseRef: ${DB_NAME_BLUE} standbyDatabaseRefs: - ${DB_NAME_GREEN} protectionMode: MaxAvailability fastStartFailover: false loadBalancer: true主な構成パラメータ:
protectionMode: 少なくとも 1 つのスタンバイが使用可能な場合はデータ損失が発生しないようにMaxAvailabilityに設定し、少なくとも 1 つのスタンバイに到達可能な場合は非同期モードに移行します。fastStartFailover:falseに設定して自動フェイルオーバーを無効にします。 有効にすると、プライマリ データベースが使用不能になった場合に、オブザーバー プロセスが自動的にフェイルオーバーをトリガーできます。loadBalancer:trueに設定して、ブローカー用の KubernetesLoadBalancerサービスを作成します。これにより、常に現在のプライマリ データベースにルーティングされる安定した外部 IP アドレスが提供されます。
ブローカーのステータスが
Healthyになるまでモニタリングします。kk get dataguardbroker -n ${DB_NAMESPACE} -w出力は次のようになります。
NAME PRIMARY STANDBYS PROTECTION MODE CONNECT STR STATUS FSFO broker-blue-green MaxAvailability Creating broker-blue-green MaxAvailability Creating broker-blue-green ORCLBLUE ORCLGREEN MaxAvailability 10.0.0.25:32345/DATAGUARD Creating false broker-blue-green ORCLBLUE ORCLGREEN MaxAvailability 10.0.0.25:32345/DATAGUARD Healthy falseDataguardBrokerは、トラフィックを現在のプライマリ データベースに自動的にルーティングする Kubernetes Service（broker-blue-green）を作成します。これにより、アプリケーションの安定した接続ポイントが提供されます。このサービスを取得します。kk get svc -n ${DB_NAMESPACE} broker-blue-green出力は次のようになります。クラスタ内クライアント用の
CLUSTER-IPと、ロードバランサを使用する外部クライアント用のEXTERNAL-IPの両方がプロビジョニングされていることに注意してください。NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE broker-blue-green LoadBalancer 10.0.19.198 100.66.38.138 1521:31116/TCP,5500:31842/TCP 8mブローカー サービスのエンドポイントを確認します。最初は、青色の Pod の IP アドレスを指している必要があります。
kk get endpoints -n ${DB_NAMESPACE} broker-blue-green出力は次のようになります。
BLUE_POD_IPの代わりに青色の Pod の IP が表示されます。NAME ENDPOINTS broker-blue-green [BLUE_POD_IP]:5500,[BLUE_POD_IP]:1521データベース Pod を確認して IP を関連付けます。
kk get pod -n ${DB_NAMESPACE} -o wide
データ同期とロールをテストする
クラスタ内クライアント Pod を使用して、プライマリにデータを書き込み、スタンバイから読み取ることで、レプリケーションを検証します。
ブローカー サービスを使用してプライマリ データベースに書き込む
一時的な Pod をデプロイして、安定したブローカー サービスを使用してプライマリ データベースに接続します。
kk run sqlplus -n ${DB_NAMESPACE} --rm -it --restart=Never \ --image=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest \ --image-pull-policy=Always \ --overrides='{"spec": {"imagePullSecrets": [{"name": "'${HARBOR_PULL_SECRET_NAME}'"}]}}' \ -- sqlplus sys/${ADMIN_PASSWORD}@broker-blue-green:1521/ORCLPDB1 as sysdbaテストテーブルを作成します。
CREATE TABLE employees (id NUMBER, name VARCHAR2(50)); INSERT INTO employees VALUES (1, 'John Doe'); COMMIT; SELECT * FROM employees; exit;出力は次のようになります。
ID NAME ---------- -------------------------------------------------- 1 John Doe
スタンバイから読み取る（直接アクセス）
一時的な Pod をデプロイして、スタンバイ サービスに直接接続します。
kk run sqlplus -n ${DB_NAMESPACE} --rm -it --restart=Never \ --image=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest \ --image-pull-policy=Always \ --overrides='{"spec": {"imagePullSecrets": [{"name": "'${HARBOR_PULL_SECRET_NAME}'"}]}}' \ -- sqlplus sys/${ADMIN_PASSWORD}@${DB_NAME_GREEN}:1521/ORCLPDB1 as sysdbaデータ レプリケーションを確認します。
SELECT * FROM employees; exit;出力は次のようになります。
ID NAME ---------- -------------------------------------------------- 1 John Doe
手動スイッチオーバーを実行する
手動スイッチオーバーをトリガーしてロールを反転させ、緑色のデータベースを新しいプライマリにします。オペレーターには、スイッチオーバー ターゲットの SID（ORCLGREEN など）が必要です。
次のコマンドを実行します。
kk patch dataguardbroker broker-blue-green -n ${DB_NAMESPACE} --type='merge' \ -p "{\"spec\":{\"setAsPrimaryDatabase\":\"ORCLGREEN\"}}"スイッチオーバーの進行状況をモニタリングします。
kk get sidb -n ${DB_NAMESPACE} -wスイッチオーバーが完了すると、出力は次のようになります。
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PHYSICAL_STANDBY database-green Healthy PRIMARYデータベース インスタンスのロールが切り替わり、緑色のデータベースがプライマリになっていることを確認します。
kk get dataguardbroker -n ${DB_NAMESPACE}出力は次のようになります。
NAME PRIMARY STANDBYS PROTECTION MODE broker-blue-green ORCLGREEN ORCLBLUE MaxAvailabilitybroker-blue-greenサービス エンドポイントが更新され、緑色の Pod の IP を指していることを確認します。kk get endpoints -n ${DB_NAMESPACE} broker-blue-green出力は次のようになります。
GREEN_POD_IPの代わりに緑色の Pod の IP が表示されます。NAME ENDPOINTS broker-blue-green [GREEN_POD_IP]:5500,[GREEN_POD_IP]:1521