Solucionar problemas de verificações de integridade do Ingress

As verificações de integridade com falha do Ingress no Google Kubernetes Engine (GKE) podem impedir que o tráfego chegue ao aplicativo, mesmo que os pods estejam em execução.

Use este documento para saber como as verificações de integridade do Entrada funcionam, entender as considerações sobre BackendConfig e sondagem de prontidão e diagnosticar problemas como aplicativos sem resposta ou regras de firewall ausentes.

Essas informações são importantes para administradores e operadores de plataforma e desenvolvedores de aplicativos que configuram e gerenciam recursos do Entrada e precisam garantir que os aplicativos estejam informando corretamente a integridade ao balanceador de carga. Para mais informações sobre os papéis comuns e exemplos de tarefas que referenciamos no Google Cloud conteúdo, consulte Tarefas e papéis de usuário comuns do GKE.

Entender como as verificações de integridade do Entrada funcionam

Antes de prosseguir para as etapas de solução de problemas, é útil entender como as verificações de integridade funcionam no GKE e quais considerações devem ser consideradas para garantir verificações de integridade bem-sucedidas.

Quando você expõe um ou mais serviços por meio de um Entrada usando o controlador padrão Entrada, o GKE cria um balanceador de carga de aplicativo clássico ou um balanceador de carga de aplicativo interno. Esses dois balanceadores de carga são compatíveis com vários serviços de back-end em um único mapa de URLs. Cada um dos serviços de back-end corresponde a um serviço do Kubernetes, e cada serviço de back-end precisa fazer referência a uma Google Cloud verificação de integridade. Essa verificação de integridade é diferente de uma sondagem de atividade ou prontidão do Kubernetes porque a verificação de integridade é implementada fora do cluster.

As verificações de integridade do balanceador de carga são especificadas por serviço de back-end. Embora seja possível usar a mesma verificação de integridade em todos os serviços de back-end do balanceador de carga, a referência da verificação de integridade não é especificada para o balanceador de carga como um todo (no objeto Entrada).

O GKE cria verificações de integridade com base em um dos seguintes métodos:

  • CRD BackendConfig: uma definição de recurso personalizada (CRD) que oferece controle preciso sobre como os serviços interagem com o balanceador de carga. As CRDs BackendConfig permitem especificar configurações personalizadas para a verificação de integridade associada ao serviço de back-end correspondente. Essas configurações personalizadas oferecem maior flexibilidade e controle sobre as verificações de integridade do balanceador de carga de aplicativo clássico e do balanceador de carga de aplicativo interno criado por um Entrada.
  • Sondagem de prontidão: uma verificação de diagnóstico que determina se um contêiner em um pod está pronto para veicular tráfego. O controlador do Ingress do GKE cria a verificação de integridade para o serviço de back-end do Serviço com base na sondagem de prontidão usada pelos pods de exibição desse Serviço. É possível derivar os parâmetros de verificação de integridade, como caminho, porta e protocolo, da definição de sondagem de prontidão.
  • Valores padrão: os parâmetros usados quando você não configura uma BackendConfig CRD ou define atributos para a sondagem de prontidão.
Prática recomendada:

Use uma CRD BackendConfig para ter mais controle sobre as configurações de verificação de integridade do balanceador de carga.

O GKE usa o procedimento a seguir para criar uma verificação de integridade para cada serviço de back-end correspondente a um serviço do Kubernetes:

  • Se o serviço referir-se a uma CRD BackendConfig com informações de healthCheck, o GKE usará isso para criar a verificação de integridade. Tanto o controlador do Ingress do GKE Enterprise quanto o controlador do Ingress do GKE dão suporte à criação de verificações de integridade dessa maneira.

  • Se o Serviço não referenciar um CRD BackendConfig:

    • O GKE poderá inferir alguns ou todos os parâmetros de uma verificação de integridade. Para isso, os pods de exibição precisam usar um modelo com um contêiner em que a sondagem de prontidão tenha atributos que possam ser interpretados como parâmetros de verificação de integridade. Consulte Parâmetros de uma sondagem de prontidão para ver detalhes de implementação e Parâmetros padrão e inferidos para ver uma lista de atributos que podem ser usados para criar parâmetros de verificações de integridade. Somente o controlador de Ingress do GKE tem suporte para inferência de parâmetros de uma sondagem de prontidão.

    • Se o modelo dos pods de exibição do Serviço não tiver um contêiner com uma sondagem de prontidão que tenha atributos que possam ser interpretados como parâmetros de verificação de integridade, os valores padrão serão usados para criar a verificação de integridade. O controlador do Ingress do GKE Enterprise e o controlador do Ingress do GKE podem criar uma verificação de integridade usando apenas os valores padrão.

Considerações

Esta seção descreve algumas considerações a serem consideradas ao configurar uma CRD BackendConfig ou usar uma sondagem de prontidão.

CRD BackendConfig

Ao configurar CRDs BackendConfig, tenha em mente as seguintes considerações:

  • Se você estiver usando balanceamento de carga nativo de contêiner, verifique se a porta de verificação de integridade no manifesto BackendConfig corresponde ao containerPort de um pod de exibição.
  • Para back-ends de grupos de instâncias, verifique se a porta de verificação de integridade no manifesto BackendConfig corresponde ao nodePort exposto pelo Serviço.
  • Entrada não é compatível com gRPC para configurações de verificação de integridade personalizadas. O BackendConfig só oferece suporte à criação de verificações de integridade usando os protocolos HTTP, HTTPS ou HTTP2. Para um exemplo de como usar o protocolo em uma BackendConfig CRD, consulte gke-networking-recipes.

Para mais informações, consulte Quando usar BackendConfig CRDs.

Sondagem de prontidão

Ao usar o Ingress do GKE com o balanceamento de carga HTTP ou HTTPS, o GKE envia as sondagens de verificação de integridade para determinar se o aplicativo está em execução corretamente. Essas sondagens de verificação de integridade são enviadas para a porta específica nos pods definidos na seção spec.containers[].readinessProbe.httpGet.port da configuração YAML do pod, desde que as seguintes condições sejam atendidas:

  • O número da porta da sondagem de prontidão especificado em spec.containers[].readinessProbe.httpGet.port precisa corresponder à porta real em que o aplicativo está escutando no contêiner, que é definido no campo containers[].spec.ports.containerPort da configuração do pod.
  • O containerPort do pod de exibição precisa corresponder ao targetPort do serviço. Isso garante que o tráfego seja direcionado do serviço para a porta correta nos pods.
  • A especificação da porta de back-end do serviço Ingress precisa fazer referência a uma porta válida da seção spec.ports[] das configurações de serviço. Isso pode ser feito de duas maneiras:
    • spec.rules[].http.paths[].backend.service.port.name no Entrada corresponde a spec.ports[].name definido no serviço correspondente.
    • spec.rules[].http.paths[].backend.service.port.number no Entrada corresponde a spec.ports[].port definido no serviço correspondente.

Resolver problemas comuns de verificação de integridade

Use o fluxograma de solução de problemas a seguir para ajudar a identificar problemas de verificação de integridade:

Solução de problemas de verificações de integridade do Ingress.
Figura: solucionar problemas de verificações de integridade

Neste fluxograma, as seguintes orientações de solução de problemas ajudam a determinar onde o problema está:

  1. Investigar a integridade do pod: se a verificação de integridade falhar, examine o status dos pods de exibição do serviço. Se os pods não estiverem em execução e íntegros:

    • Verifique os registros do pod para detectar erros ou problemas que impeçam a execução deles.
    • Verifique o status das sondagens de prontidão e atividade.

  2. Geração de registros de verificação de integridade: verifique se você ativou a geração de registros de verificação de integridade.

  3. Verificar a configuração do firewall: verifique se as regras de firewall permitem que as sondagens de verificação de integridade cheguem aos pods. Se não:

    • Verifique as regras de firewall para confirmar se elas permitem o tráfego de entrada dos intervalos de endereços IP da sondagem de verificação de integridade.
    • Ajuste as regras de firewall conforme necessário para acomodar esses intervalos de endereços IP.

  4. Analisar a captura de pacotes: se o firewall estiver configurado corretamente, execute uma captura de pacotes para verificar se o aplicativo está respondendo às verificações de integridade. Se a captura de pacotes mostrar uma resposta bem-sucedida, entre em contato com o Google Cloud suporte para receber mais ajuda.

  5. Solucionar problemas do aplicativo: se a captura de pacotes não mostrar uma resposta bem-sucedida, investigue por que o aplicativo não está respondendo corretamente às solicitações de verificação de integridade. Verifique se a verificação de integridade está direcionada ao caminho e à porta corretos nos pods e examine os registros de aplicativos, arquivos de configuração e dependências. Se você não encontrar o erro, entre em contato com o Google Cloud suporte.

Aplicativo sem resposta às verificações de integridade

O aplicativo não responde com o código de status esperado (200 OK para HTTP ou SYN, ACK para TCP) durante as verificações de integridade no caminho e na porta configurados.

Se o aplicativo não responder corretamente às verificações de integridade, isso poderá ocorrer por um dos seguintes motivos:

  • Grupos de endpoints de rede(NEGs, na sigla em inglês):
    • O aplicativo não está em execução corretamente no pod.
    • O aplicativo não está escutando na porta ou no caminho configurado.
    • Há problemas de conectividade de rede que impedem que a verificação de integridade chegue ao pod.
  • Grupo de instâncias:
    • Os nós no grupo de instâncias não estão íntegros.
    • O aplicativo não está em execução corretamente nos nós.
    • As solicitações de verificação de integridade não estão chegando aos nós.

Se as verificações de integridade falharem, com base na configuração, solucione o problema da seguinte maneira:

Para NEGs:

  1. Acesse um pod usando kubectl exec:

    kubectl exec -it pod-name -- command

    A flag -it fornece uma sessão de terminal interativa (i para interativo, t para TTY).

    Substitua:

    • pod-name: o nome do pod.
    • command: o comando que você quer executar no pod. O comando mais comum é bash ou sh para acessar um shell interativo.

  2. Execute comandos curl para testar a conectividade e a capacidade de resposta do aplicativo:

    • curl localhost:<Port>/<Path>
    • curl -v http://<POD_IP>/[Path configured in HC]
    • curl http://localhost/[Path configured in HC]

Para grupos de instâncias:

  1. Verifique se os nós estão íntegros e respondendo às sondagens de verificação de integridade padrão.
  2. Se os nós estiverem íntegros, mas o pod do aplicativo não estiver respondendo, investigue o aplicativo.
  3. Se as solicitações não estiverem chegando aos pods, pode ser um problema de rede do GKE. Entre em contato com o Google Cloud suporte para receber ajuda.

Erro ao editar a sondagem de prontidão no pod

Quando você tenta editar a sondagem de prontidão em um pod para mudar os parâmetros de verificação de integridade, ocorre um erro semelhante ao seguinte:

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

Se você modificar a sondagem de prontidão dos pods associados a um serviço que já está vinculado a um Entrada (e ao balanceador de carga correspondente), o GKE não atualizará automaticamente a configuração de verificação de integridade no balanceador de carga. Isso leva a uma incompatibilidade entre a verificação de prontidão do pod e a verificação de integridade do balanceador de carga, fazendo com que a verificação de integridade falhe.

Para resolver esse problema, reimplemente os pods e o recurso de entrada. Isso força o GKE a recriar o balanceador de carga e as verificações de integridade e incorporar as novas configurações de sondagem de prontidão.

A implantação e o balanceador de carga não são iniciados

Se a implantação não for iniciada e os serviços de back-end por trás do balanceador de carga do controlador de entrada forem marcados como não íntegros, um erro de sondagem de prontidão poderá ser o motivo.

Talvez você veja a seguinte mensagem de erro mencionando uma falha de sondagem de prontidão:

Readiness probe failed: connection refused

O aplicativo no pod não responde corretamente à sondagem de prontidão configurada na configuração YAML do pod. Isso pode ocorrer por vários motivos, como o aplicativo não ser iniciado corretamente, escutar na porta errada ou encontrar um erro durante a inicialização.

Para resolver esse problema, investigue e corrija as discrepâncias na configuração ou no comportamento do aplicativo fazendo o seguinte:

  • Verifique se o aplicativo está configurado corretamente e respondendo no caminho e na porta especificados nos parâmetros de sondagem de prontidão.
  • Analise os registros do aplicativo e solucione problemas ou erros de inicialização.
  • Verifique se o containerPort na configuração do pod corresponde ao targetPort no serviço e à porta de back-end especificada no Entrada.

Regras de firewall de entrada automáticas ausentes

Você criou um recurso de entrada, mas o tráfego não chega ao serviço de back-end.

As regras de firewall de entrada automáticas, que normalmente o GKE cria quando um recurso de entrada é criado, estão ausentes ou foram excluídas inadvertidamente.

Para restaurar a conectividade com o serviço de back-end, siga estas etapas:

  • Verifique a existência das regras de firewall de entrada automáticas na rede VPC.
  • Se as regras estiverem ausentes, você poderá recriá-las manualmente ou excluir e recriar o recurso de entrada para acionar a criação automática delas.
  • Verifique se as regras de firewall permitem o tráfego nas portas e protocolos apropriados, conforme definido no recurso de entrada.

Protocolo incorreto usado no manifesto BackendConfig

Se você configurar uma CRD BackendConfig com um protocolo do tipo TCP, o seguinte erro será exibido:

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

O BackendConfig oferece suporte à criação de verificações de integridade usando apenas os protocolos HTTP, HTTPS ou HTTP/2. Para mais informações, consulte Critérios de sucesso para HTTP, HTTPS e HTTP/2.

A seguir

  • Para configurar verificações de integridade personalizadas para Entrada em um único cluster, consulte Receitas de rede do GKE.

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