Traffic Director integration with Service Directory

This document provides an overview of how to use Service Directory's service registry with Traffic Director, which lets Traffic Director route traffic to and apply traffic policies to services registered with Service Directory. This document is for Traffic Director developers who want to integrate their applications with other services in Google Cloud.

Service Directory is a service registry that stores information about network services that are registered with it, including their names, locations, and attributes. You can register your services automatically, capturing all details, and all services can be registered, regardless of their infrastructure.

The registry can contain not only Google Cloud services, but also hybrid services running on-premises or in other public clouds. To best understand the information in this document, we recommend that you familiarize yourself with the basics of Service Directory operations.

When you use Service Directory's service registry with Traffic Director, the integration makes services in the service registry available to the applications in your mesh and to gateways configured by Traffic Director. Traffic Director's integration with Service Directory is supported, with Envoy and with proxyless gRPC, for Service Directory integrations with Internal TCP/UDP Load Balancing, Internal HTTP(S) Load Balancing, and L4 Private Service Connect.

To integrate your services, you register a service with Service Directory, then bind the service to a Traffic Director backend service. After a binding is established, Traffic Director queries Service Directory to obtain information about the registered service and how that service can be reached. Traffic Director also tracks any changes to the service. Using the integration allows your service mesh and self- managed gateway to send traffic to these services. It also lets you enforce policies—for example, advanced traffic management policies—that you configure in Traffic Director.

When you use this integration, the service binding acts as a backend, regardless of the type of backend used by the service itself. The integration simplifies your Traffic Director deployment, because Traffic Director can send traffic to the service without regard to the type of backend.

When a service is registered with Service Directory, you don't need to configure instance groups or different types of network endpoint groups (NEGs) to get access to services you need. You can automatically register Google Kubernetes Engine, internal load balancers, and Private Service Connect to Service Directory, further simplifying Traffic Director's access to these services.

Service Directory services whose endpoints are IP addresses versus FQDNs

When a Service Directory service's endpoint is an FQDN, Traffic Director sets the FQDN as the endpoint address and marks the cluster discovery type as STRICT_DNS. In Strict DNS resolution mode, Envoy continuously and asynchronously resolves the specified DNS targets. Each returned IP address in the DNS result is considered an explicit host in the upstream cluster. For example, if the DNS query returns three IP addresses, Envoy assumes that the cluster has three hosts, and traffic should be load balanced to all three. If a host is removed from the result, Envoy assumes that it no longer exists and drains traffic from any existing connection pools.

For services with IP address endpoints, Traffic Director marks the cluster discovery type as EDS and returns the IP address using the EDS protocol.

Resources used by the integration

The integration between Traffic Director and Service Directory uses the following resources.

Service Directory services

Service Directory is a service registry. Service Directory lets you register various types of services, including services based in Google Cloud or other environments (for example, an on-premises data center). Each service consists of a unique name and zero or more service endpoints. A service endpoint consists of an address, port, properties, and metadata. If there are zero endpoints, you cannot route traffic to the service.

Service bindings

A service binding is a resource that includes the fully qualified domain name (FQDN) of the Service Directory service. For example, projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service is an FQDN for a Service Directory service.

Backend services

Backend services are configuration resources that provide information to Traffic Director, including the backends, such as managed instances groups, to which the backend service routes traffic. Backend services that reference service bindings cannot have backends. To use the Traffic Director integration with Service Directory, you create a new backend service to reference service bindings.

A backend service can have multiple service bindings. This configuration is useful in a situation where you have regional deployments of the same application. You might register each regional deployment to a regional instance of Service Directory, as regional service 1 and regional service 2. Each of these regional Service Directory services can then be associated with the same backend service, using two service bindings. Global service binding 1 would be associated with regional service 1 in region A and global service binding 2 would be associated with regional service 2 in region B.

Use cases

Integrating your Traffic Director deployment with Service Directory enables new use cases that are helpful when you depend on services that other teams or organizations own or publish.

Make existing services available to Traffic Director

Service Directory integrates with Google Cloud products such as GKE, Internal TCP/UDP Load Balancing, and Internal HTTP(S) Load Balancing. When service producers create a GKE service or a load balancer, they can register it with Service Directory.

After a service is registered with Service Directory, you can configure Traffic Director to communicate with that service. Traffic Director clients can then communicate with services that run behind Internal TCP/UDP Load Balancing and Internal HTTP(S) Load Balancing.

Improve coordination between service producers and consumers

Large enterprises have many independent developer teams. These teams make their services available to other teams so that more teams can use the capabilities provided by the shared service. This creates cross-team dependencies. While these dependencies enable teams to share their efforts, dependencies also create coordination overhead.

When you use Service Directory, one team (the producer) registers a service that it wants to make available to other teams or organizations (consumers). The producer shares a reference to this service with a consumer. The consumer can use this reference to look up the producer's service in Service Directory and discover the service's endpoints. For example, the endpoint might be a virtual IP address (VIP) on which the producer's service expects to receive traffic.

Traffic Director's integration with Service Directory lets you automate the process by binding a Service Directory service to a Traffic Director backend service, which has the following advantages:

  • Traffic Director automatically resolves the service's endpoints by synchronizing them from Service Directory. If the Service Directory service's endpoints are updated, Traffic Director automatically synchronizes these changes.
  • You can set various routing and traffic management policies, such as timeouts, in Traffic Director. These policies let you fine-tune how your applications issue requests to the Service Directory service. For information about routing and traffic management in Traffic Director, see Advanced traffic management.
  • Traffic Director uses traffic management capabilities such as proximity-based load balancing to optimally direct traffic from applications to endpoints—for example, by minimizing round-trip time.
Using Service Directory for service discovery.
Using Service Directory for service discovery (click to enlarge)

When you, a consumer, use Traffic Director and attach a backend service to a Service Directory service, cross-team coordination overhead is reduced.

  • You attach the service, Payments, by name.
  • Traffic Director shares information about the Payments service with its clients.

    • For example, the sidecar proxies running in your service mesh now know the endpoint (for example 10.0.0.1:80) at which the service can be reached.
  • Your applications can call this service by name without you or your application needing to know anything about the external service's endpoint. In the diagram, the service is the Payments service.

  • When the service producer updates the external service (for example, changing its endpoint), Traffic Director picks up the update and seamlessly shares it with its clients.

Access services within a perimeter using an ingress point

A team might group a collection of services within a VPC Service Controls perimeter and expose those services through a single ingress point. This ingress point can be registered to Service Directory and made available to users who want to access the services within the perimeter. For more information about VPC Service Controls perimeters, see Service perimeter details and configuration.

For example, a team creates an ingress gateway using Internal HTTP(S) Load Balancing that distributes requests to a collection of Kubernetes services in a cluster. This ingress gateway is automatically registered as a service to Service Directory. A consumer who wants to access the Kubernetes services can look up this ingress gateway in Service Directory. The consumer can then configure the Traffic Director mesh to access services within the perimeter through the gateway.

Connect services across domains

You might have services in different domains that you need to connect.

Connect services across organizations

You might want access to services owned by another organization, such as Google APIs (for example, Cloud SQL) or third-party managed services.

Service Directory supports Private Service Connect. When you create a Private Service Connect endpoint in your network, the endpoint can be registered as a service with Service Directory. You can then attach this service to Traffic Director, so that mesh clients, such as Envoy and gRPC clients, and self-managed gateways, such as Apigee, can call on these services.

Using Service Directory for service discovery with Private Service Connect.
Using Service Directory for service discovery with Private Service Connect (click to enlarge)

The preceding example, using Cloud Storage, illustrates how you can use Private Service Connect to call Google APIs using an endpoint in your Virtual Private Cloud network.

Connect services across VPC networks

Some companies use multiple VPC networks as part of their Google Cloud deployment. In such cases, a service in one VPC network might need to access a service in a different VPC network. You can configure VPC peering to access a service in a different VPC network, but this configuration creates complications when there are overlapping IP address ranges between peered networks.

Private Service Connect can securely and privately make a service in one VPC network accessible to services in another VPC network, using a single IP:port endpoint.

Detailed view of using Service Directory for service discovery with Private Service Connect.
Detailed view of using Service Directory for service discovery with Private Service Connect (click to enlarge)

Connect services across domains

The previous two examples illustrate cases where you might need to cross domains, but there are many additional examples. For example, you create a gateway that sits at the intersection of two Google Cloud regions. Services in one region can reach services in another region through this gateway. You register the gateway as a service in Service Directory, then use the gateway with Traffic Director as described in this document.

Apply policies when services are accessed

Traffic Director supports capabilities such as advanced traffic management that are configurable using policies. For example, you can set a traffic mirroring policy so that anytime a client sends a request to a particular backend service, the traffic also gets sent to a second backend service.

When you bind a Service Directory service to a Traffic Director backend service, you can configure these types of policies in Traffic Director. Your sidecar proxies, middle or edge proxies, and proxyless clients learn about these policies and enforce them.

Some examples:

  • Weight-based traffic splitting—for example, between two Service Directory services
  • Traffic mirroring—for example, to an audit service
Requests for `users` service are mirrored to `audit` service
Requests for users service are mirrored to audit service (click to enlarge)

Support for Traffic Director and existing clients

Even when Traffic Director is deployed in your organization, you might have clients that don't use Traffic Director. For example, you might need to access a service from a virtual machine that isn't part of a service mesh.

When you bind a Service Directory service to a Traffic Director backend service, Traffic Director's clients automatically get up-to-date information about that service. Your clients that do not use Traffic Director can look up and use service information in Service Directory.

What's next