Vista geral da rede do GKE

Esta página fornece um guia para os principais aspetos da rede do Google Kubernetes Engine (GKE).

Esta página não aborda tópicos gerais do Kubernetes nem do GKE. Esta página pressupõe que tem conhecimentos sobre o seguinte:

  • Conceitos de gestão de rede do Linux
  • Utilitários, como regras de encaminhamento e iptables

Além disso, esta página pressupõe que conhece a terminologia básica relacionada com o seguinte:

  • Camada de transporte
  • Camada de Internet
  • Camadas de aplicação
  • Conjunto de protocolos de Internet (IP), incluindo HTTP e DNS

Esta página e o resto deste conjunto de documentação destinam-se a arquitetos da nuvem e especialistas em redes que concebem e arquitetam a rede para a respetiva organização. Para uma vista geral de todos os conjuntos de documentação do GKE, consulte o artigo Explore a documentação do GKE. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns de utilizadores do GKE.

O Kubernetes permite-lhe definir declarativamente como as suas aplicações são implementadas, como as aplicações comunicam entre si e com o plano de controlo do Kubernetes, e como os clientes podem alcançar as suas aplicações. Esta página também fornece informações sobre como o GKE configura os serviços Google Cloud, onde é relevante para o funcionamento em rede.

Por que motivo a rede do Kubernetes é diferente

Quando usa o Kubernetes para orquestrar as suas aplicações, é importante alterar a forma como pensa no design de rede das suas aplicações e respetivos anfitriões. Com o Kubernetes, pensa em como os pods, os serviços e os clientes externos comunicam, em vez de pensar em como os seus anfitriões ou máquinas virtuais (VMs) estão ligados.

As redes definidas por software (SDN) avançadas do Kubernetes permitem o encaminhamento e o reencaminhamento de pacotes para pods, serviços e nós em diferentes zonas no mesmo cluster regional. O Kubernetes também configura dinamicamente as regras de filtragem de IP, as tabelas de encaminhamento e as regras de firewall em cada nó, consoante o modelo declarativo das suas implementações do Kubernetes e a configuração do cluster no Google Cloud. Google Cloud

Terminologia relacionada com as redes do Kubernetes

O modelo de rede do Kubernetes depende muito dos endereços IP. Os serviços, os pods, os contentores e os nós comunicam através de endereços IP e portas. O Kubernetes oferece diferentes tipos de equilíbrio de carga para direcionar o tráfego para os Pods corretos. Todos estes mecanismos são descritos mais detalhadamente mais tarde. Tenha em atenção os seguintes termos relacionados com endereços IP à medida que lê:

  • ClusterIP: o endereço IP atribuído a um serviço. Noutros documentos, pode ser denominado "IP do cluster". Este endereço é estável durante a vida útil do serviço, conforme abordado em Serviços.
  • Endereço IP do Pod: o endereço IP atribuído a um determinado Pod. Isto é efémero, conforme abordado em Agrupamentos.
  • Endereço IP do nó: o endereço IP atribuído a um determinado nó.

Requisitos de conetividade do cluster

Todos os clusters requerem conetividade com *.googleapis.com, *.gcr.io, *.pkg.dev e o endereço IP do plano de controlo. Este requisito é cumprido pelas regras de saída permitidas implícitas e pelas regras de firewall criadas automaticamente que o GKE cria.

Rede dentro do cluster

Esta secção aborda as redes num cluster do Kubernetes, no que diz respeito à atribuição de IP, aos pods, aos serviços, ao DNS e ao plano de controlo.

Atribuição de endereços IP

O Kubernetes usa vários intervalos de IP para atribuir endereços IP a nós, pods e serviços.

  • Cada nó tem um endereço IP atribuído a partir da rede de nuvem virtual privada (VPC) do cluster. O IP deste nó fornece conetividade a partir de componentes de controlo, como o kube-proxy e o kubelet, para o servidor da API Kubernetes. Este endereço IP é a ligação do nó ao resto do cluster.

  • Cada nó tem um conjunto de endereços IP que o GKE atribui aos pods em execução nesse nó (um bloco CIDR/24 por predefinição). Opcionalmente, pode especificar o intervalo de IPs quando cria o cluster. A funcionalidade de intervalo CIDR de agrupamento flexível permite-lhe reduzir o tamanho do intervalo para endereços IP de agrupamentos para nós num conjunto de nós

  • Cada Pod tem um único endereço IP atribuído a partir do intervalo CIDR do Pod do respetivo nó. Este endereço IP é partilhado por todos os contentores em execução no Pod e liga-os a outros Pods em execução no cluster.

  • Cada serviço tem um endereço IP, denominado ClusterIP, atribuído a partir da rede VPC do cluster. Opcionalmente, pode personalizar a rede de VPC quando cria o cluster.

  • Cada plano de controlo tem um endereço IP público ou interno com base no tipo de cluster, versão e data de criação. Para mais informações, consulte a descrição do plano de controlo.

O modelo de rede do GKE não permite a reutilização de endereços IP na rede. Quando migra para o GKE, tem de planear a atribuição de endereços IP para reduzir a utilização de endereços IP internos no GKE.

Unidade de transmissão máxima (MTU)

A MTU selecionada para uma interface de pod depende da interface de rede do contentor (CNI) usada pelos nós do cluster e da definição de MTU da VPC subjacente. Para mais informações, consulte o artigo Pods.

O valor MTU da interface do pod é 1460 ou herdado da interface principal do nó.

CNI MTU GKE Standard
kubenet 1460 Predefinição
kubenet
(GKE versão 1.26.1 e posterior) 		Herdado Predefinição
Calico 1460

Ativada através da utilização da funcionalidade --enable-network-policy.

Para ver detalhes, consulte o artigo Controle a comunicação entre Pods e serviços através de políticas de rede.
netd Herdado Ativada através de qualquer uma das seguintes opções:
GKE Dataplane V2 Herdado

Ativada através da utilização da funcionalidade --enable-dataplane-v2.

Para obter detalhes, consulte o artigo Usar o GKE Dataplane V2.

Para mais informações, consulte o artigo Clusters nativos de VPC.

Plug-ins de rede suportados

  • Para usar um plugin de rede, tem de o instalar. O GKE oferece os seguintes plug-ins de rede suportados nativamente:
    • Calico (no Dataplane V1)
    • Cilium (no Dataplane V2)
    • Istio-CNI (no Managed Dataplane Controller para o GKE Enterprise)

Agrupamentos

No Kubernetes, um pod é a unidade implementável mais básica num cluster do Kubernetes. Um pod executa um ou mais contentores. Zero ou mais pods são executados num nó. Cada nó no cluster faz parte de um conjunto de nós.

No GKE, estes nós são máquinas virtuais, cada uma executada como uma instância no Compute Engine.

Os pods também podem ser anexados a volumes de armazenamento externos e outros recursos personalizados. Este diagrama mostra um único nó a executar dois pods, cada um associado a dois volumes.

imagem

Quando o Kubernetes agenda um pod para ser executado num nó, cria um namespace de rede para o pod no kernel Linux do nó. Este espaço de nomes de rede liga a interface de rede física do nó, como eth0, ao pod através de uma interface de rede virtual, para que os pacotes possam fluir para e a partir do pod. A interface de rede virtual associada no espaço de nomes de rede raiz do nó liga-se a uma ponte Linux que permite a comunicação entre Pods no mesmo nó. Um Pod também pode enviar pacotes fora do nó através da mesma interface virtual.

O Kubernetes atribui um endereço IP (o endereço IP do pod) à interface de rede virtual no espaço de nomes de rede do pod a partir de um intervalo de endereços reservados para pods no nó. Este intervalo de endereços é um subconjunto do intervalo de endereços IP atribuído ao cluster para pods, que pode configurar quando cria um cluster.

Um contentor executado num Pod usa o espaço de nomes de rede do Pod. Do ponto de vista do contentor, o pod parece ser uma máquina física com uma interface de rede. Todos os contentores no agrupamento veem esta mesma interface de rede. O localhost de cada contentor está ligado, através do pod, à interface de rede física do nó, como eth0.

Tenha em atenção que esta conetividade difere drasticamente consoante use a interface de rede de contentores (CNI) do GKE ou opte por usar a implementação do Calico ativando a política de rede quando cria o cluster.

  • Se usar o CNI do GKE, uma extremidade do par de dispositivos de Ethernet virtual (veth) é anexada ao pod no respetivo espaço de nomes e a outra está ligada ao dispositivo de ponte Linux cbr0.1 Neste caso, o seguinte comando mostra os endereços MAC dos vários pods anexados a cbr0:

    arp -n

    A execução do seguinte comando no contentor da caixa de ferramentas mostra o fim do espaço de nomes raiz de cada par veth anexado a cbr0:

    brctl show cbr0

  • Se a política de rede estiver ativada, uma extremidade do par veth é anexada ao pod e a outra ao eth0. Neste caso, o comando seguinte mostra os endereços MAC dos vários pods associados a diferentes dispositivos veth:

    arp -n

    A execução do seguinte comando no contentor da caixa de ferramentas mostra que não existe um dispositivo de ponte Linux denominado cbr0:

    brctl show

As regras de iptables que facilitam o encaminhamento no cluster diferem de um cenário para outro. É importante ter esta distinção em mente durante a resolução de problemas detalhada de problemas de conetividade.

Por predefinição, cada Pod tem acesso não filtrado a todos os outros Pods em execução em todos os nós do cluster, mas pode limitar o acesso entre Pods. O Kubernetes destrói e recria regularmente os pods. Isto acontece quando um conjunto de nós é atualizado, quando altera a configuração declarativa do pod ou a imagem de um contentor, ou quando um nó fica indisponível. Por conseguinte, o endereço IP de um pod é um detalhe de implementação e não deve confiar nele. O Kubernetes fornece endereços IP estáveis através de serviços.

  1. A ponte de rede virtual cbr0 só é criada se existirem Pods que definam hostNetwork: false.↩

Serviços

No Kubernetes, pode atribuir pares de chave-valor arbitrários denominados etiquetas a qualquer recurso do Kubernetes. O Kubernetes usa etiquetas para agrupar vários Pods relacionados numa unidade lógica denominada Serviço. Um serviço tem um endereço IP e portas estáveis e fornece o equilíbrio de carga entre o conjunto de pods cujas etiquetas correspondem a todas as etiquetas que define no seletor de etiquetas quando cria o serviço.

O diagrama seguinte mostra dois serviços separados, cada um dos quais é composto por vários pods. Cada um dos pods no diagrama tem a etiqueta app=demo, mas as outras etiquetas são diferentes. O serviço "frontend" corresponde a todos os pods com app=demo e component=frontend, enquanto o serviço "users" corresponde a todos os pods com app=demo e component=users. O Client Pod não corresponde exatamente a nenhum ServiceSelector, pelo que não faz parte de nenhum serviço. No entanto, o Client Pod pode comunicar com qualquer um dos serviços porque é executado no mesmo cluster.

imagem

O Kubernetes atribui um endereço IP estável e fiável a cada serviço recém-criado (o ClusterIP) do conjunto de endereços IP de serviço disponíveis do cluster. O Kubernetes também atribui um nome de anfitrião ao ClusterIP, adicionando uma entrada DNS. O ClusterIP e o nome do anfitrião são exclusivos no cluster e não mudam ao longo do ciclo de vida do serviço. O Kubernetes só lança o ClusterIP e o nome do anfitrião se o serviço for eliminado da configuração do cluster. Pode alcançar um pod saudável que execute a sua aplicação através do ClusterIP ou do nome do anfitrião do serviço.

À primeira vista, um serviço pode parecer um ponto único de falha para as suas aplicações. No entanto, o Kubernetes distribui o tráfego da forma mais uniforme possível pelos Pods, em execução em muitos nós, pelo que um cluster pode resistir a uma indisponibilidade que afete um ou mais (mas não todos) nós.

Kube-Proxy

O Kubernetes gere a conetividade entre Pods e serviços através do componente kube-proxy, que é executado tradicionalmente como um Pod estático em cada nó.

kube-proxy, que não é um proxy inline, mas um controlador de balanceamento de carga baseado em saída, monitoriza o servidor da API Kubernetes e mapeia continuamente o ClusterIP para pods saudáveis adicionando e removendo regras de NAT de destino (DNAT) para o subsistema iptables do nó. Quando um contentor em execução num pod envia tráfego para o ClusterIP de um serviço, o nó seleciona um pod aleatoriamente e encaminha o tráfego para esse pod.

Quando configura um serviço, pode remapear opcionalmente a respetiva porta de escuta definindo valores para port e targetPort.

  • O port é onde os clientes acedem à aplicação.
  • O targetPort é a porta onde a aplicação está realmente a ouvir o tráfego no Pod.

O kube-proxy gere este remapeamento de portas adicionando e removendo regras iptables no nó.

Este diagrama ilustra o fluxo de tráfego de um pod de cliente para um pod de servidor num nó diferente. O cliente estabelece ligação ao Serviço em 172.16.12.100:80. O servidor da API Kubernetes mantém uma lista de pods que executam a aplicação. O kube-proxy processo em cada nó usa esta lista para criar uma regra iptables para direcionar o tráfego para um pod adequado (como 10.255.255.202:8080). O pod do cliente não precisa de conhecer a topologia do cluster nem quaisquer detalhes sobre pods ou contentores individuais nos mesmos.

imagem

A forma como o kube-proxy é implementado depende da versão do GKE do cluster:

  • Para as versões 1.16.0 e 1.16.8-gke.13 do GKE, o kube-proxy é implementado como um DaemonSet.
  • Para versões do GKE posteriores à 1.16.8-gke.13, o kube-proxy é implementado como um pod estático para nós.

DNS

O GKE oferece as seguintes opções de DNS de cluster gerido para resolver nomes de serviços e nomes externos:

  • kube-dns: um suplemento de cluster implementado por predefinição em todos os clusters do GKE. Para mais informações, consulte o artigo Usar o kube-dns.

  • Cloud DNS: uma infraestrutura de DNS de cluster gerida na nuvem que substitui o kube-dns no cluster. Para mais informações, consulte o artigo Use o Cloud DNS para o GKE.

O GKE também fornece o NodeLocal DNSCache como um suplemento opcional com o kube-dns ou o Cloud DNS para melhorar o desempenho do DNS do cluster.

Para saber como o GKE fornece DNS, consulte o artigo Deteção de serviços e DNS.

Plano de controlo

No Kubernetes, o plano de controlo faz a gestão dos processos do plano de controlo, incluindo o servidor da API Kubernetes. A forma como acede ao painel de controlo depende de como configurou o isolamento da rede do painel de controlo.

Rede fora do cluster

Esta secção explica como o tráfego de fora do cluster chega às aplicações em execução num cluster do Kubernetes. Estas informações são importantes quando concebe as aplicações e as cargas de trabalho do cluster.

Já leu sobre como o Kubernetes usa Serviços para fornecer endereços IP estáveis para aplicações em execução em Pods. Por predefinição, os agrupamentos não expõem um endereço IP externo, porque o kube-proxy gere todo o tráfego em cada nó. Os pods e os respetivos contentores podem comunicar livremente, mas as ligações fora do cluster não podem aceder ao serviço. Por exemplo, na ilustração anterior, os clientes fora do cluster não podem aceder ao serviço de frontend através do respetivo ClusterIP.

O GKE oferece três tipos diferentes de equilibradores de carga para controlar o acesso e distribuir o tráfego recebido pelo cluster da forma mais uniforme possível. Pode configurar um serviço para usar vários tipos de equilibradores de carga em simultâneo.

  • Os balanceadores de carga externos gerem o tráfego proveniente de fora do cluster e de fora da sua Google Cloud rede VPC. Usam regras de encaminhamento associadas à redeGoogle Cloud para encaminhar o tráfego para um nó do Kubernetes.
  • Os balanceadores de carga internos gerem o tráfego proveniente da mesma rede VPC. Tal como os balanceadores de carga externos, usam regras de encaminhamento associadas à Google Cloud rede para encaminhar o tráfego para um nó do Kubernetes.
  • Os balanceadores de carga de aplicações são balanceadores de carga externos especializados usados para tráfego HTTP(S). Usam um gateway (recomendado) ou um recurso de entrada em vez de uma regra de encaminhamento para encaminhar o tráfego para um nó do Kubernetes.

Quando o tráfego atinge um nó do Kubernetes, é processado da mesma forma, independentemente do tipo de balanceador de carga. O balanceador de carga não sabe que nós no cluster estão a executar pods para o respetivo serviço. Em vez disso, equilibra o tráfego em todos os nós no cluster, mesmo os que não estão a executar um pod relevante. Num cluster regional, a carga é distribuída por todos os nós em todas as zonas da região do cluster. Quando o tráfego é encaminhado para um nó, o nó encaminha o tráfego para um Pod, que pode estar a ser executado no mesmo nó ou num nó diferente. O nó encaminha o tráfego para um pod escolhido aleatoriamente através das regras iptables que o kube-proxy gere no nó.

No diagrama seguinte, o Network Load Balancer de passagem externo direciona o tráfego para o nó intermédio e o tráfego é redirecionado para um pod no primeiro nó.

imagem

Quando um equilibrador de carga envia tráfego para um nó, o tráfego pode ser encaminhado para um pod num nó diferente. Isto requer saltos de rede adicionais. Se quiser evitar os saltos adicionais, pode especificar que o tráfego tem de ir para um pod que esteja no mesmo nó que recebe inicialmente o tráfego.

Para especificar que o tráfego tem de ir para um pod no mesmo nó, defina externalTrafficPolicy como Local no manifesto do serviço:

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: demo
    component: users
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Quando define externalTrafficPolicy como Local, o balanceador de carga envia tráfego apenas para nós que tenham um pod em bom estado pertencente ao serviço. O balanceador de carga usa uma verificação de funcionamento para determinar que nós têm os pods adequados.

Balanceador de carga externo

Se o seu serviço tiver de estar acessível a partir do exterior do cluster e da sua rede VPC, pode configurar o seu serviço como um LoadBalancer, definindo o campo type do serviço como Loadbalancer quando definir o serviço. Em seguida, o GKE aprovisiona um balanceador de carga de rede de encaminhamento externo à frente do serviço. O Network Load Balancer de passagem externo tem conhecimento de todos os nós no cluster e configura as regras de firewall da rede VPC para permitir ligações ao serviço a partir do exterior da rede VPC, através do endereço IP externo do serviço. Pode atribuir um endereço IP externo estático ao serviço.

Para mais informações, consulte o artigo Configurar nomes de domínios com endereços IP estáticos.

Para saber mais sobre as regras de firewall, consulte o artigo Regras de firewall criadas automaticamente.

Detalhes técnicos

Quando usa o equilibrador de carga externo, o tráfego recebido é inicialmente encaminhado para um nó através de uma regra de encaminhamento associada à rede Google Cloud . Depois de o tráfego chegar ao nó, o nó usa a respetiva tabela NAT para escolher um pod.iptables O kube-proxy gere as regras iptables no nó.

Balanceador de carga interno

Para o tráfego que precisa de alcançar o cluster a partir da rede VPC do cluster ou de redes ligadas à rede VPC do cluster, pode configurar o seu serviço para aprovisionar um Network Load Balancer de passagem interno. O Network Load Balancer de passagem interno escolhe um endereço IP da sub-rede da VPC do cluster em vez de um endereço IP externo. As aplicações ou os serviços, quer estejam na rede VPC do cluster ou em redes ligadas, podem usar este endereço IP para comunicar com os serviços no interior do cluster.

Detalhes técnicos

O balanceamento de carga interno é fornecido pela Google Cloud. Quando o tráfego atinge um determinado nó, esse nó usa a respetiva tabela NAT para escolher um pod, mesmo que o pod esteja num nó diferente.iptables O kube-proxy gere as regras iptables no nó.

Para mais informações sobre balanceadores de carga internos, consulte o artigo Usar um balanceador de carga de rede de encaminhamento interno.

Balanceador de carga de aplicações

Muitas aplicações, como as APIs de serviços Web RESTful, comunicam através de HTTP(S). Pode permitir que clientes externos à sua rede VPC acedam a este tipo de aplicação através da API Gateway do Kubernetes.

O controlador do GKE Gateway é a implementação da Google da API Gateway do Kubernetes para o Cloud Load Balancing. A API Gateway é um projeto de código aberto destinado a padronizar a forma como as malhas de serviços e os controladores de entrada expõem aplicações no Kubernetes. Foi concebido para ser um sucessor mais expressivo, flexível e extensível do recurso Ingress.

O controlador do GKE Gateway é usado para configurar balanceadores de carga de aplicações da camada 7 para expor tráfego HTTP(S) a aplicações que são executadas no cluster.

Prática recomendada:

Use a API Gateway para implementar o seu equilibrador de carga.

A API Gateway usa os seguintes recursos:

  • Gateway Class: este recurso define o tipo de balanceador de carga que o GKE implementa. O GKE fornece GatewayClasses que podem ser usadas em clusters.
  • Gateway: um recurso Gateway define configurações de ouvinte, como portas, protocolos e nomes de anfitriões, e atua como o ponto de entrada para o tráfego no seu cluster.
  • HTTPRoute: um HTTPRoute especifica como o tráfego recebido por um Gateway é encaminhado para os serviços. As HTTPRoutes podem incluir funcionalidades avançadas, como o encaminhamento baseado em caminhos, a correspondência de cabeçalhos, a divisão de tráfego para testes A/B e um controlo mais detalhado dos limites de tempo e das repetições.
  • Política: pode anexar uma política a um gateway, a uma rota ou a um serviço do Kubernetes para definir como a infraestrutura subjacente deve funcionar. Google Cloud

Para mais informações, consulte o artigo Acerca da API Gateway.

Detalhes técnicos

Quando cria um objeto Gateway, o controlador do GKE Gateway configura um balanceador de carga de aplicações de acordo com as regras nos manifestos Gateway, HTTPRoute e Service. O cliente envia um pedido ao Application Load Balancer. O balanceador de carga é um proxy real; escolhe um nó e encaminha o pedido para a combinação NodeIP:NodePort desse nó. O nó usa a respetiva tabela NAT para escolher um pod.iptables O kube-proxy gere as regras iptables no nó.

Segurança de redes

Para melhorar a segurança do seu cluster, pode limitar a conetividade entre nós, entre pods e com equilibradores de carga.

Limite a conetividade entre nós

A criação de regras de firewall de entrada ou saída que segmentam nós no seu cluster pode ter efeitos adversos. Por exemplo, a aplicação de regras de negação de saída a nós no seu cluster pode danificar funcionalidades como NodePort e kubectl exec.

Limite a conetividade a pods e serviços

Por predefinição, todos os pods em execução no mesmo cluster podem comunicar livremente. No entanto, pode limitar a conetividade num cluster de diferentes formas, consoante as suas necessidades.

Limite o acesso entre pods

Pode limitar o acesso entre os pods através de uma política de rede. As definições da política de rede permitem-lhe restringir a entrada e a saída de pods com base numa combinação arbitrária de etiquetas, intervalos de IP e números de portas.

Por predefinição, não existe uma política de rede, pelo que todo o tráfego entre os pods no cluster é permitido. Assim que criar a primeira política de rede num espaço de nomes, todo o outro tráfego é recusado.

Depois de criar uma política de rede, tem de a ativar explicitamente para o cluster. Para mais informações, consulte o artigo Configurar políticas de rede para aplicações.

Limite o acesso a um balanceador de carga externo

Se o seu serviço usar um balanceador de carga externo, o tráfego de qualquer endereço IP externo pode aceder ao seu serviço por predefinição. Pode restringir os intervalos de endereços IP que podem aceder aos pontos finais no seu cluster configurando a opção loadBalancerSourceRanges quando configurar o serviço. Pode especificar vários intervalos e atualizar a configuração de um serviço em execução em qualquer altura. A instância kube-proxy em execução em cada nó configura as regras iptables desse nó para negar todo o tráfego que não corresponda ao loadBalancerSourceRanges especificado. Além disso, quando cria um serviço LoadBalancer, o GKE cria uma regra de firewall da VPC correspondente para aplicar estas restrições ao nível da rede.

Limite o acesso a um balanceador de carga de aplicações

Se o seu serviço usar um Application Load Balancer, pode usar uma política de segurança do Google Cloud Armor para limitar os endereços IP externos que podem aceder ao seu serviço e as respostas a devolver quando o acesso é recusado devido à política de segurança. Pode configurar o Cloud Logging para registar informações sobre estas interações.

Se uma política de segurança do Cloud Armor não for suficientemente detalhada, pode ativar o Identity-Aware Proxy nos seus pontos finais para implementar a autenticação e a autorização baseadas no utilizador para a sua aplicação. Visite o tutorial detalhado para configurar as CAsI para mais informações.

Problemas conhecidos

Esta secção aborda os problemas conhecidos.

O nó com contentores ativados não consegue estabelecer ligação ao intervalo 172.17/16

Uma VM de nó com o containerd ativado não consegue estabelecer ligação a um anfitrião que tenha um IP dentro de 172.17/16. Para mais informações, consulte o artigo Conflito com o intervalo de endereços IP 172.17/16.

Recursos restantes de clusters do GKE eliminados com o Private Service Connect

Se criou e eliminou clusters do GKE com o Private Service Connect antes de 7 de maio de 2024 e eliminou o projeto que continha o cluster antes do próprio cluster, pode ter divulgado recursos do Private Service Connect associados. Estes recursos permanecem ocultos e não permitem eliminar as sub-redes associadas. Se ocorrer este problema, contacte o Google Cloud apoio técnico.

O que se segue?