Resolver problemas de verificações de integridade do Ingress

Nesta página, mostramos como resolver problemas relacionados às verificações de integridade do Entrada no Google Kubernetes Engine (GKE).

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

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

Antes de seguir para as etapas de solução de problemas, é útil entender como as verificações de integridade funcionam no GKE e quais considerações precisam ser consideradas para garantir a realização delas.

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 fazer referência a uma verificação de integridade do Google Cloud . 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 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 de entrada 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 da sondagem de prontidão.
  • Valores padrão: os parâmetros usados quando você não configura um 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 a serem consideradas ao configurar um 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 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ó permite a criação de verificações de integridade usando os protocolos HTTP, HTTPS ou HTTP2. Para conferir um exemplo de como usar o protocolo em um CRD BackendConfig, consulte gke-networking-recipes.

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

Sondagem de prontidão

Quando você usa o GKE Ingress 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 para a porta específica nos pods que você definiu na seção spec.containers[].readinessProbe.httpGet.port da configuração do 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á 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[] da configuração do serviço. Isso pode ser feito de duas maneiras:
    • spec.rules[].http.paths[].backend.service.port.name no Entrada corresponde a spec.ports[].name definida no serviço correspondente.
    • spec.rules[].http.paths[].backend.service.port.number no 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 abaixo 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. 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 se há erros ou problemas nos registros do pod que impeçam a execução.
    • Verifique o status das sondagens de prontidão e de atividade.

  2. Registro de verificação de integridade: verifique se você ativou o registro 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 alcancem seus pods. Se não:

    • Verifique se as regras do 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. Analisar a captura de pacotes: se o firewall estiver configurado corretamente, faça uma captura de pacotes para saber se o aplicativo está respondendo às verificações de integridade. Se a captura de pacote mostrar uma resposta bem-sucedida, entre em contato com o suporte doGoogle Cloud para receber mais ajuda.

  5. Resolver 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, os arquivos de configuração e as dependências do aplicativo. Se você não encontrar o erro, entre em contato com o suporte do Google Cloud .

O aplicativo 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, isso pode ser devido a um dos seguintes motivos:

  • Grupos de endpoints de rede(NEGs):
    • O aplicativo não está sendo executado corretamente no pod.
    • O aplicativo não está detectando a porta ou o caminho configurado.
    • Há problemas de conectividade de rede que impedem que o 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 falharem, com base na sua configuração, solucione o problema da seguinte forma:

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 saudáveis e respondendo às sondagens de verificação de integridade padrão.
  2. Se os nós estiverem saudáveis, mas o pod do aplicativo não estiver respondendo, investigue o aplicativo.
  3. Se as solicitações não estiverem chegando aos pods, talvez seja um problema de rede do GKE. Entre em contato com o suporte do Google Cloud 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 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 da 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 ela 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 da 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, a causa pode ser uma falha na sondagem de prontidão.

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

Para resolver isso, investigue e corrija todas 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.
  • Analise os registros do aplicativo 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 no Entrada.

Regras de firewall de entrada automáticas ausentes

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

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

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

  • Verifique se há regras de firewall de entrada automáticas na sua rede VPC.
  • Se as regras estiverem ausentes, você poderá recriar elas manualmente ou excluir e recriar o recurso Entrada para acionar a criação automática.
  • Verifique se as regras de firewall permitem o tráfego nas portas e nos protocolos adequados, conforme definido no recurso de entrada.

Protocolo incorreto usado no manifesto BackendConfig

Se você configurar um 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 permite a 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.