Este documento descreve o modelo de rede usado pelo Google Kubernetes Engine (GKE) e como pode diferir dos modelos de rede noutros ambientes do Kubernetes. Este documento aborda os seguintes conceitos:
- Os modelos de rede mais comuns usados por várias implementações do Kubernetes.
- Os mecanismos de endereçamento IP dos modelos de rede mais comuns.
- As vantagens e as desvantagens que cada modelo de rede oferece.
- Uma descrição detalhada do modelo de rede predefinido que o GKE usa.
Este documento destina-se a arquitetos de nuvem, engenheiros de operações e engenheiros de rede que possam estar familiarizados com outras implementações do Kubernetes e que planeiam usar o GKE. Este documento pressupõe que tem conhecimentos sobre Kubernetes e o respetivo modelo de rede básico. Também deve estar familiarizado com conceitos de redes, como o endereçamento IP, a tradução de endereços de rede (NAT), as firewalls e os proxies.
Este documento não aborda como modificar o modelo de rede do GKE predefinido para cumprir várias restrições de endereços IP. Se tiver uma escassez de endereços IP ao migrar para o GKE, consulte o artigo Estratégias de gestão de endereços IP ao migrar para o GKE.
Implementações típicas de modelos de rede
Pode implementar o modelo de rede do Kubernetes de várias formas. No entanto, qualquer implementação tem sempre de cumprir os seguintes requisitos:
- Cada Pod precisa de um endereço IP único.
- Os pods podem comunicar com outros pods em todos os nós sem usar NAT.
- Os agentes num nó, como o
kubelet, podem comunicar com todos os pods nesse nó. - Os pods na rede anfitriã de um nó podem comunicar com todos os pods em todos os nós sem usar NAT.
Foram desenvolvidas mais de 20 implementações diferentes para o modelo de rede do Kubernetes que cumprem estes requisitos.
Estas implementações podem ser agrupadas em três tipos de modelos de rede. Estes três modelos diferem nos seguintes aspetos:
- Como os pods podem comunicar com serviços não pertencentes ao Kubernetes na rede corporativa.
- Como os pods podem comunicar com outros clusters do Kubernetes na mesma organização.
- Indica se é necessário NAT para a comunicação fora do cluster.
- Se os endereços IP dos pods podem ser reutilizados noutros clusters ou noutro local na rede empresarial.
Cada fornecedor de nuvem implementou um ou mais destes tipos de modelos.
A tabela seguinte identifica os três tipos de modelos usados frequentemente e em que implementação do Kubernetes são usados:
| Nome do modelo de rede | Usados nestas implementações |
|---|---|
| Totalmente integrado ou plano |
|
| Modo isolado ou com ligação |
|
| Isolado ou com lacuna de ar |
|
Quando este documento descreve estes modelos de rede, refere-se aos respetivos efeitos nas redes no local ligadas. No entanto, pode aplicar os conceitos descritos para redes no local ligadas a redes que estão ligadas através de uma rede privada virtual (VPN) ou através de uma interligação privada, incluindo ligações a outros fornecedores de nuvem. Para o GKE, estas ligações incluem toda a conetividade através do Cloud VPN ou do Cloud Interconnect.
Modelo de rede totalmente integrado
O modelo de rede totalmente integrado (ou simples) oferece facilidade de comunicações com aplicações fora do Kubernetes e noutros clusters do Kubernetes. Os principais fornecedores de serviços na nuvem implementam normalmente este modelo porque podem integrar estreitamente a respetiva implementação do Kubernetes com a respetiva rede definida por software (SDN).
Quando usa o modelo totalmente integrado, os endereços IP que usa para os pods são encaminhados na rede em que o cluster do Kubernetes está localizado. Além disso, a rede subjacente sabe em que nó se encontram os endereços IP dos pods. Em muitas implementações, os endereços IP dos pods no mesmo nó pertencem a um intervalo de endereços IP dos pods específico e pré-atribuído. No entanto, este intervalo de endereços pré-atribuído não é um requisito.
O diagrama seguinte mostra as opções de comunicação do Pod no modelo de rede totalmente integrado:
O diagrama anterior de um modelo de rede totalmente integrado mostra os seguintes padrões de comunicação:
- Os pods num cluster do Kubernetes podem comunicar diretamente entre si.
- Os pods podem comunicar com outros pods noutros clusters, desde que esses clusters estejam na mesma rede.
- Os pods não precisam de NAT para comunicar com outras aplicações fora do cluster, independentemente de essas aplicações estarem na mesma rede ou em redes interligadas.
O diagrama também mostra que os intervalos de endereços IP dos pods são distintos entre diferentes clusters.
Disponibilidade
O modelo de rede totalmente integrado está disponível nas seguintes implementações:
- Por predefinição, o GKE implementa este modelo. Para mais informações sobre esta implementação, consulte o modelo de rede do GKE mais adiante neste documento.
- Por predefinição, o Amazon EKS implementa este modelo. Nesta implementação, o Amazon EKS usa o plug-in da interface de rede de contentores (CNI) da Amazon VPC para o Kubernetes para atribuir endereços IP de pods diretamente do espaço de endereços da VPC. O plug-in CNI atribui endereços IP a partir da sub-rede predefinida na qual os nós se encontram ou a partir de uma sub-rede personalizada. Os endereços IP dos pods não provêm de um intervalo de endereços IP dos pods dedicado por nó.
- No Azure, o AKS implementa este modelo quando usa o Azure CNI (redes avançadas). Esta implementação não é a configuração predefinida. Nesta implementação, cada Pod recebe um endereço IP da sub-rede. Também pode configurar o número máximo de agrupamentos por nó. Assim, o número de endereços IP reservados antecipadamente para agrupamentos nesse nó é igual ao número máximo de agrupamentos por nó.
Vantagens
A utilização de um modelo de rede totalmente integrado oferece as seguintes vantagens:
- Melhores dados de telemetria. Os endereços IP dos pods estão visíveis em toda a rede. Esta visibilidade torna os dados de telemetria mais úteis do que noutros modelos, porque é possível identificar os pods mesmo a partir de dados de telemetria recolhidos fora do cluster.
- Configuração da firewall mais fácil. Ao definir regras de firewall, é mais fácil distinguir o tráfego de nós e pods no modelo de rede totalmente integrado do que nos outros modelos.
- Melhor compatibilidade. Os pods podem comunicar através de protocolos que não suportam NAT.
- Melhor depuração. Se a firewall o permitir, os recursos fora do cluster podem alcançar os pods diretamente durante o processo de depuração.
- Compatibilidade com malhas de serviços. As malhas de serviço, como o Istio ou o Cloud Service Mesh, podem comunicar facilmente entre clusters porque os pods podem comunicar diretamente entre si. Algumas implementações de malha de serviços só suportam a conetividade de pod para pod para malhas de serviços em vários clusters.
Desvantagens
A utilização de um modelo de rede totalmente integrado tem as seguintes desvantagens:
- Utilização do endereço IP. Não pode reutilizar endereços IP de agrupamentos na rede, e cada endereço IP tem de ser exclusivo. Estes requisitos podem resultar num grande número de endereços IP que têm de ser reservados para os pods.
- Requisitos de SDN. Um modelo de rede totalmente integrado requer uma integração profunda com a rede subjacente, porque a implementação do Kubernetes tem de programar diretamente a SDN. A programação da SDN é transparente para o utilizador e não produz desvantagens visíveis para o utilizador. No entanto, estes modelos de rede profundamente integrados não podem ser implementados facilmente em ambientes autogeridos no local.
Modelo de rede no modo isolado
O modelo de rede no modo isolado (ou em ponte) é usado frequentemente para implementações do Kubernetes no local, onde não é possível uma integração profunda com a rede subjacente. Quando usa um modelo de rede no modo isolado, os pods num cluster do Kubernetes podem comunicar com recursos fora do cluster através de algum tipo de gateway ou proxy.
O diagrama seguinte mostra as opções de comunicação do Pod num modelo de rede no modo isolado:
O diagrama anterior de um modelo de rede no modo isolado mostra como os pods num cluster do Kubernetes podem comunicar diretamente entre si. O diagrama também mostra que os agrupamentos num cluster têm de usar um gateway ou um proxy quando comunicam com aplicações fora do cluster ou agrupamentos noutros clusters. Embora a comunicação entre um cluster e uma aplicação externa requeira um único gateway, a comunicação entre clusters requer dois gateways. O tráfego entre dois clusters passa por um gateway quando sai do primeiro cluster e por outro gateway quando entra no outro cluster.
Existem diferentes formas de implementar as gateways ou os proxies num modelo de rede isolado. As seguintes implementações são os dois gateways ou proxies mais comuns:
Usar os nós como gateways. Esta implementação é usada frequentemente quando os nós no cluster fazem parte da rede existente e os respetivos endereços IP são encaminháveis nativamente nesta rede. Neste caso, os próprios nós são as entradas que oferecem conetividade do interior do cluster para a rede maior. O tráfego de saída de um Pod para fora do cluster pode ser direcionado para outros clusters ou para aplicações não Kubernetes, por exemplo, para chamar uma API no local na rede empresarial. Para este tráfego de saída, o nó que contém o pod usa NAT de origem (SNAT) para mapear o endereço IP do pod para o endereço IP do nó. Para permitir que as aplicações que estão fora do cluster comuniquem com os serviços dentro do cluster, pode usar o tipo de serviço NodePort para a maioria das implementações. Em algumas implementações, pode usar o tipo de serviço LoadBalancer para expor serviços. Quando usa o tipo de serviço LoadBalancer, atribui a esses serviços um endereço IP virtual com equilíbrio de carga entre nós e encaminhado para um pod que faz parte do serviço.
O diagrama seguinte mostra o padrão de implementação quando usa nós como gateways:
O diagrama anterior mostra que a utilização de nós como gateways não tem um impacto na comunicação de pod para pod num cluster. Os pods num cluster continuam a comunicar diretamente entre si. No entanto, o diagrama também mostra os seguintes padrões de comunicação fora do cluster:
- Como os pods comunicam com outros clusters ou aplicações não pertencentes ao Kubernetes através do SNAT quando saem do nó.
- Como o tráfego proveniente de fora dos serviços noutros clusters ou aplicações não pertencentes ao Kubernetes entra no cluster através de um serviço NodePort antes de ser encaminhado para o Pod correto no cluster.
Usar máquinas virtuais (VMs) de proxy com várias interfaces de rede. Este padrão de implementação usa proxies para aceder à rede que contém o cluster do Kubernetes. Os proxies têm de ter acesso ao espaço de endereços IP do pod e do nó. Neste padrão, cada VM de proxy tem duas interfaces de rede: uma interface na rede empresarial maior e uma interface na rede que contém o cluster do Kubernetes.
O diagrama seguinte mostra o padrão de implementação quando usa VMs de proxy:
O diagrama anterior mostra que a utilização de proxies no modo de ilha não tem impacto na comunicação num cluster. Os pods num cluster continuam a poder comunicar entre si diretamente. No entanto, o diagrama também mostra como a comunicação dos pods para outros clusters ou aplicações não Kubernetes passa por um proxy que tem acesso à rede do cluster e à rede de destino. Além disso, a comunicação que entra no cluster a partir do exterior também passa pelo mesmo tipo de proxy.
Disponibilidade
O modelo de rede no modo isolado está disponível nas seguintes implementações:
- Por predefinição, o Azure Kubernetes Service (AKS) usa o trabalho em rede no modo de ilha quando usa o trabalho em rede Kubenet (básico). Quando o AKS usa redes no modo isolado, a rede virtual que contém o cluster inclui apenas endereços IP de nós. Os endereços IP dos pods não fazem parte da rede virtual. Em alternativa, os pods recebem endereços IP de um espaço lógico diferente. O modelo de modo isolado usado pelo AKS também encaminha o tráfego de pod para pod entre nós através de rotas definidas pelo utilizador com encaminhamento de IP ativado na interface dos nós. Para a comunicação do pod com recursos fora do cluster, o nó usa o SNAT para mapear o endereço IP do pod para o endereço IP do nó antes de o tráfego de saída sair do nó.
- No Oracle Container Engine for Kubernetes (OKE), a comunicação de pod para pod usa uma rede de sobreposição VXLAN. Além disso, o tráfego dos pods para aplicações fora do cluster usa o SNAT para mapear o endereço IP do pod para o endereço IP do nó.
Vantagens
A utilização de um modelo de rede no modo isolado tem as seguintes vantagens:
Utilização do endereço IP. Os endereços IP dos pods no cluster podem ser reutilizados noutros clusters. No entanto, os clusters nativos da VPC predefinidos do GKE não suportam a reutilização de intervalos de endereços IP de pods em clusters na mesma rede VPC. No GKE, os endereços IP dos pods são diretamente encaminháveis na sua rede VPC. Por conseguinte, os endereços IP dos pods têm de ser exclusivos em todos os clusters e recursos nessa única VPC. Se precisar de reutilizar endereços IP, implemente os seus clusters do GKE em redes VPC separadas. Independentemente do modelo de rede, os pods que precisam de comunicar com serviços externos na sua rede empresarial não podem usar endereços IP que esses serviços externos já usam. Para a rede no modo isolado, a prática recomendada é reservar um espaço de endereços IP de pods que seja exclusivo na sua rede empresarial e usar este espaço de endereços IP para todos os clusters que usam esta configuração no modo isolado.
Definições de segurança mais fáceis. Uma vez que os pods não estão diretamente expostos ao resto da rede empresarial, não precisa de proteger os pods contra o tráfego de entrada do resto da rede empresarial.
Desvantagens
A utilização de um modelo de rede no modo isolado tem as seguintes desvantagens:
- Telemetria imprecisa. Os dados de telemetria recolhidos fora do cluster contêm apenas o endereço IP do nó e não o endereço IP do pod. A falta de endereços IP de pods dificulta a identificação da origem e do destino do tráfego.
- Mais difícil de depurar. Quando depura, não pode estabelecer ligação diretamente aos pods a partir do exterior do cluster.
- Mais difícil de configurar firewalls. Só pode usar endereços IP de nós quando configura a sua firewall. Assim, as definições da firewall resultantes permitem que todos os pods num nó e o próprio nó alcancem serviços externos ou não permitem que nenhum deles alcance serviços externos.
Compatibilidade com malhas de serviços. Com o modo isolado, a comunicação direta Pod-to-Pod entre clusters em malhas de serviço, como o Istio ou o Cloud Service Mesh, não é possível.
Existem mais restrições com algumas implementações de malha de serviços. O suporte multi-cluster do Cloud Service Mesh para clusters do GKE no Google Cloud só suporta clusters na mesma rede. Para implementações do Istio que suportam um modelo de várias redes, a comunicação tem de ocorrer através de Istio Gateways, o que torna as implementações de malha de serviços de vários clusters mais complexas.
Modelo de rede isolado
O modelo de rede isolada (ou com lacuna de ar) é mais comummente usado para clusters que não precisam de acesso à rede corporativa maior, exceto através de APIs viradas para o público. Quando usa um modelo de rede isolado, cada cluster do Kubernetes está isolado e não pode usar endereços IP internos para comunicar com o resto da rede. O cluster está na sua própria rede privada. Se qualquer Pod no cluster precisar de comunicar com serviços fora do cluster, esta comunicação tem de usar endereços IP públicos para entrada e saída.
O diagrama seguinte mostra as opções de comunicação do pod num modelo de rede isolada:
O diagrama anterior de um modelo de rede isolado mostra que os pods num cluster do Kubernetes podem comunicar diretamente entre si. O diagrama também mostra que os pods não podem usar endereços IP internos para comunicar com pods noutros clusters. Além disso, os pods só podem comunicar com aplicações fora do cluster quando os seguintes critérios forem cumpridos:
- Existe um gateway de Internet que liga o cluster ao exterior.
- A aplicação externa usa um endereço IP externo para comunicações.
Por último, o diagrama mostra como o mesmo espaço de endereços IP para pods e nós pode ser reutilizado entre diferentes ambientes.
Disponibilidade
O modelo de rede isolada não é usado habitualmente por implementações do Kubernetes. No entanto, pode alcançar um modelo de rede isolado em qualquer implementação. Só tem de implementar um cluster do Kubernetes numa rede ou numa VPC separada sem qualquer ligação a outros serviços ou à rede empresarial. A implementação resultante teria as mesmas vantagens e desvantagens que o modelo de rede isolado.
Vantagens
A utilização de um modo de rede isolado tem as seguintes vantagens:
- Utilização do endereço IP. Pode reutilizar todos os endereços IP internos no cluster: endereços IP de nós, endereços IP de serviços e endereços IP de pods. A reutilização de endereços IP internos é possível porque cada cluster tem a sua própria rede privada e a comunicação com recursos fora do cluster só ocorre através de endereços IP públicos.
- Controlo. Os administradores do cluster têm controlo total sobre o endereçamento IP no cluster e não têm de realizar tarefas de gestão de endereços IP. Por exemplo, os administradores podem atribuir o espaço de endereços
10.0.0.0/8completo a pods e serviços no cluster, mesmo que estes endereços já sejam usados na organização. - Segurança. A comunicação fora do cluster é rigorosamente controlada e, quando permitida, usa interfaces externas bem definidas e NAT.
Desvantagens
A utilização de um modelo de rede isolado tem as seguintes desvantagens:
- Sem comunicação privada. A comunicação através de endereços IP internos não é permitida a outros clusters ou outros serviços na rede.
Modelo de rede do GKE
O GKE usa um modelo de rede totalmente integrado, onde os clusters são implementados numa rede de nuvem privada virtual (VPC) que também pode conter outras aplicações.
Recomendamos a utilização de um cluster nativo da VPC para o seu ambiente do GKE. Pode criar o seu cluster nativo de VPC no modo Standard ou Autopilot. Se escolher o modo Autopilot, o modo nativo da VPC está sempre ativado e não pode ser desativado. Os parágrafos seguintes descrevem o modelo de rede do GKE no modo Standard com notas sobre as diferenças do Autopilot.
Compreenda a gestão de endereços IP em clusters nativos de VPC
Quando usa um cluster nativo da VPC, os endereços IP dos pods são endereços IP secundários em cada nó. A cada nó é atribuída uma sub-rede específica de um intervalo de endereços IP do pod que seleciona no seu espaço de endereços IP internos quando cria o cluster. Por predefinição, um cluster nativo da VPC atribui
uma sub-rede /24
a cada nó para utilização como endereços IP de pods. Uma sub-rede /24 corresponde a 256 endereços IP. No Autopilot, o cluster usa uma sub-rede /26 que
corresponde a 64 endereços, e não pode alterar esta definição de sub-rede.
O modelo de rede do GKE não permite a reutilização de endereços IP na rede. Quando migra para o GKE, tem de planear a atribuição de endereços IP para reduzir a utilização de endereços IP internos no GKE.
Uma vez que os endereços IP dos pods são encaminháveis na rede VPC, por predefinição, os pods podem receber tráfego dos seguintes recursos:
- De outros serviços na rede VPC.
- De redes da VPC ligadas através do intercâmbio da rede da VPC.
- A partir de redes no local ligadas através do Cloud VPN ou do Cloud Interconnect.
Faça a gestão da comunicação de tráfego externo com o agente de ocultação de IP
Quando comunica a partir de Pods para serviços fora do cluster, o agente de mascaramento de IP determina como o tráfego aparece nesses serviços. O agente de mascaramento de IP processa os endereços IP privados e externos de forma diferente, conforme descrito nos seguintes pontos:
- Por predefinição, o agente de mascaramento de IP não mascara o tráfego para endereços IP internos, incluindo endereços IP RFC 1918 e endereços IP não RFC 1918 que são usados internamente com frequência. (Para mais informações, consulte a lista de destinos não mascarados predefinidos). Uma vez que os endereços IP internos não são mascarados, o nó não usa NAT nesses endereços.
- Para endereços IP externos, o agente de mascaramento de IP mascara esses endereços para o endereço IP do nó. Assim, esses endereços mascarados são traduzidos para um endereço IP externo pelo Cloud NAT ou para o endereço IP externo da instância de máquina virtual (VM).
Também pode usar
endereços IP públicos usados de forma privada (PUPI)
na sua rede VPC ou redes ligadas. Se usar endereços PUPI, ainda pode beneficiar do modelo de rede totalmente integrado e ver o endereço IP do pod diretamente como uma origem. Para alcançar estes dois objetivos, tem de incluir os endereços PUPI na lista nonMasqueradeCIDRs.
Compreenda o fluxo de tráfego de pods numa rede do GKE
O diagrama seguinte mostra como os pods podem comunicar no modelo de rede do GKE:
O diagrama anterior mostra como os pods em ambientes do GKE podem usar endereços IP internos para comunicar diretamente com os seguintes recursos:
- Outros pods no mesmo cluster.
- Pods noutros clusters do GKE na mesma rede VPC.
- Outras Google Cloud aplicações na mesma VPC de rede.
- Aplicações no local ligadas através da Cloud VPN.
O diagrama também mostra o que acontece quando um pod tem de usar um endereço IP externo para comunicar com uma aplicação. À medida que o tráfego sai do nó, o nó no qual o pod reside usa o SNAT para mapear o endereço IP do pod para o endereço IP do nó. Depois de o tráfego sair do nó, o Cloud NAT traduz o endereço IP do nó num endereço IP externo.
Para as vantagens descritas anteriormente neste documento, especialmente para a vantagem de ter endereços IP de pods visíveis em todos os dados de telemetria, a Google escolheu um modelo de rede totalmente integrado. No GKE, os endereços IP dos pods são expostos nos registos de fluxo de VPC (incluindo os nomes dos pods nos metadados), espelhamento de pacotes, registo de regras de firewall, e nos registos da sua própria aplicação para destinos não mascarados.
O que se segue?
- Saiba mais sobre as estratégias de gestão de endereços IP ao migrar para o GKE
- Saiba mais sobre as práticas recomendadas de rede do GKE
- Compare os serviços da AWS e do Azure para Google Cloud
- Leia o artigo Migrar contentores para Google Cloud: migrar o Kubernetes para o GKE