Container Service for Kubernetes:Diagnóstico de Ingress

Item de diagnóstico

O que é verificado

Como corrigir

Verificação de Ingress

Se o Ingress especificado existe.

Verifique se existe uma regra de Ingress para a url. Confira se o caminho utiliza expressão regular e se a anotação use-regex está definida corretamente.

Verificação de base-url-scheme

Presença da anotação obsoleta nginx.ingress.kubernetes.io/base-url-scheme. Essa anotação foi descontinuada no Ingress Controller 0.22.0.

Consulte a versão do seu controlador de Ingress. Remova a anotação ou substitua-a por uma alternativa suportada.

Verificação de grpc-backend

Existência da anotação obsoleta nginx.ingress.kubernetes.io/grpc-backend. Descontinuada no Ingress Controller 0.21.0.

Valide a versão do controlador de Ingress. Exclua a anotação ou adote uma alternativa compatível.

Verificação de mirror-uri

Uso da anotação obsoleta nginx.ingress.kubernetes.io/mirror-uri. Descontinuada no Ingress Controller 0.24.0.

Analise a versão do controlador de Ingress. Elimine a anotação ou troque por uma opção suportada.

Verificação de secure-backends

Detecção da anotação obsoleta nginx.ingress.kubernetes.io/secure-backends. Descontinuada no Ingress Controller 0.21.0.

Cheque a versão do controlador de Ingress. Remova a anotação ou utilize uma alternativa válida.

Verificação de session-cookie-hash

Identificação da anotação obsoleta nginx.ingress.kubernetes.io/session-cookie-hash. Descontinuada no Ingress Controller 0.24.0.

Revise a versão do controlador de Ingress. Exclua a anotação ou substitua por uma alternativa suportada.

Verificação de nginx.com/nginx.org

Se o Ingress usa anotações iniciadas com nginx.com ou nginx.org. Essas anotações destinam-se ao controlador NGINX Ingress comercial e a versão open source não as reconhece.

Migre para anotações suportadas pelo controlador NGINX Ingress open source. Consulte Gerenciamento de NGINX Ingress ou a Documentação do NGINX Ingress Controller.

Status canary

Se a anotação nginx.ingress.kubernetes.io/canary: "true" está definida. Sem essa anotação, as regras de roteamento canary não têm efeito.

Adicione a anotação ao Ingress: nginx.ingress.kubernetes.io/canary: "true".

Item de diagnóstico

O que é verificado

Como corrigir

Percentual de prontidão dos pods de Ingress

A proporção de pods de Ingress no estado Ready em relação às réplicas definidas no Deployment. Um valor abaixo de 100% indica falha na inicialização ou no health check de alguns pods.

Analise os logs de erro dos pods para identificar as falhas e corrija a causa raiz. Consulte Solução de problemas do controlador NGINX Ingress.

Verificação de endereço IP do Ingress

Se o controlador de Ingress atribuiu um endereço IP ao Ingress.

Caso nenhum endereço IP tenha sido atribuído, confirme se a IngressClass correta está referenciada e se o controlador de Ingress opera normalmente.

Verificação de pod líder

Se um pod líder foi eleito. A ausência de um pod líder impede o processamento das regras de Ingress pelo controlador. Isso pode ocorrer se o tempo de inicialização do pod for muito curto ou se as permissões do controlador estiverem mal configuradas.

Examine os logs de erro dos pods de Ingress e corrija quaisquer falhas apresentadas. Veja Solução de problemas do controlador NGINX Ingress.

Anotações do NGINX Ingress

Uso de anotações iniciadas com nginx.com ou nginx.org. O controlador NGINX Ingress open source reconhece apenas anotações nginx.ingress.kubernetes.io. Anotações desconhecidas são ignoradas silenciosamente, o que pode impedir que configurações tenham efeito.

Substitua as anotações nginx.com/nginx.org pelas equivalentes nginx.ingress.kubernetes.io. Consulte a Referência de anotações.

Grupos de captura e rewrite-target

Utilização de rewrite-target com grupos de captura. A partir do Ingress Controller 0.22.0, é obrigatório definir explicitamente os grupos de captura ao usar rewrite-target; a omissão gera erros no encaminhamento de tráfego.

Atualize o Ingress para incluir grupos de captura com rewrite-target. Veja Configurações avançadas de NGINX Ingress. Exemplo: defina nginx.ingress.kubernetes.io/rewrite-target: /$1 com um caminho como /api/(.*).

Contagem de Services canary

Se service-match ou service-weight especifica mais de dois Services. Essas anotações suportam divisão de tráfego entre exatamente dois Services. Services adicionais são ignorados silenciosamente.

Reduza para dois o número de Services em service-match ou service-weight. Consulte Releases canary e implantações blue-green com NGINX Ingress.

Nome do Ingress

Os nomes das regras de Ingress correspondentes.

Apenas informativo. Nenhuma ação necessária.

Logs de erro de pods

Geração de logs de erro pelos pods do controlador de Ingress. Logs de erro indicam possível falha no processamento correto das regras pelo controlador.

Identifique a causa do erro nos logs e aplique a correção. Veja Solução de problemas do controlador NGINX Ingress.

Grupos de captura de caminho em rewrite-target

Se os caminhos que utilizam nginx.ingress.kubernetes.io/rewrite-target definem os grupos de captura obrigatórios. No Ingress Controller 0.22.0 e posteriores, a falta de grupos de captura causa erros de roteamento de caminho.

Inclua grupos de captura nos caminhos afetados. Consulte Configurar regras de roteamento para redirecionar tráfego de URLs específicas.

Múltiplos alvos em service-*

Especificação de mais de dois Services em service-match ou service-weight.

Configure exatamente dois Services em service-weight ou service-match. Veja Releases canary e implantações blue-green com NGINX Ingress.

Verificação de Service do Ingress

Existência do Service referenciado nos parâmetros de inicialização do controlador de Ingress. A ausência do Service impede a inicialização do controlador.

Localize o nome do Service excluído nos parâmetros de inicialização do Deployment e restaure-o. Consulte Operações de alto risco relacionadas a redes e instâncias slb.

Verificação de endpoint do Service de Ingress

Se o Service associado ao Ingress possui pelo menos um endpoint. Sem endpoints, a instância slb não consegue rotear tráfego para o controlador de Ingress.

Confirme se o seletor de rótulos do Service corresponde aos rótulos dos pods do controlador de Ingress.

Eventos do Service de Ingress

Presença de eventos Warning ou Error no Service associado ao Ingress. Tais eventos geralmente indicam erros de configuração do slb.

Analise os eventos do Service para determinar a causa raiz e corrija o problema. Veja Erros e soluções de Service.

Política de tráfego externo do Service de Ingress

A política de tráfego externo do Service de Ingress. O padrão é Local. No modo Cluster, os endereços IP dos clientes não são preservados, o que pode tornar imprecisos os resultados de health check.

Mantenha a política como Local, a menos que sua carga de trabalho exija o modo Cluster ou você precise acessar o controlador de Ingress de dentro do cluster via endereço IP do slb.

Endereço IP externo do Service de Ingress

Se o cloud controller manager atribuiu um endereço IP externo ao Service de Ingress. Sem um endereço IP, o Ingress fica inacessível pela internet.

Verifique o status do Service, o status do cloud controller manager e as cotas de slb. A maioria dos problemas aparece como eventos do Service.

Tipo de Service de Ingress

Se o Service referenciado nos parâmetros de inicialização do controlador de Ingress é do tipo LoadBalancer. Um tipo de Service diferente de LoadBalancer torna o controlador de Ingress inacessível pela internet.

Altere o tipo de Service para LoadBalancer se for necessário acesso externo. Esta verificação não se aplica caso sua configuração utilize intencionalmente outro tipo de Service.

Verificação de --force-namespace-isolation

Uso do parâmetro de inicialização obsoleto --force-namespace-isolation. Este parâmetro foi descontinuado no Ingress Controller 0.24.0.

Valide a versão do controlador de Ingress e remova o parâmetro de inicialização do Deployment.

Verificação de --sort-backends

Utilização do parâmetro de inicialização obsoleto --sort-backends. Descontinuado no Ingress Controller 0.22.0.

Consulte a versão do controlador de Ingress e elimine o parâmetro de inicialização do Deployment.

Item de diagnóstico

O que é verificado

Como corrigir

Instância slb

Existência da instância slb utilizada pelo controlador de Ingress.

Verifique se há eventos de anomalia no Service do controlador de Ingress e se a instância slb aparece no console slb. Se a instância foi excluída acidentalmente, recrie o Service. Consulte O que fazer se eu excluir acidentalmente uma instância slb?

Integridade dos servidores backend do slb

Se todos os servidores backend da instância slb estão íntegros.

Caso haja servidores backend não íntegros, verifique eventos de anomalia no Service do controlador de Ingress e confirme se os pods do controlador não estão sobrecarregados. Veja Solução de problemas do controlador NGINX Ingress.

ID do slb

O ID da instância slb.

Apenas informativo. Nenhuma ação necessária.

Contagem de conexões do slb

Se o número de conexões ativas na instância slb ultrapassou 80% do limite nos últimos três dias. Atingir o limite bloqueia novas conexões de clientes.

Faça upgrade da instância slb para uma especificação superior. Consulte Usar uma instância slb existente.

Taxa de novas conexões do slb

Se a taxa de novas conexões na instância slb excedeu 80% do limite nos últimos três dias. Atingir esse limite impede temporariamente que clientes estabeleçam novas conexões.

Realize upgrade da instância slb para uma especificação maior. Veja Usar uma instância slb existente.

QPS do slb

Se as consultas por segundo (QPS) na instância slb superaram 80% do limite nos últimos três dias. Atingir o limite de QPS bloqueia conexões de clientes.

Promova upgrade da instância slb para uma especificação mais alta. Consulte Usar uma instância slb existente.

Host tls e SecretName

Se os campos host e secretName estão definidos na configuração tls. Ambos são obrigatórios; omitir qualquer um deles interrompe a terminação tls.

Defina tanto host quanto secretName na seção tls do Ingress e garanta que o host seja idêntico ao do certificado.

Status de health check do slb

Ocorrência de falhas de health check na instância slb nos últimos três dias. Falhas indicam possível sobrecarga dos pods do controlador ou erros na configuração do slb.

Verifique eventos de anomalia no Service do controlador de Ingress e confirme que os pods não estão sobrecarregados. Consulte Solução de problemas do controlador NGINX Ingress.