Neste documento, descrevemos as práticas recomendadas para configurar opções de rede em clusters do Google Kubernetes Engine (GKE). O objetivo dele é ser um guia de planejamento de arquitetura para arquitetos de nuvem e engenheiros de rede com recomendações aplicáveis à maioria dos clusters do GKE. Antes de criar os clusters do GKE, recomendamos que você analise todas as seções deste documento para entender as opções de rede compatíveis com o GKE e as implicações delas.
As opções de rede escolhidas afetam a arquitetura dos clusters do GKE. Algumas dessas opções não poderão ser alteradas depois de serem configuradas sem recriar o cluster.
Este documento não é destinado a introduzir conceitos de rede ou terminologia do Kubernetes e pressupõe que você já tenha algum nível de conhecimento de conceitos gerais de rede e conhecimento de rede do Kubernetes. Para mais informações, consulte a visão geral de redes no GKE.
Ao analisar este documento, considere o seguinte:
- Como você planeja expor cargas de trabalho internamente à sua rede de nuvem privada virtual (VPC), outras cargas de trabalho no cluster, outros clusters do GKE ou externamente à Internet.
- Como você planeja escalonar as cargas de trabalho.
- quais tipos de Serviços do Google você quer consumir.
Para uma lista resumida de todas as práticas recomendadas, consulte o Resumo da lista de verificação.
Design da VPC
Ao projetar as redes VPC, siga as práticas recomendadas para o design da VPC.
Na seção a seguir, apresentamos algumas recomendações específicas do GKE para o design da rede VPC.
Usar clusters nativos de VPC
Recomendamos que você use clusters nativos de VPC. Eles usam intervalos de endereços IP de alias nos nós do GKE e são necessários para os clusters particulares do GKE e para a criação deles em VPCs compartilhadas. Além disso, eles têm muitos outros benefícios. Para clusters criados no modo Autopilot, o modo nativo de VPC sempre está ativado e não pode ser desativado.
Os clusters nativos de VPC são escalonados com mais facilidade que os clusters baseados em roteamento, sem consumir rotas do Google Cloud. Por isso, são menos suscetíveis a atingir limites de roteamento.
As vantagens do uso de clusters nativos de VPC são compatíveis com o suporte a IP de alias. Por exemplo, os grupos de endpoints de rede (NEGs, na sigla em inglês) só podem ser usados com endereços IP secundários. Portanto, eles são compatíveis apenas com clusters nativos de VPC.
Usar redes VPC compartilhadas
Os clusters do GKE exigem um planejamento cuidadoso do endereço IP. A maioria das organizações costuma ter uma estrutura de gerenciamento centralizada com um administrador de rede que pode alocar espaço de endereço IP para clusters e um administrador de plataforma para operar os clusters. Esse tipo de estrutura organizacional funciona bem com a arquitetura de rede VPC compartilhada do Google Cloud. Na arquitetura de rede VPC compartilhada, um administrador de rede pode criar sub-redes e compartilhá-las com VPCs. É possível criar clusters do GKE em um projeto de serviço e usar as sub-redes compartilhadas da VPC compartilhada no projeto host. O componente de endereço IP permanece no projeto host, e os outros componentes do cluster residem no projeto de serviço.
Em geral, uma rede VPC compartilhada é uma arquitetura muito usada, adequada à maioria das organizações com uma equipe de gerenciamento centralizada. Recomendamos o uso de redes VPC compartilhadas para criar as sub-redes para seus clusters do GKE e evitar conflitos de endereços IP em toda a organização. Também é possível usar VPCs compartilhadas para governança de funções operacionais. Por exemplo, é possível ter uma equipe de rede que trabalha apenas em componentes de rede e confiabilidade e outra equipe que trabalha no GKE.
Estratégias de gerenciamento de endereços IP
Todos os clusters do Kubernetes, incluindo clusters do GKE, exigem um endereço IP exclusivo para cada pod.
Para saber mais, consulte o modelo de rede do GKE.No GKE, todos esses endereços são roteáveis em toda a rede VPC. Portanto, o planejamento de endereços IP é necessário porque os endereços não podem se sobrepor ao espaço de endereço IP interno usado no local ou em outros ambientes conectados. Nas seções a seguir, você verá algumas estratégias para o gerenciamento de endereços IP com o GKE.
Práticas recomendadas:
Planeje a cota de endereço IP necessária.Use espaço não RFC 1918, se necessário.
Use o modo de sub-rede personalizado.
Planeje a densidade de pods por nó.
Evite sobreposições com endereços IP usados em outros ambientes.
Crie uma sub-rede do balanceador de carga.
Reserve espaço de endereço IP suficiente para o escalonador automático de cluster.
Compartilhe endereços IP entre clusters.
Compartilhe endereços IP para serviços LoadBalancer internos.
Planejar a cota de endereço IP necessária
Os clusters particulares são recomendados e discutidos com mais detalhes na seção Segurança de rede. No contexto de clusters particulares, somente os clusters nativos de VPC são compatíveis e exigem os seguintes intervalos de endereços IP:
- Intervalo de endereços IP do plano de controle: use uma sub-rede /28 nos intervalos particulares de endereços IP incluídos na RFC 1918. É preciso garantir que essa sub-rede não se sobreponha a nenhum outro roteamento entre domínios sem classe (CIDR) na rede VPC.
- Sub-rede de nós: a sub-rede com o intervalo de IP principal que você quer alocar
para todos os nós no cluster. Os serviços com o tipo
LoadBalancerque usam a anotaçãocloud.google.com/load-balancer-type: "Internal"também usam essa sub-rede por padrão. Também é possível usar uma sub-rede dedicada para balanceadores de carga internos. - Intervalo de endereços IP do pod: o intervalo de IPs que você aloca para todos os pods no cluster. O GKE provisiona esse intervalo como um alias da sub-rede. Para mais informações, consulte Intervalos de endereço IP para clusters nativos de VPC.
- Intervalo de endereços IP do serviço: o intervalo de endereços IP que você aloca para todos os serviços no cluster. O GKE provisiona esse intervalo como um alias da sub-rede.
Para clusters particulares, defina uma sub-rede de nó, um intervalo de endereços IP do pod e um intervalo de endereços IP do serviço.
Se você quiser usar o espaço de endereços IP com mais eficiência, consulte Reduzir o uso de endereços IP internos no GKE.O intervalo de endereços IP do plano de controle é dedicado ao plano de controle gerenciado pelo GKE que reside em um projeto de locatário gerenciado pelo Google que faz peering com sua VPC. Esse intervalo de endereços IP não pode se sobrepor a nenhum endereço IP no grupo de peering de VPC, porque o GKE importa essa rota para o projeto. Isso significa que, se você tiver rotas para o mesmo CIDR no seu projeto, poderá enfrentar problemas de roteamento.
Ao criar um cluster, a sub-rede tem um intervalo primário para os nós do cluster e precisa existir antes da criação dele. A sub-rede precisa acomodar o número máximo de nós esperado no cluster e os endereços IP do balanceador de carga interno em todo o cluster usando a sub-rede.
Use o escalonador automático de cluster para limitar o número máximo de nós.Os intervalos de endereços IP do pod e do serviço são representados como intervalos secundários distintos da sub-rede, implementados como endereços IP de alias em clusters nativos de VPC.
Escolha intervalos de endereços IP grandes o suficiente para acomodar todos os nós, pods e serviços do cluster.
Considere as seguintes limitações:
- É possível expandir intervalos de endereços IP principais, mas não reduzi-los. Esses intervalos de endereços IP não podem ser descontínuos.
- É possível expandir o intervalo de pods anexando outros intervalos de pods ao cluster ou criando novos pools de nós com outros intervalos de pods secundários.
- O intervalo de endereços IP secundário para serviços não pode ser expandido ou alterado durante a vida útil do cluster.
- Revise as limitações do intervalo de endereços IP secundário para pods e serviços.
Usar mais de endereços IP particulares RFC 1918
Em alguns ambientes, o espaço RFC 1918 em grandes blocos CIDR contíguos pode já estar alocado em uma organização. Use espaços não RFC 1918 em outros CIDRs para clusters do GKE, se eles não se sobrepuserem em endereços IP públicos de propriedade do Google. Recomendamos usar a parte 100.64.0.0/10 do espaço de endereço RFC, porque o espaço de endereço Classe E pode apresentar problemas de interoperabilidade. com hardwares no local. É possível usar IPs públicos reutilizados de maneira particular (PUPI, na sigla em inglês).
Ao usar endereços IP públicos reutilizados de modo privado, tenha cuidado e considere controlar anúncios de rota em redes locais para a Internet ao escolher essa opção.
Não use a conversão de endereços de rede de origem (SNAT, na sigla em inglês) em um cluster com tráfego de pod para pod e de pod para serviço. Isso interrompe o modelo de rede do Kubernetes.
O Kubernetes supõe que todos os endereços IP não RFC 1918 são endereços IP públicos reutilizados de modo privado e usa o SNAT para todo o tráfego proveniente desses endereços.
Se você estiver usando um endereço IP não RFC 1918 no cluster do GKE, para clusters padrão, será necessário desativar explicitamente o SNAT ou configurar o agente de mascaramento de IP para excluir os endereços IP do pod do cluster e os intervalos de endereços IP secundários para serviços do SNAT. Para clusters do Autopilot, isso não exige outras etapas.
Usar o modo de sub-rede personalizado
Ao configurar a rede, você também seleciona o modo de sub-rede: auto (padrão)
ou custom (recomendado). O modo auto deixa a alocação de sub-rede no
Google e é uma boa opção para começar sem um planejamento de endereço IP. No entanto,
recomendamos selecionar o modo custom, porque ele permite escolher intervalos de
endereços IP que não se sobrepõem a outros intervalos no seu ambiente. Se você estiver usando uma VPC compartilhada, um administrador da organização ou um administrador de rede poderá selecionar esse modo.
No exemplo a seguir, criamos uma rede chamada my-net-1 com o modo de sub-rede
personalizado:
gcloud compute networks create my-net-1 --subnet-mode custom
Planejar a densidade de pods por nó
Por padrão, os clusters padrão reservam um intervalo /24 para cada nó fora do espaço de endereço do pod na sub-rede e permitem até 110 pods por nó. No entanto, é possível configurar um cluster padrão para aceitar até 256 pods por nó, com um intervalo /23 reservado para cada nó. Dependendo do tamanho dos nós e do perfil do aplicativo dos seus pods, é possível executar significativamente menos pods em cada nó.
Se você não quiser executar mais de 64 pods por nó, recomendamos ajustar o máximo de pods por nó para preservar o espaço de endereços IP na sub-rede do pod.
Se você pretende executar mais do que os 110 pods padrão por nó, aumente os pods máximos por nó até 256, com /23 reservado para cada nó. Com esse tipo de configuração de alta densidade de pod, recomendamos o uso de instâncias com 16 ou mais núcleos de CPU para garantir a escalonabilidade e o desempenho do cluster.
Para clusters Autopilot, o número máximo de pods por nó é definido como 32, reservando um intervalo de /26 para cada nó. Não é possível definir essa configuração em clusters do Autopilot.
Evitar sobreposições com endereços IP usados em outros ambientes
É possível conectar sua rede VPC a um ambiente local ou a outros provedores de serviços de nuvem usando o Cloud VPN ou o Cloud Interconnect. Esses ambientes podem compartilhar rotas, tornando o esquema de gerenciamento de endereços IP local importante para o planejamento de endereços IP do GKE. Evite que os endereços IP se sobreponham aos endereços IP usados em outros ambientes.
Criar uma sub-rede do balanceador de carga
Crie uma sub-rede do balanceador de carga separada para expor serviços com balanceamento de carga interno TCP/UDP. Se uma sub-rede do balanceador de carga separada não for usada, esses serviços serão expostos com um endereço IP da sub-rede do nó, o que pode levar ao uso de todo o espaço alocado nessa sub-rede antes do esperado e pode impedir o escalonamento do cluster do GKE para o número esperado de nós.
Usar uma sub-rede do balanceador de carga separado também permite filtrar o tráfego de e para os nós do GKE separadamente para serviços expostos pelo balanceamento de carga TCP/UDP interno, o que permite definir limites de segurança mais rigorosos.
Reservar espaço de endereço IP suficiente para o escalonador automático de cluster
Use o escalonador automático de cluster para adicionar e remover nós dinamicamente. Assim, é possível controlar os custos e melhorar a utilização. No entanto, ao usar o escalonador automático do cluster, verifique se o planejamento de endereço IP é responsável pelo tamanho máximo de todos os pools de nós. Cada novo nó requer o próprio endereço IP de nó, além do próprio conjunto alocável de endereços IP do pod com base nos pods configurados por nó. O número de pods por nó pode ser configurado de maneira diferente do que é configurado no nível do cluster. Não é possível alterar o número de pods por nó depois de criar o cluster ou o pool de nós. Considere os tipos de carga de trabalho e os atribua a pools de nós distintos para otimizar a alocação de endereços IP.
Use o provisionamento automático de nós, com o escalonador automático de cluster, especialmente se você estiver usando clusters nativos de VPC. Para mais informações, consulte Intervalos de limitação de nós.
Compartilhar endereços IP entre clusters
Talvez seja necessário compartilhar endereços IP entre clusters se você tiver uma equipe centralizada que gerencia a infraestrutura dos clusters. Para compartilhar endereços IP entre clusters do GKE, consulte Como compartilhar intervalos de endereços IP entre clusters do GKE. É possível reduzir a sobrecarga criando três intervalos para pods, Serviços e nós e reutilizando ou compartilhando-os, especialmente em um modelo de VPC compartilhada. Além disso, os administradores de rede podem gerenciar endereços IP mais facilmente, já que não precisam criar sub-redes específicas para cada cluster.
Considere o seguinte:
- Como prática recomendada, use sub-redes e intervalos de endereços IP separados para todos os clusters.
- É possível compartilhar o intervalo de endereços IP do pod secundário, mas isso não é recomendado porque um cluster pode usar todos os endereços IP.
- É possível compartilhar intervalos de endereços IP de serviço secundários, mas esse recurso não funciona com Cloud DNS para escopo da VPC no GKE.
No entanto, se os endereços IP do pod ficarem sem capacidade, crie intervalos de endereços IP do pod adicionais usando CIDR de vários pods distintos.
Compartilhar endereços IP para serviços LoadBalancer internos
É possível compartilhar um único endereço IP com até 50 back-ends usando portas diferentes. Isso permite reduzir o número de endereços IP necessários para serviços internos LoadBalancer.
Para mais informações, consulte IP compartilhado.
Opções de segurança de rede
Veja nesta seção algumas recomendações importantes para o isolamento de cluster. A segurança de rede para clusters do GKE é uma responsabilidade compartilhada entre o Google e os administradores do cluster.
Práticas recomendadas:
Use o GKE Dataplane V2.Escolher um tipo de cluster particular.
Minimizar a exposição do plano de controle do cluster.
Autorize o acesso ao plano de controle.
Permita a conectividade ao plano de controle.
Implante proxies para acessar o plano de controle a partir de redes com peering.
Restrinja o tráfego de cluster usando políticas de rede.
Ative as políticas de segurança do Google Cloud Armor para entrada.
Use o Identity-Aware Proxy para fornecer autenticação para aplicativos com usuários do IAM.
Use as restrições da política da organização para aumentar ainda mais a segurança.
Usar o plano de dados V2 do GKE
O GKE Dataplane V2
é baseado no eBPF e fornece uma experiência
integrada de segurança e visibilidade da rede. Ao criar um cluster usando o
GKE Dataplane V2, não é necessário ativar explicitamente as políticas de
rede, porque o GKE Dataplane V2 gerencia o roteamento,
a geração de registros e a aplicação da política de rede. Ative o novo plano de dados com a opção --enable-dataplane-v2 da CLI do Google Cloud
ao criar um cluster. Depois que as políticas de rede
são configuradas, um objeto CRD NetworkLoggingpadrão pode ser
configurado
para registrar conexões de rede permitidas e negadas. Recomendamos a criação de clusters
com o GKE Dataplane V2 para aproveitar ao máximo os recursos integrados, como a
geração de registros de políticas de rede.
Escolher um tipo de cluster particular
Clusters públicos têm endereços IP privados e públicos em nós e apenas um endpoint público para nós do plano de controle. Clusters particulares dão mais isolamento porque têm apenas endereços IP internos nos nós e têm endpoints públicos e privados para nós do plano de controle. Isso pode ser isolado ainda mais e é abordado na seção Minimizar a exposição do plano de controle do cluster. Em clusters privados, ainda é possível acessar APIs do Google com o Acesso privado do Google. Recomendamos escolher clusters particulares.
Em um cluster particular, os pods são isolados da comunicação de entrada e de saída (o perímetro do cluster). É possível controlar esses fluxos direcionais ao expor serviços usando o balanceamento de carga e o Cloud NAT, discutidos na seção sobre conectividade do cluster neste documento. O diagrama a seguir mostra esse tipo de configuração:
Este diagrama mostra como um cluster privado pode se comunicar. Os clientes locais podem se conectar ao cluster com o cliente kubectl. O acesso aos serviços do Google é oferecido pelo Acesso privado do Google, e a comunicação com a Internet está disponível apenas usando o Cloud NAT.
Para mais informações, consulte requisitos, restrições e limitações dos clusters particulares.
Minimizar a exposição do plano de controle do cluster
Em um cluster particular, o servidor da API GKE pode ser exposta como um endpoint público ou particular. Decida qual endpoint usar ao
criar o cluster. É possível controlar o acesso com redes autorizadas,
em que os endpoints públicos e particulares assumem como padrão toda a
comunicação entre o pod e os endereços IP do nó no cluster. Para
ativar um endpoint particular ao criar um cluster, use a flag
--enable-private-endpoint.
Autorizar acesso ao plano de controle
As redes autorizadas podem ajudar a ditar quais sub-redes de endereço IP podem acessar
os nós do plano de controle do GKE. Depois de ativar essas redes,
restrinja o acesso a intervalos de endereços IP de origem específicos. Se o endpoint público
estiver desativado, esses intervalos de endereços IP de origem precisarão ser particulares. Se um endpoint público
estiver ativado, será possível permitir intervalos de endereços IP públicos ou internos.
Configure divulgações de rota personalizadas
para permitir que o endpoint particular do plano de controle do cluster possa ser acessado em
um ambiente local. É possível tornar o endpoint particular da API GKE
acessível globalmente usando a opção --enable-master-global-access
ao criar um cluster.
O diagrama a seguir mostra a conectividade típica do plano de controle usando redes autorizadas:
Esse diagrama mostra usuários confiáveis comunicando-se com o plano de controle do GKE pelo endpoint público, já que fazem parte de redes autorizadas, enquanto o acesso de agentes não confiáveis é bloqueado. A comunicação para o cluster do GKE e a partir dele é feita pelo endpoint particular do plano de controle.
Permitir conectividade ao plano de controle
Determinados pods de sistema em cada nó de trabalho precisam alcançar serviços como o servidor da API Kubernetes (kube-apiserver), as APIs do Google ou o servidor de metadados.
O kube-apiserver também precisa se comunicar com alguns pods do sistema, como event-exporter, especificamente. Essa comunicação é permitida por padrão. Se você
implantar regras de firewall VPC nos projetos (mais detalhes na
seção Restringir tráfego de cluster),
verifique se esses pods podem continuar se comunicando com o kube-apiserver e com as
APIs do Google.
Implantar proxies para acessar o plano de controle a partir de redes com peering
O acesso ao plano de controle para clusters particulares do GKE é pelo Peering da rede VPC. O peering da rede VPC não é transitivo. Portanto, não é possível acessar o plano de controle do cluster de outra rede com peering.
Para ter acesso direto de outra rede com peering ou do local ao usar uma arquitetura hub e spoke, implante proxies para o tráfego do plano de controle.
Restringir o tráfego de cluster usando políticas de rede
Vários níveis de segurança de rede são possíveis para cargas de trabalho do cluster que podem ser combinadas: regras de firewall VPC, políticas de firewall hierárquicas e políticas de rede do GKE. As regras de firewall da VPC e as políticas de firewall hierárquicas se aplicam no nível da máquina virtual (VM), que são os nós de trabalho em que estão os pods do cluster do GKE. As políticas de rede do Kubernetes são aplicadas no nível do pod para aplicar caminhos de tráfego entre pods.
Se você implementar firewalls de VPC, isso poderá interromper a comunicação padrão do plano de controle obrigatória, por exemplo, a comunicação do kubelet com o plano de controle. Por padrão, o GKE cria as regras de firewall necessárias, mas elas podem ser substituídas. Algumas implantações podem exigir que o plano de controle chegue ao cluster no serviço. Use firewalls de VPC para configurar uma política de entrada que torne o serviço acessível.
As políticas de rede do GKE são configuradas pela
API Kubernetes Network Policy para aplicar a comunicação de pod e serviço de um cluster. É possível
ativar as políticas de rede ao criar um cluster usando a
opção --enable-network-policy do gcloud container
clusters create. Para
restringir o tráfego usando políticas de rede, siga o guia de implementação do blueprinting do Anthos.
Ativar as políticas de segurança do Google Cloud Armor para entrada
Usando as políticas de segurança do Google Cloud Armor, é possível proteger os aplicativos que usam balanceadores de carga de aplicativo externos contra ataques DDoS e outros ataques baseados na Web bloqueando esse tráfego na extremidade da rede. No GKE, ative as políticas de segurança do Google Cloud Armor para aplicativos usando o Entrada para balanceadores de carga de aplicativo externos e adicionando uma política de segurança ao BackendConfig anexada ao objeto do Entrada.
Usar o Identity-Aware Proxy para fornecer autenticação para aplicativos com usuários do IAM
Se você quiser implantar os serviços para serem acessados apenas por usuários dentro da organização, mas sem precisar estar na rede corporativa, use o Identity-Aware Proxy para criar uma camada de autenticação para esses aplicativos. Para ativar o Identity-Aware Proxy para o GKE, siga as etapas de configuração para adicionar o Identity-Aware Proxy como parte do BackendConfig para a entrada do serviço. O Identity-Aware Proxy pode ser combinado com o Google Cloud Armor.
Usar as restrições da política da organização para aumentar ainda mais a segurança
Com as restrições de políticas da organização, é possível definir políticas para melhorar ainda mais sua postura de segurança. Por exemplo, é possível usar restrições para restringir a criação de balanceadores de carga a determinados tipos, como balanceadores de carga internos.
Como escalonar a conectividade do cluster
Nesta seção, você verá opções escalonáveis para DNS e conectividade de saída dos clusters para a Internet e para os Serviços do Google.
Práticas recomendadas:
Use o Cloud DNS para o GKE.Ativar NodeLocal DNSCache.
Usar o Cloud NAT para o acesso à Internet em clusters particulares.
Usar o Acesso privado do Google para acessar os Serviços do Google.
Usar o Cloud DNS para o GKE
É possível usar o Cloud DNS para GKE para fornecer resolução de DNS de pods e serviços com DNS gerenciado sem um provedor de DNS hospedado no cluster. O Cloud DNS elimina a sobrecarga de gerenciar um servidor DNS hospedado no cluster e não requer escalonamento, monitoramento ou gerenciamento de instâncias de DNS porque é um serviço hospedado do Google.
Ativar NodeLocal DNSCache
O GKE usa kube-dns para fornecer o serviço DNS
local do cluster como um complemento de cluster padrão. kube-dns é replicado no cluster
como uma função do número total de núcleos e nós no cluster.
É possível melhorar o desempenho do DNS com o DNSCache NodeLocal. O DNSCache NodeLocal é um complemento implantado como um DaemonSet e não requer alterações na configuração do pod. As buscas DNS no serviço de pod local não criam conexões abertas que precisam ser rastreadas no nó, o que permite maior escala. As pesquisas de nomes do host externos são encaminhadas para o Cloud DNS, enquanto todas as outras consultas DNS vão para o kube-dns.
Ative o NodeLocal DNSCache para tempos de consulta DNS mais consistentes e melhor escala de cluster. Em clusters do Autopilot, o NodeCache DNSCache é ativado por padrão e não pode ser substituído.
A seguinte opção da CLI do Google Cloud ativa o NodeLocal DNSCache quando
você cria um cluster: --addons NodeLocalDNS.
Se você tiver controle sobre o nome que os aplicativos querem resolver,
existem maneiras de melhorar o escalonamento de DNS. Por exemplo, use um FQDN (encerre o
nome do host com um ponto) ou desative a expansão do caminho de pesquisa usando a
opção de manifesto Pod.dnsConfig.
Usar o Cloud NAT para o acesso à Internet em clusters particulares
Por padrão, os clusters particulares não têm acesso à Internet. Para permitir que os pods acessem a Internet, ative o Cloud NAT para cada região. Ative pelo menos o Cloud NAT para os intervalos principal e secundário na sub-rede do GKE. Certifique-se de alocar endereços IP para o Cloud NAT e portas por VM suficientes.
Siga as práticas recomendadas de configuração do gateway do Cloud NAT ao usar o Cloud NAT para clusters particulares:
- Ao criar o gateway do Cloud NAT, ative-o apenas para os intervalos de sub-rede usados pelos clusters. Contando todos os nós em todos os clusters, é possível determinar quantas VMs de consumidor de NAT há no projeto.
Use a alocação de porta dinâmica para alocar números diferentes de portas por VM, com base no uso da VM. Comece com portas mínimas de 64 e portas máximas de 2048.
Se você precisar gerenciar muitas conexões simultâneas com as mesmas três tuplas de destino, diminua o tempo limite de
TIME_WAITdo TCP do valor padrão de120spara5s. Para mais informações, consulte Especificar tempos limite diferentes para NAT.Ative a geração de registros de erros do Cloud NAT para verificar os registros relacionados.
Verifique os registros do gateway do Cloud NAT depois de configurar o gateway. Para reduzir os problemas de queda de status de alocação, talvez seja necessário aumentar o número máximo de portas por VM.
Evite SNAT duplo para o tráfego de pods (SNAT primeiro no nó do GKE e novamente com o Cloud NAT). A menos que você precise de SNAT para ocultar os endereços de IPs de pod em redes locais conectadas pelo Cloud VPN ou Cloud Interconnect, disable-default-snat e descarregue o rastreamento de SNAT para o Cloud NAT para escalabilidade. Essa solução funciona para todos os intervalos de IP de sub-redes primárias e secundárias. Use políticas de rede para restringir o tráfego externo depois de ativar o Cloud NAT. O Cloud NAT não é necessário para acessar os serviços do Google.
Usar o Acesso privado do Google para acessar os Serviços do Google
Em clusters particulares, os pods não têm endereços IP públicos para acessar serviços públicos, incluindo APIs e serviços do Google. O Acesso privado do Google permite que os recursos privados do Google Cloud alcancem os Serviços do Google.
O Acesso privado do Google é ativado por padrão em clusters particulares, exceto para clusters de VPC compartilhada.
Como exibir aplicativos
Ao criar aplicativos acessíveis externamente ou internos à sua organização, use o tipo e as opções certas do balanceador de carga. Nesta seção, você verá algumas recomendações sobre como expor e dimensionar aplicativos com o Cloud Load Balancing.
Práticas recomendadas:
Usar o balanceamento de carga nativo de contêiner.Escolher o recurso correto do GKE para expor o aplicativo.
Criar verificações de integridade baseadas em BackendConfig.
Usar a política de tráfego local para preservar os endereços IP originais.
Usar o Private Service Connect.
Usar balanceamento de carga nativo de contêiner
Use o balanceamento de carga nativo de contêiner ao expor serviços usando o HTTP(S) externamente. O balanceamento de carga nativo de contêiner permite menos saltos de rede, menor latência e distribuição de tráfego mais exata. Isso também aumenta a visibilidade no tempo de retorno e permite usar recursos de balanceamento de carga, como o Google Cloud Armor.
Escolher o recurso correto do GKE para expor o aplicativo
Dependendo do escopo dos seus clientes (interno, externo ou até mesmo interno ao cluster), da regionalidade do aplicativo e dos protocolos que você usa, há diferentes recursos do GKE que podem ser escolhidos para expor o aplicativo. A Visão geral da rede de serviços, explica essas opções e pode ajudar você a escolher o melhor recurso para expor cada parte do seu aplicativo usando as opções de balanceamento de carga do Google Cloud.
Criar verificações de integridade baseadas em BackendConfig
Se você usar uma entrada para expor serviços, use uma configuração de verificação de integridade em um CRD BackendConfig para usar a funcionalidade de verificação de integridade do balanceador de carga de aplicativo externo. É possível direcionar a verificação de integridade para o endpoint apropriado e definir seus próprios limites. Sem um CRD BackendConfig, as verificações de integridade são inferidas dos parâmetros de sondagem de prontidão ou usam parâmetros padrão.
Usar a política de tráfego local para preservar os endereços IP originais
Ao usar um balanceador de carga de rede interno com o GKE,
defina a opção externalTrafficPolicy
como Local para preservar o endereço IP de origem das solicitações. Use essa
opção se o aplicativo exigir o endereço IP de origem original. No entanto, a
opção externalTrafficPolicy local pode levar a uma distribuição de carga menos ideal.
Use esse recurso apenas quando necessário. Para serviços HTTP(S), é possível usar
controladores de entrada e conseguir o endereço IP original lendo o
cabeçalho X-Forwarded-For na solicitação
HTTP.
Usar o Private Service Connect.
Use o Private Service Connect para compartilhar serviços de balanceador de carga de rede de passagem interna em outras redes VPC. Isso é útil para serviços hospedados em clusters do GKE, mas que estão atendendo clientes que estão sendo executados em diferentes projetos e VPCs.
É possível usar o Private Service Connect para reduzir o consumo de endereços IP fornecendo conectividade entre VPCs com endereços IP sobrepostos.
Operações e administração
Práticas recomendadas:
Usar o IAM para permissões do GKE para controlar políticas em redes VPC compartilhadas.Usar clusters regionais e distribuir as cargas de trabalho para ter alta disponibilidade.
Usar o Cloud Logging e o Cloud Monitoring e ativar a geração de registros de políticas de rede.
As seções a seguir contêm práticas recomendadas operacionais que ajudam a garantir opções de autorização granulares para suas cargas de trabalho. Para evitar a criação de regras de firewall manuais, siga as práticas recomendadas operacionais desta seção. Você também verá recomendações para distribuição de cargas de trabalho, monitoramento e geração de registros no GKE.
Usar o IAM para permissões do GKE para controlar políticas em redes VPC compartilhadas
Ao usar redes VPC compartilhadas, as regras de firewall para balanceadores de carga são criadas automaticamente no projeto host.
Para evitar a necessidade de criar regras de firewall manualmente, atribua um papel personalizado de privilégio mínimo à conta de serviço do GKE no projeto host service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.
Substitua HOST_PROJECT_NUMBER pelo número do
projeto host da VPC compartilhada.
O papel personalizado que você cria precisa ter as seguintes permissões:
compute.firewalls.createcompute.firewalls.getcompute.firewalls.listcompute.firewalls.delete
Além disso, as regras de firewall criadas pelo GKE sempre têm a prioridade padrão de 1.000. Portanto, é possível impedir o tráfego específico de fluir criando regras de firewall com prioridade maior.
Se você quiser restringir a criação de determinados tipos de balanceador de carga, use políticas organizacionais para restringir a criação do balanceador de carga.
Usar clusters regionais e distribuir as cargas de trabalho para ter alta disponibilidade
Os clusters regionais aumentam a disponibilidade de aplicativos em um cluster porque o plano de controle e os nós do cluster são distribuídos por várias zonas.
No entanto, para ter a melhor experiência possível em caso de falha na zona, use o escalonador automático de cluster para garantir que o cluster possa lidar com a carga necessária a qualquer momento.Além disso, use a antiafinidade de pods para garantir que os pods de um determinado serviço sejam programados em várias zonas.
Para mais informações sobre como definir essas configurações para alta disponibilidade e otimização de custo, consulte as práticas recomendadas para alta disponibilidade de clusters do GKE.
Usar o Cloud Logging e o Cloud Monitoring e ativar a geração de registros de políticas de rede
Embora cada organização tenha requisitos diferentes para visibilidade e auditoria, recomendamos ativar a geração de registros de política de rede. Esse recurso está disponível apenas com o GKE Dataplane V2. A geração de registros de políticas de rede proporciona visibilidade sobre os padrões de aplicação da política e tráfego de pods. Esteja ciente de que há custos envolvidos no registro da política de rede.
Para clusters do GKE que usam a versão 1.14 ou mais recente, o Logging e o Monitoring são ativados por padrão. O Monitoring fornece um painel para os clusters do GKE. O Logging também ativa as anotações do GKE para registros de fluxo de VPC. Por padrão, o Logging coleta registros para todas as cargas de trabalho implantadas no cluster, mas também há uma opção de registros somente do sistema. Use o painel do GKE para observar e definir alertas. Para clusters criados no modo Autopilot, o monitoramento e a geração de registros são ativados automaticamente e não são configuráveis.
Esteja ciente de que há custos envolvidos para a Google Cloud Observability.