Problemas conhecidos de rede do GKE

Fuga de endereço IP do pod em nós com GKE Dataplane V2

Os clusters com o GKE Dataplane V2 ativado podem sofrer esgotamento do endereço IP do pod nos nós. Este problema é causado por um erro de tempo de execução do contentor que pode divulgar endereços IP atribuídos quando os pods encontram erros CNI transitórios durante a criação.

O problema é acionado quando o nó do cluster do GKE é atualizado para uma das seguintes versões do GKE ou é criado com uma delas:

• 1.33 e posterior
• 1.32 e posteriores
• 1.31.2-gke.1115000 ou posterior
• 1.30.8-gke.1051001 ou posterior
• 1.29.10-gke.1059000 ou posterior
• 1.28.15-gke.1024000 ou posterior

Quando este problema ocorre, os novos pods agendados no nó afetado não são iniciados e devolvem uma mensagem de erro semelhante à seguinte: failed to assign an IP address to container.

Solução alternativa:

Para mitigar este problema, pode aplicar o DaemonSet de mitigação ao cluster para limpar os recursos de IP com fugas:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cleanup-ipam-dir
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: cleanup-ipam
  template:
    metadata:
      labels:
        name: cleanup-ipam
    spec:
      hostNetwork: true
      securityContext:
        runAsUser: 0
        runAsGroup: 0
        seccompProfile:
          type: RuntimeDefault
      automountServiceAccountToken: false
      containers:
      - name: cleanup-ipam
        image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e
        command:
        - /bin/bash
        - -c
        - |
          while true; do
          for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do
          hash="${hash%%[[:space:]]}"
          if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then
          grep -ilr $hash /hostipam
          fi
          done | xargs -r rm
          echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)"
          sleep 120s
          done
        volumeMounts:
        - name: host-ipam
          mountPath: /hostipam
        - name: host-ctr
          mountPath: /run/containerd
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
      volumes:
      - name: host-ipam
        hostPath:
          path: /var/lib/cni/networks/gke-pod-network
      - name: host-ctr
        hostPath:
          path: /run/containerd

• 1.33.1-gke.1107000 e posteriores

Indisponibilidades de balanceadores de carga de entrada e de serviços em clusters com uma rede antiga

Uma incompatibilidade com as redes antigas faz com que os back-ends de um equilibrador de carga gerido pelo GKE implementado através do Ingress ou do serviço sejam separados. Isto faz com que o balanceador de carga não tenha back-ends ativos, o que, por sua vez, leva à rejeição de todos os pedidos recebidos para esses balanceadores de carga.

O problema afeta os clusters do GKE que usam uma rede antiga e estão na versão 1.31 ou posterior.

Para identificar clusters do GKE com uma rede antiga, execute o seguinte comando:

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"
  

Um cluster com uma rede antiga recebe uma saída vazia para este comando.

Solução alternativa:

Uma vez que as redes antigas foram descontinuadas há algum tempo, a solução preferencial é migrar a sua rede antiga para uma rede da VPC. Pode fazê-lo convertendo uma rede antiga que contenha clusters do GKE. Se não conseguir realizar esta migração neste momento, contacte o apoio ao cliente da nuvem.

• 1.30.10-gke.1070000 e posterior
• 1.31.5-gke.1068000 e posteriores
• 1.32.1-gke.1002000 e posteriores

Os nós criados recentemente não são adicionados aos balanceadores de carga internos da camada 4

Cloud de Confiance by S3NS Os balanceadores de carga criados para serviços LoadBalancer internos podem não detetar nós criados recentemente no grupo de instâncias de back-end.

O problema é mais visível num cluster que foi dimensionado para zero nós e, em seguida, dimensionado novamente para um ou mais nós.

Soluções alternativas:

• Ative a restrição de subconjuntos do GKE e recrie o serviço.

  Nota: não é possível desativar a restrição de subconjuntos do GKE depois de a ativar.

• Crie outro serviço de equilíbrio de carga interno. Quando sincroniza, o grupo de instâncias também é corrigido para o serviço afetado. O novo serviço pode ser removido após a sincronização.
• Adicione e, em seguida, remova a etiqueta node.kubernetes.io/exclude-from-external-load-balancers de um dos nós.
• Adicione um nó ao cluster. Pode remover o nó depois de o serviço começar a funcionar.

• 1.31.7-gke.1158000 e posteriores
• 1.32.3-gke.1499000 e posteriores

Problemas da API Gateway devido à remoção de storedVersions do estado do CRD

O Kube-Addon-Manager no GKE remove incorretamente o v1alpha2 storedVersion do estado dos CRDs da API Gateway, como gateway, httpRoute, gatewayClass e referenceGrant. Este problema ocorre mesmo quando o cluster ainda tem instâncias desses CRDs armazenadas no formato v1alpha2. Se a versão do cluster do GKE for atualizada sem o storedVersions, as chamadas da API Gateway falham. As chamadas com falhas também podem danificar os controladores que implementam a API Gateway.

O seu cluster pode estar em risco se cumprir todas as seguintes condições:

• A API Gateway está ativada no seu cluster.
• Já instalou, em algum momento, uma versão v1alpha2 de um CRD da API Gateway.
• O seu cluster foi executado numa versão afetada do GKE.

Solução alternativa:

A solução alternativa recomendada é atrasar as atualizações do cluster até o problema ser resolvido.

Em alternativa, se precisar de atualizar a versão do cluster, tem de atualizar a versão de armazenamento de todos os CRDs da API Gateway afetados para v1beta1. O exemplo seguinte atualiza o CRD gatewayClass:

1. Verifique a presença da v1alpha2 versão de armazenamento:

   kubectl get crd gatewayclasses.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"

2. Ajuste a versão de armazenamento para v1beta1 executando o seguinte em todos os recursos GatewayClass presentes no cluster:

   kubectl annotate gatewayclass gateway-class-name bump-storage-version="yes"

3. Remova a versão de armazenamento v1alpha2 e defina a versão de armazenamento como v1beta1:

   kubectl patch customresourcedefinitions gatewayclasses.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1beta1"]}}'

4. Faça a atualização como habitualmente.

• 1.32.3-gke.1170000 e posteriores

Os novos pods não conseguem inicializar e ficam bloqueados em ContainerCreating

Não é possível criar novos pods, que ficam bloqueados no estado ContainerCreating. Quando este problema ocorre, o contentor de serviços regista o seguinte:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded

O problema afeta clusters do GKE nas versões entre 1.32 e antes de 1.32.3-gke.1170000, que foram criados nas versões 1.31 ou 1.32 do GKE. A causa principal é que uma estrutura de dados na memória que mantinha uma coleção de identidades do Cilium não estava corretamente sincronizada com o estado do servidor da API Kubernetes.

Para confirmar a versão do GKE que foi usada para criar o cluster, pode consultar o recurso initialClusterVersion através do seguinte comando:

  gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
  

Se o cluster do GKE tiver o registo ativado, o contentor cilium-agent regista a mensagem unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key no Explorador de registos através da seguinte consulta:

   resource.type="k8s_container"
   resource.labels.container_name="cilium-agent"
  

Solução alternativa:

Uma mitigação temporária consiste em reiniciar o plano de controlo. Isto pode ser conseguido atualizando o plano de controlo para a mesma versão que já está a ser executada:

  gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master
  

O controlador NEG deixa de gerir os pontos finais quando a porta é removida do serviço

Quando o controlador NEG está configurado para criar um NEG autónomo para um serviço e uma das portas configuradas for posteriormente removida do serviço, o controlador NEG acaba por deixar de gerir os pontos finais do NEG. Além dos serviços em que o utilizador cria uma anotação NEG autónoma, isto também afeta os serviços que são referenciados pelo GKE Gateway, MCI e GKE Multi Cluster Gateway.

Solução alternativa:

Quando remove uma porta de um serviço com uma anotação NEG autónoma, a anotação também tem de ser atualizada para remover a porta em questão.

Erro de configuração de TLS do gateway

Identificámos um problema com a configuração do TLS para gateways em clusters com a versão 1.28.4-gke.1083000 do GKE. Isto afeta as configurações TLS que usam um SSLCertificate ou um CertificateMap. Se estiver a atualizar um cluster com gateways existentes, as atualizações feitas ao gateway falham. Para novos gateways, os balanceadores de carga não são aprovisionados. Este problema vai ser corrigido numa versão de patch do GKE 1.28 futura.

• 1.26.13-gke.1052000 e posterior
• 1.27.10-gke.1055000 e posteriores
• 1.28.6-gke.1095000 e posterior
• 1.29.1-gke.1016000 e posteriores

Falhas intermitentes no estabelecimento de ligação

Os clusters nas versões 1.26.6-gke.1900 e posteriores do plano de controlo podem encontrar falhas intermitentes no estabelecimento de ligações.

As probabilidades de falhas são baixas e não afetam todos os clusters. As falhas devem parar completamente após alguns dias desde o início do sintoma.

• 1.27.11-gke.1118000 ou posterior
• 1.28.7-gke.1100000 ou posterior
• 1.29.2-gke.1217000 ou posterior

Problemas de resolução de DNS com o SO otimizado para contentores

As cargas de trabalho executadas em clusters do GKE com nós baseados no SO otimizado para contentores podem ter problemas de resolução de DNS.

A política de rede rejeita uma ligação devido a uma pesquisa de acompanhamento de ligações incorreta

Para clusters com o GKE Dataplane V2 ativado, quando um pod cliente se liga a si próprio através de um serviço ou do endereço IP virtual de um equilibrador de carga de rede de passagem interno, o pacote de resposta não é identificado como parte de uma ligação existente devido a uma pesquisa de conntrack incorreta no plano de dados. Isto significa que uma política de rede que restringe o tráfego de entrada para o pod é aplicada incorretamente no pacote.

O impacto deste problema depende do número de pods configurados para o serviço. Por exemplo, se o serviço tiver 1 pod de back-end, a ligação falha sempre. Se o serviço tiver 2 pods de back-end, a ligação falha 50% das vezes.

Solução alternativa:

Pode mitigar este problema configurando o port e o containerPort no manifesto do serviço para terem o mesmo valor.

• 1.28.3-gke.1090000 ou posterior
• 1.27.11-gke.1097000 ou posterior

Perdas de pacotes para fluxos de ligação em cotovelo

Para clusters com o GKE Dataplane V2 ativado, quando um pod cria uma ligação TCP a si próprio através de um serviço, de modo que o pod seja a origem e o destino da ligação, o GKE Dataplane V2 eBPF rastreia incorretamente os estados de ligação, o que leva a entradas de conntrack com fugas.

Quando uma tupla de ligação (protocolo, IP de origem/destino e porta de origem/destino) foi divulgada, as novas ligações que usam a mesma tupla de ligação podem resultar na rejeição de pacotes de retorno.

Solução alternativa:

Use uma das seguintes soluções alternativas:

• Ativar a reutilização de TCP (keep-alives) para uma aplicação em execução num pod que pode comunicar consigo própria através de um serviço. Isto impede a emissão da flag FIN do TCP e evita a fuga da entrada de conntrack.
• Quando usar ligações de curta duração, exponha o pod através de um balanceador de carga de proxy, como o Gateway, para expor o serviço. Isto faz com que o destino do pedido de ligação seja definido para o endereço IP do balanceador de carga, o que impede que o GKE Dataplane V2 execute o SNAT para o endereço IP de loopback.

A rede introduzida no dispositivo na rede múltipla do GKE falha com nomes de rede longos

A criação do cluster falha com o seguinte erro:

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

Solução alternativa:

Limite o comprimento dos nomes de objetos de rede introduzidos no dispositivo a 41 carateres ou menos. O caminho completo de cada socket de domínio UNIX é composto, incluindo o nome da rede correspondente. O Linux tem uma limitação no comprimento dos caminhos de sockets (inferior a 107 bytes). Depois de ter em conta o diretório, o prefixo do nome do ficheiro e a extensão .sock, o nome da rede está limitado a um máximo de 41 carateres.

• 1.30.4-gke.1282000 ou posterior
• 1.29.8-gke.1157000 ou posterior
• 1.28.13-gke.1078000 ou posterior
• 1.27.16-gke.1342000 ou posterior

Problemas de conetividade para hostPort pods após a atualização do plano de controlo

Os clusters com a política de rede ativada podem ter problemas de conetividade com os pods hostPort. Além disso, os Pods criados recentemente podem demorar mais 30 a 60 segundos a ficar prontos.

O problema é acionado quando o painel de controlo do GKE de um cluster é atualizado para uma das seguintes versões do GKE

• 1.30 a 1.30.4-gke.1281999
• 1.29.1-gke.1545000 a 1.29.8-gke.1156999
• 1.28.7-gke.1042000 a 1.28.13-gke.1077999
• 1.27.12-gke.1107000 a 1.27.16-gke.1341999

Solução alternativa:

Atualize ou recrie nós imediatamente após a atualização do plano de controlo do GKE.

• 1.32.1-gke.1729000 ou posterior
• 1.31.6-gke.1020000 ou posterior

Tráfego UDP danificado entre pods executados no mesmo nó

Os clusters com a visibilidade intranó ativada podem ter problemas com o tráfego UDP entre pods executados no mesmo nó.

O problema é acionado quando o nó do cluster do GKE é atualizado para uma das seguintes versões do GKE ou é criado com uma delas:

• 1.32.1-gke.1729000 ou posterior
• 1.31.6-gke.1020000 ou posterior

O caminho afetado é o tráfego UDP de pod para pod no mesmo nó através de Hostport ou serviço.

Resolução

Atualize o cluster para uma das seguintes versões corrigidas:

• 1.32.3-gke.1927000 ou posterior
• 1.31.7-gke.1390000 ou posterior

Os Calico Pods não estão em bom estado nos clusters com menos de 3 nós totais e um número insuficiente de vCPUs

Não é possível agendar pods calico-typha e calico-node em clusters que cumpram todas as seguintes condições: menos de 3 nós no total, cada nó com 1 ou menos vCPUs atribuíveis e política de rede ativada. Isto deve-se a recursos da CPU insuficientes.

Soluções alternativas:

• Escale para um mínimo de 3 conjuntos de nós com 1 nó a usar 1 vCPU atribuível.
• Redimensione um único node pool para um mínimo de 3 nós com 1 vCPU atribuível.
• Use um tipo de máquina com, pelo menos, 2 vCPUs atribuíveis num conjunto de nós com um único nó.

Indisponibilidades do Multi-Cluster Gateway (MCG) em clusters zonais durante as atualizações do plano de controlo

As implementações que usam o Multi-Cluster Gateway (MCG) em clusters zonais do GKE podem sofrer interrupções com erros `503` durante eventos que causam um reinício do plano de controlo, como uma atualização do cluster. Isto ocorre porque o MCG depende de um mecanismo antigo para a deteção do grupo de pontos finais de rede (NEG) que comunica incorretamente zero back-ends quando os nós num cluster zonal ficam temporariamente indisponíveis durante o reinício do plano de controlo. Isto faz com que o balanceador de carga remova todos os back-ends, o que resulta na perda de tráfego.

Soluções alternativas:

• A solução recomendada é migrar do cluster do GKE zonal para o cluster do GKE regional. Os clusters regionais têm um plano de controlo de elevada disponibilidade, o que elimina o ponto único de falha que aciona este problema durante as atualizações ou os reinícios.