Visão geral da rede de serviços

Nesta página, descrevemos como implantar serviços no Google Kubernetes Engine (GKE). Use esta página como um guia para entender melhor os atributos da rede de serviços e os recursos da rede de serviço que existem no GKE.

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.

Clientes e aplicativos têm diversas necessidades sobre como eles podem e precisam se comunicar. Pode ser algo simples, como expor o aplicativo no cluster do Kubernetes para consumo de pods, ou complicado como direcionar o tráfego para o aplicativo 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.

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 balancear o tráfego para fornecer menor latência e maior resiliência aos seus 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 o tráfego interno e externo:

Neste diagrama, o balanceador de carga de aplicativo 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 de aplicativo 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 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:

Conforme mostrado no diagrama, um administrador de infraestrutura ou aplicativo implanta um manifesto declarativo no cluster do GKE. Os controladores de entrada e serviço observam os recursos de rede do GKE (como objetos Entrada) e implantam balanceadores de carga (além de endereçamento IP, regras de firewall etc.) 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 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 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 uma comparação detalhada dos recursos de Entrada, consulte a Configuração do Ingress.

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 use o balanceamento de carga ClusterIP nativo do Kubernetes.

Os clientes também podem ser clientes de rede interna, que acessam seu aplicativo de dentro da nuvem privada virtual (VPC) ou de uma 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
Interno Serviço ClusterIP
Serviço NodePort
Serviço interno LoadBalancer
Entrada interna
Externo Serviço NodePort1
Serviço externo LoadBalancer
Entrada externa
Ingress de vários clusters

1Os clusters públicos do GKE fornecem endereços 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 ClusterIP
Serviço NodePort
Serviço interno LoadBalancer
Serviço externo LoadBalancer
L7 HTTP
HTTPS
HTTP2 		Entrada interna
Entrada externa
Ingress 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 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 ingress 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.

  • 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 a seguir 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 ClusterIP
Serviço NodePort
Serviço interno LoadBalancer
Serviço externo LoadBalancer
Entrada interna
Entrada externa
Vários clusters Entrada de vários clusters
Escopo do front-end Soluções disponíveis
Regional Serviço ClusterIP
Entrada interna
Global Serviço ClusterIP
Serviço NodePort
Serviço interno LoadBalancer
Serviço externo LoadBalancer
Entrada externa
Ingress de vários clusters

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

As soluções anteriores não são as únicas disponíveis para expor aplicativos. As soluções a seguir também podem ser substituições viáveis ou complementos para balanceadores de carga 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 GKE, 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 autônomos fornecem esse recurso 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. 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 Cloud Service Mesh e o Cloud Service Mesh potencializam a capacidade de balancear a carga do tráfego interno em clusters do GKE, em regiões e também entre contêineres e VMs. 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 anteriores do GKE geralmente implantam balanceadores de carga de proxy intermediário para clientes que não têm proxies de arquivos secundários próprios. No entanto, se um cliente e um servidor estiverem na mesma malha, é possível processar a exposição de aplicativos por meio da malha, em vez de usar o balanceamento de carga do proxy intermediário.

A seguir