Práticas recomendadas para a rede do GKE

Esta página descreve as práticas recomendadas para configurar as opções de rede para clusters do Google Kubernetes Engine (GKE). Destina-se a ser um guia de planeamento de arquitetura para arquitetos de nuvem e engenheiros de rede com recomendações de configuração de clusters aplicáveis à maioria dos clusters do GKE. Antes de criar os clusters do GKE, recomendamos que reveja todas as secções desta página para compreender as opções de rede suportadas pelo GKE e as respetivas implicações.

As opções de rede que escolher afetam a arquitetura dos seus clusters do GKE. Não é possível alterar algumas destas opções depois de configuradas sem recriar o cluster.

Antes de ler esta página, certifique-se de que conhece os conceitos e a terminologia de rede do Kubernetes, alguns conceitos gerais de rede e a rede do Kubernetes. Para mais informações, consulte a vista geral da rede do GKE.

Ao rever estas práticas recomendadas, tenha em atenção o seguinte:

• Como planeia expor cargas de trabalho internamente à sua rede da nuvem virtual privada (VPC), outras cargas de trabalho no cluster, outros clusters do GKE ou externamente à Internet.
• Como planeia dimensionar as suas cargas de trabalho.
• Que tipos de serviços Google quer consumir.

Para uma lista de verificação resumida de todas as práticas recomendadas, consulte o Resumo da lista de verificação.

Práticas recomendadas de design de VPC

A secção seguinte fornece algumas recomendações específicas do GKE para o design da rede VPC.

Use clusters nativos de VPC

Recomendamos que use clusters nativos da VPC. Os clusters nativos da VPC usam intervalos de endereços IP de alias em nós do GKE e são necessários para clusters baseados na interligação de redes VPC, para clusters em VPCs partilhadas e têm muitas outras vantagens. Para clusters criados no modo Autopilot, o modo nativo da VPC está sempre ativado e não pode ser desativado.

Os clusters nativos de VPC são dimensionados mais facilmente do que os clusters baseados em rotas sem consumir Trusted Cloud by S3NS rotas e, por isso, são menos suscetíveis de atingir os limites de encaminhamento.

As vantagens da utilização de clusters nativos da VPC estão intimamente relacionadas com o suporte de IPs de alias. Por exemplo, os grupos de pontos finais de rede (NEGs) só podem ser usados com endereços IP secundários, pelo que só são suportados em clusters nativos da VPC.

Use redes VPC partilhadas

Os clusters do GKE requerem um planeamento cuidadoso dos endereços IP. A maioria das organizações tende a ter uma estrutura de gestão centralizada com uma equipa de administração de rede que pode atribuir espaço de endereços IP para clusters e um administrador da plataforma para operar os clusters. Este tipo de estrutura organizacional funciona bem com a arquitetura de rede VPC partilhada do Trusted Cloud. Na arquitetura de rede da VPC partilhada, um administrador de rede pode criar sub-redes e partilhá-las com VPCs. Pode criar clusters do GKE num projeto de serviço e usar as sub-redes partilhadas a partir da VPC partilhada no projeto anfitrião. O componente de endereço IP permanece no projeto anfitrião e os outros componentes do cluster residem no projeto de serviço.

Em geral, uma rede VPC partilhada é uma arquitetura usada com frequência que é adequada para a maioria das organizações com uma equipa de gestão centralizada. Recomendamos que use redes de VPC partilhadas para criar as sub-redes dos seus clusters do GKE e evitar conflitos de endereços IP na sua organização. Também pode usar VPCs partilhadas para a governação de funções operacionais. Por exemplo, pode ter uma equipa de rede que trabalha apenas em componentes de rede e fiabilidade, e outra equipa que trabalha no GKE.

Estratégias de gestão de endereços IP

Todos os clusters do Kubernetes, incluindo os clusters do GKE, requerem um endereço IP exclusivo para cada pod. Para saber mais, consulte o modelo de rede do GKE.

No GKE, todos estes endereços IP são encaminháveis através da rede VPC. Por conseguinte, o planeamento de endereços IP é necessário porque os endereços não podem sobrepor-se ao espaço de endereços IP interno usado no local ou noutros ambientes ligados. As secções seguintes sugerem estratégias para a gestão de endereços IP com o GKE.

Planeie a atribuição de endereços IP necessária

Recomendamos a utilização de clusters nativos da VPC com o Private Service Connect (PSC). Os clusters que usam o intercâmbio da rede da VPC têm de ser clusters nativos de VPC.

Os clusters nativos de VPC requerem os seguintes intervalos de endereços IP:

• Intervalo de endereços IP do plano de controlo: use uma sub-rede /28 nos intervalos privados de endereços IP incluídos na RFC 1918. Tem de garantir que esta sub-rede não se sobrepõe a nenhum outro Classless Inter-Domain Routing (CIDR) na rede VPC.
• Sub-rede do nó: a sub-rede com o intervalo de endereços IP principal que quer atribuir a todos os nós no seu cluster. Os serviços com o tipo LoadBalancer que usam a anotação cloud.google.com/load-balancer-type: "Internal" também usam esta sub-rede por predefinição. Também pode usar uma sub-rede dedicada para equilibradores de carga internos.
• Intervalo de endereços IP do Pod: o intervalo de IP que atribui a todos os Pods no seu cluster. O GKE aprovisiona este intervalo como um alias da sub-rede. Para mais informações, consulte o artigo Intervalos de endereços IP para clusters nativos da VPC
• Intervalo de endereços IP de serviço: o intervalo de endereços IP que atribui a todos os serviços no seu cluster. O GKE aprovisiona este intervalo como um alias da sub-rede.

Ao configurar a rede de clusters, tem de definir uma sub-rede de nós, um intervalo de endereços IP de pods e um intervalo de endereços IP de serviços.

Se quiser usar o espaço de endereços IP de forma mais eficiente, consulte o artigo Reduza a utilização de endereços IP internos no GKE.

O intervalo de endereços IP do plano de controlo é dedicado ao plano de controlo gerido pelo GKE que reside num projeto de inquilino gerido pela Google com intercâmbio na sua VPC. Este intervalo de endereços IP não deve sobrepor-se a nenhum endereço IP no seu grupo de intercâmbio de VPC porque o GKE importa esta rota para o seu projeto. Isto significa que, se tiver rotas para o mesmo CIDR no seu projeto, pode ter problemas de encaminhamento.

Quando cria um cluster, a sub-rede tem um intervalo principal para os nós do cluster e deve existir antes da criação do cluster. A sub-rede deve acomodar o número máximo de nós que espera no cluster e os endereços IP do balanceador de carga interno no cluster através da sub-rede.

Pode usar o dimensionamento automático de clusters para limitar o número máximo de nós.

Os intervalos de endereços IP de pods e serviços são representados como intervalos secundários distintos da sua sub-rede, implementados como endereços IP de alias em clusters nativos da VPC.

Escolha intervalos de endereços IP suficientemente amplos para poder acomodar todos os nós, pods e serviços do cluster.

Considere as seguintes limitações:

• Pode expandir os intervalos de endereços IP principais, mas não os pode reduzir. Estes intervalos de endereços IP não podem ser descontínuos.
• Pode expandir o intervalo de pods anexando intervalos de pods adicionais ao cluster ou criando novos conjuntos de nós com outros intervalos de pods secundários.
• O intervalo de endereços IP secundário para os Serviços não pode ser expandido nem alterado durante o ciclo de vida do cluster.
• Reveja as limitações do intervalo de endereços IP secundários para pods e serviços.

Use mais do que endereços IP RFC 1918 privados

Para alguns ambientes, o espaço RFC 1918 em grandes blocos CIDR contíguos pode já estar alocado numa organização. Pode usar o espaço não RFC 1918 para CIDRs adicionais para clusters do GKE, se não se sobrepuserem a endereços IP públicos pertencentes à Google. Recomendamos que use a parte 100.64.0.0/10 do espaço de endereços RFC, porque o espaço de endereços Classe E pode apresentar problemas de interoperabilidade com hardware no local. Pode usar IPs públicos reutilizados privadamente (PUPI).

Quando usar endereços IP públicos usados de forma privada, use com precaução e considere controlar os anúncios de rotas em redes no local para a Internet quando escolher esta opção.

Não deve usar a tradução de endereços de rede de origem (SNAT) num cluster com tráfego de pod para pod e de pod para serviço. Isto quebra o modelo de rede do Kubernetes.

O Kubernetes assume que todos os endereços IP não RFC 1918 são endereços IP públicos reutilizados de forma privada e usa o SNAT para todo o tráfego proveniente destes endereços.

Se estiver a usar um endereço IP não RFC 1918 para o seu cluster do GKE, para clusters Standard, tem de desativar explicitamente o SNAT ou configurar o agente de mascaramento de IP para excluir os endereços IP dos pods do seu cluster e os intervalos de endereços IP secundários para serviços do SNAT. Para clusters do Autopilot, isto não requer passos adicionais.

Use o modo de sub-rede personalizado

Quando configura a rede, também seleciona o modo de sub-rede: auto (predefinição) ou custom (recomendado). O modo auto deixa a atribuição de sub-redes a cargo da Google e é uma boa opção para começar sem planeamento de endereços IP. No entanto, recomendamos que selecione o modo custom, uma vez que este modo lhe permite escolher intervalos de endereços IP que não se sobrepõem a outros intervalos no seu ambiente. Se estiver a usar uma VPC partilhada, um administrador da organização ou um administrador da rede pode selecionar este modo.

O exemplo seguinte cria uma rede denominada my-net-1 com o modo de sub-rede personalizado:

gcloud compute networks create my-net-1 --subnet-mode custom

Densidade de pods do plano por nó

Por predefinição, os clusters padrão reservam um intervalo /24 para cada nó do espaço de endereços do pod na sub-rede e permitem até 110 pods por nó. No entanto, pode configurar um cluster Standard para suportar até 256 pods por nó, com um intervalo /23 reservado para cada nó. Consoante o tamanho dos seus nós e o perfil da aplicação dos seus pods, pode executar consideravelmente menos pods em cada nó.

Se não espera executar mais de 64 agrupamentos por nó, recomendamos que ajuste o número máximo de agrupamentos por nó para preservar o espaço de endereços IP na sua sub-rede de agrupamentos.

Se espera executar mais do que os 110 agrupamentos predefinidos por nó, pode aumentar o número máximo de agrupamentos por nó até 256, com /23 reservado para cada nó. Com este tipo de configuração de alta densidade de pods, recomendamos a utilização de instâncias com 16 ou mais núcleos de CPU para garantir a escalabilidade e o desempenho do cluster.

Para clusters do Autopilot, o número máximo de pods por nó está definido como 32, reservando um intervalo /26 para cada nó. Esta definição não é configurável em clusters do Autopilot.

Evite sobreposições com endereços IP usados noutros ambientes

Pode ligar a sua rede VPC a um ambiente nas instalações ou a outros fornecedores de serviços na nuvem através do Cloud VPN ou do Cloud Interconnect. Estes ambientes podem partilhar rotas, o que torna o esquema de gestão de endereços IP no local importante no planeamento de endereços IP para o GKE. Recomendamos que se certifique de que os endereços IP não se sobrepõem aos endereços IP usados noutros ambientes.

Crie uma sub-rede do balanceador de carga

Crie uma sub-rede do balanceador de carga separada para expor serviços com balanceamento de carga de TCP/UDP interno. Se não for usada uma sub-rede do balanceador de carga separada, estes serviços são expostos através de um endereço IP da sub-rede do nó, o que pode levar à utilização de todo o espaço alocado nessa sub-rede antes do esperado e impedir que dimensione o cluster do GKE para o número esperado de nós.

A utilização de uma sub-rede do balanceador de carga separada também significa que pode filtrar o tráfego de entrada e saída dos nós do GKE separadamente para serviços expostos pelo balanceamento de carga de TCP/UDP interno, o que lhe permite definir limites de segurança mais rigorosos.

Reserve espaço de endereço IP suficiente para o redimensionador automático de clusters

Pode usar o autoscaler de clusters para adicionar e remover dinamicamente nós no cluster, de modo a controlar os custos e melhorar a utilização. No entanto, quando usa o escalador automático de clusters, certifique-se de que o planeamento do endereço IP tem em conta o tamanho máximo de todos os conjuntos de nós. Cada novo nó requer o seu próprio endereço IP do nó, bem como o seu próprio conjunto atribuível de endereços IP dos pods com base nos pods configurados por nó. O número de pods por nó pode ser configurado de forma diferente do que está configurado ao nível do cluster. Não pode alterar o número de pods por nó depois de criar o cluster ou o conjunto de nós. Deve considerar os tipos de carga de trabalho e atribuí-los a conjuntos de nós distintos para uma atribuição de endereços IP ideal.

Considere usar o aprovisionamento automático de nós com o escalador automático de clusters, particularmente se estiver a usar clusters nativos da VPC. Para mais informações, consulte os intervalos de limitação de nós.

Partilhe endereços IP entre clusters

Pode ter de partilhar endereços IP entre clusters se tiver uma equipa centralizada que esteja a gerir a infraestrutura dos clusters. Para partilhar endereços IP entre clusters do GKE, consulte o artigo Partilhar intervalos de endereços IP entre clusters do GKE. Pode reduzir o esgotamento de IPs criando três intervalos para pods, serviços e nós, e reutilizando-os ou partilhando-os, especialmente num modelo de VPC partilhada. Esta configuração também pode facilitar a gestão de endereços IP por parte dos administradores de rede, uma vez que não exige que criem 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.
• Pode partilhar o intervalo de endereços IP do pod secundário, mas não é recomendado, porque um cluster pode usar todos os endereços IP.
• Pode partilhar intervalos de endereços IP de serviço secundários, mas esta funcionalidade não funciona com o Cloud DNS com âmbito de VPC para o GKE.

Se ficar sem endereços IP, pode criar intervalos de endereços IP de pods adicionais usando o CIDR de vários pods descontínuos.

Partilhe endereços IP para serviços LoadBalancer internos

Pode partilhar um único endereço IP com até 50 back-ends através de portas diferentes. Isto permite-lhe reduzir o número de endereços IP necessários para os serviços de LoadBalancer internos.

Para mais informações, consulte o artigo IP partilhado.

Práticas recomendadas de segurança de rede

Nesta secção, são descritas algumas recomendações importantes para o isolamento de clusters. A segurança de rede para clusters do GKE é uma responsabilidade partilhada entre a Google e os administradores dos seus clusters.

Use o GKE Dataplane V2

O GKE Dataplane V2 baseia-se no eBPF e oferece uma experiência integrada de segurança e visibilidade da rede. Quando cria um cluster com o GKE Dataplane V2, não precisa de ativar explicitamente as políticas de rede porque o GKE Dataplane V2 gere o encaminhamento de serviços, a aplicação de políticas de rede e o registo. Ative o novo plano de dados com a opção --enable-dataplane-v2 da CLI do Google Cloud ao criar um cluster. Depois de configurar as políticas de rede, pode configurar um objeto CRD NetworkLogging predefinido para registar as ligações de rede permitidas e recusadas. Recomendamos que crie clusters com o GKE Dataplane V2 para tirar total partido das funcionalidades incorporadas, como o registo da política de rede.

Minimize a exposição do nó

Num cluster com apenas nós privados, os pods estão isolados da comunicação de entrada e saída (o perímetro do cluster). Pode controlar estes fluxos direcionais expondo serviços através do equilíbrio de carga e do Cloud NAT, conforme explicado na secção Conetividade do cluster neste documento. O diagrama seguinte mostra este tipo de configuração:

Este diagrama mostra como um cluster com nós privados pode comunicar. Os clientes no local podem estabelecer ligação ao cluster com o cliente kubectl. O acesso aos serviços Google é fornecido através do acesso privado à Google, e a comunicação com a Internet só está disponível através do Cloud NAT.

Minimize a exposição do plano de controlo do cluster

O plano de controlo tem dois tipos de pontos finais para acesso ao cluster:

• Ponto final baseado em DNS
• Pontos finais baseados em IP

O ponto final de DNS é acessível a partir de qualquer rede alcançável pelas APIs, incluindo redes locais ou outras redes na nuvem. Trusted Cloud by S3NS Para ativar o ponto final baseado em DNS, use a flag --enable-dns-access.

O servidor da API GKE também pode ser exposto como um ponto final público ou privado baseado em IP. Pode decidir que ponto final usar quando criar o cluster. Pode controlar o acesso com redes autorizadas, em que os pontos finais públicos e privados permitem por predefinição toda a comunicação entre o pod e os endereços IP dos nós no cluster. Para ativar um ponto final privado quando criar um cluster, use a flag --enable-private-endpoint.

Autorize o acesso ao plano de controlo

As redes autorizadas podem ajudar a determinar que sub-redes de endereços IP podem aceder aos nós do plano de controlo do GKE. Depois de ativar estas redes, pode restringir o acesso a intervalos de endereços IP de origem específicos. Se o ponto final público estiver desativado, estes intervalos de endereços IP de origem devem ser privados. Se um ponto final público estiver ativado, pode permitir intervalos de endereços IP públicos ou internos. Configure anúncios de rotas personalizadas para permitir que o ponto final privado do plano de controlo do cluster seja acessível a partir de um ambiente no local. Pode tornar o ponto final da API GKE privado acessível globalmente através da opção --enable-master-global-access quando cria um cluster.

O diagrama seguinte mostra a conetividade típica do plano de controlo através de redes autorizadas:

Este diagrama mostra que os utilizadores fidedignos podem comunicar com o plano de controlo do GKE através do ponto final público, uma vez que fazem parte das redes autorizadas, enquanto o acesso de atores não fidedignos é bloqueado. A comunicação de e para o cluster do GKE ocorre através do ponto final privado do plano de controlo.

Permita a conetividade do plano de controlo

Determinados pods do sistema em cada nó de trabalho têm de alcançar serviços como o servidor da API Kubernetes (kube-apiserver), as APIs Google ou o servidor de metadados. O kube-apiservertambém tem de comunicar com alguns pods do sistema, como event-exporter especificamente. Esta comunicação é permitida por predefinição. Se implementar regras de firewall de VPC nos projetos (mais detalhes na secção Restringir tráfego de clusters), certifique-se de que esses pods podem continuar a comunicar com o kube-apiserver, bem como com as APIs Google.

Implemente proxies para o acesso ao plano de controlo a partir de redes com peering

Se o seu cluster usar o intercâmbio das redes da VPC, não pode aceder ao plano de controlo do cluster a partir de outra rede com intercâmbio.

Se quiser acesso direto a partir de outra rede com peering ou a partir de instalações locais quando usar uma arquitetura de hub e raios, implemente proxies para o tráfego do plano de controlo.

Restrinja o tráfego do cluster através de políticas de rede

É possível ter vários níveis de segurança de rede para cargas de trabalho de clusters que podem ser combinados: regras de firewall da VPC, políticas de firewall hierárquicas e políticas de rede do Kubernetes. As regras de firewall de VPC e as políticas de firewall hierárquicas aplicam-se ao nível da máquina virtual (VM), ou seja, aos nós de trabalho nos quais residem os pods do cluster do GKE. As políticas de rede do Kubernetes aplicam-se ao nível do Pod para aplicar caminhos de tráfego de Pod para Pod.

Se implementar firewalls da VPC, pode interromper a comunicação do plano de controlo predefinido e obrigatório, por exemplo, a comunicação do kubelet com o plano de controlo. Por predefinição, o GKE cria regras de firewall obrigatórias, mas podem ser substituídas. Algumas implementações podem exigir que o plano de controlo alcance o cluster no serviço. Pode usar 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 através da API Network Policy do Kubernetes para aplicar a comunicação de pods de um cluster. Pode ativar as políticas de rede quando cria um cluster através da opção gcloud container clusters create--enable-network-policy. Para restringir o tráfego através de políticas de rede, pode seguir o guia de implementação do esquema de restrição do tráfego do Anthos.

Ative as políticas de segurança do Google Cloud Armor para o Ingress

Ao usar as políticas de segurança do Google Cloud Armor, pode proteger as aplicações que usam equilibradores de carga de aplicações externos contra ataques DDoS e outros ataques baseados na Web, bloqueando esse tráfego no limite da rede. No GKE, ative as políticas de segurança do Google Cloud Armor para aplicações através da utilização do Ingress para equilibradores de carga de aplicações externos e adicionando uma política de segurança ao BackendConfig anexado ao objeto Ingress.

Use o Identity-Aware Proxy para fornecer autenticação para aplicações com utilizadores do IAM

Se quiser implementar serviços que só possam ser acedidos por utilizadores na organização, mas sem a necessidade de estar na rede empresarial, pode usar o Identity-Aware Proxy para criar uma camada de autenticação para estas aplicações. Para ativar o Identity-Aware Proxy para o GKE, siga os passos de configuração para adicionar o Identity-Aware Proxy como parte do BackendConfig para o seu serviço Ingress. O Identity-Aware Proxy pode ser combinado com o Google Cloud Armor.

Use restrições de políticas da organização para melhorar ainda mais a segurança

Ao usar restrições da política organizacional, pode definir políticas para melhorar ainda mais a sua postura de segurança. Por exemplo, pode usar restrições para restringir a criação de balanceadores de carga a determinados tipos, como apenas balanceadores de carga internos.

Escalabilidade da conetividade do cluster

Esta secção aborda as opções escaláveis para DNS e conetividade de saída dos seus clusters para a Internet e os serviços Google.

Use o Cloud DNS para o GKE

Pode usar o Cloud DNS para o GKE para fornecer resolução de DNS de pods e serviços com DNS gerido sem um fornecedor de DNS alojado no cluster. O Cloud DNS remove a sobrecarga da gestão de um servidor DNS alojado num cluster e não requer escalabilidade, monitorização nem gestão de instâncias de DNS, uma vez que é um serviço Google alojado.

Ative a NodeLocal DNSCache

O GKE usa o kube-dns para fornecer o serviço DNS local do cluster como um suplemento de cluster predefinido. kube-dns é replicado no cluster como uma função do número total de núcleos e nós no cluster.

Pode melhorar o desempenho do DNS com a NodeLocal DNSCache. O NodeLocal DNSCache é um suplemento implementado como um DaemonSet e não requer alterações de configuração do Pod. As pesquisas de DNS para o serviço de pod local não criam ligações abertas que precisam de ser monitorizadas no nó, o que permite uma maior escala. As pesquisas de nomes de anfitriões externos são encaminhadas para o Cloud DNS, enquanto todas as outras consultas DNS são encaminhadas para o kube-dns.

Ative a NodeLocal DNSCache para tempos de procura de consultas DNS mais consistentes e uma escala de cluster melhorada. Para os clusters do Autopilot, o NodeLocal DNSCache está ativado por predefinição e não pode ser substituído.

A seguinte opção da CLI do Google Cloud ativa o NodeLocal DNSCache quando cria um cluster: --addons NodeLocalDNS.

Se tiver controlo sobre o nome que as aplicações estão a tentar resolver, existem formas de melhorar o dimensionamento do DNS. Por exemplo, use um FQDN (termine o nome do anfitrião com um ponto) ou desative a expansão do caminho de pesquisa através da Pod.dnsConfigopção de manifesto.

Use o Cloud NAT para aceder à Internet a partir de clusters

Por predefinição, os clusters com nós privados ativados não têm acesso à Internet. Para permitir que os pods alcancem a Internet, ative o Cloud NAT para cada região. No mínimo, ative a NAT na nuvem para os intervalos principal e secundário na sub-rede do GKE. Certifique-se de que atribui endereços IP suficientes para a NAT na nuvem e portas por VM.

Use as seguintes práticas recomendadas de configuração da gateway do Cloud NAT enquanto usa o Cloud NAT para clusters:

• Quando criar o gateway NAT do Cloud, ative-o apenas para os intervalos de sub-redes usados pelos seus clusters. Ao contabilizar todos os nós em todos os clusters, pode determinar quantas VMs de consumidor de NAT tem no projeto.

• Use a atribuição dinâmica de portas para atribuir diferentes números de portas por VM, com base na utilização da VM. Comece com um mínimo de 64 portas e um máximo de 2048 portas.

• Se precisar de gerir muitas ligações simultâneas ao mesmo triplo de destino, diminua o tempo limite de TIME_WAITTCP do valor predefinido de 120s para 5s. Para mais informações, consulte o artigo Especifique diferentes limites de tempo para o NAT.

• Ative o registo de erros da NAT na nuvem para verificar os registos relacionados.

• Verifique os registos da gateway do Cloud NAT após configurar a gateway. Para diminuir os problemas de estado de atribuição rejeitado, pode ter de aumentar o número máximo de portas por VM.

Deve evitar o SNAT duplo para o tráfego de pods (SNAT primeiro no nó do GKE e, em seguida, novamente com o Cloud NAT). A menos que precise de SNAT para ocultar os endereços IP dos pods em relação às redes no local ligadas pelo Cloud VPN ou Cloud Interconnect, disable-default-snat e descarregar a monitorização de SNAT para o Cloud NAT para escalabilidade. Esta solução funciona para todos os intervalos de IP de sub-rede principais e secundários. 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 aceder aos serviços Google.

Use o acesso privado Google para aceder aos serviços Google

Em clusters com nós privados, os pods não têm endereços IP públicos para contactar serviços públicos, incluindo APIs e serviços Google. O acesso privado à Google permite que os recursos privados Trusted Cloud by S3NS alcancem os serviços Google.

O acesso privado à Google está ativado por predefinição em clusters com nós privados, exceto para clusters de VPC partilhada.

Práticas recomendadas de escalabilidade de aplicações

Quando criar aplicações acessíveis externamente ou internamente à sua organização, certifique-se de que usa o tipo e as opções de balanceador de carga corretos. Esta secção apresenta algumas recomendações sobre a exposição e o dimensionamento de aplicações com o Cloud Load Balancing.

Use o balanceamento de carga nativa do contentor

Use o balanceamento de carga nativo do contentor quando expõe serviços através de HTTP(S) externamente. O balanceamento de carga nativa do contentor permite menos saltos de rede, uma latência mais baixa e uma distribuição de tráfego mais exata. Também aumenta a visibilidade no tempo de resposta e permite-lhe usar funcionalidades de equilíbrio de carga, como o Google Cloud Armor.

Escolha o recurso do GKE correto para expor a sua aplicação

Consoante o âmbito dos seus clientes (internos, externos ou até mesmo internos ao cluster), a regionalidade da sua aplicação e os protocolos que usa, existem diferentes recursos do GKE que pode optar por usar para expor a sua aplicação. A vista geral da rede de serviços explica estas opções e pode ajudar a escolher o melhor recurso para expor cada parte da sua aplicação através das Trusted Cloud by S3NS opções de equilíbrio de carga.

Crie verificações de funcionamento com base no BackendConfig

Se usar um Ingress para expor serviços, use uma configuração de verificação de funcionamento num CRD BackendConfig para usar a funcionalidade de verificação de funcionamento do Application Load Balancer externo. Pode direcionar a verificação de estado para o ponto final adequado e definir os seus próprios limites. Sem um CRD BackendConfig, as verificações de estado são inferidas a partir dos parâmetros da sondagem de disponibilidade ou usam os parâmetros predefinidos.

Use a política de tráfego local para preservar os endereços IP originais

Quando usa um Network Load Balancer de passagem interno com o GKE, defina a opção externalTrafficPolicy como Local para preservar o endereço IP de origem dos pedidos. Use esta opção se a sua aplicação exigir o endereço IP de origem original. No entanto, a opção externalTrafficPolicy local pode levar a uma distribuição da carga menos ideal, pelo que só deve usar esta funcionalidade quando for necessário. Para serviços HTTP(S), pode usar controladores de entrada e obter o endereço IP original lendo o cabeçalho X-Forwarded-For no pedido HTTP.

Use o Private Service Connect

Pode usar o Private Service Connect para partilhar serviços do balanceador de carga de rede de encaminhamento interno noutras redes VPC. Isto é útil para serviços alojados em clusters do GKE, mas que atendem clientes que estão a ser executados em projetos e VPCs diferentes.

Pode usar o Private Service Connect para reduzir o consumo de endereços IP, fornecendo conetividade entre VPCs com endereços IP sobrepostos.

Práticas recomendadas operacionais

As secções seguintes contêm práticas recomendadas operacionais que ajudam a garantir opções de autorização detalhadas para as suas cargas de trabalho. Para evitar a criação de regras de firewall manuais, siga as práticas recomendadas operacionais nesta secção. Também inclui recomendações para distribuir as suas cargas de trabalho e para monitorizar e registar no GKE.

Use o IAM para autorizações do GKE para controlar políticas em redes de VPC partilhada

Quando usa redes VPC partilhadas, as regras de firewall para equilibradores de carga são criadas automaticamente no projeto anfitrião.

Para evitar ter de criar regras de firewall manualmente, atribua uma função personalizada com privilégios mínimos à conta de serviço do GKE no projeto anfitrião denominado service-HOST_PROJECT_NUMBER@container-engine-robot.s3ns.iam.gserviceaccount.com.

Substitua HOST_PROJECT_NUMBER pelo número do projeto do projeto anfitrião da VPC partilhada.

A função personalizada que criar deve ter as seguintes autorizações:

• compute.firewalls.create
• compute.firewalls.get
• compute.firewalls.list
• compute.firewalls.delete

Além disso, as regras de firewall criadas pelo GKE têm sempre a prioridade predefinida de 1000, pelo que pode impedir o fluxo de tráfego específico criando regras de firewall com uma prioridade mais elevada.

Se quiser restringir a criação de determinados tipos de balanceadores de carga, use as políticas organizacionais para restringir a criação de balanceadores de carga.

Use clusters regionais e distribua as suas cargas de trabalho para garantir uma elevada disponibilidade

Os clusters regionais podem aumentar a disponibilidade de aplicações num cluster porque o painel de controlo e os nós do cluster estão distribuídos por várias zonas.

No entanto, para ter a melhor experiência do utilizador possível em caso de falha de uma zona, use o escalador automático do cluster para garantir que o cluster consegue processar a carga necessária em qualquer altura.

Também pode usar a antafinidade de pods para garantir que os pods de um determinado serviço são agendados em várias zonas.

Use o Cloud Logging e o Cloud Monitoring, e ative o registo de políticas de rede

Embora cada organização tenha requisitos diferentes para visibilidade e auditoria, recomendamos que ative o registo da política de rede. Esta funcionalidade só está disponível com o GKE Dataplane V2. O registo da política de rede oferece visibilidade sobre a aplicação de políticas e os padrões de tráfego de pods. Tenha em atenção que existem custos envolvidos no registo da política de rede.

Para clusters do GKE que usam a versão 1.14 ou posterior, o registo e a monitorização estão ativados por predefinição. A monitorização fornece um painel de controlo para os seus clusters do GKE. O registo também permite anotações do GKE para registos de fluxo de VPC. Por predefinição, o Logging recolhe registos para todas as cargas de trabalho implementadas no cluster, mas também existe uma opção de registos apenas do sistema. Use o painel de controlo do GKE para observar e definir alertas. Para clusters criados no modo Autopilot, a monitorização e o registo são ativados automaticamente e não são configuráveis.

Resumo da lista de verificação

O que se segue?

• Estatísticas de práticas recomendadas do GKE
• Práticas recomendadas para a multilocação empresarial