Resolva problemas do servidor da API Kubernetes

Esta página mostra-lhe como resolver problemas com o servidor da API Kubernetes (kube-apiserver) para o Google Distributed Cloud.

Esta página destina-se a administradores de TI e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente e respondem a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são cumpridos ou as aplicações falham. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulteFunções e tarefas comuns do utilizador do GKE.

Tempos limite de webhook e chamadas de webhook com falhas

Estes erros podem ser vistos de várias formas diferentes. Se tiver algum dos seguintes sintomas, é possível que as chamadas de webhook estejam a falhar:

  • Ligação recusada: se o kube-apiserver comunicar erros de limite de tempo excedido para chamar o webhook, o seguinte erro é comunicado nos registos:

    failed calling webhook "server.system.private.gdc.goog":
failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s":
dial tcp 10.202.1.18:443: connect: connection refused

  • Context deadline exceeded: também pode ver o seguinte erro comunicado nos registos:

    failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post
"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\":
context deadline exceeded"

Se considerar que está a ter tempos limite de webhook ou chamadas de webhook falhadas, use um dos seguintes métodos para confirmar o problema:

  • Verifique o registo do servidor da API para ver se existe um problema de rede.

    • Verifique se existem erros relacionados com a rede, como TLS handshake error, no registo.
    • Verifique se o IP/porta corresponde ao que o servidor da API está configurado para responder.

  • Monitorize a latência do webhook com os seguintes passos:

    1. Na consola, aceda à página Cloud Monitoring.

      Aceda à página do Cloud Monitoring

    2. Selecione Explorador de métricas.

    3. Selecione a métrica apiserver_admission_webhook_admission_duration_seconds.

Para resolver este problema, reveja as seguintes sugestões:

  • Podem ser necessárias regras de firewall adicionais para o webhook. Para mais informações, veja como adicionar regras de firewall para exemplos de utilização específicos.

  • Se o webhook precisar de mais tempo para ser concluído, pode configurar um valor de tempo limite personalizado. A latência dos webhooks é adicionada à latência dos pedidos de API, pelo que deve ser avaliada o mais rapidamente possível.

  • Se o erro do webhook bloquear a disponibilidade do cluster ou o webhook for inofensivo para remover e mitigar a situação, verifique se é possível definir temporariamente o failurePolicy como Ignore ou remover o webhook ofensivo.

Latência ou falha de ligação do servidor da API

Este erro pode ser apresentado de várias formas:

  • Erros de resolução de nomes externos: um cliente externo pode devolver erros que contenham lookup na mensagem, como:

    dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host

    Este erro não se aplica a um cliente em execução no cluster. O IP do serviço Kubernetes é injetado, pelo que não é necessária nenhuma resolução.

  • Erros de rede: o cliente pode imprimir um erro de rede genérico ao tentar estabelecer ligação ao servidor da API, como nos seguintes exemplos:

    dial tcp 10.96.0.1:443: connect: no route to host
dial tcp 10.96.0.1:443: connect: connection refused
dial tcp 10.96.0.1:443: connect: i/o timeout

  • Latência elevada ao estabelecer ligação ao servidor da API: a ligação ao servidor da API pode ser bem-sucedida, mas os pedidos expiram no lado do cliente. Neste cenário, o cliente imprime normalmente mensagens de erro que contêm context deadline exceeded.

Se a ligação ao servidor da API falhar completamente, experimente a ligação no mesmo ambiente em que o cliente comunica o erro. Os contentores efémeros do Kubernetes podem ser usados para injetar um contentor de depuração nos espaços de nomes existentes da seguinte forma:

  1. A partir do local onde o cliente problemático é executado, use kubectl para fazer um pedido com verbosidade elevada. Por exemplo, um pedido GET para /healthz normalmente não requer autenticação:

    kubectl get -v999 --raw /healthz

  2. Se o pedido falhar ou kubectl estiver indisponível, pode obter o URL a partir do resultado e executar manualmente o pedido com curl. Por exemplo, se o anfitrião do serviço obtido a partir do resultado anterior for https://192.0.2.1:36917/, pode enviar um pedido semelhante da seguinte forma:

    # Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing
# a local cluster and you trust the connection cannot be tampered.
# The output is always "ok" and thus contains no sensentive information.

curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz

    Normalmente, o resultado deste comando indica a causa principal de uma ligação falhada.

    Se a ligação for bem-sucedida, mas for lenta ou expirar o respetivo tempo limite, indica que o servidor da API está sobrecarregado. Para confirmar, na consola, consulte as métricas de API Server Request Rate e de latência de pedidos em Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.

Para resolver estas falhas de ligação ou problemas de latência, reveja as seguintes opções de correção:

  • Se ocorrer um erro de rede no cluster, pode haver um problema com o plugin da interface de rede de contentores (CNI). Normalmente, este problema é transitório e resolve-se sozinho após uma recriação ou um reagendamento do pod.

  • Se o erro de rede for externo ao cluster, verifique se o cliente está configurado corretamente para aceder ao cluster ou gere novamente a configuração do cliente. Se a ligação passar por um proxy ou um gateway, verifique se outra ligação que passe pelo mesmo mecanismo funciona.

  • Se o servidor da API estiver sobrecarregado, significa normalmente que muitos clientes acedem ao servidor da API ao mesmo tempo. Um único cliente não pode sobrecarregar um servidor de API devido à limitação e à funcionalidade Prioridade e equidade. Reveja a carga de trabalho para as seguintes áreas:

    • Funciona ao nível do pod. É mais comum criar e esquecer-se de Pods por engano do que de recursos de nível superior.
    • Ajustar o número de réplicas através de um cálculo incorreto.
    • Um webhook que devolve o pedido a si próprio ou amplifica a carga criando mais pedidos do que processa.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte: