Solucionar problemas de verificações de integridade do Ingress

Falhas nas verificações de integridade do Ingress no Google Kubernetes Engine (GKE) podem impedir que o tráfego chegue ao seu 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 sondagens de prontidão e diagnosticar problemas como aplicativos que não respondem 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 de entrada e precisam garantir que os aplicativos estejam sendo informados corretamente como íntegros para o balanceador de carga. Para mais informações sobre as funções comuns e as tarefas de exemplo que mencionamos no conteúdo do Cloud de Confiance by S3NS , consulte Funções e tarefas comuns do usuário do GKE.

Entenda como as verificações de integridade de 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 manter em mente para garantir verificações de integridade bem-sucedidas.

Quando você expõe um ou mais serviços por meio de um Ingress usando o controlador padrão do Ingress, 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 referenciar uma verificação de integridade doCloud de Confiance . 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 Ingress).

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 seus serviços interagem com o balanceador de carga. Os 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 mais 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 criados 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 de 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 CRD BackendConfig ou define atributos para a sondagem de prontidão.
Prática recomendada:

Use um 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 importantes ao configurar uma CRD BackendConfig ou usar uma sondagem de prontidão.

CRD BackendConfig

Ao configurar CRDs BackendConfig, considere o seguinte:

  • Se você estiver usando o balanceamento de carga nativo do 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 grupo de instâncias, verifique se a porta de verificação de integridade no manifesto BackendConfig corresponde à nodePort exposta pelo serviço.
  • A Entrada não é compatível com gRPC para configurações de verificação de integridade personalizadas. O BackendConfig só permite criar verificações de integridade usando os protocolos HTTP, HTTPS ou HTTP2. Para ver um exemplo de como usar o protocolo em uma CRD BackendConfig, consulte gke-networking-recipes.

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

Sondagem de prontidão

Quando você usa a Entrada do GKE com balanceamento de carga HTTP ou HTTPS, o GKE envia as sondagens de verificação de integridade para determinar se o aplicativo está sendo executado corretamente. Essas sondagens de verificação de integridade são enviadas à porta específica dos pods que você definiu 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 que seu aplicativo está detectando no contêiner, que é definida 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 de Ingress precisa referenciar 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 na Entrada corresponde a spec.ports[].name definida no serviço correspondente.
    • spec.rules[].http.paths[].backend.service.port.number na Entrada corresponde a spec.ports[].port definida no serviço correspondente.

Resolver problemas comuns de verificação de integridade

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

Solução de problemas de verificações de integridade do Ingress.
Figura: resolver 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. Investigue a integridade do pod: se a verificação de integridade estiver falhando, examine o status dos pods de exibição do serviço. Se os pods não estiverem em execução e em bom estado:

    • Verifique os registros do pod para conferir se há erros ou problemas que impedem a execução.
    • 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. Verifique a configuração do firewall: confira se as regras de firewall permitem que as sondagens de verificação de integridade alcancem seus pods. Se não:

    • Verifique se as regras de firewall 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. Analise a captura de pacotes: se o firewall estiver configurado corretamente, faça 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 suporte doCloud de Confiance by S3NS 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á direcionando para o caminho e a porta corretos nos pods e examine os registros do aplicativo, os arquivos de configuração e as dependências. Se você não encontrar o erro, entre em contato com o suporte do Cloud de Confiance by S3NS .

Aplicativo que não responde à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, o motivo pode ser um dos seguintes:

  • Grupos de endpoints de rede(NEGs):
    • O aplicativo não está sendo executado corretamente no pod.
    • O aplicativo não está detectando 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á sendo executado 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 estiverem falhando, com base na sua configuração, resolva 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 de interativo, t de TTY).

    Substitua:

    • pod-name: o nome do pod.
    • command: o comando que você quer executar dentro do pod. O comando mais comum é bash ou sh para abrir 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 mais a fundo.
  3. Se as solicitações não estiverem chegando aos pods, pode ser um problema de rede do GKE. Entre em contato com o suporte de Cloud de Confiance by S3NS 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, isso resulta em um erro semelhante a este:

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 vai 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 isso, reimplante 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.

Falha ao iniciar a implantação e o balanceador de carga

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, o motivo pode ser uma falha na sondagem de prontidão.

Talvez você veja a seguinte mensagem de erro mencionando uma falha na verificação 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 acontecer por vários motivos, como o aplicativo não iniciar corretamente, fazer detecções na porta errada ou encontrar um erro durante a inicialização.

Para resolver isso, 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 da sondagem de prontidão.
  • Revise os registros de aplicativos e resolva 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 na 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 geralmente o GKE cria quando um recurso de entrada é criado, estão faltando ou foram excluídas por engano.

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 sua rede VPC.
  • Se as regras estiverem faltando, recrie-as manualmente ou exclua e recrie 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 adequados, conforme definido no recurso Entrada.

Protocolo incorreto usado no manifesto BackendConfig

Se você configurar um CRD BackendConfig com um protocolo do tipo TCP, vai aparecer o seguinte erro:

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 só permite criar verificações de integridade usando 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 seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: