Visão geral do Traffic Director
Este documento é destinado a administradores de redes e proprietários de serviços que querem se familiarizar com o Traffic Director e os recursos dele.
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?
O Traffic Director ajuda a resolver esses tipos de desafios em uma implantação moderna, baseada em serviços. O Traffic Director usa a infraestrutura gerenciada pelo Google Cloud para que você não precise 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.
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 e de outros documentos do Traffic Director, os ícones rosa de seis lados representam os 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.
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.
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 balanceador
de carga de aplicativo externo. Ele é roteado para Service A no cluster do Kubernetes
em asia-southeast1 e para Service D em uma VM em europe-west1.
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.
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 de aplicativo externo permite a entrada de clientes externos, com tráfego roteado para serviços em um cluster do Kubernetes. Um balanceador de carga de aplicativo interno encaminha o tráfego interno para o serviço em execução na VM.
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 anterior, os clientes públicos da Internet acessam seus serviços por meio do balanceador de carga de aplicativo externo. Os clientes, como microsserviços que residem na rede da nuvem privada virtual (VPC), usam um balanceador de carga de aplicativo interno para acessá-los.
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, as manipula 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. Para mais informações sobre quando usar um gateway, consulte Tráfego de entrada para sua malha.
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 de aplicativo externo e um balanceador de carga de aplicativo interno é roteado para o gateway e, em seguida,
para os três serviços.
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.
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, é possível usar o console do Google Cloud (para alguns recursos e configurações), a Google Cloud CLI, 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 e a verificação de integridade do Google para equilibrar o tráfego de maneira ideal com base no local do cliente e do back-end, proximidade do back-end, integridade e capacidade. Você melhora a disponibilidade do serviço fazendo o failover do tráfego automaticamente para back-ends íntegros com capacidade. É possível personalizar o balanceamento de carga para distribuir o tráfego e atender às suas necessidades de negócios.
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 centralmente na Observabilidade 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.
VPC Service Controls
É possível usar o VPC Service Controls para fornecer segurança adicional aos recursos e serviços do seu aplicativo. É possível adicionar projetos a perímetros de serviço que protejam recursos e serviços (como o Traffic Director) de solicitações originadas fora do perímetro. Para saber mais sobre o VPC Service Controls, consulte a visão geral sobre ele.
Para saber mais sobre como usar o Traffic Director com VPC Service Controls, consulte a página Produtos compatíveis.
A seguir
Para implantar o Traffic Director:
- Para o Compute Engine com VMs, use as APIs de roteamento de serviço.
- Para o Google Kubernetes Engine com pods, use as APIs de gateway.
Para encontrar casos de uso e padrões de arquitetura para serviços do gRPC sem proxy, consulte a Visão geral dos serviços do gRPC sem proxy.
Para saber como o gerenciamento de tráfego fornece controle sobre como o tráfego é tratado, consulte a Visão geral do gerenciamento de tráfego avançado.
Para saber como o Traffic Director é compatível com ambientes que se estendem além do Google Cloud, consulte os seguintes documentos:
- Integração do Traffic Director com o Diretório de serviços
- Traffic Director com grupos de endpoints de rede de conectividade híbrida (somente APIs legadas)
- Traffic Director com grupos de endpoints de rede da Internet (somente APIs legadas)