内部ロードバランサを登録する

このページでは、内部パススルー ネットワーク ロードバランサまたは内部アプリケーション ロードバランサ（プレビュー）を構成して、Service Directory に自動的に登録する方法について説明します。

ロードバランサを作成するときに、既存の Service Directory の名前空間と選択したサービスのエンドポイントとして登録できます。その後、クライアント アプリケーションは、Service Directory（HTTP または gRPC を使用）や DNS（Service Directory DNS ゾーンを作成した場合）を使用して、内部ロードバランサ サービスのアドレスを解決し、直接接続できます。

制限事項

Service Directory と内部ロード バランシングの統合には、次の制限事項があります。

• 自動登録は、内部ロードバランサとネットワーク ロードバランサにのみ適用されます。GKE 統合を使用して、Google Kubernetes Engine ロード バランシング サービスを登録できます。Service Directory API を呼び出すことで、グローバル ロードバランサと Google Kubernetes Engine の上り（内向き）とゲートウェイを登録できます。
• 自動登録は、転送ルールの作成時にのみ使用できます。既存の転送ルールに対する Google Cloud CLI の更新を使用した自動登録は使用できません。
• 共有 VPC ネットワーク設定のホスト プロジェクトまたはサービス プロジェクトで、内部ロードバランサを Service Directory に登録できます。ただし、すべてのロード バランシング コンポーネントとバックエンドは同じプロジェクト内に存在する必要があります。詳細については、内部ロードバランサの制限事項をご覧ください。
• Service Directory は接続を提供しません。つまり、Service Directory は内部ロードバランサの仮想 IP アドレスを保存しますが、Service Directory で内部ロードバランサを検索しても、仮想 IP アドレスに接続できるとは限りません。

始める前に

この手順では、次のものが必要です。

• Service Directory の名前空間とサービスがすでに存在している必要があります。ない場合は、Service Directory の構成の手順に沿って、名前空間とサービスを作成します。

  Service Directory の Namespace とサービスは、作成する内部ロードバランサの転送ルールと同じプロジェクトとリージョンに存在する必要があります。

• 内部ロードバランサの転送ルールを作成するために必要なリソースがすでに設定されている必要があります。

  • 内部パススルー ネットワーク ロードバランサの作成方法については、内部パススルー ネットワーク ロードバランサを設定するをご覧ください。
  • 内部アプリケーション ロードバランサの作成方法については、内部アプリケーション ロードバランサを設定するをご覧ください。

Service Directory に内部ロードバランサを登録するように転送ルールを設定する

Service Directory に内部ロードバランサを登録するには、転送ルールを設定する必要があります。内部パススルー ネットワーク ロードバランサまたは内部アプリケーション ロードバランサを登録するには、次のセクションをご覧ください。

内部パススルー ネットワーク ロードバランサを登録する

内部パススルー ネットワーク ロードバランサを登録するには、gcloud compute forwarding-rules create コマンドを実行して service-directory-registration フラグを設定します。

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --region=REGION \
    --load-balancing-scheme=INTERNAL \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --address=RESERVED_IP_ADDRESS \
    --ip-protocol=PROTOCOL_TYPE \
    --ports=PORT_NUMBER \
    --backend-service=BACKEND_SERVICE_NAME \
    --backend-service-region=REGION \
    --service-directory-registration=SD_SERVICE_NAME

次のように置き換えます。

• FORWARDING_RULE_NAME: 作成する転送ルールの名前
• REGION: 転送ルールを作成するリージョン
• NETWORK_NAME: この転送ルールが適用されるネットワーク
• SUBNET_NAME: この転送ルールが適用されるサブネットワーク
• RESERVED_IP_ADDRESS: 転送ルールが提供する IP アドレス
• PROTOCOL_TYPE: ルールが提供する IP プロトコル
• PORT_NUMBER: カンマ区切りのポートのリスト
• BACKEND_SERVICE_NAME: トラフィックを受信する対象のバックエンド サービス
• SD_SERVICE_NAME: エンドポイントを登録する Service Directory サービスの完全修飾名。これは、作成する転送ルールと同じプロジェクトとリージョンに存在する必要があります。例: projects/PROJECT/locations/REGION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME

内部アプリケーション ロードバランサを登録する

リージョン内部アプリケーション ロードバランサを登録するには、gcloud compute forwarding-rules create コマンドを実行して service-directory-registration フラグを設定します。

gcloud beta compute forwarding-rules create FORWARDING_RULE_NAME \
    --region=REGION \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=NETWORK_NAME \
    --address=RESERVED_IP_ADDRESS \
    --target-https-proxy=PROXY_NAME \
    --target-https-proxy-region=PROXY_REGION \
    --ports=PORT_NUMBER \
    --service-directory-registration=SD_SERVICE_NAME

次のように置き換えます。

• FORWARDING_RULE_NAME: 作成する転送ルールの名前
• REGION: 転送ルールを作成するリージョン
• NETWORK_NAME: この転送ルールが適用されるネットワーク
• RESERVED_IP_ADDRESS: 転送ルールが提供する IP アドレス
• PROXY_NAME: トラフィックを受信するターゲット プロキシ
• PROXY_REGION: プロキシのリージョン
• PORT_NUMBER: カンマ区切りのポートのリスト
• SD_SERVICE_NAME: エンドポイントを登録する Service Directory サービスの完全修飾名。このサービスは、作成する転送ルールと同じプロジェクトとリージョンに存在する必要があります。例: projects/PROJECT/locations/REGION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME

エンドポイントを確認する

内部ロードバランサを登録するときに作成される 1 つ以上の Service Directory エンドポイントには、次の特性があります。

• エンドポイントの名前は、指定されたポート番号（<forwarding rule name>-<port>）の転送ルールの名前と同じです。たとえば、--port=8080 を使用して転送ルール RULE を作成すると、RULE-8080 というエンドポイントが作成されます。同じルールで 2 つのポート --port=8080, 8081 を指定した場合、2 つのエンドポイント RULE-8080 と RULE-8081 が取得されます。--port=ALL を指定すると、Service Directory エンドポイントはポート 0 に登録されます。内部ロードバランサのオーナーは、API 呼び出し元が接続するポートを認識していることを確認する必要があります。
• パブリック Service Directory API を使用してエンドポイントを変更または削除することはできません。エンドポイントが自動的に削除されるのは、転送ルールを削除した場合のみです。つまり、転送ルールが存在する間は、エンドポイントが存在するサービスと Namespace を削除できません。
• エンドポイント自体は課金されませんが、エンドポイントへの API 呼び出しには通常の料金詳細が適用されます。

エンドポイントが作成されたことを確認するには、Service Directory でサービスを解決します。指定したポート番号を持つ転送ルールの名前と同じ名前のエンドポイントが表示されます。

Service Directory でサービスを解決するには、次の操作を行います。

gcloud service-directory services resolve SD_SERVICE_NAME \
    --namespace=SD_NAMESPACE_NAME \
    --location=REGION

省略可: Cloud DNS を使用して Service Directory ゾーンを作成する

この統合を通じて登録された Service Directory エンドポイントは、他の Service Directory エンドポイントと同様に DNS を使用して解決できます。Cloud DNS を使用して Service Directory ゾーンを作成するには、Service Directory ゾーンの構成をご覧ください。

ゾーンが正しく設定されていることを確認するには、Service Directory ゾーンの DNS クエリを実行します。DNS を使用してクエリを実行する方法については、DNS を使用したクエリをご覧ください。ゾーンが正しく構成されている場合は、コマンド出力に内部ロードバランサの IP アドレスが表示されます。

クリーンアップ

作成したリソースを削除するには、次の操作を行います。

次のステップ

• Service Directory の概要については、Service Directory の概要をご覧ください。
• Service Directory の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。