Visão geral da rede de serviços

A rede de serviços é a publicação de aplicativos de uma forma que resume a propriedade, a implementação ou o ambiente subjacente do aplicativo que está sendo consumido pelos clientes. Em sua forma mais simples, um Serviço é um endpoint seguro, consistente e disponível por meio do qual um aplicativo é acessado.

Nesta página, descrevemos as maneiras de implantar serviços no Google Kubernetes Engine (GKE). Clientes e aplicativos têm diversas necessidades sobre como eles podem e precisam se comunicar. Pode ser algo simples, como expor seu aplicativo no cluster do Kubernetes para consumo de pods, ou tão complicado quanto direcionar o tráfego para clientes de clientes da Internet em todo o mundo. O GKE fornece várias maneiras de expor aplicativos como serviços que se adaptam aos casos de uso exclusivos. Use esta página como um guia para entender melhor os atributos da rede de serviços e os recursos nativos da rede de serviço que existem no GKE.

Elementos de um serviço

A exposição de um aplicativo aos clientes envolve três elementos principais de um Service:

  • Front-end: o front-end do balanceador de carga define o escopo em que os clientes podem acessar e enviar tráfego para o balanceador de carga. Esse é o local de rede que está detectando tráfego. Ela tem uma rede, uma região específica (ou uma sub-rede dentro da rede), um ou mais IPs na rede, portas, protocolos específicos e certificados TLS apresentados para estabelecer conexões seguras.

  • Roteamento e balanceamento de carga: o roteamento e o balanceamento de carga definem como você processa e encaminha seu tráfego. É possível rotear o tráfego para Serviços com base em parâmetros como protocolos, cabeçalhos HTTP e caminhos HTTP. Dependendo do balanceador de carga que você usa, ele pode equilibrar o tráfego em várias zonas ou regiões para fornecer menor latência e aumentar a resiliência aos clientes.

  • Back-ends: os back-ends do balanceador de carga são definidos pelo tipo de endpoints, plataforma de aplicativos e integração de descoberta de serviços de back-end. O GKE usa a integração da descoberta de serviços para atualizar dinamicamente os back-ends do balanceador de carga conforme os endpoints do GKE são criados e desativados.

O diagrama a seguir ilustra esses conceitos para fluxos de tráfego interno e externo no Google Cloud:

Os balanceadores de carga externos localizados ao redor do mundo conectam clientes externos dispersos geograficamente a back-ends de aplicativos na sua rede VPC no Google Cloud. Os clientes internos na sua rede VPC se conectam a back-ends de aplicativos por meio de um balanceador de carga interno

Neste diagrama, o balanceador de carga HTTP(S) externo está detectando tráfego na Internet pública por meio de centenas de pontos de presença do Google em todo o mundo. Esse front-end global permite que o tráfego seja encerrado na extremidade, próximo aos clientes, antes de balancear a carga de tráfego para os back-ends em um data center do Google.

O balanceador de carga HTTP(S) interno detecta o escopo da rede VPC, permitindo que as comunicações particulares sejam realizadas internamente. Essas propriedades do balanceador de carga as tornam adequadas para diferentes tipos de casos de uso do aplicativo.

Noções básicas sobre balanceamento de carga do GKE

Para expor aplicativos fora de um cluster do GKE, o GKE fornece um controlador GKE Ingress e um controlador de serviço do GKE integrados que implantam. Balanceadores de carga do Google Cloud em nome dos usuários do GKE. Isso é o mesmo que a infraestrutura de balanceamento de carga da VM, mas o ciclo de vida é totalmente automatizado e controlado pelo GKE. Os controladores de rede do GKE fornecem balanceamento de carga do IP nativo de contêiner usando interfaces opostas e de nível superior que estão em conformidade com os padrões da API Ingress e Service.

O diagrama a seguir ilustra como os controladores de rede do GKE automatizam a criação de balanceadores de carga:

Como os controladores de rede do GKE automatizam a criação de balanceadores de carga

Conforme mostrado no diagrama, um administrador de infraestrutura ou aplicativo implanta um manifesto declarativo no cluster do GKE. Os controladores de entrada e serviços observam os recursos de rede do GKE, como objetos Ingress ou MultiClusterIngress, e implantam balanceadores de carga do Google Cloud ( Endereços IP, regras de firewall e outros) com base no manifesto. O controlador continua gerenciando o balanceador de carga e os back-ends com base em alterações ambientais e de tráfego. Por isso, o balanceamento de carga do GKE se torna um balanceador de carga dinâmico e autossuficiente com uma interface simples e voltada para o desenvolvedor.

Como escolher o método para expor seu aplicativo

Quando você escolhe um método para expor seu aplicativo no GKE, a rede cliente, o protocolo e a região do aplicativo são os principais fatores a serem considerados. Com o conjunto de controladores nativos e de entrada do GKE, você pode expor seus aplicativos com cada um desses fatores em mente.

As seções a seguir não abrangem todos os aspectos da rede de aplicativos, mas trabalhar em todos os fatores a seguir pode ajudar você a determinar quais são as melhores soluções para seus aplicativos. A maioria dos ambientes do GKE hospeda muitos tipos diferentes de aplicativos, todos com requisitos exclusivos. Dessa maneira, é provável que você use mais de um em qualquer cluster.

Para ver uma comparação detalhada de todos os recursos do GKE e do Anthos Ingress, consulte Recursos de entrada.

Rede de clientes

Uma rede cliente refere-se à rede em que os clientes do aplicativo acessam o aplicativo. Isso influencia a detecção do front-end do seu balanceador de carga. Por exemplo, os clientes podem estar no mesmo cluster do GKE do aplicativo. Nesse caso, ele acessa seu aplicativo dentro da rede do cluster, permitindo que ele usa o balanceamento de carga ClusterIP nativo do Kubernetes. Os clientes também podem ser clientes de rede internos, acessando seu aplicativo na nuvem privada virtual (VPC) do Google Cloud ou na rede local em um Cloud Interconnect. Os clientes também podem ser externos, acessando seu aplicativo em toda a Internet pública. Cada tipo de rede determina uma topologia de balanceamento de carga diferente.

No GKE, é possível escolher entre balanceadores de carga internos e externos. Interno refere-se à rede VPC que é uma rede privada interna que não pode ser acessada diretamente da Internet. Externo refere-se à Internet pública. Os serviços ClusterIP são internos para um único cluster do GKE, por isso têm escopo para uma rede ainda menor que a rede VPC.

A tabela a seguir fornece uma visão geral de quais soluções estão disponíveis para redes internas e externas.

Tipo de rede Soluções disponíveis
Interna Serviço de ClusterIP
Serviço NodePort
Serviço LoadBalancer interno
Entrada interna
Externa Serviço NodePort1
Serviço LoadBalancer externo
Entrada externa
Entrada em vários clusters

1Os clusters públicos do GKE fornecem IPs públicos e privados para cada nó do GKE, para que os serviços NodePort possam ser acessados interna e externamente.

Protocolo

Um protocolo é a linguagem que seus clientes falam com o aplicativo. Aplicativos de voz, jogos e de baixa latência geralmente usam TCP ou UDP diretamente, exigindo balanceadores de carga que têm controle granular na camada 4. Outros aplicativos falam HTTP, HTTPS, gRPC ou HTTP2 e exigem balanceadores de carga com suporte explícito a esses protocolos. Os requisitos de protocolo definem ainda mais os tipos de método de exposição de aplicativos mais adequados.

No GKE, é possível configurar os balanceadores de carga da camada 4, que encaminham o tráfego com base em informações de rede, como porta e protocolo, e balanceadores de carga da camada 7, que têm informações sobre o aplicativo, como sessões de clientes. Cada balanceador de carga diferente é fornecido com suporte a protocolo específico, como mostrado na tabela a seguir:

Camadas Protocolos Soluções disponíveis
L4 'TCP'
'UDP'
Serviço de ClusterIP
Serviço NodePort
Serviço LoadBalancer interno
Serviço LoadBalancer externo
;
L7 HTTP
HTTPS
HTTP2
Entrada interna
Entrada externa
Entrada de vários clusters

Regionalidade do aplicativo

A regionalidade do aplicativo se refere ao grau de distribuição do aplicativo em mais de uma região do Google Cloud ou um cluster do GKE. Hospedar uma única instância de um aplicativo tem requisitos diferentes dos que hospeda instâncias redundantes de um aplicativo em dois clusters independentes do GKE. Hospedar um aplicativo distribuído geograficamente em cinco clusters do GKE para colocar cargas de trabalho mais próximas do usuário final para reduzir a latência exige ainda mais reconhecimento de vários clusters e multirregional para o balanceador de carga.

É possível dividir a regionalidade das soluções de balanceamento de carga do GKE em duas áreas:

  • Escopo do back-end (ou escopo do cluster): indica se um balanceador de carga pode enviar tráfego para back-ends em vários clusters do GKE. A entrada de vários clusters tem a capacidade de expor um único endereço IP virtual que direciona o tráfego para pods de clusters e regiões diferentes do Google Cloud.

  • Escopo de front-end: refere-se a um IP do balanceador de carga escutando em uma única região ou em várias regiões. Todos os balanceadores de carga externos ouvem na Internet, o que é inerentemente multirregional, mas alguns balanceadores de carga internos detectam somente uma região.

A tabela abaixo detalha as soluções de balanceamento de carga do GKE nessas duas dimensões.

Escopo de back-end
(escopo do cluster)
Soluções disponíveis
Cluster único Serviço de ClusterIP
Serviço NodePort
Serviço LoadBalancer interno
Serviço LoadBalancer externo
Entrada interna
Entrada externa
Vários clusters Entrada em vários clusters
Escopo do front-end Soluções disponíveis
Regional Serviço de ClusterIP
Entrada interna
Global Serviço de ClusterIP
Serviço NodePort
Serviço LoadBalancer interno
Serviço LoadBalancer externo
Entrada externa
Entrada em vários clusters

Outras soluções de exposição de aplicativos

As soluções acima não são as únicas disponíveis para expor aplicativos. As soluções a seguir também podem ser substituições ou complementos viáveis para os balanceadores de carga nativos do GKE.

Entrada no cluster

A Entrada no cluster se refere aos controladores de entrada de software que têm os proxies de entrada hospedados no próprio cluster do Kubernetes. Isso é diferente dos controladores de entrada do Google Cloud, que hospedam e gerenciam a infraestrutura de balanceamento de carga separadamente do cluster do Kubernetes. Essas soluções de terceiros costumam ser autoimplantadas e autogerenciadas pelo operador do cluster. istio-ingressgateway e nginx-ingress são dois exemplos de controladores de entrada no cluster de código aberto e muito usados.

Os controladores de entrada no cluster geralmente estão em conformidade com as especificações do Ingress do Kubernetes e fornecem recursos variados e facilidade de uso. As soluções de código aberto provavelmente exigirão um gerenciamento mais próximo e um nível superior de conhecimento técnico, mas podem atender às suas necessidades se fornecerem recursos específicos necessários para seus aplicativos. Além disso, há um vasto ecossistema de soluções empresariais de Entrada criadas em torno da comunidade de código aberto, que oferece recursos avançados e suporte empresarial.

Grupos de endpoints de rede (NEGs, na sigla em inglês) autônomos

Os controladores de entrada e serviço do GKE fornecem métodos automatizados, declarativos e nativos do Kubernetes para implantar o Cloud Load Balancing. Há também casos de uso válidos para implantar balanceadores de carga manualmente para back-ends do GKE. Por exemplo, é possível ter um controle direto e mais granular sobre o balanceador de carga ou o balanceamento de carga entre os back-ends de contêineres e VMs.

Os NEGs independentes oferecem essa capacidade atualizando os IPs de back-end do pod dinamicamente para um NEG, mas permitem que o front-end do balanceador de carga seja implantado manualmente por meio da API Google Cloud. Isso proporciona controle máximo e direto do balanceador de carga enquanto mantém os back-ends dinâmicos controlados pelo cluster do GKE.

Malha de serviço

As malhas de serviço fornecem balanceamento de carga do lado do cliente por meio de um plano de controle centralizado. O Traffic Director e o Anthos Service Mesh potencializam o balanceamento de carga do tráfego interno entre clusters do GKE, entre regiões e também entre contêineres e VMs. para criar um anexo da VLAN de monitoramento. Isso desfoca a linha entre o balanceamento de carga interno (tráfego leste-oeste) e a exposição do aplicativo (tráfego norte-sul). Com a flexibilidade e o alcance dos planos de controle da malha de serviço modernos, é mais provável do que nunca ter o cliente e o servidor no mesmo escopo de malha de serviço. As soluções de Entrada e Serviço do GKE acima implantam balanceadores de carga do proxy intermediário para clientes que não têm proxies próprios de arquivo secundário. No entanto, se um cliente e um servidor estiverem na mesma malha, é possível processar a exposição tradicional de aplicativos por meio da malha, em vez de usar o balanceamento de carga do proxy intermediário.

A seguir