Configuring an internal load balancer in Service Directory

This page provides information about how to configure an internal TCP/UDP load balancer or an internal HTTP(S) load balancer so that it is automatically registered in Service Directory.

When you create your load balancer, you can register it as an endpoint in an existing Service Directory namespace and service of your choice. Client applications can then use Service Directory (using HTTP or gRPC) and/or DNS (if you have created a Service Directory DNS zone) to resolve the address of the internal load balancer service and connect to it directly.

Limitations

Service Directory integration with internal load balancing has the following limitations:

  • Automatic registration only applies to internal load balancers. You can register external load balancers, global load balancers, and Google Kubernetes Engine load balancers by calling the Service Directory API.
  • You can register internal load balancers to Service Directory in the host or service project(s) of a shared VPC network setup. However, all load balancing components and backends must exist in the same project. For more details, see the internal load balancing limitations.
  • Service Directory does not provide connectivity, which means that although Service Directory stores the virtual IP address of the internal load balancer, looking up the internal load balancer in Service Directory does not guarantee that you can connect to the virtual IP address.

Before you begin

These instructions require the following:

  • You must already have a Service Directory namespace and service in place. If you do not, create a namespace and service using the procedure in Configuring Service Directory.

  • You must already have set up the necessary resources to create an internal load balancer forwarding rule.

Setting up forwarding rules to register an internal load balancer in Service Directory

You must set up a forwarding rule to register the internal load balancer in Service Directory. To register either an internal TCP/UDP load balancer or an internal HTTP(S) load balancer, see the following sections.

Registering an internal TCP/UDP load balancer

To register an internal TCP/UDP load balancer, do the following:

gcloud

Run the gcloud compute forwarding-rules create command and set the service-directory-registrations flag:

gcloud beta 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

Replace the following:

  • FORWARDING_RULE_NAME: a name for the forwarding rule to create
  • REGION: the region to create the forwarding rule in
  • NETWORK_NAME: the network that this forwarding rule applies to
  • SUBNET_NAME: the subnetwork that this forwarding rule applies to
  • RESERVED_IP_ADDRESS: the IP address that the forwarding rule serves
  • PROTOCOL_TYPE: the IP protocol that the rule will serve
  • PORT_NUMBER: a list of comma-separated ports
  • BACKEND_SERVICE_NAME: target backend service that receives the traffic
  • SD_SERVICE_NAME: the fully qualified name of the Service Directory service where you want to register the endpoint. It must live in the same project and region as the forwarding rule being created. For example: projects/PROJECT/locations/REGION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME.

Registering an internal HTTP(S) load balancer

To register an internal HTTP(S) load balancer, do the following:

gcloud

Run the gcloud compute forwarding-rules create command and set the service-directory-registrations flag:

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

Replace the following:

  • FORWARDING_RULE_NAME: a name for the forwarding rule to create
  • REGION: the region to create the forwarding rule in
  • NETWORK_NAME: the network that this forwarding rule applies to
  • RESERVED_IP_ADDRESS: the IP address that the forwarding rule serves
  • PROXY_NAME: target proxy that receives the traffic
  • PROXY_REGION: region of the proxy to operate on
  • PORT_NUMBER: a list of comma-separated ports
  • SD_SERVICE_NAME: the fully qualified name of the Service Directory service where you want to register the endpoint. It must live in the same project and region as the forwarding rule being created. For example: projects/PROJECT/locations/REGION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME.

Verifying the endpoint

The Service Directory endpoint(s) that are created when you register an internal load balancer have the following characteristics:

  • The endpoint has the same name as the name of the forwarding rule with the specified port number (<forwarding rule name>-<port>). For example, if you create a forwarding rule RULE with --port=8080, you get an endpoint called RULE-8080. For the same rule, if you specified two ports --port=8080, 8081, you get two endpoints, RULE-8080 and RULE-8081. If you specify --port=ALL, the Service Directory endpoint is registered with port 0. If you are the internal load balancer owner, you must ensure that the API caller knows what port to connect on.
  • You cannot modify or delete the endpoint using the public Service Directory API. Only when you delete the forwarding rule does the endpoint get automatically deleted. This means that you cannot delete the service and namespace that the endpoint resides in while the forwarding rule exists.
  • The endpoint itself is not billed, although normal pricing details apply to any API calls to the endpoint.

To confirm that the endpoint is created, resolve the service in Service Directory. You should see an endpoint with the same name as the name of the forwarding rule with the specified port number.

To resolve the service in Service Directory, do the following:

glcoud

Run the gcloud service-directory services resolve command:

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

Replace the following:

  • SD_SERVICE_NAME: the name of the Service Directory service to resolve. It must live in the Service Directory namespace name.
  • SD_NAMESPACE_NAME: the name that you gave the namespace containing your service.
  • REGION: the Google Cloud region containing the namespace. This should be the same as the region that you created the forwarding rule in.

(Optional) Creating a Service Directory zone using Cloud DNS

You can resolve Service Directory endpoints that are registered through this integration using DNS like any other Service Directory endpoint. To create a Service Directory zone using Cloud DNS, see Configuring a Service Directory zone.

To check that your zone is set up correctly, you can run a DNS query of your Service Directory zone. For instructions about how to query using DNS, see Querying using DNS. If your zone is configured correctly, you should see the IP address of your internal load balancer in the command output.

Cleanup

To delete the resources that you created, do the following:

gcloud

  1. To delete the forwarding rule, run the gcloud compute forwarding-rules delete command:

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
      --region=REGION \
    

    Replace the following:

    • FORWARDING_RULE_NAME: the name of the forwarding rule that you created
    • REGION: the region for the forwarding rule

    For further details, see Deleting a forwarding rule.

    To confirm that deleting the forwarding rule has automatically deleted the endpoint from Service Directory, run the gcloud service-directory services resolve command described in Verifying the endpoint section on your Service Directory service.

  2. To delete the zone, if you created one, follow the instructions in Deleting a managed zone.

  3. To delete the Service Directory namespace and service, see Deleting resources.

What's next