Resolver problemas de verificações de integridade do Ingress

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

Entenda 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 lembradas para garantir o sucesso das verificações de integridade.

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 Trusted 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 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 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 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 atender o 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 de 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 importantes 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 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ó permite criar verificações de integridade usando os protocolos HTTP, HTTPS ou HTTP2. Para 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

Ao usar 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 para a porta específica dos pods definida 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á 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 fazer referência a 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 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 seu serviço. Se os pods não estiverem em execução e íntegros:

    • Verifique se há erros ou problemas nos registros do pod 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. Analisar captura de pacote: se o firewall estiver configurado corretamente, faça uma captura de pacote para ver 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 doTrusted Cloud by S3NS para receber mais ajuda.

  5. Solução de problemas do aplicativo: se a captura de pacote 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 de aplicativos, os arquivos de configuração e as dependências. Se não encontrar o erro, entre em contato com o suporte do Trusted Cloud by S3NS .

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 acontecer por 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 na porta ou no caminho configurado.
    • Há problemas de conectividade de rede que impedem que a verificação de integridade alcance o 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, solucione o problema de acordo com sua configuração:

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 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, talvez seja um problema de rede do GKE. Entre em contato com o suporte de Trusted Cloud 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, 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 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 dele, além de 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 estiverem marcados como não íntegros, a falha de uma sondagem de prontidão pode ser o motivo.

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 iniciar corretamente, ouvir 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 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 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 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 permite criar 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