このドキュメントでは、Google Distributed Cloud（GDC）のエアギャップで高可用性（HA）仮想マシン（VM）アプリケーションをデプロイする方法について説明します。復元力を確保するには、アプリケーションを複数のゾーンにデプロイし、非同期ストレージ レプリケーションを構成して、予期しないダウンタイムやローカル災害が発生した場合にアプリケーションとそのデータを復元できるようにする必要があります。
このドキュメントは、復元力のある VM ワークロードの作成を担当するアプリケーション デベロッパーを対象としています。
詳細については、GDC エアギャップの対象ユーザーに関するドキュメントをご覧ください。
目標
- GDC ユニバース内の 2 つ以上のゾーンにブートディスクがアタッチされた VM インスタンスを作成します。
- グローバル ロード バランシングを構成します。
- ブロック ストレージまたはオブジェクト ストレージを使用して、非同期ストレージ レプリケーションを構成します。
始める前に
このドキュメントのタスクを準備するには、必要な権限を取得して環境を確認する必要があります。
IAM のロールと権限をリクエストする
組織の IAM 管理者に連絡して、次のロールをリクエストします。
- プロジェクトの VirtualMachine 管理者（
project-vm-admin）: プロジェクト Namespace で VM を作成して編集します。 - グローバル PNP 管理者（
global-project-networkpolicy-admin）: ゾーン間でプロジェクト ネットワーク ポリシーを作成および編集します。 - グローバル ロードバランサ管理者（
global-load-balancer-admin）: グローバル ロードバランサを作成して編集します。 - バケット プロジェクト管理者（
global-project-bucket-admin）: デュアルゾーン ストレージ バケットを作成して編集します。
詳細については、ロールの説明をご覧ください。
環境を準備する
エアギャップ環境に次のツールと構成が存在することを確認します。
gdcloud CLI をインストールして構成し、ゾーン コンテキストとグローバル コンテキストを設定します。詳細については、ゾーン間のリソースを管理するをご覧ください。
kubectl CLI をインストールし、グローバル API サーバーと Management API サーバーに適切な kubeconfig ファイルを設定します。詳細については、kubeconfig ファイルを手動で生成するをご覧ください。
GDC ユニバースで複数のゾーンが使用可能であることを確認します。詳細については、ユニバース内のゾーンを一覧表示するをご覧ください。
複数のゾーンに VM インスタンスを作成する
高可用性 VM アプリケーションを作成するには、GDC ユニバースの各ゾーンに個別の VM インスタンスを作成する必要があります。
次の手順では、GDC 提供の OS イメージを使用して、ブートディスクを VM にアタッチします。VM インスタンスの作成とカスタム イメージの使用の詳細については、VM を作成して起動するをご覧ください。
デフォルトでは、すべての GDC プロジェクトで GDC 提供の OS イメージから VM を作成できます。
コンソール
- ナビゲーション メニューで、[Virtual Machines] > [インスタンス] を選択します。
- [インスタンスを作成] をクリックします。
- [名前] フィールドに、VM の名前を指定します。
- VM を作成するゾーンを選択します。
- [ラベルを追加] をクリックして、VM にラベルを割り当て、VM インスタンスを整理します。
- VM に使用するマシン構成を選択します。要件に応じて、マシンタイプがワークロードと一致していることを確認します。
- [次へ] をクリックします。
- VM インスタンスの外部アクセスを有効にします。
- [次へ] をクリックします。
- [新しいディスクを追加] を選択します。
- VM ディスクに名前を割り当てます。
- ディスクサイズとアタッチメントの設定を構成します。
- [保存] をクリックします。
- [作成] をクリックして VM インスタンスを作成します。
- GDC ユニバース内の各ゾーンに対して、上記の手順を繰り返します。HA 戦略で必要なすべてのゾーンに VM インスタンスが存在することを確認します。
gdcloud
VM インスタンスをホストするゾーンにログインします。
gdcloud config set core/zone ZONEGDC 提供のイメージを使用して、ゾーンに VM インスタンスを作成します。
gdcloud compute instances create VM_NAME \ --machine-type=MACHINE_TYPE \ --image=BOOT_DISK_IMAGE_NAME --image-project=vm-system \ --boot-disk-size=BOOT_DISK_SIZE \ --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE次のように置き換えます。
VM_NAME: 新しい VM の名前。名前には英数字とダッシュのみを使用でき、53 文字以下にする必要があります。MACHINE_TYPE: 新しい VM の事前定義されたマシンタイプ。使用可能なマシンタイプを選択するには、gdcloud compute machine-types listを実行します。BOOT_DISK_IMAGE_NAME: 新しい VM ブートディスクに使用するイメージの名前。BOOT_DISK_SIZE: ブートディスクのサイズ（20GBなど）。この値は常に、ブートディスク イメージのminimumDiskSize以上である必要があります。NO_BOOT_DISK_AUTO_DELETE: VM インスタンスが削除されたときにブートディスクが自動的に削除されるかどうか。
GDC ユニバース内の各ゾーンに対して、上記の手順を繰り返します。HA 戦略で必要なすべてのゾーンに VM インスタンスが存在することを確認します。
API
GDC 提供のイメージを使用して、ゾーンに VM インスタンスを作成します。
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: virtualmachine.gdc.goog/v1 kind: VirtualMachineDisk metadata: name: VM_BOOT_DISK_NAME namespace: PROJECT spec: source: image: name: BOOT_DISK_IMAGE_NAME namespace: vm-system size: BOOT_DISK_SIZE --- apiVersion: virtualmachine.gdc.goog/v1 kind: VirtualMachine metadata: name: VM_NAME namespace: PROJECT spec: compute: virtualMachineType: MACHINE_TYPE disks: - virtualMachineDiskRef: name: VM_BOOT_DISK_NAME boot: true autoDelete: BOOT_DISK_AUTO_DELETE --- apiVersion: virtualmachine.gdc.goog/v1 kind: VirtualMachineExternalAccess metadata: name: VM_NAME namespace: PROJECT spec: enabled: true ports: - name: port-80 port: 80 protocol: TCP EOF次のように置き換えます。
MANAGEMENT_API_SERVER: VM インスタンスを作成するゾーンの Management API サーバーの kubeconfig ファイル。Management API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。VM_BOOT_DISK_NAME: 新しい VM ブートディスクの名前。PROJECT: VM を作成する GDC プロジェクト。BOOT_DISK_IMAGE_NAME: 新しい VM ブートディスクに使用するイメージの名前。BOOT_DISK_SIZE: ブートディスクのサイズ（20Giなど）。この値は常に、ブートディスク イメージのminimumDiskSize以上である必要があります。VM_NAME: 新しい VM の名前。名前には英数字とダッシュのみを使用でき、53 文字以下にする必要があります。MACHINE_TYPE: 新しい VM の事前定義されたマシンタイプ。使用可能なマシンタイプを選択するには、gdcloud compute machine-types listを実行します。BOOT_DISK_AUTO_DELETE: VM インスタンスが削除されたときにブートディスクが自動的に削除されるかどうか。
VM が使用可能であることを確認し、VM が
Running状態になるまで待ちます。Running状態は、OS の準備が完全に整い、アクセス可能であることを示すものではありません。kubectl --kubeconfig MANAGEMENT_API_SERVER \ get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECTVM_NAMEとPROJECTは、VM の名前とプロジェクトに置き換えます。GDC ユニバース内の各ゾーンに対して、上記の手順を繰り返します。HA 戦略で必要なすべてのゾーンに VM インスタンスが存在することを確認します。
ロードバランサを構成する
異なるゾーンの VM 間でトラフィックを分散するには、ロードバランサを作成します。内部ロードバランサと外部ロードバランサの両方をグローバルに構成して、クライアント リクエストが正常なゾーンに転送されるようにすることができます。
グローバル内部ロードバランサを作成する
内部ロードバランサ（ILB）は、組織に割り当てられた内部 IP アドレス プールから組織内のサービスを公開します。ILB サービスには、組織外のエンドポイントからアクセスできません。
次の手順に沿って、VM ワークロードのグローバル ILB を作成します。
gdcloud
gdcloud CLI を使用して、VM ワークロードをターゲットとする ILB を作成します。
この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。Backend カスタム リソースは、ゾーンにスコープ設定する必要があります。
gcloud CLI を使用して ILB を作成するには、次の操作を行います。
VM が実行されている各ゾーンにゾーン
Backendリソースを作成して、ILB のエンドポイントを定義します。gdcloud compute backends create BACKEND_NAME \ --labels=LABELS \ --project=PROJECT \ --zone=ZONE次のように置き換えます。
BACKEND_NAME: バックエンド リソースに選択した名前（my-backendなど）。LABELS: このバックエンド リソースに使用する VM 間のエンドポイントを定義するセレクタ（app=webなど）。PROJECT: プロジェクトの名前。ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドに対してゾーンフラグをプリセットするには、gdcloud config set core/zone ZONEを実行します。ゾーンフラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。
この手順を GDC ユニバースの各ゾーンで繰り返します。
ILB のグローバル ヘルスチェックを定義します。
gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \ --check-interval=CHECK_INTERVAL \ --healthy-threshold=HEALTHY_THRESHOLD \ --timeout=TIMEOUT \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ --port=PORT \ --global次のように置き換えます。
HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-checkなど）。CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は5です。このフィールドは省略可能です。HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。デフォルト値は5です。このフィールドは省略可能です。TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。デフォルト値は5です。このフィールドは省略可能です。UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は2です。このフィールドは省略可能です。PORT: ヘルスチェックが実行されるポート。デフォルト値は80です。このフィールドは省略可能です。
グローバル
BackendServiceリソースを作成します。gdcloud compute backend-services create BACKEND_SERVICE_NAME \ --project=PROJECT \ --target-ports=TARGET_PORTS \ --health-check=HEALTH_CHECK_NAME \ --global次のように置き換えます。
BACKEND_SERVICE_NAME: バックエンド サービスの名前。PROJECT: プロジェクトの名前。TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りのリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドはprotocol:port:targetportの形式にする必要があります（例:TCP:80:8080）。このフィールドは省略可能です。HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。
各ゾーンで、前に作成した
BackendリソースにBackendServiceリソースを追加します。gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --backend-zone=ZONE \ --backend=BACKEND_NAME \ --project=PROJECT \ --global次のように置き換えます。
BACKEND_SERVICE_NAME: グローバル バックエンド サービスの名前。ZONE: バックエンドのゾーン。BACKEND_NAME: ゾーン バックエンドの名前。PROJECT: プロジェクトの名前。
前に作成したゾーン バックエンドごとに、この手順を完了します。
サービスが利用可能な仮想 IP アドレス（VIP）を定義する内部
ForwardingRuleリソースを作成します。gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \ --backend-service=BACKEND_SERVICE_NAME \ --cidr=CIDR \ --ip-protocol-port=PROTOCOL_PORT \ --load-balancing-scheme=INTERNAL \ --project=PROJECT \ --global次のように置き換えます。
FORWARDING_RULE_INTERNAL_NAME: 転送ルールの名前。CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace にあるSubnetリソースの名前を指定します。Subnetリソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnetリソースの詳細については、サブネットを管理するをご覧ください。PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドはip-protocol=TCP:80の形式にする必要があります。公開ポートは、実際のアプリケーションが VM 内で公開しているポートと同じである必要があります。
構成された ILB を検証するには、作成された各オブジェクトの
Ready条件を確認します。VIP へのcurlリクエストでトラフィックを確認します。割り当てられた VIP を取得するには、転送ルールを説明します。
gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global転送ルールのフィールドで指定されたポートの VIP に
curlリクエストを送信して、トラフィックを確認します。curl http://FORWARDING_RULE_VIP:PORT
次のように置き換えます。
FORWARDING_RULE_VIP: 転送ルールの VIP。PORT: 転送ルールのポート番号。
API
KRM API を使用して、VM ワークロードをターゲットとする ILB を作成します。この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してグローバル ILB を作成する手順は次のとおりです。
Backendリソースを作成して、ILB のエンドポイントを定義します。VM ワークロードが配置されているゾーンごとにBackendリソースを作成します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: networking.gdc.goog/v1 kind: Backend metadata: namespace: PROJECT name: BACKEND_NAME spec: endpointsLabels: matchLabels: app: APP_NAME EOF次のように置き換えます。
MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。詳細については、ゾーン コンテキストに切り替えるをご覧ください。PROJECT: プロジェクトの名前。BACKEND_NAME:Backendリソースの名前。APP_NAME: VM アプリケーションの名前。
各ゾーンに同じ
Backendリソースを使用することも、各ゾーンに異なるラベルセットを持つBackendリソースを作成することもできます。ILB のグローバル ヘルスチェックを定義します。
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: HealthCheck metadata: namespace: PROJECT name: HEALTH_CHECK_NAME spec: tcpHealthCheck: port: PORT timeoutSec: TIMEOUT checkIntervalSec: CHECK_INTERVAL healthyThreshold: HEALTHY_THRESHOLD unhealthyThreshold: UNHEALTHY_THRESHOLD EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル コンテキストに切り替えるをご覧ください。PROJECT: プロジェクトの名前。HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-checkなど）。PORT: ヘルスチェックを実行するポート。デフォルト値は80です。TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。デフォルト値は5です。CHECK_INTERVAL: 1 回のプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は5です。HEALTHY_THRESHOLD: エンドポイントが正常と見なされるために合格する必要があるプローブの連続回数。デフォルト値は2です。UNHEALTHY_THRESHOLD: エンドポイントが異常と見なされるために連続して失敗しなければならないプローブの数。デフォルト値は2です。
前に作成した
Backendリソースを使用してBackendServiceオブジェクトを作成します。HealthCheckリソースを含めてください。kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: BackendService metadata: namespace: PROJECT name: BACKEND_SERVICE_NAME spec: backendRefs: - name: BACKEND_NAME zone: ZONE healthCheckName: HEALTH_CHECK_NAME targetPorts: - port: PORT protocol: PROTOCOL targetPort: TARGET_PORT EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。PROJECT: プロジェクトの名前。BACKEND_SERVICE_NAME:BackendServiceリソースに選択した名前。HEALTH_CHECK_NAME: 以前に作成したHealthCheckリソースの名前。BACKEND_NAME: ゾーンBackendリソースの名前。ZONE:Backendリソースが存在するゾーン。backendRefsフィールドで複数のバックエンドを指定できます。次に例を示します。- name: my-backend-1 zone: us-east1-a - name: my-backend-2 zone: us-east1-btargetPortsフィールドは省略可能です。このリソースは、このBackendServiceリソースが変換するポートを一覧表示します。このオブジェクトを使用する場合は、次の値を指定します。PORT: サービスによって公開されるポート。PROTOCOL: トラフィックが一致する必要があるレイヤ 4 プロトコル。TCP と UDP のみがサポートされます。TARGET_PORT: 値の変換先となるポート（8080など）。値は、特定のオブジェクト内で繰り返すことはできません。targetPortsの例を次に示します。targetPorts: - port: 80 protocol: TCP targetPort: 8080
サービスが利用可能な仮想 IP アドレス（VIP）を定義する内部
ForwardingRuleリソースを作成します。kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: ForwardingRuleInternal metadata: namespace: PROJECT name: FORWARDING_RULE_INTERNAL_NAME spec: cidrRef: name: CIDR_NAME ports: - port: PORT protocol: PROTOCOL backendServiceRef: name: BACKEND_SERVICE_NAME EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。PROJECT: プロジェクトの名前。FORWARDING_RULE_INTERNAL_NAME:ForwardingRuleInternalリソースに選択した名前。CIDR_NAME: 転送ルールで使用する CIDR の名前。このフィールドは省略可能です。指定しない場合、IPv4/32CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace にあるSubnetリソースの名前を指定します。Subnetリソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnetリソースの詳細については、サブネットを管理するをご覧ください。PORT: 転送ルールで公開するポート。portsフィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。portフィールドを使用して、ポート番号を指定します。公開ポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。PROTOCOL: 転送ルールに使用するプロトコル（TCPなど）。ports配列のエントリは次のようになります。ports: - port: 80 protocol: TCP
構成された ILB を検証するには、作成された各オブジェクトの
Ready条件を確認します。VIP へのcurlリクエストでトラフィックを確認します。VIP を取得します。
kubectl get forwardingruleinternal -n PROJECT出力は次のようになります。
NAME BACKENDSERVICE CIDR READY ilb-name BACKEND_SERVICE_NAME 192.0.2.0/32 True転送ルールのフィールドで指定されたポートの VIP に
curlリクエストを送信して、トラフィックをテストします。curl http://FORWARDING_RULE_VIP:PORT次のように置き換えます。
FORWARDING_RULE_VIP: 転送ルールの VIP。PORT: 転送ルールのフィールドのポート番号。
グローバル外部ロードバランサを作成する
外部ロードバランサ（ELB）は、組織に割り当てられたより大きなインスタンス外部 IP アドレス プールから組織に割り当てられたプールの IP アドレスから、組織外からのアクセスに対してサービスを公開します。
VM ワークロードのグローバル ELB を作成する手順は次のとおりです。
gdcloud
gdcloud CLI を使用して、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットとするグローバル ELB を作成します。Backend カスタム リソースはゾーンにスコープ設定する必要があります。
ELB サービスが機能するには、この ELB サービスのワークロードへのトラフィックを許可するように、独自のカスタマイズされた
ProjectNetworkPolicyデータ移転ポリシーを構成して適用する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開します。外部トラフィックをワークロード ポート（8080など）に許可するには、明示的なネットワーク ポリシーが必要です。この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: ProjectNetworkPolicy metadata: namespace: PROJECT name: allow-inbound-traffic-from-external spec: policyType: Ingress subject: subjectType: UserWorkload ingress: - from: - ipBlock: cidr: CIDR ports: - protocol: TCP port: PORT EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。グローバル API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。PROJECT: プロジェクトの名前。CIDR: ELB にアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織外のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。PORT: ロードバランサの背後にある VM のバックエンド ポート。この値は、Serviceリソースのマニフェストの.spec.ports[].targetPortfieldフィールドにあります。このフィールドは省略可能です。
この構成により、プロジェクト内のすべてのリソースが指定された CIDR の範囲にアクセスできるようになります。
各ゾーンに
Backendリソースを作成して、ELB のエンドポイントを定義します。gdcloud compute backends create BACKEND_NAME \ --labels=LABELS \ --project=PROJECT次のように置き換えます。
BACKEND_NAME: バックエンド リソースの名前（my-backendなど）。LABELS: このバックエンド リソースに使用する VM 間のエンドポイントを定義するセレクタ（app=webなど）。PROJECT: プロジェクトの名前。
各ゾーンに同じ
Backendリソースを使用することも、各ゾーンに異なるラベルセットを持つBackendリソースを作成することもできます。ELB のグローバル ヘルスチェックを定義します。
gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \ --check-interval=CHECK_INTERVAL \ --healthy-threshold=HEALTHY_THRESHOLD \ --timeout=TIMEOUT \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ --port=PORT \ --global次のように置き換えます。
HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-checkなど）。CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は5です。このフィールドは省略可能です。HEALTHY_THRESHOLD: 障害を宣言するまでの待機時間。デフォルト値は5です。このフィールドは省略可能です。TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。デフォルト値は5です。このフィールドは省略可能です。UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は2です。このフィールドは省略可能です。PORT: ヘルスチェックを実行するポート。デフォルト値は80です。このフィールドは省略可能です。
グローバル
BackendServiceリソースを作成します。gdcloud compute backend-services create BACKEND_SERVICE_NAME \ --project=PROJECT \ --target-ports=TARGET_PORTS \ --health-check=HEALTH_CHECK_NAME \ --global次のように置き換えます。
BACKEND_SERVICE_NAME: このバックエンド サービスに選択した名前。PROJECT: プロジェクトの名前。TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りのリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは、TCP:80:8080などのprotocol:port:targetport形式にする必要があります。このフィールドは省略可能です。HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。
グローバル
BackendServiceリソースを、前に作成したゾーンBackendリソースに追加します。gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --backend=BACKEND_NAME \ --backend-zone BACKEND_ZONE \ --project=PROJECT \ --global前に作成したゾーン バックエンドごとに、この手順を完了します。
サービスが利用可能な VIP を定義する外部
ForwardingRuleリソースを作成します。gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \ --backend-service=BACKEND_SERVICE_NAME \ --cidr=CIDR \ --ip-protocol-port=PROTOCOL_PORT \ --load-balancing-scheme=EXTERNAL \ --project=PROJECT \ --global次のように置き換えます。
FORWARDING_RULE_EXTERNAL_NAME: 転送ルールの名前。CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace にあるSubnetリソースの名前を指定します。Subnetリソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnetリソースの詳細については、サブネットを管理するをご覧ください。PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドはip-protocol=TCP:80の形式にする必要があります。公開されるポートは、実際のアプリケーションが VM 内で公開しているポートと同じである必要があります。PROJECT: プロジェクトの名前。
構成された ELB を検証するには、作成された各オブジェクトの
Ready条件を確認します。VIP へのcurlリクエストでトラフィックを確認します。割り当てられた VIP を取得するには、転送ルールを説明します。
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME転送ルールの
PROTOCOL_PORTフィールドで指定されたポートの VIP へのcurlリクエストでトラフィックを確認します。curl http://FORWARDING_RULE_VIP:PORT次のように置き換えます。
FORWARDING_RULE_VIP: 転送ルールの VIP。PORT: 転送ルールのPROTOCOL_PORTフィールドのポート番号。
API
KRM API を使用して、VM ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してゾーン ELB を作成する手順は次のとおりです。
ELB サービスが機能するには、この ELB サービスのワークロードへのトラフィックを許可するように、独自のカスタマイズされた
ProjectNetworkPolicyデータ移転ポリシーを構成して適用する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開します。外部トラフィックをワークロード ポート（8080など）に許可するには、明示的なネットワーク ポリシーが必要です。この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: ProjectNetworkPolicy metadata: namespace: PROJECT name: allow-inbound-traffic-from-external spec: policyType: Ingress subject: subjectType: UserWorkload ingress: - from: - ipBlock: cidr: CIDR ports: - protocol: TCP port: PORT EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。グローバル API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。PROJECT: プロジェクトの名前。CIDR: ELB にアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織外のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。PORT: ロードバランサの背後にある VM のバックエンド ポート。この値は、Serviceリソースのマニフェストの.spec.ports[].targetPortfieldフィールドにあります。このフィールドは省略可能です。
Backendリソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとにBackendリソースを作成します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: networking.gdc.goog/v1 kind: Backend metadata: namespace: PROJECT name: BACKEND_NAME spec: endpointsLabels: matchLabels: app: server EOF次のように置き換えます。
MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。ターゲット ゾーンの API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。PROJECT: プロジェクトの名前。BACKEND_NAME:Backendリソースの名前。
各ゾーンに同じ
Backendリソースを使用することも、各ゾーンに異なるラベルセットを持つBackendリソースを作成することもできます。ELB のグローバル ヘルスチェックを定義します。
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: HealthCheck metadata: namespace: PROJECT name: HEALTH_CHECK_NAME spec: tcpHealthCheck: port: PORT timeoutSec: TIMEOUT checkIntervalSec: CHECK_INTERVAL healthyThreshold: HEALTHY_THRESHOLD unhealthyThreshold: UNHEALTHY_THRESHOLD EOF次のように置き換えます。
HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-checkなど）。PORT: ヘルスチェックを実行するポート。デフォルト値は80です。TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。デフォルト値は5です。CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は5です。HEALTHY_THRESHOLD: エンドポイントが正常と見なされるために合格する必要がある連続プローブの数。デフォルト値は2です。UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は2です。
これはグローバル ELB であるため、グローバル API でヘルスチェックを作成します。
前に作成した
Backendリソースを使用してBackendServiceオブジェクトを作成します。kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: BackendService metadata: namespace: PROJECT name: BACKEND_SERVICE_NAME spec: backendRefs: - name: BACKEND_NAME zone: ZONE healthCheckName: HEALTH_CHECK_NAME EOF次のように置き換えます。
BACKEND_SERVICE_NAME:BackendServiceリソースに選択した名前。HEALTH_CHECK_NAME: 以前に作成したHealthCheckリソースの名前。Pod ワークロードの ELB を構成する場合は、このフィールドを含めないでください。ZONE:Backendリソースが存在するゾーン。backendRefsフィールドで複数のバックエンドを指定できます。次に例を示します。
- name: my-backend-1 zone: us-east1-a - name: my-backend-2 zone: us-east1-bサービスが利用可能な VIP を定義する外部
ForwardingRuleリソースを作成します。kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: networking.global.gdc.goog/v1 kind: ForwardingRuleExternal metadata: namespace: PROJECT name: FORWARDING_RULE_EXTERNAL_NAME spec: cidrRef: name: CIDR_NAME ports: - port: PORT protocol: PROTOCOL backendServiceRef: name: BACKEND_SERVICE_NAME EOF次のように置き換えます。
FORWARDING_RULE_EXTERNAL_NAME:ForwardingRuleExternalリソースに選択した名前。CIDR_NAME: 転送ルールで使用する CIDR の名前。このフィールドは省略可能です。指定しない場合、IPv4/32CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace にあるSubnetリソースの名前を指定します。Subnetリソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnetリソースの詳細については、サブネットを管理するをご覧ください。PORT: 転送ルールで公開するポート。portsフィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。portフィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。PROTOCOL: 転送ルールに使用するプロトコル（TCPなど）。ports配列のエントリは次のようになります。
ports: - port: 80 protocol: TCP構成された ELB を検証するには、作成された各オブジェクトの
Ready条件を確認します。VIP へのcurlリクエストでトラフィックをテストします。プロジェクトの VIP を取得します。
kubectl get forwardingruleexternal -n PROJECT出力は次のようになります。
NAME BACKENDSERVICE CIDR READY elb-name BACKEND_SERVICE_NAME 192.0.2.0/32 True転送ルールの
PORTフィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。curl http://FORWARDING_RULE_VIP:PORTFORWARDING_RULE_VIP:PORTは、転送ルールの VIP とポート（192.0.2.0:80など）に置き換えます。
非同期ストレージ レプリケーションを構成する
GDC マルチゾーン ユニバースは、障害復旧のための非同期ストレージ レプリケーションをサポートしています。この戦略では、同じリージョン内の任意の 2 つのゾーン間でデータ レプリケーションが行われるため、ゾーンが使用できなくなってもアプリケーション データにアクセスできます。
VM アプリケーションに次のいずれかの非同期ストレージ レプリケーション タイプを選択します。
オブジェクト ストレージ用のデュアルゾーン バケットを作成する
オブジェクト ストレージ データは、両方のゾーンにデータが保存されている単一のバケットに書き込まれます。データはゾーン間で非同期でコピーされるため、ゾーンに同じオブジェクト バージョンが含まれていない可能性がありますが、追加の変更が行われない場合は、最終的に同等になります。ボリューム レプリケーションとは異なり、レプリケートされたバケットはゾーン パーティション中に書き込み可能です。オブジェクトへの書き込みごとに異なるバージョンが生成され、接続が復元された後の最終状態は、いずれかのゾーンの最新バージョンになります。
インフラストラクチャ オペレータ（IO）が
BucketLocationConfigカスタム リソースを作成していることを確認します。これは、オブジェクト ストレージのゾーン間の非同期レプリケーションに必要です。このリソースは、ルート グローバル API サーバーにデプロイする必要があります。デュアルゾーンの
Bucketカスタム リソースを作成します。kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: object.global.gdc.goog/v1 kind: Bucket metadata: name: BUCKET_NAME namespace: PROJECT spec: location: LOCATION_NAME description: Sample DZ Bucket storageClass: Standard EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig ファイル。BUCKET_NAME: ストレージ バケットの名前。PROJECT: バケットが存在するプロジェクトの名前。LOCATION_NAME: バケット内のオブジェクト データが存在する物理的な場所。これは、既存のBucketLocationリソースの名前にマッピングする必要があります。組織のグローバル API サーバーに利用可能なBucketLocationリソースのリストをクエリするには、kubectl --kubeconfig GLOBAL_API_SERVER bucketlocationsを実行します。BucketLocationリソースがない場合は、IO に連絡して、非同期レプリケーションが有効になっていることを確認します。
ゾーン間の非同期ブロック ストレージ レプリケーションを構成する
レプリケートされたブロック ストレージは、プライマリ ボリュームとセカンダリ ボリューム間のブロックの同等性を維持する非同期レプリケート ボリューム（PV）を提供します。非同期であるため、セカンダリ ボリュームには過去のある時点のプライマリ ゾーンの状態が反映されます（RPO はゼロ以外）。セカンダリ ボリュームはレプリケーションのターゲットである間はマウントできません。関係を終了して書き込みを有効にするには、手動での操作が必要です。
ソースゾーンのデータが使用できなくなった場合にフェイルオーバーに使用できる複製データを作成するには、VolumeReplicationRelationship カスタム リソースをグローバル API サーバーにデプロイする必要があります。
開始する前に、インフラストラクチャ オペレーター（IO）が StorageClusterPeering カスタム リソースと StorageVirtualMachinePeering カスタム リソースを作成して構成し、ゾーン間のブロック ストレージ レプリケーションを許可していることを確認します。このリソースは、ルート グローバル API サーバーにデプロイする必要があります。
gdcloud
プライマリ ゾーンとセカンダリ ゾーン間の非同期レプリケーション ボリュームの関係を設定します。
gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \ --project PROJECT \ --zone PRIMARY_ZONE \ --secondary-disk SECONDARY_DISK_NAME \ --secondary-zone SECONDARY_ZONE次のように置き換えます。
PRIMARY_DISK_NAME: レプリケートされるソースディスクの名前。PROJECT: プライマリ ディスクの GDC プロジェクト。PRIMARY_ZONE: プライマリ ディスクが存在するゾーン。SECONDARY_DISK_NAME: レプリケート先のディスクの名前。SECONDARY_ZONE: セカンダリ ディスクが配置されるゾーン。
移行先ゾーンに
VolumeFailoverカスタム リソースを作成します。これにより、移行元ゾーンが何らかの理由で使用できなくなった場合に、移行先ゾーンへのレプリケーションが停止します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: storage.gdc.goog/v1 kind: VolumeFailover metadata: name: FAILOVER_NAME namespace: PROJECT spec: volumeReplicationRelationshipRef: REPL_NAME EOF次のように置き換えます。
MANAGEMENT_API_SERVER: Management API サーバーの kubeconfig ファイル。FAILOVER_NAME: フェイルオーバーの名前。PROJECT: ストレージ インフラストラクチャが存在するプロジェクト。REPL_NAME: ボリューム レプリケーションの関係の名前。
VM ワークロードの非同期レプリケーションの管理の詳細については、ボリュームを非同期で複製するをご覧ください。
API
VolumeReplicationRelationshipカスタム リソース YAML ファイルを作成し、グローバル API サーバーにデプロイします。kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF apiVersion: storage.global.gdc.goog/v1 kind: VolumeReplicationRelationship metadata: name: VRR_NAME namespace: PROJECT spec: source: virtualMachineDisk: virtualMachineDiskRef: PRIMARY_DISK_NAME zoneRef: PRIMARY_ZONE destination: volumeOverrideName: SECONDARY_DISK_NAME zoneRef: SECONDARY_ZONE EOF次のように置き換えます。
GLOBAL_API_SERVER: グローバル管理 API サーバーの kubeconfig ファイル。VRR_NAME: ボリューム レプリケーションの関係の名前。非同期レプリケーションを停止するときは、同じ名前を使用する必要があります。PROJECT: プライマリ ディスクの GDC プロジェクト。PRIMARY_DISK_NAME: レプリケートされるソースディスクの名前。PRIMARY_ZONE: プライマリ ディスクが存在するゾーン。SECONDARY_DISK_NAME: レプリケート先の宛先ディスクの名前。SECONDARY_ZONE: セカンダリ ディスクが配置されるゾーン。
移行先ゾーンに
VolumeFailoverカスタム リソースを作成します。これにより、移行元ゾーンが何らかの理由で使用できなくなった場合に、移行先ゾーンへのレプリケーションが停止します。kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF apiVersion: storage.gdc.goog/v1 kind: VolumeFailover metadata: name: FAILOVER_NAME namespace: PROJECT spec: volumeReplicationRelationshipRef: REPL_NAME EOF次のように置き換えます。
MANAGEMENT_API_SERVER: Management API サーバーの kubeconfig ファイル。FAILOVER_NAME: フェイルオーバーの名前。PROJECT: ストレージ インフラストラクチャが存在するプロジェクト。REPL_NAME: ボリューム レプリケーションの関係の名前。
VM ワークロードの非同期レプリケーションの管理の詳細については、ボリュームを非同期で複製するをご覧ください。