Práticas recomendadas para redes do GKE

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 clusters, recomendamos que você analise todas as seções para entender as opções e implicações de rede. Este documento não se destina a introduzir a terminologia ou conceitos de rede do Kubernetes. Ele supõe que você já tenha algum nível de conhecimento de redes do Kubernetes. Para mais informações, consulte a visão geral de redes no GKE.

Ao analisar este documento, considere o nível de exposição e tipo de cluster, como você pretende expor as cargas de trabalho internamente à rede da nuvem privada virtual (VPC) ou externamente à Internet, como pretende escalonar suas cargas de trabalho e que tipos de serviços do Google que serão consumidos.

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

Antes de criar um cluster, é preciso escolher um cluster baseado em rotas ou um cluster nativo de VPC. Recomendamos escolher um cluster nativo de VPC, porque eles usam intervalos de endereços IP de alias em nós do GKE e são escalonados com mais facilidade que os clusters baseados em rotas. Os clusters nativos de VPC são necessários para os clusters particulares do GKE e para a criação de clusters nas VPCs compartilhadas. 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 participantes específicos. Em seguida, crie clusters do GKE em projetos de serviço nessas sub-redes.

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.

Estratégias de gerenciamento de endereços IP

Os clusters do Kubernetes exigem um endereço IP exclusivo para cada pod. 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 privado 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.

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 clusters nativos de VPC são compatíveis e requerem que os seguintes intervalos de IP sejam definidos:

  • Intervalo de endereços IP do plano de controle: uma sub-rede RFC 1918/28 que não pode sobrepor outros tipos de 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. Serviços com o tipo LoadBalancer que usam a anotação cloud.google.com/load-balancer-type: "Internal" também usam essa sub-rede.
  • Intervalo de endereços IP do pod: o intervalo de IP que você aloca para todos os pods no cluster, também conhecido como CIDR do cluster.
  • Intervalo de endereços IP de serviço: o intervalo de endereços IP alocado para todos os serviços do cluster, também conhecido como CIDR de serviços.

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 endereços IP no grupo de peering de VPC.

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. 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 grandes o suficiente para acomodar todos os nós, pods e serviços do cluster.

Usar espaço não RFC 1918, se necessário

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 o uso de parte do espaço de endereço RFC 6598 (100.64.0.0/10) porque o espaço de endereço da Class E pode apresentar problemas de interoperabilidade com o hardware local (links em inglês). Além disso, ao usar IPs públicos reutilizados de maneira particular, tenha cuidado e considere controlar as divulgações de rota em redes locais para a Internet ao escolher essa opção.

Evite o uso de SNAT no pod de cluster para pod e tráfego de serviços. Ao usar IPs públicos reutilizados com clusters particulares, o comportamento padrão pressupõe o SNAT para todo o espaço de endereços não RFC 1918. Para corrigir isso, configure o agente de mascaramento de IP corretamente. O nonMasqueradeCIDRs precisa conter pelo menos o CIDR do cluster e o CIDR dos serviços.

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 da rede pode 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ó. 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.

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 ativar e desativar nós no cluster dinamicamente para 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.

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.

Escolher um tipo de cluster particular

Existem dois tipos de isolamento de rede para clusters: público e privado. 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 privados dão mais isolamento porque têm apenas endereços IP privados 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 que você escolha clusters particulares para o isolamento de rede.

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:

Comunicação de cluster particular
Diagrama 1: comunicação de cluster particular

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 sinalização --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 particulares. 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:

conectividade do plano de controle usando redes
autorizadas:
Diagrama 2: conectividade 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. Para mais informações, consulte Como criar clusters particulares do Kubernetes usando proxies de rede para acesso ao 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 GKE são aplicadas no nível do pod para impor caminhos de tráfego do pod. Para mais informações, consulte Blueprint de segurança do Anthos: como restringir o tráfego.

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 (em inglês).

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 gcloud --enable-dataplane-v2 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.

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 balanceamento de carga do HTTP(S) externo 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 entrada para balanceamento de carga do HTTP(S) externo e adicionando uma política de segurança ao BackendConfig anexado ao objeto de 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 do balanceador de carga a determinados tipos, como apenas balanceadores de carga internos, ou restringir o uso de endereços IP externos.

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.

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 opção de ferramenta de linha de comando gcloud a seguir ativa o NodeLocal DNSCache ao criar 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.

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 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 entrar em contato com 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. Os serviços típicos do Google compatíveis com o Acesso privado do Google incluem BigQuery, autorização binária, Artifact Registry e muito mais.

Essa opção fica desativada por padrão e precisa ser ativada na sub-rede associada ao cluster durante a criação da sub-rede.

A opção da ferramenta de linha de comando --enable-private-ip-google-access gcloud ativa o Acesso privado do Google quando você cria a sub-rede.

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.

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. Ele também aumenta a visibilidade no tempo de retorno e permite usar recursos de balanceamento de carga, como o Cloud CDN e 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 podem 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 balanceamento de carga HTTP(S). É 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 TCP/UDP 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.

Operações e administração

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 a Identidade da carga de trabalho para autenticar as cargas de trabalho nas APIs do Google

Use a Identidade da carga de trabalho para acessar outros serviços do Google Cloud no cluster do GKE. A Identidade da carga de trabalho ajuda a manter o princípio de privilégio mínimo ao vincular contas de serviço do Kubernetes a contas de serviço do Google. As contas de serviço do Kubernetes podem ser atribuídas a pods, o que permite ter permissões granulares para acessar APIs do Google por carga de trabalho. A identidade da carga de trabalho é ativada por padrão nos clusters do Autopilot.

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 não precisar criar regras de firewall manualmente, conceda o papel Administrador de segurança do Compute à conta de serviço do GKE no projeto host chamado service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com. Substitua HOST_PROJECT_NUMBER pelo número do projeto host da VPC compartilhada.

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 Operations for GKE e geração de registro 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 (Beta). Este recurso só está disponível no GKE Dataplane v2 , também na versão Beta. 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 posterior, o Cloud Operations for GKE permite o monitoramento e a geração de registros por padrão, além de fornecer um painel para os clusters do GKE. Ele também ativa as anotações do GKE para registros de fluxo de VPC. Por padrão, o Cloud Operations for GKE coleta registros de todas as cargas de trabalho implantadas no cluster, mas também existe uma opção de registros somente para sistema. Use o painel de Operações do Cloud para GKE para observar e definir alertas. Lembre-se de que há custos envolvidos no pacote de operações do Google Cloud. Para clusters criados no modo Autopilot, o Cloud Operations for GKE é ativado automaticamente e não configurável.

Lista de verificação resumida

A tabela a seguir resume as práticas recomendadas para configurar as opções de rede dos clusters do GKE.

Área Treinar
Design da VPC
Estratégias de gerenciamento de endereços IP
Segurança
Escalonamento
Como exibir aplicativos
Operações e administração

A seguir