Traffic Director —Is it a Managed Istio Control Plane?

If your application is deployed in a microservices architecture then you are likely familiar with the networking challenges that come with it. Traffic Director helps you run microservices in a global service mesh. Traffic Director is Google Cloud’s fully managed application networking platform and service mesh. The mesh handles networking for your microservices so that you can focus on your business logic and application code, and that doesn’t need to know about underlying networking complexities. This separation of application logic from networking logic helps you improve your development velocity, increase service availability, and introduce modern DevOps practices in your organization.

For the ones who know Istio, this might sound overlapping and confusing. In this post I’ll go over what Traffic Director is, how it is related to the Istio service-mesh.

Istio has three core components: Pilot for Traffic Management, Mixer for Observability and Citadel for Service-to-Service Security.

Traffic Director delivers a GCP-managed Pilot along with additional capabilities mentioned such as global load balancing and centralised health checking.

Some of the common application networking challenges encountered, as the number of services and microservices in your deployment grows, are following:

• How do I make my services resilient?
• How do I get traffic to my services, and how do services know about and communicate with each other?
• How do I understand what is happening when my services are communicating with each other?
• How do I update my services without risking an outage?
• How do I manage the infrastructure that makes my deployment possible?

Features of Traffic Director

Some of the highlights of Traffic Director features are discussed below.

Fully managed control plane, health checking, and load balancing

You want to spend your time delivering business value, not managing infrastructure. Traffic Director is a fully managed solution with an uptime SLA, so you don’t have to install, configure, or update infrastructure. You benefit from the same infrastructure that Google uses for health checking and global load balancing.

Built on open source products

Traffic Director uses the same control plane (xDS) APIs that popular open source projects such as Envoy and Istio use.

The infrastructure that delivers application networking capabilities — either Envoy or gRPC depending on your use case — is also open source, so you don’t need to worry about being locked in to proprietary infrastructure.

Scale

From one-off application networking solutions to massive service mesh deployments with thousands of services, Traffic Director is built to meet your scaling requirements.

Service discovery and tracking your endpoints and backends

When your application sends a request to my-service, your infrastructure seamlessly handles the request and sends it to the correct destination. Your application doesn't need to know anything about IP addresses, protocols, or other networking complexities.

Global load balancing and failover

Traffic Director uses Google’s global load balancing and health checking to optimally balance traffic based on backend proximity, health, and capacity. You improve your service availability by having traffic automatically fail over to healthy backends with capacity.

Traffic management

Advanced traffic management, including routing and request manipulation (based on hostname, path, headers, cookies, and more), enables you to determine how traffic flows between your services. You can also apply actions like retries, redirects, and weight-based traffic splitting for canary deployments. Advanced patterns like fault injection, traffic mirroring, and outlier detection enable DevOps use cases that improve your resiliency.

Observability

Your application networking infrastructure collects telemetry information, such as metrics, logs, and traces, that can be aggregated centrally in Google Cloud’s operations suite. After this information is collected, you can gain insights and create alerts so that if anything goes wrong, you get notified.

VPC Service Controls

You can use VPC Service Controls to provide additional security for your application’s resources and services. You can add projects to service perimeters that protect resources and services (like Traffic Director) from requests that originate outside the perimeter.

Traffic Director for service mesh

A common pattern for solving application networking challenges is to use a service mesh. Traffic Director supports service mesh and many other deployment patterns that fit your needs.

In a typical service mesh, the following is true:

• You deploy your services to a Kubernetes cluster.
• Each of the services’ Pods has a dedicated proxy (usually Envoy) running as a sidecar proxy.
• Each sidecar proxy talks to the networking infrastructure (a control plane) that is installed in your cluster. The control plane tells the sidecar proxies about services, endpoints, and policies in your service mesh.
• When a Pod sends or receives a request, the request goes to the Pod’s sidecar proxy. The sidecar proxy handles the request, for example, by sending it to its intended destination.

Beyond service mesh

Traffic Director supports more types of deployments than a typical service mesh.

Multi-cluster Kubernetes

With Traffic Director, you get application networking that works across Kubernetes clusters. Your service mesh can extend across multiple Kubernetes clusters in multiple Google Cloud regions. Services in one cluster can talk to services in another cluster. You can even have services that consist of Pods in multiple clusters.

With Traffic Director’s proximity-based global load balancing, requests destined for Service B go to the nearest Pod that can serve the request. You also get seamless failover; if a Pod is down, the request automatically fails over to another Pod that can serve the request, even if this Pod is in a different Kubernetes cluster.

Virtual machines

Kubernetes is becoming increasingly popular, but many workloads are deployed to virtual machine (VM) instances. Traffic Director solves application networking for these workloads, too; your VM-based workloads easily interoperate with your Kubernetes-based workloads. Google provides a seamless mechanism to set up VM-based workloads with Traffic Director. You only add a flag to your Compute Engine VM instance template, and Google handles the infrastructure setup. This setup includes installing and configuring the proxies that deliver application networking capabilities.

Proxyless gRPC

gRPC is a feature-rich open source RPC framework that you can use to write high-performance microservices. With Traffic Director, you can easily bring application networking capabilities (such as service discovery, load balancing, and traffic management) to your gRPC applications. Traffic Director supports proxyless gRPC services. These services use a recent version of the open source gRPC library that supports the xDS APIs. Your gRPC applications can connect to Traffic Director by using the same xDS APIs that Envoy uses.

After your applications are connected, the gRPC library takes care of application networking functionality such as service discovery, load balancing, and traffic management. This functionality happens natively in gRPC, so service proxies are not required — that’s why they’re called proxyless gRPC applications.

Ingress and gateways

For many use cases, you need to handle traffic that originates from clients that aren’t configured by Traffic Director. For example, you might need to ingress public internet traffic to your microservices. You might also want to configure a load balancer as a reverse proxy that handles traffic from a client before sending it on to a destination. Traffic Director works with Cloud Load Balancing to provide a managed ingress experience. You set up an external or internal load balancer, and then configure that load balancer to send traffic to your microservices.

For some use cases, you might want to set up Traffic Director to configure a gateway. A gateway is essentially a reverse proxy, typically Envoy running on one or more VMs, that listens for inbound requests, handles them, and sends them to a destination. The destination can be in any Google Cloud region or Google Kubernetes Engine (GKE) cluster. It can even be a destination outside of Google Cloud that is reachable from Google Cloud by using hybrid connectivity.

Multiple environments

Whether you have services in Google Cloud, on-premises, in other clouds, or all of these, your fundamental application networking challenges remain the same. How do you get traffic to these services? How do these services communicate with each other? When you use Traffic Director, you can send requests to destinations outside of Google Cloud. This enables you to use Cloud Interconnect or Cloud VPN to privately route traffic from services inside Google Cloud to services or gateways in other environments.

Conclusion

Traffic Director is a managed Pilot (with extra capabilities) which will support Istio APIs for management. Thus, it should enable an easy opt-in replacement in case you want to replace your on-cluster, unmanaged pilot, with a fully managed one with high SLA.