Resolva problemas de verificações de funcionamento do Ingress

Esta página mostra-lhe como resolver problemas relacionados com as verificações de funcionamento da entrada no Google Kubernetes Engine (GKE).

Compreenda como funcionam as verificações de estado do Ingress

Antes de avançar para os passos de resolução de problemas, pode ser útil compreender como funcionam as verificações de funcionamento no GKE e que considerações deve ter em atenção para garantir verificações de funcionamento bem-sucedidas.

Quando expõe um ou mais serviços através de um Ingress com o controlador Ingress predefinido, o GKE cria um balanceador de carga de aplicações clássico ou um balanceador de carga de aplicações interno. Ambos os balanceadores de carga suportam vários serviços de back-end num ú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 tem de fazer referência a uma Google Cloud verificação de estado. Esta verificação de funcionamento é diferente de uma sondagem de atividade ou disponibilidade do Kubernetes, porque a verificação de funcionamento é implementada fora do cluster.

As verificações de funcionamento do balanceador de carga são especificadas por serviço de back-end. Embora seja possível usar a mesma verificação de estado para todos os serviços de back-end do equilibrador de carga, a referência de verificação de estado não é especificada para todo o equilibrador de carga (no próprio objeto Ingress).

O GKE cria verificações de funcionamento com base num dos seguintes métodos:

  • BackendConfig CRD: uma definição de recurso personalizado (CRD) que lhe dá controlo preciso sobre a forma como os seus serviços interagem com o balanceador de carga. BackendConfig Os CRDs permitem-lhe especificar definições personalizadas para a verificação de estado associada ao serviço de back-end correspondente. Estas definições personalizadas oferecem maior flexibilidade e controlo sobre as verificações de funcionamento para o balanceador de carga de aplicações clássico e o balanceador de carga de aplicações interno criados por um Ingress.
  • Sondagem de prontidão: uma verificação de diagnóstico que determina se um contentor num pod está pronto para publicar tráfego. O controlador de entrada do GKE cria a verificação de estado do serviço de back-end do serviço com base na sondagem de disponibilidade usada pelos pods de publicação desse serviço. Pode derivar os parâmetros de verificação de estado, como o caminho, a porta e o protocolo, da definição da sondagem de disponibilidade.
  • Valores predefinidos: os parâmetros usados quando não configura um BackendConfig CRD ou define atributos para a sondagem de prontidão.
Prática recomendada:

Use um CRD para ter o máximo controlo sobre as definições de verificação de funcionamento do balanceador de carga.BackendConfig

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

  • Se o serviço fizer referência a um BackendConfig CRD com informações healthCheck, o GKE usa-o para criar a verificação de estado. Tanto o controlador de entrada do GKE Enterprise como o controlador de entrada do GKE suportam a criação de verificações de funcionamento desta forma.

  • Se o serviço não fizer referência a um CRD BackendConfig:

    • O GKE pode inferir alguns ou todos os parâmetros para uma verificação de estado se os pods de serviço usarem um modelo de pod com um contentor cuja sonda de disponibilidade tenha atributos que possam ser interpretados como parâmetros de verificação de estado. Consulte Parâmetros de uma análise de prontidão para ver detalhes de implementação e Parâmetros predefinidos e inferidos para ver uma lista de atributos que podem ser usados para criar parâmetros de verificação de estado. Apenas o controlador GKE Ingress suporta a inferência de parâmetros a partir de uma análise de prontidão.

    • Se o modelo de pod dos pods de publicação do serviço não tiver um contentor com uma sonda de prontidão cujos atributos possam ser interpretados como parâmetros de verificação de estado, os valores predefinidos são usados para criar a verificação de estado. Tanto o controlador de entrada do GKE Enterprise como o controlador de entrada do GKE podem criar uma verificação de estado de funcionamento apenas com os valores predefinidos.

Considerações

Esta secção descreve algumas considerações a ter em conta quando configura um CRD ou usa uma sonda de prontidão.BackendConfig

BackendConfig CRD

Quando configurar CRDs BackendConfig, tenha em atenção as seguintes considerações:

  • Se estiver a usar o balanceamento de carga nativo do contentor, certifique-se de que a porta de verificação de funcionamento no manifesto BackendConfig corresponde ao containerPort de um pod de publicação.
  • Por exemplo, para grupos de back-ends, certifique-se de que a porta de verificação de estado no manifesto BackendConfig corresponde à nodePort exposta pelo serviço.
  • O Ingress não suporta gRPC para configurações de verificação de estado personalizadas. O BackendConfig só suporta a criação de verificações de funcionamento com os protocolos HTTP, HTTPS ou HTTP2. Para ver um exemplo de como usar o protocolo num CRD, consulte gke-networking-recipes.BackendConfig

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

Sonda de prontidão

Quando usa o GKE Ingress com o balanceamento de carga HTTP ou HTTPS, o GKE envia as sondas de verificação de funcionamento para determinar se a sua aplicação está a ser executada corretamente. Estas sondas de verificação do estado de funcionamento são enviadas para a porta específica nos seus pods que definiu na secção spec.containers[].readinessProbe.httpGet.port da configuração YAML do seu pod, desde que sejam cumpridas as seguintes condições:

  • O número da porta da sondagem de prontidão especificado em spec.containers[].readinessProbe.httpGet.port tem de corresponder à porta real em que a sua aplicação está a escutar no contentor, que é definida no campo containers[].spec.ports.containerPort da configuração do pod.
  • O containerPort do pod de publicação tem de corresponder ao targetPort do serviço. Isto garante que o tráfego é direcionado do serviço para a porta correta nos seus pods.
  • A especificação da porta de back-end do serviço do Ingress tem de fazer referência a uma porta válida da secção spec.ports[] da configuração do serviço. Isto pode ser feito de duas formas:
    • spec.rules[].http.paths[].backend.service.port.name nas correspondências de entrada spec.ports[].name definidas no serviço correspondente.
    • spec.rules[].http.paths[].backend.service.port.number nas correspondências de entrada spec.ports[].port definidas no serviço correspondente.

Resolva problemas comuns de verificações de funcionamento

Use o seguinte fluxograma de resolução de problemas para ajudar a identificar problemas de verificação do estado:

Resolução de problemas de verificações de funcionamento do Ingress.
Figura: resolva problemas de verificações de saúde

Neste fluxograma, as seguintes orientações de resolução de problemas ajudam a determinar onde se encontra o problema:

  1. Investigue o estado do pod: se a verificação de estado estiver a falhar, examine o estado dos pods de serviço do seu serviço. Se os pods não estiverem em execução e estiverem em bom estado:

    • Verifique se existem erros ou problemas nos registos do pod que impeçam a sua execução.
    • Verifique o estado das sondas de prontidão e de atividade.

  2. Registo de verificações de funcionamento: certifique-se de que ativou o registo de verificações de funcionamento.

  3. Valide a configuração da firewall: certifique-se de que as regras da firewall permitem que as sondas de verificação de estado alcancem os seus pods. Se não resolver:

    • Verifique as regras de firewall para confirmar que permitem o tráfego de entrada dos intervalos de endereços IP da sonda de verificação de estado.
    • Ajuste as regras de firewall conforme necessário para acomodar estes intervalos de endereços IP.

  4. Analise a captura de pacotes: se a firewall estiver configurada corretamente, faça uma captura de pacotes para ver se a sua aplicação está a responder às verificações de estado. Se a captura de pacotes mostrar uma resposta bem-sucedida, contacte o Google Cloud apoio técnico para receber assistência adicional.

  5. Resolva problemas da aplicação: se a captura de pacotes não mostrar uma resposta bem-sucedida, investigue por que motivo a sua aplicação não está a responder corretamente aos pedidos de verificação de estado. Verifique se a verificação de estado está a segmentar o caminho e a porta corretos nos pods e examine os registos da aplicação, os ficheiros de configuração e as dependências. Se não conseguir encontrar o erro, contacte o Google Cloud apoio técnico.

A aplicação não responde às verificações de funcionamento

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

Se a sua aplicação não responder corretamente às verificações de estado, tal pode dever-se a um dos seguintes motivos:

  • Grupos de pontos finais da rede(NEGs):
    • A aplicação não está a ser executada corretamente no Pod.
    • A aplicação não está a ouvir na porta ou no caminho configurado.
    • Existem problemas de conetividade de rede que impedem a verificação de estado de alcançar o pod.
  • Grupo de instâncias:
    • Os nós no grupo de instâncias não estão em bom estado.
    • A aplicação não está a ser executada corretamente nos nós.
    • Os pedidos de verificação do estado não estão a chegar aos nós.

Se as verificações de funcionamento estiverem a falhar, com base na sua configuração, resolva o problema da seguinte forma:

Para NEGs:

  1. Aceda a um Pod através do kubectl exec:

    kubectl exec -it pod-name -- command

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

    Substitua o seguinte:

    • pod-name: o nome do seu Pod.
    • command: o comando que quer executar no Pod. O comando mais comum é bash ou sh para obter uma shell interativa.

  2. Execute comandos curl para testar a conetividade e a capacidade de resposta da aplicação:

    • 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. Certifique-se de que os nós estão em bom estado e a responder às sondas de verificação de funcionamento predefinidas.
  2. Se os nós estiverem em bom estado, mas o pod da aplicação não estiver a responder, investigue a aplicação mais detalhadamente.
  3. Se os pedidos não estiverem a chegar aos pods, pode ser um problema de rede do GKE. Contacte o apoio técnico do Google Cloud para receber assistência.

Erro ao editar a sondagem de disponibilidade no pod

Quando tenta editar a sondagem de disponibilidade num Pod para alterar os parâmetros de verificação de funcionamento, ocorre um erro semelhante ao seguinte:

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

Se modificar a sondagem de prontidão dos pods associados a um serviço que já esteja associado a um Ingress (e ao respetivo equilibrador de carga), o GKE não atualiza automaticamente a configuração da verificação de estado no equilibrador de carga. Isto leva a uma incompatibilidade entre a verificação de disponibilidade do pod e a verificação de funcionamento do balanceador de carga, o que faz com que a verificação de funcionamento falhe.

Para resolver este problema, volte a implementar os pods e o recurso Ingress. Isto força o GKE a recriar o equilibrador de carga e as respetivas verificações de funcionamento, e a incorporar as novas definições da sonda de disponibilidade.

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

Se a implementação não for iniciada e os serviços de back-end por detrás do balanceador de carga do controlador de entrada estiverem marcados como não íntegros, a falha de uma sondagem de disponibilidade pode ser o motivo.

Pode ver a seguinte mensagem de erro que menciona uma falha da sondagem de prontidão:

Readiness probe failed: connection refused

A aplicação no pod não responde corretamente à análise de prontidão configurada na configuração YAML do pod. Isto pode dever-se a vários motivos, como a aplicação não iniciar corretamente, estar a ouvir na porta errada ou encontrar um erro durante a inicialização.

Para resolver este problema, investigue e corrija quaisquer discrepâncias na configuração ou no comportamento da sua aplicação fazendo o seguinte:

  • Certifique-se de que a aplicação está configurada corretamente e a responder no caminho e na porta especificados nos parâmetros da sondagem de disponibilidade.
  • Reveja os registos da aplicação e resolva problemas ou erros de arranque.
  • Verifique se o containerPort na configuração do Pod corresponde ao targetPort no serviço e à porta de back-end especificada no Ingress.

Regras de firewall de entrada automáticas em falta

Criou um recurso Ingress, mas o tráfego não chega ao serviço de back-end.

As regras da firewall de entrada automáticas, que normalmente o GKE cria quando é criado um recurso de entrada, estão em falta ou foram eliminadas inadvertidamente.

Para restaurar a conetividade ao serviço de back-end, siga estes passos:

  • Verifique a existência das regras da firewall de entrada automáticas na sua rede de VPC.
  • Se as regras estiverem em falta, pode recriá-las manualmente ou eliminar e recriar o recurso Ingress para acionar a respetiva criação automática.
  • Certifique-se de que as regras de firewall permitem o tráfego nas portas e nos protocolos adequados, conforme definido no seu recurso de entrada.

Foi usado um protocolo incorreto no manifesto BackendConfig

Se configurar um BackendConfig CRD com um protocolo do tipo TCP, é apresentado 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 suporta a criação de verificações de funcionamento apenas com os protocolos HTTP, HTTPS ou HTTP/2. Para mais informações, consulte os critérios de êxito para HTTP, HTTPS e HTTP/2.

O que se segue?