Resolver problemas de entrada do GKE

Problemas com Entrada no Google Kubernetes Engine (GKE) podem impedir que o tráfego externo ou interno chegue aos seus serviços.

Use este documento para encontrar soluções para erros relacionados à classe Entrada, anotações de IP estático, tamanhos de chaves de certificado e interações com níveis de rede.

Estas informações são destinadas a administradores e operadores de plataforma e desenvolvedores de aplicativos que implantam e gerenciam aplicativos expostos usando Entrada no GKE. Para mais informações sobre os papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Funções e tarefas de usuário comuns do GKE.

A anotação da classe Entrada está incorreta

Sintoma

Ao criar um Entrada, você pode receber o seguinte erro:

Missing one or more resources. If resource creation takes longer than expected, you might have an invalid configuration.

Causas possíveis

Ao criar a Entrada, talvez você tenha configurado incorretamente a classe de Entrada no manifesto.

Resolução

Para especificar uma classe de entrada, é necessário usar a anotação kubernetes.io/ingress.class. Não é possível especificar uma Entrada do GKE usando spec.ingressClassName.

  • Para implantar um balanceador de carga de aplicativo interno, use a anotação kubernetes.io/ingress.class: gce-internal.
  • Para implantar um balanceador de carga de aplicativo externo, use a anotação kubernetes.io/ingress.class: gce.

A anotação do endereço IP estático está incorreta

Sintoma

Ao configurar um Entrada externo para usar um endereço IP estático, você pode receber o seguinte erro:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer <Name of load balancer> does not exist: the given static IP name <Static IP> doesn't translate to an existing static IP.

Causas possíveis

  • Você não criou um endereço IP externo estático antes de implantar o Entrada.
  • Você não está usando a anotação correta para seu tipo de balanceador de carga.

Resolução

Se você estiver configurando uma Entrada externa:

Se você estiver configurando um Entrada interno:

  • Reserve um endereço IP interno estático regional antes de implantar o Entrada.
  • Use a anotação kubernetes.io/ingress.regional-static-ip-name no recurso de entrada.

O endereço IP estático já está em uso

Sintoma

Você pode receber o seguinte erro ao especificar um endereço IP estático para provisionar o recurso de entrada interno ou externo:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <LB name> does not exist:
googleapi: Error 409: IP_IN_USE_BY_ANOTHER_RESOURCE - IP ''<IP address>'' is already being used by another resource.

Causas possíveis

O endereço IP estático já está sendo usado por outro recurso.

Erro ao desativar o HTTP e usar um certificado gerenciado pelo Google

Sintoma

Se você estiver configurando um certificado SSL gerenciado pelo Google e desativando o tráfego HTTP no Entrada, vai aparecer o seguinte erro:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <Load Balancer name> does not exist:
googleapi: Error 404: The resource ''projects/<Project>/global/sslPolicies/<Policy name>' was not found, notFound

Causas possíveis

Não é possível usar as seguintes anotações juntas ao configurar o Entrada:

  • networking.gke.io/managed-certificates (para associar o certificado gerenciado pelo Google a uma Entrada)
  • kubernetes.io/ingress.allow-http: false (para desativar o tráfego HTTP)

Resolução

Desative o tráfego HTTP somente depois que o balanceador de carga de aplicativo externo estiver totalmente programado. Você pode atualizar a entrada e adicionar a anotação kubernetes.io/ingress.allow-http: false ao manifesto.

A sub-rede somente proxy está ausente para um recurso de entrada interno

Sintoma

Ao implantar um Entrada para um balanceador de carga de aplicativo interno, talvez você veja o seguinte erro:

Error syncing to GCP: error running load balancer syncing routine:
loadbalancer <LB name> does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/<Project ID>/regions/<Region>/targetHttpsProxies/<Target proxy>'.
An active proxy-only subnetwork is required in the same region and VPC as
the forwarding rule.

Causas possíveis

Você não criou uma sub-rede somente proxy antes de criar o recurso de entrada. Uma sub-rede somente proxy é necessária para balanceadores de carga de aplicativo internos.

Resolução

Crie uma sub-rede somente proxy antes de implantar o Entrada interno.

A chave do certificado SSL é muito grande

Sintoma

Se o tamanho da chave do certificado SSL do balanceador de carga for muito grande, você poderá receber o seguinte erro:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer gky76k70-load-test-trillian-api-ingress-fliismmb does not exist: Cert creation failures - k8s2-cr-gky76k70-znz6o1pfu3tfrguy-f9be3a4abbe573f7 Error:googleapi: Error 400: The SSL key is too large., sslCertificateKeyTooLarge

Causas possíveis

Google Cloud tem um limite de 2.048 bits para chaves de certificado SSL.

Resolução

Reduza o tamanho da chave do certificado SSL para 2.048 bits ou menos.

Erro ao criar uma entrada no nível Standard

Sintoma

Se você estiver implantando um Entrada em um projeto com o nível de rede padrão do projeto definido como Standard, a seguinte mensagem de erro vai aparecer:

Error syncing to GCP: error running load balancer syncing routine: load balancer <LB Name> does not exist: googleapi: Error 400: STANDARD network tier (the project''s default network tier) is not supported: STANDARD network tier is not supported for global forwarding rule., badRequest

Resolução

Configure o nível de rede padrão do projeto como Premium.

Erro "Não encontrado" esperado para k8s-ingress-svc-acct-permission-check-probe

O controlador de Ingress realiza verificações periódicas das permissões da conta de serviço buscando um recurso de teste do seu projeto Google Cloud . Você vai encontrar isso como um GET do BackendService global (não existente) com o nome k8s-ingress-svc-acct-permission-check-probe. Como esse recurso normalmente não existe, a solicitação GET vai retornar "não encontrado". Isso é esperado. O controlador está verificando se a chamada de API não foi rejeitada devido a problemas de autorização. Se você criar um BackendService com o mesmo nome, o GET será bem-sucedido em vez de retornar "não encontrado".

Erros ao usar o balanceamento de carga nativo de contêiner

Use as técnicas a seguir para verificar a configuração de rede. As seções a seguir explicam como resolver problemas comuns relacionados ao balanceamento de carga nativo de contêiner.

  • Veja a documentação de balanceamento de carga para saber como listar grupos de endpoints de rede.

  • É possível encontrar o nome e as zonas do NEG correspondente a um serviço na anotação neg-status do serviço. Veja a especificação do serviço com:

    kubectl get svc SVC_NAME -o yaml

    A anotação metadata:annotations:cloud.google.com/neg-status lista as zonas e o nome do NEG correspondente ao serviço.

  • É possível verificar a integridade do serviço de back-end correspondente a um NEG com o seguinte comando:

    gcloud compute backend-services --project PROJECT_NAME \
    get-health BACKEND_SERVICE_NAME --global

    O serviço de back-end tem o mesmo nome que o NEG.

  • Para imprimir os logs de eventos de um serviço:

    kubectl describe svc SERVICE_NAME

    A string do nome do serviço inclui o nome e o namespace do serviço correspondente do GKE.

Não é possível criar um cluster com IPs de alias

Sintomas

Quando você tenta criar um cluster com IPs de alias, pode encontrar o seguinte erro:

ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Causas possíveis

Você encontrará esse erro se tentar criar um cluster com IPs de alias que também usa uma rede legada.

Resolução

Verifique se você não criou um cluster com IPs de alias e uma rede legada ativada simultaneamente. Para mais informações sobre como usar IPs de alias, consulte Criar um cluster nativo de VPC.

O tráfego não alcança os endpoints

Sintomas
Erros 502/503 ou conexões rejeitadas.
Causas possíveis

Novos endpoints geralmente se tornam acessíveis depois de anexados ao balanceador de carga, desde que respondam a verificações de integridade. Poderão ocorrer erros 502 ou conexões rejeitadas se o tráfego não conseguir alcançar os endpoints.

Erros 502 e conexões rejeitadas também podem ser causados por um contêiner que não lida com SIGTERM. Se um contêiner não lida com SIGTERM de maneira explícita, ele encerra imediatamente e para de processar as solicitações. O balanceador de carga continua a enviar tráfego de entrada para este contêiner encerrado, causando erros.

O balanceador de carga nativo do contêiner tem apenas um endpoint de back-end. Durante uma atualização gradual, o endpoint antigo é desprogramado antes que o novo endpoint seja programado.

Os pods de back-end são implantados em uma nova zona pela primeira vez depois que um balanceador de carga nativo de contêiner é provisionado. A infraestrutura do balanceador de carga é programada em uma zona quando há pelo menos um endpoint na zona. Quando um novo endpoint é adicionado a uma zona, a infraestrutura do balanceador de carga é programada e causa interrupções no serviço.

Resolução

Configure os contêineres para lidar com SIGTERM e continuar a responder às solicitações durante o período de carência do encerramento (30 segundos por padrão). Configure os pods para começarem a falhar nas verificações de integridade ao receberem SIGTERM. Isso envia um sinal para que o balanceador de carga pare de enviar tráfego para o pod enquanto a desprogramação do endpoint estiver em andamento.

Se o aplicativo não for encerrado normalmente e parar de responder a solicitações ao receber um SIGTERM, o hook preStop poderá ser usado para processar SIGTERM e continuar veiculando tráfego enquanto a desprogramação do endpoint estiver em andamento.

lifecycle:
  preStop:
    exec:
      # if SIGTERM triggers a quick exit; keep serving traffic instead
      command: ["sleep","60"]

Consulte a documentação sobre encerramento de pods.

Se o back-end do balanceador de carga tiver apenas uma instância, configure a estratégia de implantação para evitar a desmontagem da única instância antes que a nova instância seja completamente programada. Para pods de aplicativos gerenciados pela carga de trabalho Deployment, isso pode ser feito configurando a estratégia de lançamento com o parâmetro maxUnavailable igual a 0.

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Para solucionar problemas de tráfego que não alcança os endpoints, verifique se as regras de firewall permitem o tráfego TCP de entrada para os endpoints nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Para saber mais, consulte Como adicionar verificações de integridade na documentação do Cloud Load Balancing.

Veja os serviços de back-end no seu projeto. A string de nome do serviço de back-end relevante inclui o nome e o namespace do serviço do GKE correspondente:

gcloud compute backend-services list

Recupere o status de integridade do back-end do serviço correspondente:

gcloud compute backend-services get-health BACKEND_SERVICE_NAME

Se nenhum back-end estiver íntegro, significa que pode haver problemas na configuração de seu firewall, sua entrada ou seu serviço.

Se alguns back-ends não estiverem íntegros por um curto período de tempo, a causa poderá ser a latência de programação de rede.

Se alguns back-ends não aparecerem na lista de serviços de back-end, a causa poderá ser a latência de programação. É possível verificar isso executando o seguinte comando, em que NEG_NAME é o nome do serviço de back-end. NEGs e serviços de back-end compartilham o mesmo nome:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Verifique se todos os endpoints esperados estão no NEG.

Se você tiver um pequeno número de back-ends (por exemplo, um pod) selecionado por um balanceador de carga nativo de contêiner, considere aumentar o número de réplicas e distribuir os pods de back-end em todas as zonas do cluster do GKE. Isso garante que a infraestrutura subjacente do balanceador de carga seja totalmente programada. Caso contrário, considere restringir os pods de back-end a uma única zona.

Se você configurar uma política de rede para o endpoint, verifique se a entrada da sub-rede somente proxy é permitida.

Lançamento interrompido

Sintomas
O lançamento de uma implantação atualizada é interrompido e o número de réplicas atualizadas não corresponde ao escolhido.
Causas possíveis

As verificações de integridade da implantação estão falhando. A imagem do contêiner pode estar corrompida ou a verificação de integridade pode estar mal configurada. O lançamento da substituição dos pods está esperando até que o pod recém-iniciado passe o portão de prontidão do pod (em inglês). Isso só ocorrerá se o pod estiver respondendo às verificações de integridade do balanceador de carga. Se o pod não responder ou se a verificação de integridade estiver configurada incorretamente, as condições do portão de prontidão não serão atendidas e o lançamento não poderá continuar.

Se você estiver usando kubectl 1.13 ou superior, é possível verificar o status dos portões de prontidão de um pod com o seguinte comando:

kubectl get pod POD_NAME -o wide

Verifique a coluna READINESS GATES.

Essa coluna não existe em kubectl 1,12 ou inferior. Um pod marcado como READY pode ter um portão de prontidão falho. Para verificar isso, use o seguinte comando:

kubectl get pod POD_NAME -o yaml

Os portões de prontidão e os status deles são listados na saída.

Resolução

Verifique se a imagem do contêiner na especificação do pod de implantação está funcionando corretamente e se é capaz de responder a verificações de integridade. Verifique se as verificações de integridade estão configuradas corretamente.

Erros de modo degradado

Sintomas

A partir da versão 1.29.2-gke.1643000 do GKE, você pode receber os seguintes avisos no serviço na Análise de registros quando os NEGs são atualizados:

Entering degraded mode for NEG <service-namespace>/<service-name>-<neg-name>... due to sync err: endpoint has missing nodeName field
Causas possíveis

Esses avisos indicam que o GKE detectou configurações incorretas do endpoint durante uma atualização do NEG com base em objetos EndpointSlice, acionando um processo de cálculo mais detalhado chamado modo degradado. O GKE continua atualizando os NEGs com base no melhor esforço, corrigindo a configuração incorreta ou excluindo os endpoints inválidos das atualizações do NEG.

Alguns erros comuns são:

  • endpoint has missing pod/nodeName field
  • endpoint corresponds to an non-existing pod/node
  • endpoint information for attach/detach operation is incorrect
Resolução

Normalmente, os estados transitórios causam esses eventos e são corrigidos por conta própria. No entanto, os eventos causados por configurações incorretas em objetos EndpointSlice personalizados permanecem sem resolução. Para entender a configuração incorreta, examine os objetos EndpointSlice correspondentes ao serviço:

kubectl get endpointslice -l kubernetes.io/service-name=<service-name>

Valide cada endpoint com base no erro do evento.

Para resolver o problema, você precisa modificar manualmente os objetos EndpointSlice. A atualização aciona os NEGs a serem atualizados. Quando a configuração incorreta não existir mais, a saída será semelhante a esta:

NEG <service-namespace>/<service-name>-<neg-name>... is no longer in degraded mode

Erros ao usar certificados SSL gerenciados pelo Google

Nesta seção, apresentamos informações sobre como resolver problemas com certificados gerenciados do Google.

Verifique eventos nos recursos ManagedCertificate e Entrada

Se você exceder o número de certificados permitidos, um evento com um motivo TooManyCertificates será adicionado ao ManagedCertificate. Verifique os eventos em um objeto ManagedCertificate usando o comando a seguir:

kubectl describe managedcertificate CERTIFICATE_NAME

Substitua CERTIFICATE_NAME pelo nome do ManagedCertificate.

Se você anexar um ManagedCertificate inexistente a uma Entrada, um evento com um motivo MissingCertificate será adicionado à Entrada. Verifique os eventos em uma Entrada usando o seguinte comando:

kubectl describe ingress INGRESS_NAME

Substitua INGRESS_NAME pelo nome do seu Ingress.

Certificado gerenciado não provisionado quando o domínio resolve para endereços IP de vários balanceadores de carga

Quando o domínio estiver resolvido para endereços IP de vários balanceadores de carga (vários objetos de Entrada), crie um único objeto ManagedCertificate e anexe-o a todos os objetos de Entrada. Se, em vez disso, você criar muitos objetos ManagedCertificate e anexar cada um deles a uma Entrada separada, a autoridade de certificação talvez não consiga verificar a propriedade do domínio, e alguns dos certificados podem não ser provisionado. Para que a verificação seja bem-sucedida, o certificado precisa estar visível para todos os endereços IP onde seu domínio é resolvido.

Especificamente, quando seu domínio resolver para endereços IPv4 e IPv6 configurados com diferentes recursos de Entrada, crie um único recurso ManagedCertificate e anexe-o às duas entradas.

Comunicação interrompida entre certificados gerenciados do Google e a Entrada

Os certificados gerenciados se comunicam com a Entrada usando a anotaçãoingress.gcp.kubernetes.io/pre-shared-cert Essa comunicação poderá ser interrompida se você, por exemplo:

  • Execute um processo automatizado que limpa a anotação ingress.gcp.kubernetes.io/pre-shared-cert.
  • Armazene um snapshot da Entrada e depois exclua e restaure a Entrada a partir do snapshot. Enquanto isso, um recurso SslCertificate listado na anotação ingress.gcp.kubernetes.io/pre-shared-cert pode ter sido excluído. A entrada não funcionará se faltar algum certificado anexado a ele.

Se a comunicação entre certificados gerenciados do Google e a Entrada for interrompida, exclua o conteúdo da anotação ingress.gcp.kubernetes.io/pre-shared-cert e aguarde a reconciliação do sistema. Para evitar recorrência, verifique se a anotação não foi modificada ou excluída por engano.

Erros de validação ao criar um certificado gerenciado do Google

As definições de ManagedCertificate são validadas antes da criação do objeto ManagedCertificate. Se a validação falhar, o objeto ManagedCertificate não será criado e uma mensagem de erro será impressa. As diferentes mensagens de erro e os motivos são explicados da seguinte maneira:

spec.domains in body should have at most 100 items

Seu manifesto ManagedCertificate lista mais de 100 domínios no campo spec.domains. Os certificados gerenciados do Google são compatíveis com até 100 domínios.

spec.domains in body should match '^(([a-zA-Z0-9]+|[a-zA-Z0-9][-a-zA-Z0-9]*[a-zA-Z0-9])\.)+[a-zA-Z][-a-zA-Z0-9]*[a-zA-Z0-9]\.?$'

Você especificou um nome de domínio inválido ou um nome de domínio curinga no campo spec.domains. O objeto ManagedCertificate não tem suporte para domínios curinga (por exemplo, *.example.com).

spec.domains in body should be at most 63 chars long

Você especificou um nome de domínio longo demais. Certificados gerenciados do Google são compatíveis com nomes de domínio com, no máximo, 63 caracteres.

Como atualizar manualmente um certificado gerenciado pelo Google

Para atualizar manualmente o certificado de modo que o certificado do domínio antigo continue funcionando até que o novo seja provisionado, siga estas etapas:

  1. Crie um ManagedCertificate para o novo domínio.
  2. Adicione o nome do ManagedCertificate à anotação networking.gke.io/managed-certificates na entrada usando uma lista separada por vírgulas. Não remova o nome do certificado antigo.
  3. Aguarde até que o ManagedCertificate fique ativo.
  4. Desanexe o certificado antigo da Entrada e exclua-o.

Quando você cria um ManagedCertificate,o Google Cloud cria um certificado SSL gerenciado pelo Google. Não é possível atualizar o certificado. Se você atualizar o ManagedCertificate, Google Cloud excluirá e recriará o certificado SSL gerenciado pelo Google.

Para fornecer uma Entrada criptografada por HTTPS segura para seus clusters do GKE, consulte o exemplo de Entrada segura.

A seguir

  • Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: