Esta página foi traduzida pela API Cloud Translation.

Saiba mais sobre a arquitetura de rede do GKE

Autopilot Standard

A rede do Google Kubernetes Engine (GKE) usa e estende a infraestrutura de rede definida por software (SDN) fornecida pela nuvem privada virtual (VPC). Com a rede do GKE, seus componentes podem se comunicar em um cluster do Kubernetes e com serviços e redes externas. O modelo de rede do GKE se baseia no princípio de rede do Kubernetes, em que cada pod recebe um endereço IP próprio, para fornecer endereçamento IP, balanceamento de carga, resolução de DNS e aplicação de políticas de rede. Este documento explica como os componentes principais, como nós, pods e serviços, interagem com o plano de controle no contexto da rede do GKE, abordando o seguinte:

Como esses componentes interagem na sua VPC
Como os endereços IP são alocados e gerenciados
Como o tráfego flui para dentro, dentro e para fora do cluster

Arquitetura de uma rede do GKE

Uma rede do GKE é criada com base na nuvem privada virtual (VPC) do Google Cloud. Essa base oferece conectividade robusta e escalonável para todos os seus aplicativos em contêineres.

A base da VPC e os intervalos de endereços IP

Na VPC, você define sub-redes, que são intervalos regionais de endereços IP. O GKE usa estrategicamente diferentes intervalos de endereços IP nessas sub-redes para vários componentes do cluster, geralmente usando intervalos de endereços IP de alias da VPC:

Intervalo de endereços IP do nó: é o intervalo de endereços IP principal da sub-rede em que os nós do cluster são implantados. Todos os nós de trabalho do GKE, que são VMs do Compute Engine, recebem os endereços IP principais desse intervalo. Esses endereços IP são usados para comunicação entre nós e para verificações de integridade de balanceadores de carga. O endereço IP do nó também é a origem do tráfego que se origina no próprio nó. Em clusters nativos de VPC, o tráfego de pods usa o endereço IP do pod como o endereço de origem, a menos que ele seja traduzido por um recurso como o Cloud NAT.
Intervalo de endereços IP do pod: um intervalo de endereços IP secundário dedicado, geralmente um bloco CIDR maior, que está na sua sub-rede. Cada nó recebe um pool de endereços IP desse intervalo. O GKE atribui esses endereços IP aos pods executados nesse nó. Cada pod no cluster recebe um endereço IP exclusivo desse intervalo. Esses endereços IP de pod podem ser roteados nativamente na sua nuvem privada virtual. Por padrão, cada nó recebe um intervalo /24, que fornece 256 endereços IP. No entanto, o GKE limita o número máximo de pods por nó a 110. Esse buffer ajuda a garantir a disponibilidade de endereços IP durante a criação e exclusão rápidas de pods, também conhecidas como rotatividade. Esses endereços IP permitem a comunicação direta entre pods em diferentes nós sem exigir a conversão de endereços de rede (NAT).
Intervalo de endereços IP de serviço (ClusterIP): um intervalo de endereços IP secundário para os endereços IP virtuais (ClusterIPs) atribuídos aos serviços do Kubernetes. Esses endereços IP estáveis são usados apenas para comunicação dentro do cluster.
Endereço IP do plano de controle: cada plano de controle tem um endereço IP público ou interno, dependendo do tipo de cluster, da versão e da data de criação. Esse endereço IP é usado por nós de trabalho e clientes externos, como kubectl, para se comunicar com segurança com o servidor da API Kubernetes. O GKE Frontend (GKFE) fornece um endpoint baseado em DNS para cada cluster, oferecendo uma maneira segura e confiável de acessar o plano de controle sem gerenciar diretamente os endereços IP.

Os três pilares da rede do GKE

A rede do GKE consiste em três pilares interconectados, cada um representando uma camada distinta de comunicação. Esse framework ajuda você a entender como os aplicativos se comunicam dentro do cluster e com redes externas:

Rede de pods: a camada fundamental, que define como os contêineres individuais (pods) se comunicam entre si no cluster.
Rede de serviços: criada com base na rede de pods, essa camada descreve como os serviços do Kubernetes fornecem endpoints estáveis para expor aplicativos a clientes internos ou externos, incluindo balanceamento de carga e descoberta de serviços.
Rede de cluster: a camada mais externa, que abrange como todo o cluster do GKE se conecta ao ecossistema de rede mais amplo, incluindo o gerenciamento de entrada da Internet, saída para serviços externos e conectividade com serviços Google Cloud e sistemas locais.

Essas camadas trabalham juntas para criar um modelo de comunicação abrangente que oferece suporte à conectividade, segurança e escalonabilidade internas e externas. As seções a seguir exploram cada pilar em detalhes.

Redes de pods

A rede de pods é a base de toda a comunicação em um cluster do GKE. Ele define como os aplicativos em execução nos pods podem se encontrar e interagir entre si. No Kubernetes, um pod é a menor e mais básica unidade implantável. Um pod atua como um host lógico para seus aplicativos. Ele executa um ou mais contêineres que compartilham recursos de rede. Quando um pod é programado em um nó, o Kubernetes cria um namespace de rede dedicado para ele no kernel Linux do nó, que isola a rede de outros pods no mesmo nó.

Como funciona a rede de pods

A rede de pods é estabelecida por uma combinação de endereços IP exclusivos, dispositivos de rede virtual e plug-ins especializados que gerenciam a conectividade.

Interface de rede de contêiner (CNI): o GKE usa plug-ins CNI para implementar e gerenciar a rede de pods. Para clusters nativos de VPC, o padrão é o Google CNI. Outras opções incluem kubenet (para clusters não nativos de VPC), Calico e GKE Dataplane V2 (baseado no Cilium). Esses plug-ins são responsáveis por conectar pods à rede e aplicar políticas de rede.

Alocação de endereços IP: cada nó recebe um pool de endereços IP do intervalo de endereços IP do pod para atribuir aos pods. O GKE reserva uma parte desses endereços para criar um buffer que garante a disponibilidade de endereços IP durante a rotatividade rápida de pods (criação e destruição). É por isso que o número de endereços IP de pods alocáveis por nó é sempre menor que o tamanho do intervalo.
Namespaces de rede e pares Ethernet virtuais (veth): para facilitar a comunicação, o Kubernetes conecta o namespace de rede isolado do pod ao namespace de rede principal ou raiz do nó. O Kubernetes faz essa conexão usando um par Ethernet virtual, ou par veth, que funciona como um cabo de rede virtual. Uma extremidade do par é colocada dentro do namespace do pod e aparece como eth0. A outra extremidade se conecta a uma ponte de rede ou diretamente à pilha de rede do nó no namespace raiz dele, o que permite o fluxo de pacotes para e do pod.

O método de conexão específico depende do plug-in CNI usado pelo cluster:
- CNI do Google: é a CNI padrão para clusters nativos da VPC. O par veth do pod se conecta ao namespace de rede raiz do nó. Como os endereços IP do pod são endereços IP de alias conhecidos pela rede VPC, o roteamento padrão do Linux no nó direciona o tráfego para e do pod.
- GKE Dataplane V2: usa programas eBPF para processar a rede de pods e geralmente ignora pontes Linux convencionais e pares veth para gerenciar diretamente fluxos de pacotes no kernel para maior desempenho.
- Kubenet: usado em clusters não nativos de VPC. A outra extremidade do par veth se conecta a um dispositivo de ponte do Linux chamado cbr0 no namespace raiz do nó. Essa ponte gerencia o tráfego entre pods no mesmo nó e usa NAT para o tráfego que sai do nó.
- Calico: quando a política de rede é ativada com o Calico, a outra extremidade do par veth se conecta ao namespace raiz do nó, e o Calico programa rotas de host para direcionar o tráfego aos pods corretos.

Unidade máxima de transmissão (MTU): determina o maior tamanho de pacote que pode ser enviado por uma rede sem ser fragmentado. No GKE, a MTU para a interface de um pod é uma configuração crítica que depende do plug-in CNI do GKE usado pelo cluster e das configurações de MTU da rede VPC subjacente. Uma incompatibilidade nos valores de MTU pode causar perda de pacotes ou degradação do desempenho. O valor da MTU da interface do pod é um valor fixo de 1.460 bytes ou é herdado da interface de rede principal do nó, conforme mostrado na tabela a seguir.

CNI	MTU	Uso
CNI do Google	1460	Padrão para clusters nativos de VPC que usam versões do GKE anteriores à 1.26.1.
CNI do Google	Herdado	Padrão para clusters nativos de VPC que usam as versões 1.26.1 e mais recentes do GKE.
Calico	1460	Usado quando a política de rede está ativada (`--enable-network-policy`).
GKE Dataplane V2	Herdado	Usado quando o GKE Dataplane V2 está ativado (`--enable-dataplane-v2`).
netd	Herdado	Usado quando recursos como visibilidade "Intranode", federação de identidade da carga de trabalho para GKE ou rede de pilha dupla IPv4/IPv6 estão ativados.

Fluxo de comunicação entre pods

O Kubernetes usa um modelo de rede plana, em que cada pod tem um endereço IP exclusivo e roteável. Esse modelo ajuda a garantir uma conectividade perfeita entre os pods.

Comunicação no mesmo nó

Quando um pod envia tráfego para outro no mesmo nó, a solicitação flui do namespace de rede do primeiro pod, passa pelo par veth e chega ao namespace de rede raiz do nó. Esse tráfego permanece dentro do nó. Dependendo do plug-in CNI usado, ele encaminha o tráfego para o par veth do segundo pod. Por exemplo, com o kubenet, um dispositivo de ponte encaminha o tráfego. Com o GKE Dataplane V2, os programas eBPF gerenciam o fluxo de pacotes diretamente.

Comunicação entre diferentes nós

Quando um pod em um nó envia tráfego para um pod em outro nó, o tráfego flui para o namespace da rede raiz do primeiro nó. Em seguida, o tráfego sai da interface de rede principal do primeiro nó e entra na rede VPC. Como os endereços IP do pod são nativamente roteáveis em um cluster do GKE nativo da VPC, a rede VPC roteia o tráfego diretamente para o segundo nó. Em seguida, o segundo nó encaminha o tráfego para o pod de destino.

Pods de rede do host

Para casos de uso específicos, é possível configurar um pod com a configuração hostNetwork: true. Essa configuração ignora a rede isolada do pod e permite que ele compartilhe o namespace de rede do nó diretamente. Com esse acesso direto, o pod usa o endereço IP do nó e pode se comunicar com todos os outros pods sem precisar do NAT. Em clusters que usam o plug-in CNI kubenet, esse comportamento é diferente dos pods comuns. Os pods regulares exigem NAT para o tráfego de saída porque os endereços IP deles não podem ser roteados diretamente na rede VPC. Por outro lado, a rede nativa da VPC do GKE torna essa tradução desnecessária para todos os pods. No entanto, ao configurar pods com a configuração hostNetwork: true, evite conflitos de porta com outros processos ou pods que são executados no mesmo nó. Em clusters que usam a CNI kubenet, a ponte de rede virtual cbr0 só é criada se o nó tiver pods com a configuração hostNetwork: false.

Rede de serviços

Embora a rede de pods forneça a conectividade fundamental entre pods individuais, ela não é suficiente para criar aplicativos robustos e escalonáveis. Os pods são temporários. Eles podem ser criados, destruídos e reprogramados a qualquer momento. Essa situação faz com que os endereços IP deles mudem. A rede de serviços resolve esse problema oferecendo uma maneira estável e confiável de expor aplicativos e gerenciar como eles se comunicam, tanto dentro do cluster quanto com o mundo externo.

Um serviço do Kubernetes é uma abstração que define um conjunto lógico de pods e uma política para acessá-los. Os serviços usam rótulos para agrupar vários pods relacionados em uma única unidade lógica. Quando você cria um Serviço, o Kubernetes atribui a ele um endereço IP virtual estável, conhecido como ClusterIP, de um pool de endereços reservados para Serviços. Esse ClusterIP, junto com um nome DNS associado, permanece constante durante todo o ciclo de vida do serviço, fornecendo um endpoint consistente que outros aplicativos podem usar para se conectar aos pods.

Como a rede de serviços funciona

A rede de serviços depende de dois mecanismos principais para rotear o tráfego de um endpoint estável de serviço para os pods de back-end dinâmicos: descoberta de serviços e balanceamento de carga.

Descoberta de serviços: para que os aplicativos se encontrem e se comuniquem, o GKE fornece um serviço de DNS interno (kube-dns ou Cloud DNS). Quando você cria um serviço, o serviço DNS cria automaticamente um registro DNS correspondente. Esse registro permite que os aplicativos se conectem ao serviço usando o nome DNS dele (por exemplo, my-app-service) em vez de precisar saber o ClusterIP. Embora kube-dns seja o padrão para clusters Standard, o Cloud DNS para GKE é a solução recomendada para a maioria dos ambientes de produção. Ela também é a única solução compatível com clusters do Autopilot do GKE. Esse serviço é totalmente gerenciado, escalonável e altamente disponível. Ele se integra à rede VPC e ao Cloud Logging, oferecendo melhor desempenho e capacidade de observação sem exigir que você gerencie os pods do kube-dns.

Mecanismos de balanceamento de carga: a implementação do balanceamento de carga de serviço depende do modo de rede do cluster do GKE.

GKE Dataplane V2: os clusters que usam o GKE Dataplane V2 (baseado no Cilium) não usam kube-proxy para balanceamento de carga de serviço. Em vez disso, o GKE Dataplane V2 usa programas eBPF que são executados no kernel do Linux. Esses programas eBPF são altamente eficientes para interceptar o tráfego para ClusterIPs de serviço e balancear a carga do tráfego diretamente para os pods de back-end apropriados. Essa abordagem resulta em melhor desempenho e é totalmente integrada aos recursos de aplicação de políticas de rede do GKE Dataplane V2.
kube-proxy (para clusters sem o GKE Dataplane V2): em todos os nós de um cluster do GKE que não usa o GKE Dataplane V2, um componente chamado kube-proxy implementa o mecanismo de endereço IP virtual para serviços. O kube-proxy monitora o servidor da API Kubernetes para detectar mudanças em serviços e endpoints e programa regras de rede no nó para interceptar o tráfego destinado ao ClusterIP de um serviço.

O kube-proxy pode operar em diferentes modos, incluindo:
- Modo iptables: é o modo padrão. O kube-proxy adiciona e remove regras de NAT de destino (DNAT) no subsistema iptables do nó. Quando o tráfego chega para um ClusterIP de um serviço, essas regras realizam uma tradução NAT e mudam o endereço IP de destino para um dos pods de back-end íntegros. O balanceamento de carga entre pods de back-end geralmente é aleatório ou em rodízio.
- Modo ipvs: usa o IP Virtual Server (IPVS) do Linux para balanceamento de carga de alta performance. O kube-proxy configura regras do IPVS, que podem processar um grande número de serviços e fornecer algoritmos de balanceamento de carga mais sofisticados.

Exemplo de fluxo de comunicação interna

A lista a seguir descreve como uma solicitação flui de um pod cliente para um pod servidor usando um serviço em um cluster que não usa o GKE Dataplane V2:

O aplicativo cliente faz uma consulta DNS para my-server-service.
O serviço de DNS interno do cluster resolve esse nome para o ClusterIP estável do serviço (por exemplo, 10.0.32.8).
O pod cliente envia uma solicitação para o ClusterIP do serviço.
As regras de iptables no nó do cliente, gerenciadas por kube-proxy, interceptam essa solicitação.
Essas regras iptables executam o DNAT e selecionam um dos pods de back-end íntegros para my-server-service (por exemplo, o pod 2 com o endereço IP 10.4.0.3). As regras também reescrevem o endereço IP de destino do pacote para o endereço IP do pod.
O pacote é roteado pela rede plana de pods para o pod 2, que processa a solicitação.

Em clusters que usam o GKE Dataplane V2, os programas eBPF processam a interceptação e o balanceamento de carga do tráfego para o ClusterIP do serviço, ignorando kube-proxy e iptables.

Exemplo de manifesto de serviço

O exemplo a seguir mostra um manifesto de serviço. O campo selector especifica quais pods recebem tráfego com base nos rótulos.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

Recursos da rede de serviços

A rede de serviços do GKE oferece vários recursos para gerenciar o fluxo de tráfego e expor aplicativos, tanto interna quanto externamente.

Balanceamento de carga interno e externo: para serviços que precisam ser acessados apenas de dentro do cluster, o kube-proxy (ou GKE Dataplane V2) processa o balanceamento de carga internamente. Para serviços que precisam ser expostos à Internet, o GKE provisiona automaticamente um balanceador de carga na nuvem para distribuir o tráfego externo aos nós do cluster.
Balanceadores de carga de aplicativo para roteamento HTTP(S): para tráfego HTTP(S), o GKE usa um balanceador de carga especializado da camada 7, o balanceador de carga de aplicativo. Você configura esse balanceador de carga usando a API Gateway do Kubernetes, que é a abordagem recomendada para todos os novos aplicativos. O controlador do gateway do GKE é a implementação do Google da API Gateway e foi projetado para ser um sucessor mais expressivo, flexível e extensível do recurso Entrada. A API Gateway usa os seguintes recursos para configurar o balanceador de carga:
- Gateway:define configurações de listener, como portas, protocolos e nomes de host. Ele funciona como o ponto de entrada do tráfego.
- HTTPRoute:especifica como o tráfego recebido por um gateway é roteado para serviços. Ele oferece suporte a recursos avançados, como roteamento baseado em caminho, correspondência de cabeçalho e divisão de tráfego.
- Política:define como a infraestrutura Google Cloud subjacente deve funcionar ao ser anexada a um gateway, uma rota ou um serviço.
Integração da malha de serviço: para arquiteturas complexas de microsserviços, o GKE oferece suporte a tecnologias de malha de serviço. Uma malha de serviço é uma camada de infraestrutura opcional que oferece recursos avançados para gerenciamento de tráfego, observabilidade e segurança. Para uma experiência totalmente gerenciada e com suporte, o GKE oferece o Cloud Service Mesh, que é criado no Istio.

Rede de cluster

A rede de cluster é a camada mais externa da rede do GKE. Ele se concentra em como todo o cluster do Kubernetes interage com recursos e redes externas, incluindo como os clientes da Internet acessam seus aplicativos, como os pods acessam APIs externas e como o cluster se conecta a data centers locais. A rede de cluster é criada com base na infraestrutura de VPC do Google Cloud.

Gerenciar o tráfego de entrada

O tráfego de entrada é aquele que entra no cluster do mundo externo. O GKE usa vários recursos Google Cloud integrados para gerenciar e proteger esse tráfego.

Fluxo de dados de acesso externo: quando um cliente da Internet envia uma solicitação para seu aplicativo (geralmente exposto por um serviço do tipo LoadBalancer ou um recurso de entrada ou gateway), ele primeiro chega a um balanceador de carga Google Cloud . O balanceador de carga encaminha a solicitação para um nó íntegro no cluster. O nó encaminha o tráfego para o pod apropriado. O kube-proxy processa esse encaminhamento em clusters que não usam o GKE Dataplane V2, ou os programas eBPF processam em clusters que usam o GKE Dataplane V2. O pod de destino pode estar no mesmo nó ou em um nó diferente.

Regras de firewall: os clusters do GKE usam regras de firewall da VPC para controlar o tráfego de entrada. Embora o GKE crie automaticamente algumas regras de firewall padrão para operações essenciais do cluster, como permitir que o plano de controle alcance os nós, é possível definir regras personalizadas para atender aos seus requisitos de segurança específicos. Essas regras de firewall da VPC funcionam com as políticas de rede do Kubernetes para oferecer defesa em profundidade controlando o tráfego nos níveis de nó e pod.

Otimização do fluxo de tráfego externo: quando um balanceador de carga envia tráfego para um nó, ele pode precisar encaminhar esse tráfego para um pod em um nó diferente, o que exige saltos de rede extras. Para evitar essa situação, defina o campo externalTrafficPolicy como Local no manifesto do serviço. Quando essa política está ativa, o balanceador de carga usa uma verificação de integridade para identificar quais nós têm pods íntegros para o serviço de destino. O balanceador de carga envia tráfego apenas para os pods íntegros, o que evita o salto de rede adicional. A desvantagem é que essa política pode levar a uma distribuição desigual do tráfego se os pods de back-end não estiverem distribuídos de maneira uniforme pelos nós do cluster.

Gerenciar o tráfego de saída

Saída é o tráfego que sai do cluster. Para que um cluster do GKE funcione e seus aplicativos alcancem serviços externos, é necessário gerenciar vários caminhos de conectividade.

Requisitos fundamentais de conectividade: todos os clusters do GKE exigem conectividade de saída com os domínios *.googleapis.com, *.gcr.io e *.pkg.dev. A conectividade de saída com o endereço IP do plano de controle também precisa funcionar corretamente. Acesso à Internet para pods usando o Cloud NAT: em clusters particulares em que os pods não têm endereços IP públicos, use o Cloud NAT para ativar o acesso à Internet de saída. O Cloud NAT é um serviço gerenciado que permite que os pods se conectem à Internet para tarefas como baixar atualizações ou acessar APIs externas sem expor conexões de entrada.

Conectividade com Google Cloud serviços: se você precisar permitir que seu cluster se comunique com segurança com outros serviços Google Cloud , como o Cloud Storage ou o Cloud SQL, sem passar pela Internet pública, use o Acesso privado do Google. Esse é um mecanismo de saída importante para clusters particulares que interagem com as APIs do Google.

Conectividade híbrida e com vários clusters

Para conectar seus clusters do GKE à infraestrutura local, use o Cloud VPN para túneis criptografados ou o Cloud Interconnect para conexões dedicadas de alta largura de banda. Para ativar a comunicação entre vários clusters do GKE, use os serviços de vários clusters, que facilitam a descoberta de serviços e o fluxo de tráfego em diferentes clusters, regiões ou projetos.

Controles de segurança de rede

Para proteger seu cluster e os aplicativos em execução nele, o GKE oferece várias camadas de controles de segurança para tráfego interno (leste-oeste) e externo (norte-sul).

Como proteger o tráfego interno (leste-oeste) com políticas de rede

Por padrão, todos os pods em um cluster do GKE podem se comunicar livremente entre si. Para proteger o tráfego interno e aplicar o princípio de menor privilégio, use NetworkPolicy. Uma NetworkPolicy é um recurso do Kubernetes que atua como um firewall para seus pods, controlando o tráfego de rede entre eles. Com os recursos NetworkPolicy, é possível definir regras para restringir o tráfego de entrada e saída de um grupo selecionado de pods com base em uma combinação de rótulos, intervalos de endereços IP e números de porta. Quando você cria o primeiro NetworkPolicy em um namespace, todo o tráfego que não é explicitamente permitido por essa política é negado. A aplicação dessas políticas é integrada diretamente ao GKE Dataplane V2 ou é processada pelo plug-in CNI do cluster, como o Calico.

Exemplo de manifesto `NetworkPolicy`

O exemplo a seguir mostra um manifesto NetworkPolicy. Essa política se aplica a pods com o rótulo app: backend e permite o tráfego de entrada somente de pods que têm o rótulo app: frontend na porta TCP 6379.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

Proteger o acesso externo ao cluster

Controlar o tráfego que entra e sai do cluster é fundamental para proteger seus aplicativos contra ameaças externas.

Regras de firewall da VPC

Os clusters do GKE residem em uma rede VPC e são protegidos por regras de firewall da VPC que controlam o tráfego de e para os nós do cluster. Google Cloud As regras de firewall da VPC e as políticas de rede funcionam juntas para oferecer defesa em profundidade. Os firewalls da VPC operam no nível do nó (camada 3 ou 4) e controlam o tráfego para as próprias VMs. As políticas de rede operam no nível do pod (camada 3 ou camada 4) e oferecem um controle mais granular sobre o tráfego entre aplicativos dentro do cluster.

Criar regras de firewall de entrada ou saída que segmentam nós no cluster pode ter efeitos adversos. Por exemplo, aplicar regras de negação de saída a nós no cluster pode interromper recursos como NodePort e kubectl exec.

Limitar o acesso aos balanceadores de carga

Ao expor aplicativos usando um serviço ou Entrada do Kubernetes, é possível aplicar outros controles de segurança no nível do balanceador de carga. Para balanceadores de carga externos, considere estas opções:

Se você expor um serviço usando o campo type: LoadBalancer, poderá especificar o campo loadBalancerSourceRanges no manifesto do serviço. Esse campo restringe o acesso ao serviço apenas aos intervalos de endereços IP que você define.
Para balanceadores de carga de aplicativo (Entrada), é possível usar serviços de segurança mais avançados ao expor aplicativos HTTP(S):
- Google Cloud Armor: esse serviço é um firewall de aplicativos da Web (WAF) que ajuda a proteger seus aplicativos contra ataques DDoS e outras ameaças cibernéticas.
- Identity-Aware Proxy (IAP): para controle de acesso detalhado, você pode ativar o IAP nos seus endpoints. O IAP verifica a identidade de um usuário e a usa para determinar se ele deve ter permissão para acessar o aplicativo.

A seguir

Aprenda a criar um cluster nativo de VPC.
Leia mais sobre o GKE Dataplane V2.
Implemente políticas de rede para proteger a comunicação entre pods.
Confira diferentes maneiras de expor aplicativos usando serviços e configurar Entrada com a API Gateway.