このガイドでは、Google Distributed Cloud（GDC）エアギャップ標準クラスタに高可用性 Oracle Data Guard 構成をデプロイする方法について説明します。この設定では、Oracle Database Enterprise Edition を使用し、ストレージとネットワーキングに GDC の既存の機能を活用します。
このデプロイでは、公式の Oracle Database Operator for Kubernetes を使用します。これにより、データベースのライフサイクル管理が自動化されます。
アーキテクチャ
このアーキテクチャでは、GDC 標準クラスタ内の Oracle Database Operator によって管理される高可用性 Oracle Database のデプロイについて説明します。高可用性デプロイは、レプリケーションとフェイルオーバー用に Data Guard で構成されたプライマリ データベースとスタンバイ データベースで構成されます。
主なコンポーネントは次のとおりです。
- GDC プロジェクト: リソースのプロジェクト コンテナ。
- 標準 Kubernetes クラスタ: コンピューティング リソースを提供する標準クラスタ。
- Oracle Database Operator: Oracle データベースのプロビジョニング、ライフサイクル管理、オブザーバビリティを自動化する Kubernetes オペレーター。パッチ適用、バックアップ、復元などの複雑なタスクが簡素化され、コンテナ化された環境でステートフルな Oracle ワークロードを簡単に実行できます。
- プライマリ データベース: アクティブな読み取り / 書き込みコンテナ化データベース インスタンス。
- スタンバイ データベース: レプリカの読み取り専用（またはフェイルオーバー中の読み取り / 書き込み）データベース インスタンス。
- Data Guard Broker: データベース間の構成とロールの移行（スイッチオーバー / フェイルオーバー）をオーケストレートします。
- Harbor: エアギャップ環境内でデータベース、オペレーター、クライアント イメージをホストするために使用される非公開 Container Registry。
- Cert-manager: Operator は、Webhook 証明書の管理を
cert-managerに依存しています。cert-managerは GDC 標準クラスタにプリインストールされています。
このガイドでは、オペレーターを独自の名前空間（oracle-database-operator-system）にデプロイし、データベース インスタンスを別の名前空間（oracle-dbs）にデプロイします。これらの名前空間は、アーキテクチャ図の点線のボックスで示されています。
この分離は、明確さと管理のしやすさの観点から推奨されます。ただし、データベースの編成方法はユーザーが決定できます。たとえば、ワークロードのニーズ、チームのオーナー権限、セキュリティ仕様に基づいてきめ細かいアクセス制御（RBAC）を管理するために、特定のデータベースを異なる Namespace にグループ化できます。
始める前に
デプロイを開始する前に、環境が次の要件を満たしていることを確認する必要があります。
- このガイド全体で生成されるすべてのリソースのホルダーとして機能するプロジェクトを作成します。
プロジェクトのクラスタ管理者ロールと標準クラスタ管理者ロールをユーザーに付与します。これにより、標準の 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 つのワーカーノード（それぞれ 16 GB 以上のメモリを搭載）を持つ標準の Kubernetes クラスタを作成します。次に例を示します。
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 Operator のマニフェストとコンテナ イメージをダウンロードできる踏み台ノードから実行されることを前提としています。インターネット アクセスがないマシンからこれを実行する場合は、これらのアセットを個別に取得し（たとえば、
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 Container Registry からイメージをダウンロードし、内部の Harbor プロジェクトに push します。テスト用に、オペレーター、エンタープライズ データベース、インスタント クライアントをミラーリングします。
Oracle データベース オペレーター イメージをミラーリングします。
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
クラスタ アクセスを構成する
リソースをデプロイする前に、Standard クラスタの認証情報を取得し、便利なエイリアスを作成します。
標準クラスタの 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 シークレットを作成します。
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 シークレットを作成します。
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${DB_NAMESPACE}データベースの管理パスワードのシークレットを作成します。
kk create secret generic ${ADMIN_PASSWORD_SECRET_NAME} \ --from-literal=password=${ADMIN_PASSWORD} \ -n ${DB_NAMESPACE}
Oracle Database Operator をインストールする
次に、3 つのマニフェストを適用して、Oracle Database Operator をクラスタにインストールします。
クラスタロール バインディング: オペレーターがクラスタ全体で機能するために必要な権限を設定します。
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.yamlOperator Deployment: Operator 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 Broker を構成する
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:MaxAvailabilityに設定すると、少なくとも 1 つのスタンバイが使用可能な 場合にデータ損失が発生しないようにします。少なくとも 1 つのスタンバイに到達可能な 場合は、非同期モードに移行します。falseに設定すると、自動フェイルオーバーが無効になります。fastStartFailover有効にすると、プライマリ データベースが使用できなくなった場合に、オブザーバー プロセスが自動的にフェイルオーバーをトリガーできます。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