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

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

制限事項

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

• 自動登録は、内部ロードバランサとネットワーク ロードバランサにのみ適用されます。Google Kubernetes Engine ロード バランシング サービスを登録するには、GKE の統合を使用します。グローバル ロードバランサ、Google Kubernetes Engine の Ingress と Gateway は、Service Directory API を呼び出して登録できます。
• 自動登録は、転送ルールの作成時にのみ使用できます。すでに存在する転送ルールの 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 の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。