Esta página descreve como pode implementar serviços no Google Kubernetes Engine (GKE). Use esta página como um guia para compreender melhor as facetas da rede de serviços e as funcionalidades da rede de serviços existentes no GKE.
Vista geral da rede de serviços
A rede de serviços é a publicação de aplicações de uma forma que abstrai a propriedade, a implementação ou o ambiente subjacente da aplicação que está a ser consumida pelos clientes. Na sua forma mais simples, um serviço é um ponto final seguro, consistente e disponível através do qual se acede a uma aplicação.
Os clientes e as aplicações têm necessidades diversas relativamente à forma como podem e devem comunicar. Pode ser tão simples como expor a sua aplicação no cluster do Kubernetes para que os pods a consumam ou tão complicado como encaminhar tráfego para a sua aplicação a partir de clientes da Internet em todo o mundo. O GKE oferece muitas formas de expor aplicações como serviços que se adequam aos seus exemplos de utilização únicos.
Elementos de um serviço
A exposição de uma aplicação aos clientes envolve três elementos principais de um serviço:
Front-end: o front-end do balanceador de carga define o âmbito no qual os clientes podem aceder e enviar tráfego para o balanceador de carga. Esta é a localização de rede que está a escutar o tráfego. Tem uma rede, uma região específica (ou uma sub-rede na rede), um ou mais IPs na rede, portas, protocolos específicos e certificados TLS apresentados para estabelecer ligações seguras.
Encaminhamento e balanceamento de carga: o encaminhamento e o balanceamento de carga definem como processa e encaminha o seu tráfego. Pode encaminhar o tráfego para serviços com base em parâmetros como protocolos, cabeçalhos HTTP e caminhos HTTP. Consoante o balanceador de carga que usar, este pode equilibrar o tráfego para oferecer uma latência mais baixa e uma maior resiliência aos seus clientes.
Back-ends: os back-ends do balanceador de carga são definidos pelo tipo de pontos finais, plataforma de aplicação e integração de deteção de serviços de back-end. O GKE usa a integração da deteção de serviços para atualizar dinamicamente os back-ends do equilibrador de carga à medida que os pontos finais do GKE são ativados e desativados.
O diagrama seguinte ilustra estes conceitos para tráfego interno e externo:
Neste diagrama, o balanceador de carga de aplicações externo está a ouvir o tráfego na Internet pública através de centenas de pontos de presença da Google em todo o mundo. Este front-end global permite que o tráfego seja terminado no limite, perto dos clientes, antes de equilibrar a carga do tráfego para os respetivos back-ends num centro de dados da Google.
O Application Load Balancer interno escuta no âmbito da sua rede VPC, o que permite que as comunicações privadas ocorram internamente. Estas propriedades do equilibrador de carga tornam-nos adequados para diferentes tipos de exemplos de utilização de aplicações.
Compreender o balanceamento de carga do GKE
Para expor aplicações fora de um cluster do GKE, o GKE fornece um controlador de entrada do GKE incorporado e um controlador de serviços do GKE que implementam equilibradores de carga em nome dos utilizadores do GKE. Isto é igual à infraestrutura de equilíbrio de carga de VMs, exceto que o respetivo ciclo de vida é totalmente automatizado e controlado pelo GKE. Os controladores de rede do GKE fornecem o balanceamento de carga de IP de pods nativos de contentores através de interfaces de nível superior com opiniões que estão em conformidade com as normas da API Ingress e Service.
O diagrama seguinte ilustra como os controladores de rede do GKE automatizam a criação de balanceadores de carga:
Conforme apresentado no diagrama, um administrador de infraestrutura ou de apps implementa um manifesto declarativo no respetivo cluster do GKE. Os controladores de entrada e serviço monitorizam os recursos de rede do GKE (como objetos Ingress) e implementam equilibradores de carga (além do endereçamento IP, regras de firewall, etc.) com base no manifesto.
O controlador continua a gerir o balanceador de carga e os back-ends com base nas alterações ambientais e de tráfego. Por este motivo, o equilíbrio de carga do GKE torna-se um equilibrador de carga dinâmico e autónomo com uma interface orientada para programadores.
Escolher o método para expor a sua aplicação
Quando escolhe um método para expor a sua aplicação no GKE, os fatores principais a ter em conta são a rede de clientes, o protocolo e a regionalidade da aplicação. Com o conjunto de controladores Ingress e Service do GKE, pode expor as suas aplicações tendo em conta cada um destes fatores.
Embora as secções seguintes não abordem todos os aspetos da rede de aplicações, trabalhar em cada um dos seguintes fatores pode ajudar a determinar que soluções são mais adequadas para as suas aplicações. A maioria dos ambientes do GKE aloja muitos tipos diferentes de aplicações, todos com requisitos únicos, pelo que é provável que use mais do que um em qualquer cluster.
Para uma comparação detalhada das capacidades de entrada, consulte o artigo Configuração de entrada.
Rede de cliente
Uma rede de clientes refere-se à rede a partir da qual os clientes da sua aplicação estão a aceder à aplicação. Isto influencia o local onde o front-end do equilibrador de carga deve estar a ouvir. Por exemplo, os clientes podem estar no mesmo cluster do GKE que a aplicação. Neste caso, estariam a aceder à sua aplicação a partir da rede do cluster, o que lhes permitiria usar o equilíbrio de carga ClusterIP nativo do Kubernetes.
Os clientes também podem ser clientes de rede interna que acedem à sua aplicação a partir da nuvem virtual privada (VPC) ou de uma rede no local através de um Cloud Interconnect.
Os clientes também podem ser externos e aceder à sua aplicação através da Internet pública. Cada tipo de rede determina uma topologia de equilíbrio de carga diferente.
No GKE, pode escolher entre balanceadores de carga internos e externos. Interno refere-se à rede da VPC, que é uma rede privada interna não acessível diretamente a partir da Internet. Externo refere-se à Internet pública. Os serviços ClusterIP são internos a um único cluster do GKE, pelo que têm um âmbito ainda mais restrito do que a rede VPC.
A tabela seguinte oferece uma vista geral das soluções disponíveis para redes internas e externas.
| Tipo de rede | Soluções disponíveis |
|---|---|
| Internos |
Serviço ClusterIP
Serviço NodePort Serviço de balanceador de carga interno Ingress interno |
| Externo |
Serviço NodePort1
Serviço LoadBalancer externo Ingress externo Ingress de vários clusters |
1 Os clusters do GKE que usam a flag --no-enable-private-nodes
podem ter nós com endereços IP públicos e privados e, por isso, os serviços NodePort podem ser acessíveis interna e externamente.
Protocolo
Um protocolo é a linguagem que os seus clientes usam para comunicar com a aplicação. As aplicações de voz, jogos e baixa latência usam normalmente TCP ou UDP diretamente, o que requer balanceadores de carga com controlo detalhado na camada 4. Outras aplicações comunicam em HTTP, HTTPS, gRPC ou HTTP2 e requerem balanceadores de carga com suporte explícito destes protocolos. Os requisitos de protocolo definem ainda mais que tipos de métodos de exposição de aplicações são mais adequados.
No GKE, pode configurar equilibradores de carga da camada 4, que encaminham o tráfego com base em informações de rede, como a porta e o protocolo, e equilibradores de carga da camada 7, que têm conhecimento das informações da aplicação, como as sessões de cliente. Cada equilibrador de carga diferente inclui suporte de protocolo específico, conforme mostrado na tabela seguinte:
| Camadas | Protocolos | Soluções disponíveis |
|---|---|---|
| L4 | TCP UDP |
Serviço ClusterIP
Serviço NodePort Serviço de balanceamento de carga interno Serviço de balanceamento de carga externo |
| L7 |
HTTP
HTTPS HTTP2 |
Entrada interna
Entrada externa Entrada em vários clusters |
Regionalidade da aplicação
A regionalidade da aplicação refere-se ao grau em que a sua aplicação é distribuída por mais do que uma região ou um cluster do GKE. A alojamento de uma única instância de uma aplicação tem requisitos diferentes do alojamento de instâncias redundantes de uma aplicação em dois clusters do GKE independentes. A alojamento de uma aplicação distribuída geograficamente em cinco clusters do GKE para colocar cargas de trabalho mais perto do utilizador final para uma latência mais baixa requer ainda mais reconhecimento de vários clusters e várias regiões para o equilibrador de carga.
Pode dividir a regionalidade das soluções de balanceamento de carga do GKE em duas áreas:
Âmbito do back-end (ou âmbito do cluster): este âmbito refere-se à possibilidade de um balanceador de carga enviar tráfego para back-ends em vários clusters do GKE. A entrada em vários clusters tem a capacidade de expor um único endereço IP virtual que direciona o tráfego para pods de diferentes clusters e regiões.
Âmbito do front-end: este âmbito refere-se ao facto de um IP do balanceador de carga ouvir dentro de uma única região ou em várias regiões. Todos os balanceadores de carga externos ouvem na Internet, que é inerentemente multirregional, mas alguns balanceadores de carga internos ouvem apenas numa única região.
A tabela seguinte detalha as soluções de equilíbrio de carga do GKE nestas duas dimensões.
| Âmbito do back-end (âmbito do cluster) |
Soluções disponíveis |
|---|---|
| Cluster único |
Serviço ClusterIP
Serviço NodePort Serviço de balanceador de carga interno Serviço de balanceador de carga externo Ingress interno Ingress externo |
| Vários clusters | Entrada em vários clusters |
| Âmbito da interface | Soluções disponíveis |
|---|---|
| Regional |
Serviço ClusterIP
Entrada interna |
| Global |
Serviço ClusterIP
Serviço NodePort Serviço de balanceamento de carga interno Serviço de balanceamento de carga externo Ingress externo Ingress de vários clusters |
Outras soluções para a exposição da aplicação
As soluções anteriores não são as únicas disponíveis para expor aplicações. As seguintes soluções também podem ser substituições ou complementos viáveis para os balanceadores de carga do GKE.
Entrada no cluster
A entrada no cluster refere-se a controladores de entrada de software que têm os respetivos proxies de entrada alojados no próprio cluster do Kubernetes. Isto é diferente dos controladores de entrada do GKE, que alojam e gerem a respetiva infraestrutura de equilíbrio de carga separadamente do cluster do Kubernetes. Estas soluções de terceiros são normalmente implementadas e geridas autonomamente pelo operador do cluster. O istio-ingressgateway e o nginx-ingress são dois exemplos de controladores de entrada no cluster usados frequentemente e de código aberto.
Normalmente, os controladores de entrada no cluster estão em conformidade com a especificação de entrada do Kubernetes e oferecem capacidades e facilidade de utilização variáveis. As soluções de código aberto requerem provavelmente uma gestão mais atenta e um nível mais elevado de conhecimentos técnicos, mas podem adequar-se às suas necessidades se oferecerem funcionalidades específicas que as suas aplicações requerem. Também existe um vasto ecossistema de soluções de entrada empresariais criadas em torno da comunidade de código aberto que oferecem funcionalidades avançadas e apoio técnico empresarial.
Grupos de pontos finais da rede (NEGs) autónomos
Os controladores GKE Ingress e Service oferecem métodos automatizados, declarativos e nativos do Kubernetes para implementar o Cloud Load Balancing. Também existem exemplos de utilização válidos para implementar equilibradores de carga manualmente para back-ends do GKE, por exemplo, ter um controlo direto e mais detalhado sobre o equilibrador de carga ou o equilíbrio de carga entre back-ends de contentores e VMs.
Os NEGs autónomos oferecem esta capacidade atualizando dinamicamente os IPs de back-end do pod para um NEG, mas permitem que o front-end do equilibrador de carga seja implementado manualmente. Isto oferece o controlo máximo e direto do equilibrador de carga, ao mesmo tempo que retém os back-ends dinâmicos controlados pelo cluster do GKE.
Malha de serviço
As malhas de serviço oferecem balanceamento de carga por parte do cliente através de um plano de controlo centralizado. O Cloud Service Mesh e o Cloud Service Mesh permitem equilibrar a carga do tráfego interno em clusters do GKE, em regiões e também entre contentores e VMs. Isto esbate a linha entre o balanceamento de carga interno (tráfego leste-oeste) e a exposição da aplicação (tráfego norte-sul). Com a flexibilidade e o alcance dos planos de controlo de malha de serviços modernos, é mais provável do que nunca ter o cliente e o servidor no mesmo âmbito da malha de serviços. Geralmente, as soluções de entrada e serviço do GKE anteriores implementam equilibradores de carga de proxy intermédios para clientes que não têm os seus próprios proxies sidecar. No entanto, se um cliente e um servidor estiverem na mesma malha, a exposição da aplicação pode ser processada através da malha em vez do equilíbrio de carga do proxy intermédio.
O que se segue?
- Saiba mais sobre as funcionalidades do Ingress.
- Saiba mais sobre o Ingress externo.
- Saiba mais sobre o Ingress interno.
- Use serviços LoadBalancer externos.
- Use serviços LoadBalancer internos.