Saiba mais sobre a arquitetura de rede do GKE

As redes do Google Kubernetes Engine (GKE) usam e expandem a infraestrutura de redes definidas por software (SDN) fornecida pela nuvem virtual privada (VPC). As redes do GKE permitem que os seus componentes comuniquem num cluster do Kubernetes e com serviços e redes externos. O modelo de rede do GKE baseia-se no princípio de rede do Kubernetes, em que cada Pod recebe o seu próprio endereço IP, para fornecer endereçamento IP, equilíbrio 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 controlo no contexto da rede do GKE, abrangendo o seguinte:

• Como estes componentes interagem na sua VPC
• Como os endereços IP são atribuídos e geridos
• Como o tráfego flui para dentro, dentro e para fora do cluster

Arquitetura de uma rede do GKE

Uma rede do GKE baseia-se na Cloud de Confiance by S3NS's nuvem privada virtual (VPC). Esta base oferece uma conetividade robusta e escalável para todas as suas aplicações em contentores.

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

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

• Intervalo de endereços IP dos nós: este é o intervalo de endereços IP principal da sub-rede onde os nós do cluster estão implementados. Todos os nós de trabalho do GKE, que são VMs do Compute Engine, recebem os respetivos endereços IP principais deste intervalo. Estes endereços IP são usados para comunicação entre nós e para verificações de estado de funcionamento dos equilibradores de carga. O endereço IP do nó também é a origem do tráfego que tem origem no próprio nó. Nos clusters nativos da VPC, o tráfego dos pods usa o endereço IP do pod como o endereço de origem, a menos que o endereço IP do pod seja traduzido por uma funcionalidade como o Cloud NAT.
• Intervalo de endereços IP do pod: um intervalo de endereços IP secundários dedicado, muitas vezes um bloco CIDR maior, que está dentro da sua sub-rede. Cada nó recebe um conjunto de endereços IP deste intervalo. O GKE atribui estes endereços IP a pods que são executados nesse nó. Cada Pod no seu cluster recebe o seu endereço IP exclusivo deste intervalo. Estes endereços IP de pods são encaminháveis nativamente na sua nuvem privada virtual. Por predefiniçã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. Este buffer ajuda a garantir a disponibilidade de endereços IP durante a criação e a eliminação rápidas de pods, também conhecidas como rotatividade. Estes endereços IP permitem a comunicação direta entre os pods em diferentes nós sem exigir a traduçã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 Kubernetes. Estes endereços IP estáveis são usados apenas para comunicação no cluster.
• Endereço IP do plano de controlo: cada plano de controlo tem um endereço IP público ou interno, consoante o tipo, a versão e a data de criação do cluster. Este endereço IP é usado pelos nós de trabalho e clientes externos, como o kubectl, para comunicar de forma segura com o servidor da API Kubernetes. O GKE Frontend (GKFE) fornece um ponto final baseado em DNS para cada cluster, oferecendo uma forma segura e fiável de aceder ao plano de controlo sem gerir diretamente os endereços IP.

Os três pilares da rede do GKE

A rede do GKE consiste em três pilares interligados, cada um que representa uma camada de comunicação distinta. Esta estrutura ajuda a compreender como as suas aplicações comunicam no cluster e com redes externas:

• Rede de pods: a camada fundamental que define como os contentores individuais (pods) comunicam entre si no cluster.
• Redes de serviços: baseada nas redes de pods, esta camada descreve como os serviços do Kubernetes fornecem pontos finais estáveis para expor aplicações a clientes internos ou externos, incluindo o equilíbrio de carga e a deteção de serviços.
• Rede de clusters: a camada mais externa, que abrange a forma como todo o seu cluster do GKE se liga ao ecossistema de rede mais amplo, incluindo a gestão da entrada da Internet, a saída para serviços externos e a conetividade com Cloud de Confiance by S3NS serviços e sistemas no local.

Estas camadas funcionam em conjunto para criar um modelo de comunicação abrangente que suporta a conetividade interna e externa, a segurança e a escalabilidade. As secções seguintes exploram cada pilar detalhadamente.

Redes de agrupamentos

A rede de pods é a base de toda a comunicação num cluster do GKE. Define a forma como as aplicações executadas nos pods podem encontrar-se e interagir entre si. No Kubernetes, um Pod é a unidade implementável mais pequena e mais básica. Um pod funciona como um anfitrião lógico para as suas aplicações. Executa um ou mais contentores que partilham recursos de rede. Quando um pod é agendado num nó, o Kubernetes cria um espaço de nomes de rede dedicado para o mesmo no kernel Linux do nó, o que isola a respetiva rede de outros pods no mesmo nó.

Como funciona a rede de pods

A rede de pods é estabelecida através de uma combinação de endereços IP únicos, dispositivos de rede virtuais e plug-ins especializados que gerem a conetividade.

Interface de rede de contentores (CNI): o GKE usa plug-ins CNI para implementar e gerir a rede de pods. Para clusters nativos de VPC, a predefinição é o CNI da Google. Outras opções incluem kubenet (para clusters não nativos da VPC), Calico e GKE Dataplane V2 (que se baseia no Cilium). Estes plug-ins são responsáveis por ligar os Pods à rede e aplicar as políticas de rede.

• Atribuição de endereços IP: cada nó recebe um conjunto de endereços IP do intervalo de endereços IP do pod para atribuir a pods. O GKE reserva uma parte destes endereços para criar um buffer que garante a disponibilidade de endereços IP durante a rápida rotatividade de pods (criação e destruição). É por causa desta reserva que o número de endereços IP de agrupamentos atribuíveis por nó é sempre inferior ao tamanho do intervalo.

• Espaços de nomes de rede e pares de Ethernet virtual (veth): para facilitar a comunicação, o Kubernetes liga o espaço de nomes de rede isolado do pod ao espaço de nomes de rede principal ou raiz do nó. O Kubernetes faz esta ligação através de um par de Ethernet virtual ou par veth, que funciona como um cabo de rede virtual. Uma extremidade do par é colocada no espaço de nomes do Pod e aparece como eth0. A outra extremidade liga-se a uma ponte de rede ou diretamente à pilha de rede do nó no espaço de nomes raiz do nó, o que permite o fluxo de pacotes de e para o pod.

  O método de ligação específico depende do plug-in CNI que o cluster usa:

  • CNI da Google: esta é a CNI predefinida para clusters nativos da VPC. O par veth do pod liga-se ao espaço de nomes da rede raiz do nó. Uma vez que os endereços IP dos pods são endereços IP com alias conhecidos pela rede VPC, o encaminhamento Linux padrão no nó direciona o tráfego para e a partir do pod.
  • GKE Dataplane V2: usa programas eBPF para processar a rede de pods e, muitas vezes, ignora as pontes Linux convencionais e os pares veth para gerir diretamente os fluxos de pacotes no kernel para um desempenho mais elevado.
  • Kubenet: é usado em clusters não nativos de VPC. A outra extremidade do par veth liga-se a um dispositivo de ponte Linux denominado cbr0 no espaço de nomes raiz do nó. Esta ponte gere o tráfego entre os pods no mesmo nó e usa NAT para o tráfego que sai do nó.
  • Calico: quando a política de rede está ativada com o Calico, a outra extremidade do par veth liga-se ao espaço de nomes raiz do nó e, em seguida, o Calico programa as rotas do anfitrião para direcionar o tráfego para os Pods corretos.

Unidade de transmissão máxima (MTU): determina o tamanho máximo do pacote que pode ser enviado através de uma rede sem ser fragmentado. No GKE, a MTU da interface de um pod é uma definição crítica que depende do plug-in CNI do GKE que o cluster usa e das definiçõ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 é de 1460 bytes fixos ou é herdado da interface de rede principal do nó, conforme mostrado na tabela seguinte.

Fluxo de comunicação entre agrupamentos

O Kubernetes usa um modelo de rede simples, em que cada Pod tem um endereço IP único e encaminhável. Este modelo ajuda a garantir uma conetividade perfeita entre os Pods.

Comunicação no mesmo nó

Quando um Pod envia tráfego para outro Pod no mesmo nó, o pedido flui do namespace de rede do primeiro Pod, através do respetivo par veth, e para o namespace de rede raiz do nó. Este tráfego permanece no nó. Consoante o plug-in CNI usado, o plug-in CNI encaminha o tráfego para o par veth do segundo pod. Por exemplo, com kubenet, um dispositivo de ponte encaminha o tráfego. Com o GKE Dataplane V2, os programas eBPF gerem o fluxo de pacotes diretamente.

Comunicação entre diferentes nós

Quando um Pod num nó envia tráfego para um Pod noutro nó, o tráfego flui para o espaço de nomes de rede raiz do primeiro nó. Em seguida, o tráfego sai da interface de rede principal do primeiro nó e entra na rede VPC. Uma vez que os endereços IP dos pods são nativamente encaminháveis num cluster do GKE nativo da VPC, a rede VPC encaminha 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 de anfitrião

Para exemplos de utilização específicos, pode configurar um Pod com a definição hostNetwork: true. Esta definição ignora a rede de pods isolada e permite que o pod partilhe o espaço de nomes de rede do nó diretamente. Com este acesso direto, o Pod usa o endereço IP do nó e pode comunicar com todos os outros Pods sem precisar de NAT. Em clusters que usam o plug-in CNI, este comportamento é diferente dos Pods normais.kubenet Os pods normais requerem NAT para o tráfego de saída porque os respetivos endereços IP não são diretamente encaminháveis na rede da VPC. Por outro lado, a rede nativa da VPC do GKE torna esta tradução desnecessária para todos os pods. No entanto, quando configurar agrupamentos com a definição hostNetwork: true, tenha cuidado para evitar conflitos de portas com outros processos ou agrupamentos que sejam executados no mesmo nó. Em clusters que usam o CNI, a ponte de rede virtual cbr0 só é criada se o nó tiver pods com a definição hostNetwork: false.kubenet

Redes de serviços

Embora a rede de pods forneça a conetividade fundamental entre pods individuais, não é suficiente para criar aplicações robustas e escaláveis. Os pods são efémeros; podem ser criados, destruídos e reagendados em qualquer altura. Esta situação faz com que os respetivos endereços IP mudem. As redes de serviços resolvem este problema, oferecendo uma forma estável e fiável de expor aplicações e gerir a forma como comunicam, tanto no cluster como com o mundo exterior.

Um serviço do Kubernetes é uma abstração que define um conjunto lógico de pods e uma política para aceder aos mesmos. Os serviços usam etiquetas para agrupar vários pods relacionados numa única unidade lógica. Quando cria um serviço, o Kubernetes atribui-lhe um endereço IP virtual estável, conhecido como ClusterIP, a partir de um conjunto de endereços reservados para serviços. Este ClusterIP, juntamente com um nome DNS associado, permanece constante durante todo o ciclo de vida do serviço, fornecendo um ponto final consistente que outras aplicações podem usar para estabelecer ligação aos pods.

Como funciona a rede de serviços

A rede de serviços baseia-se em dois mecanismos principais para encaminhar o tráfego de um ponto final estável de um serviço para os respetivos pods de back-end dinâmicos: deteção de serviços e equilíbrio de carga.

Deteção de serviços: para que as aplicações se encontrem e comuniquem entre si, o GKE fornece um serviço DNS interno (kube-dns ou Cloud DNS). Quando cria um serviço, o serviço DNS cria automaticamente um registo de DNS correspondente. Este registo permite que as aplicações se liguem ao serviço através do respetivo nome DNS (por exemplo, my-app-service) em vez de precisarem de saber o respetivo ClusterIP. Embora kube-dns seja a predefinição para clusters Standard, o Cloud DNS para GKE é a solução recomendada para a maioria dos ambientes de produção. Também é a única solução suportada para clusters do GKE Autopilot. Este serviço é totalmente gerido, escalável e altamente disponível. Integra-se com a rede VPC e o Cloud Logging, oferecendo um desempenho e uma observabilidade melhorados sem que tenha de gerir os kube-dns pods.

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

• GKE Dataplane V2: os clusters que usam o GKE Dataplane V2 (que se baseia no Cilium) não usam o kube-proxy para o equilíbrio de carga do serviço. Em alternativa, o GKE Dataplane V2 usa programas eBPF que são executados no kernel do Linux. Estes programas eBPF são altamente eficientes na interceção de tráfego para Service ClusterIPs e no equilíbrio de carga direto do tráfego para os pods de back-end adequados. Esta abordagem resulta num melhor desempenho e está estreitamente integrada com as capacidades 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 num cluster do GKE que não usa o GKE Dataplane V2, um componente denominado kube-proxy implementa o mecanismo de endereço IP virtual para os serviços. O kube-proxy monitoriza o servidor da API Kubernetes para detetar alterações aos serviços e pontos finais e, em seguida, programa regras de rede no nó para intercetar o tráfego destinado ao ClusterIP de um serviço.

  O kube-proxy pode funcionar em diferentes modos, incluindo os seguintes:

  • Modo iptables: este é o modo predefinido. O kube-proxy adiciona e remove regras de NAT de destino (DNAT) no subsistema iptables do nó. Quando o tráfego chega a um ClusterIP de um serviço, estas regras fazem uma tradução NAT e alteram o endereço IP de destino para um dos pods de back-end em bom estado. Normalmente, o balanceamento de carga nos pods de back-end é aleatório ou rotativo.
  • Modo ipvs: este modo usa o servidor virtual de IP (IPVS) do Linux para o balanceamento de carga de alto desempenho. O kube-proxy configura regras de IPVS, que podem processar um grande número de serviços e fornecer algoritmos de equilíbrio de carga mais sofisticados.

Exemplo de fluxo de comunicação interna

A lista seguinte descreve como um pedido flui de um pod cliente para um pod servidor através de um serviço num cluster que não usa o GKE Dataplane V2:

1. A aplicação cliente faz uma consulta DNS para my-server-service.
2. O serviço DNS interno do cluster resolve este nome para o ClusterIP estável do serviço (por exemplo, 10.0.32.8).
3. O pod do cliente envia um pedido para o ClusterIP do serviço.
4. As regras iptables no nó do cliente, que são geridas por kube-proxy, intercetam este pedido.
5. Estas regras iptables executam DNAT e selecionam um dos pods de back-end em bom estado 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.
6. O pacote é encaminhado através da rede de pods simples para o pod 2, que processa o pedido.

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

Exemplo de manifesto de serviço

O exemplo seguinte mostra um manifesto de serviço. O campo selector especifica que Pods recebem tráfego com base nas respetivas etiquetas.

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

Funcionalidades da rede de serviços

A rede de serviços do GKE oferece várias funcionalidades para gerir o fluxo de tráfego e expor aplicações, tanto interna como externamente.

• Balanceamento de carga interno e externo. Para os serviços que precisam de ser acedidos apenas a partir do cluster, o kube-proxy (ou o GKE Dataplane V2)kube-proxy processa o balanceamento de carga internamente. Para os serviços que precisam de ser expostos à Internet, o GKE aprovisiona automaticamente um balanceador de carga na nuvem para distribuir o tráfego externo pelos nós no cluster.
• Balanceadores de carga de aplicações para encaminhamento HTTP(S). para tráfego HTTP(S), o GKE usa um balanceador de carga de camada 7 especializado, o balanceador de carga de aplicações. Configura este equilibrador de carga através da API Kubernetes Gateway, que é a abordagem recomendada para todas as novas aplicações. O controlador do GKE Gateway é a implementação da Google da API Gateway e foi concebido para ser um sucessor mais expressivo, flexível e extensível do recurso Ingress. A API Gateway usa os seguintes recursos para configurar o equilibrador de carga:
  • Gateway: define as configurações do ouvinte, como portas, protocolos e nomes de anfitrião. Funciona como o ponto de entrada para o tráfego.
  • HTTPRoute: especifica como o tráfego recebido por um Gateway é encaminhado para os serviços. É compatível com funcionalidades avançadas, como o encaminhamento baseado em caminhos, a correspondência de cabeçalhos e a divisão de tráfego.
  • Política: define como a infraestrutura Cloud de Confiance by S3NS subjacente deve funcionar, sendo anexada a um gateway, a uma rota ou a um serviço.
• Integração de malha de serviços. Para arquiteturas de microserviços complexas, o GKE suporta tecnologias de malha de serviços. Uma malha de serviços é uma camada de infraestrutura opcional que oferece funcionalidades avançadas para a gestão de tráfego, a observabilidade e a segurança. Para uma experiência totalmente gerida e suportada, o GKE oferece o Cloud Service Mesh, que é baseado no Istio.

Redes de clusters

A rede de clusters é a camada mais exterior da rede do GKE. Centra-se na forma como todo o cluster do Kubernetes interage com recursos e redes externas, incluindo a forma como os clientes da Internet alcançam as suas aplicações, como os seus pods acedem a APIs externas e como o seu cluster se liga a centros de dados no local. A rede de clusters é criada com base na infraestrutura de VPC do Cloud de Confiance by S3NS.

Faça a gestão do tráfego de entrada

O tráfego de entrada é o tráfego que entra no seu cluster a partir do mundo exterior. O GKE usa várias Cloud de Confiance by S3NS funcionalidades integradas para gerir e proteger este tráfego.

Fluxo de dados de acesso externo: quando um cliente da Internet envia um pedido à sua aplicação (normalmente exposto através de um serviço do tipo LoadBalancer ou de um recurso de entrada ou gateway), este chega primeiro a um Cloud de Confiance by S3NS equilibrador de carga. O balanceador de carga encaminha o pedido para um nó em bom estado no seu cluster. O nó encaminha o tráfego para o pod adequado. O kube-proxy trata este encaminhamento em clusters que não usam o GKE Dataplane V2, ou os programas eBPF tratam-no em clusters que usam o GKE Dataplane V2. O pod de destino pode estar no mesmo nó ou num 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 predefinidas para operações essenciais do cluster, como permitir que o plano de controlo alcance os nós, pode definir regras personalizadas para cumprir os seus requisitos de segurança específicos. Estas regras de firewall da VPC funcionam com as políticas de rede do Kubernetes para oferecer uma defesa em profundidade através do controlo do tráfego ao nível do nó e do pod.

Otimizar o fluxo de tráfego externo: quando um equilibrador de carga envia tráfego para um nó, o nó pode ter de encaminhar esse tráfego para um Pod num nó diferente, o que requer saltos de rede adicionais. Para evitar esta situação, defina o campo externalTrafficPolicy como Local no manifesto do serviço. Quando esta política está ativa, o balanceador de carga usa uma verificação de funcionamento para identificar que nós têm pods em bom estado para o serviço de destino. O balanceador de carga envia tráfego apenas para os pods em bom estado, o que evita o salto de rede adicional. A desvantagem é que esta política pode levar a uma distribuição desigual do tráfego se os seus pods de back-end não estiverem distribuídos uniformemente pelos nós no cluster.

Faça a gestão do tráfego de saída

A saída é o tráfego que sai do seu cluster. Para que um cluster do GKE funcione e as suas aplicações alcancem serviços externos, tem de gerir vários caminhos de conetividade.

Requisitos de conetividade fundamentais: todos os clusters do GKE requerem conetividade de saída para os domínios *.googleapis.com, *.gcr.io e *.pkg.dev. A conetividade de saída ao endereço IP do plano de controlo também tem de funcionar corretamente. Acesso à Internet para pods através do Cloud NAT: em clusters privados onde 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 gerido que permite que os pods se liguem à Internet para tarefas como transferir atualizações ou aceder a APIs externas sem as expor a ligações recebidas.

Conetividade aos Cloud de Confiance by S3NS serviços: se precisar de permitir que o cluster comunique em segurança com outros Cloud de Confiance by S3NS serviços, como o Cloud Storage ou o Cloud SQL, sem atravessar a Internet pública, use o acesso privado à Google. Este é um mecanismo de saída importante para clusters privados que interagem com as APIs Google.

Conetividade híbrida e em vários clusters

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

Controlos de segurança de redes

Para proteger o cluster e as aplicações em execução no mesmo, o GKE oferece várias camadas de controlos de segurança para o tráfego interno (leste-oeste) e externo (norte-sul).

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

Por predefinição, todos os pods num cluster do GKE podem comunicar livremente entre si. Para proteger o tráfego interno e aplicar o princípio do menor privilégio, pode usar o NetworkPolicy. Um NetworkPolicy é um recurso do Kubernetes que funciona como uma firewall para os seus pods, controlando o tráfego de rede entre eles. Os recursos NetworkPolicy permitem-lhe definir regras para restringir o tráfego de entrada e saída para um grupo selecionado de pods com base numa combinação de etiquetas, intervalos de endereços IP e números de portas. Quando cria o primeiro NetworkPolicy num espaço de nomes, todo o tráfego que não seja explicitamente permitido por essa política é recusado. A aplicação destas políticas está incorporada diretamente no GKE Dataplane V2 ou é processada pelo plug-in CNI do cluster, como o Calico.

Exemplo de manifesto NetworkPolicy

O exemplo seguinte mostra um manifesto NetworkPolicy. Esta política aplica-se a pods com a etiqueta app: backend e permite o tráfego de entrada apenas de pods com a etiqueta 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

Proteja o acesso externo ao cluster

Controlar o tráfego que entra e sai do cluster é fundamental para proteger as suas aplicações de ameaças externas.

Regras de firewall da VPC

Os clusters do GKE residem numa rede Cloud de Confiance by S3NS VPC e estão protegidos por regras de firewall da VPC que controlam o tráfego de e para os nós do cluster. As regras de firewall da VPC e as políticas de rede funcionam em conjunto para oferecer uma defesa em profundidade. As firewalls da VPC funcionam ao nível do nó (camada 3 ou camada 4) e controlam o tráfego para as próprias VMs. As políticas de rede operam ao nível do pod (camada 3 ou camada 4) e oferecem um controlo mais detalhado sobre o tráfego entre as aplicações no cluster.

Limite o acesso aos equilibradores de carga

Quando expõe aplicações através de um serviço ou de um Ingress do Kubernetes, pode aplicar controlos de segurança adicionais ao nível do equilibrador de carga. Para equilibradores de carga externos, considere estas opções:

• Se expuser um serviço através do campo type: LoadBalancer, pode especificar o campo loadBalancerSourceRanges no manifesto do serviço. Este campo restringe o acesso ao serviço apenas aos intervalos de endereços IP que definir.

• Para balanceadores de carga de aplicações (Ingress), pode usar serviços de segurança mais avançados quando expõe aplicações HTTP(S):

  • Google Cloud Armor: este serviço é uma firewall de aplicação Web (WAF) que ajuda a proteger as suas aplicações contra ataques DDoS e outras ameaças baseadas na Web.
  • Identity-Aware Proxy (IAP): para um controlo de acesso detalhado, pode ativar o IAP nos seus pontos finais. A IAP valida a identidade de um utilizador e usa-a para determinar se o utilizador deve ter permissão para aceder à aplicação.

O que se segue?

• Saiba como criar um cluster nativo da VPC.
• Leia mais acerca do GKE Dataplane V2.
• Implemente políticas de rede para proteger a comunicação entre pods.
• Explore diferentes formas de expôr aplicações através de serviços e configurar a entrada com a API Gateway.