Visão geral do Traffic Director

O Traffic Director é um plano de controle gerenciado para rede de aplicativos. O Traffic Director permite fornecer serviços globais altamente disponíveis com recursos avançados de rede de aplicativos, como gerenciamento de tráfego e observabilidade.

À medida que o número de serviços e microsserviços na sua implantação aumenta, você geralmente começa a enfrentar desafios comuns da rede de aplicativos, como estes:

  • Como faço para tornar meus serviços resilientes?
  • Como obtenho tráfego para meus serviços e como os serviços sabem e se comunicam uns com os outros?
  • Como posso entender o que está acontecendo quando meus serviços se comunicam entre si?
  • Como atualizo meus serviços sem correr riscos de falha temporária?
  • Como faço para gerenciar a infraestrutura que torna minha implantação possível?
Os serviços precisam se comunicar uns com os outros.
Os serviços precisam se comunicar uns com os outros (clique para ampliar)

O Traffic Director ajuda a resolver esses tipos de desafios em uma implantação moderna, baseada em serviços. O melhor de tudo é que ele depende da infraestrutura gerenciada pelo Google Cloud para que você tenha os melhores recursos, sem precisar gerenciar sua própria infraestrutura. Concentre-se no código do aplicativo de envio que resolve seus problemas empresariais e deixe que o Traffic Director gerencie as complexidades da rede de aplicativos.

Traffic Director para malha de serviço

Um padrão comum para resolver desafios de rede de aplicativos é usar uma malha de serviço. O Traffic Director é compatível com a malha de serviço e muitos outros padrões de implantação que atendem às suas necessidades.

Uma malha de serviço típica.
Uma malha de serviço típica (clique para ampliar)

Em uma malha de serviço típica, as seguintes condições são verdadeiras:

  • Implante seus serviços em um cluster do Kubernetes.
  • Cada um dos pods de serviço tem um proxy dedicado (geralmente o Envoy) em execução como um proxy sidecar.
  • Cada proxy sidecar se comunica com a infraestrutura de rede (um plano de controle) que é instalado no cluster. O plano de controle informa os proxies sidecar sobre serviços, endpoints e políticas na malha de serviço.
  • Quando um pod envia ou recebe uma solicitação, a solicitação vai para o proxy sidecar do pod. O proxy sidecar processa a solicitação, por exemplo, enviando-a para o destino pretendido.

Nos diagramas deste documento, os ícones de rosa com seis lados representam proxies. O plano de controle está conectado a cada proxy e fornece as informações necessárias para que os proxies processem solicitações. Setas entre as caixas mostram os fluxos de tráfego. Por exemplo, o código do aplicativo em Service A envia uma solicitação. O proxy processa a solicitação e a encaminha para Service B.

Esse modelo permite mover a lógica de rede do código do seu aplicativo. Você pode focar em agregar valor aos negócios e, ao mesmo tempo, permitir que sua infraestrutura cuide da rede do aplicativo.

Como o Traffic Director é diferente

O Traffic Director funciona de modo semelhante ao modelo, mas é diferente de maneiras importantes. Tudo começa com o fato de que o Traffic Director é um serviço gerenciado pelo Google Cloud. Você não o instala, ele não é executado no cluster e você não precisa mantê-lo.

No diagrama a seguir, o Traffic Director é o plano de controle. Há quatro serviços neste cluster do Kubernetes, cada um com proxies sidecar conectados ao Traffic Director. O Traffic Director fornece as informações necessárias para os proxies encaminharem solicitações. Por exemplo, o código do aplicativo em um pod que pertence a Service A envia uma solicitação. O proxy sidecar em execução ao lado desse pod manipula a solicitação e a encaminha para um pod que pertence a Service B.

Um exemplo de malha de serviço com o Traffic Director.
Um exemplo de malha de serviço com o Traffic Director (clique para ampliar)

Além da malha de serviço

O Traffic Director é compatível com mais tipos de implantações do que uma malha de serviço típica.

Kubernetes de vários clusters

Com o Traffic Director, você recebe rede de aplicativos que funcionam nos clusters do Kubernetes. No diagrama a seguir, o Traffic Director fornece o plano de controle para clusters do Kubernetes em us-central1 e europe-west1. As solicitações podem ser encaminhadas entre os três serviços em us-central1, entre os dois serviços em europe-west1 e entre os serviços nos dois clusters.

Um exemplo de Kubernetes de vários clusters com o Traffic Director.
Um exemplo de Kubernetes de vários clusters com o Traffic Director (clique para ampliar)

Sua malha de serviço pode se estender por vários clusters do Kubernetes em várias regiões do Google Cloud. Os serviços em um cluster podem conversar com serviços em outro cluster. É possível ter serviços que consistem em pods em vários clusters.

Com o balanceamento de carga global baseado em proximidade do Traffic Director, as solicitações destinadas a Service B vão para o pod mais próximo que pode atender à solicitação. Você também terá um failover perfeito: se um pod estiver inativo, a solicitação fará o failover automaticamente para outro pod que possa servir na solicitação, mesmo se esse pod estiver em um cluster diferente do Kubernetes.

Máquinas virtuais

O Kubernetes está se tornando cada vez mais popular, mas muitas cargas de trabalho são implantadas em instâncias de máquina virtual (VM). O Traffic Director resolve a rede de aplicativos para essas cargas de trabalho: as cargas de trabalho baseadas em VM podem interoperar facilmente com as cargas de trabalho baseadas no Kubernetes.

No diagrama a seguir, o tráfego entra na implantação por meio do balanceamento de carga de HTTP(S) externo. Ele é roteado para Service A no cluster do Kubernetes em asia-southeast1 e para Service D em uma VM em europe-west1.

Um exemplo de VMs e Kubernetes com o Traffic Director.
Um exemplo de VMs e Kubernetes com o Traffic Director (clique para ampliar)

O Google oferece um mecanismo perfeito para configurar cargas de trabalho baseadas em VM com o Traffic Director. Você só adiciona uma sinalização ao modelo de instância da VM do Compute Engine, e o Google lida com a configuração da infraestrutura. Isso inclui a instalação e a configuração dos proxies que fornecem recursos de rede de aplicativos.

gRPC sem proxy

gRPC é um framework RPC de código aberto de recursos completos que pode ser usado para escrever microsserviços de alto desempenho. Com o Traffic Director, é fácil trazer recursos de rede de aplicativos (como descoberta de serviços, balanceamento de carga e gerenciamento de tráfego) para aplicativos gRPC (saiba mais). Para mais informações, consulte Traffic Director e gRPC: serviços sem proxy para a malha de serviço.

No diagrama a seguir, os aplicativos gRPC encaminham tráfego para serviços baseados em clusters do Kubernetes em uma região e para serviços em execução em VMs em regiões diferentes. Dois dos serviços incluem proxies sidecar, e os outros são sem proxy.

Um exemplo de aplicativos gRPC sem proxy com o Traffic Director.
Um exemplo de aplicativos gRPC sem proxy com o Traffic Director (clique para ampliar)

O Traffic Director é compatível com serviços do gRPC sem proxy. Esses serviços usam uma versão recente da biblioteca gRPC de código aberto compatível com as APIs xDS. Os aplicativos gRPC podem se conectar ao Traffic Director usando as mesmas APIs xDS que o Envoy usa.

Depois de conectada, a biblioteca do gRPC cuida da funcionalidade de rede de aplicativos, como descoberta de serviços, balanceamento de carga e gerenciamento de tráfego. Isso acontece nativamente no gRPC, de modo que os proxies de serviço não sejam obrigatórios. É por isso que eles são chamados de aplicativos gRPC sem proxy.

Entrada e gateways

Para muitos casos de uso, é preciso processar o tráfego proveniente de clientes que não estão configurados pelo Traffic Director. Por exemplo, talvez seja necessário encaminhar tráfego de Internet pública para seus microsserviços. Você também pode configurar um balanceador de carga como um proxy reverso que processa o tráfego de um cliente antes de enviá-lo para um destino.

No diagrama a seguir, um balanceador de carga HTTP(S) externo permite a entrada de clientes externos, com tráfego roteado para serviços em um cluster do Kubernetes. Um balanceador de carga HTTP(S) interno direciona o tráfego interno para o serviço em execução na VM.

Traffic Director com Cloud Load Balancing para entrada.
Traffic Director com o Cloud Load Balancing para entrada (clique para ampliar)

O Traffic Director trabalha com o Cloud Load Balancing para fornecer uma experiência de entrada gerenciada. Basta configurar um balanceador de carga externo ou interno e em seguida, configurá-lo para enviar tráfego aos microsserviços. No diagrama acima, os clientes de Internet pública alcançam seus serviços usando balanceamento de carga HTTP(S) externo. Os clientes, como microsserviços que residem na rede da nuvem privada virtual (VPC), usam balanceamento de carga HTTP(S) interno para acessá-los.

No diagrama a seguir, uma VM na região europe-west1 executa um proxy que atua como um gateway para três serviços que não estão executando proxies. O tráfego de um balanceador de carga HTTP(S) externo e um balanceador de carga HTTP(S) interno é encaminhado para o gateway e para os três serviços.

Traffic Director usado para configurar um gateway.
Traffic Director usado para configurar um gateway (clique para ampliar)

Em alguns casos de uso, convém configurar o Traffic Director para configurar um gateway. Esse gateway é essencialmente um proxy reverso, geralmente Envoy em execução em uma ou mais VMs, que detecta solicitações de entrada, manipula-as e as envia para um destino. O destino pode estar em qualquer região do Google Cloud ou em um cluster do Google Kubernetes Engine (GKE). É possível até mesmo um destino fora do Google Cloud que pode ser acessado pelo Google Cloud usando conectividade híbrida.

Vários ambientes

Não importa se você tem serviços no Google Cloud, no local, em outras nuvens ou em todas elas, os desafios fundamentais da rede de aplicativos permanecem os mesmos. Como você recebe tráfego para esses serviços? E como esses serviços se comunicam uns com os outros?

No diagrama a seguir, o Traffic Director encaminha o tráfego dos serviços em execução no Google Cloud para Service G, em outra nuvem pública e para Service E e Service F, sendo executados em um data center local. Service A, Service B e Service C, usam o Envoy como um proxy sidecar, enquanto Service D é um serviço gRPC sem proxy.

Traffic Director usado para comunicação entre ambientes.
Traffic Director usado para comunicação entre ambientes (clique para ampliar)

Quando você usa o Traffic Director, é possível enviar solicitações para destinos fora do Google Cloud. Isso permite que você use o Cloud Interconnect ou o Cloud VPN para encaminhar de modo particular o tráfego de serviços dentro do Google Cloud para serviços ou gateways em outros ambientes.

Como configurar o Traffic Director

A configuração do Traffic Director é composta por duas etapas. Depois de concluir o processo de configuração, a infraestrutura gerencia a rede de aplicativos e o Traffic Director mantém tudo atualizado com base nas alterações da implantação.

Implantar seus aplicativos

Primeiro, implante o código do aplicativo em contêineres ou VMs. O Google fornece mecanismos que permitem que você adicione facilmente a infraestrutura de rede de aplicativos (geralmente proxies do Envoy) às instâncias de VM e aos pods. Essa infraestrutura está configurada para se comunicar com o Traffic Director e saber mais sobre os serviços.

Configurar o Traffic Director

Em seguida, configure seus serviços globais e defina como o tráfego será tratado. Para configurar o Traffic Director, use o Console do Google Cloud, a ferramenta de linha de comando da gcloud, a API Traffic Director ou outras ferramentas, como o Terraform.

Depois de concluir essas etapas, o Traffic Director estará pronto para configurar a infraestrutura de rede de aplicativos.

A infraestrutura lida com rede de aplicativos

Quando um aplicativo envia uma solicitação para my-service, a infraestrutura de rede de aplicativos, por exemplo, um proxy sidecar do Envoy, processa a solicitação de acordo com as informações recebidas do Traffic Director. Isso permite que uma solicitação de my-service seja encaminhada facilmente para uma instância de aplicativos que possa receber a solicitação.

Monitoramento e atualizações contínuas

O Traffic Director monitora as instâncias de aplicativos que constituem seus serviços. Isso permite que o Traffic Director descubra que um serviço está íntegro ou que a capacidade dele mudou, por exemplo, quando um novo pod do Kubernetes é criado. Com base nessas informações, o Traffic Director atualiza continuamente a infraestrutura de rede de aplicativos.

Recursos

Os recursos do Traffic Director fornecem recursos de rede de aplicativos aos microsserviços. Alguns destaques são discutidos nesta seção.

Plano de controle totalmente gerenciado, verificação de integridade e balanceamento de carga

Você quer passar seu tempo fornecendo valor comercial, não gerenciando a infraestrutura. O Traffic Director é uma solução totalmente gerenciada com um SLA de tempo de atividade. Assim, você não precisa instalar, configurar ou atualizar a infraestrutura. Você se beneficia da mesma infraestrutura que o Google usa para verificação de integridade e balanceamento de carga global.

Desenvolvidos com produtos de código aberto

O Traffic Director usa as mesmas APIs de plano de controle (xDS), que projetos de código aberto conhecidos como Envoy e Istiousam (links em inglês). Para ver as versões compatíveis da API, consulte as APIs do plano de controle do xDS.

A infraestrutura que fornece recursos de rede de aplicativos (Envoy ou gRPC, dependendo do caso de uso) também é de código aberto, para que você não precise se preocupar com o bloqueio em uma infraestrutura proprietária.

Escala

De soluções de rede de aplicativos únicas a implantações de malha de serviço massivas com milhares de serviços, o Traffic Director foi criado para atender aos seus requisitos de escalonamento.

Descoberta de serviços e rastreamento de endpoints e back-ends

Quando o aplicativo envia uma solicitação para my-service, a infraestrutura processa continuamente a solicitação e a envia para o destino correto. Seu aplicativo não precisa saber nada sobre endereços IP, protocolos ou outras complexidades de rede.

Balanceamento de carga e failover globais

O Traffic Director usa o balanceamento de carga global do Google e a verificação de integridade para equilibrar o tráfego de acordo com a proximidade, a integridade e a capacidade do back-end. Você melhora a disponibilidade do serviço fazendo o failover do tráfego automaticamente para back-ends íntegros com capacidade.

Gerenciamento de tráfego

O gerenciamento avançado de tráfego, incluindo roteamento e solicitação de manipulação (com base no nome do host, caminho, cabeçalhos, cookies e muito mais), permite determinar o fluxo do tráfego entre os serviços. Também é possível aplicar ações como novas tentativas, redirecionamentos e divisão de tráfego com base no peso para implantações canário. Padrões avançados como injeção de falhas, espelhamento de tráfego e detecção de outliers permitem casos de uso de DevOps que melhoram sua resiliência.

Observabilidade

A infraestrutura de rede de aplicativos coleta informações de telemetria, como métricas, registros e traces, que podem ser agregadas de maneira centralizada no pacote de operações do Google Cloud. Depois que essas informações forem coletadas, é possível conseguir insights e criar alertas para que, caso algo dê errado, você receba uma notificação.

A seguir