Resolver problemas no servidor da API Kubernetes

Nesta página, mostramos como resolver problemas com o servidor da API Kubernetes (kube-apiserver) para o Google Distributed Cloud.

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

Tempos limite e chamadas com falha do webhook

Esses erros podem ser analisados de algumas maneiras diferentes. Se algum dos sintomas a seguir ocorrer, é possível que as chamadas do webhook estejam falhando:

  • Conexão recusada: se kube-apiserver relatar erros de tempo limite para chamar o webhook, o seguinte erro será informado nos registros:

    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
    
  • Prazo do contexto excedido: o erro a seguir também pode ser mostrado nos registros:

    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 você achar que está enfrentando tempos limite do webhook ou chamadas de webhook com falha, use um dos métodos a seguir para confirmar o problema:

  • Verifique se há um problema na rede no registro do servidor de API.

    • Verifique se há erros relacionados à rede no registro, como TLS handshake error.
    • Verifique se o IP/porta corresponde ao que o servidor da API está configurado para responder.
  • Monitore a latência do webhook de acordo com as seguintes etapas:

    1. No console, acesse a página do Cloud Monitoring.

      Acessar a página do Cloud Monitoring

    2. Selecione Metrics Explorer.

    3. Selecione a métrica apiserver_admission_webhook_admission_duration_seconds.

Para resolver esse problema, analise o seguinte:

  • O webhook pode exigir regras de firewall adicionais. Para mais informações, confira como adicionar regras de firewall em casos de uso específicos.

  • Se o webhook precisar de mais tempo para ser concluído, configure um valor personalizado de tempo limite. A latência dos webhooks aumenta a latência da solicitação da API, por isso é necessário avaliar o mais rápido possível.

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

Falha de discagem ou latência do servidor de API

Esse erro pode ser observado de algumas maneiras diferentes:

  • Erros de resolução de nome externo: um cliente externo pode retornar erros com lookup na mensagem, como:

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

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

  • Erros de rede: o cliente pode imprimir um erro de rede genérico ao tentar discar o servidor da API, como nos exemplos a seguir:

    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
    
  • Conexão de alta latência com o servidor da API: a conexão com o servidor da API pode ser bem-sucedida, mas o tempo limite das solicitações pode ser atingido no lado do cliente. Nesse cenário, o cliente geralmente imprime mensagens de erro que contêm context deadline exceeded.

Se a conexão com o servidor da API falhar completamente, tente realizar a conexão no mesmo ambiente em que o cliente informa o erro. Os contêineres temporários do Kubernetes podem ser usados para injetar um contêiner de depuração nos namespaces atuais da seguinte maneira:

  1. No local em que o cliente com problemas é executado, use kubectl para realizar uma solicitação com alto nível de detalhes. Por exemplo, uma solicitação GET para /healthz geralmente não requer autenticação:

    kubectl get -v999 --raw /healthz
    
  2. Se a solicitação falhar ou kubectl não estiver disponível, será possível extrair o URL da saída e executar manualmente a solicitação com curl. Por exemplo, se o host de serviço recebido da saída anterior for https://192.0.2.1:36917/, será possível enviar uma solicitação semelhante da seguinte maneira:

    # 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
    

    A saída desse comando geralmente indica a causa raiz de uma falha de conexão.

    Se a conexão for bem-sucedida, mas estiver lenta ou expirar, isso indica um servidor de API sobrecarregado. Para confirmar, no console, confira API Server Request Rate e solicite métricas de latência em Cloud Kubernetes > Anthos > Cluster > K8s Control Plane.

Para resolver essas falhas de conexão ou problemas de latência, analise as seguintes opções de correção:

  • Se ocorrer um erro de rede dentro do cluster, talvez haja um problema com o plug-in da interface de rede do contêiner (CNI, na sigla em inglês). Esse problema geralmente é temporário e se resolve por conta própria após uma recriação ou reagendamento do pod.

  • Se o erro de rede for de fora do cluster, verifique se o cliente está configurado corretamente para acessar o cluster ou gere a configuração de cliente de novo. Se a conexão passar por um proxy ou gateway, verifique se outra conexão que passa pelo mesmo mecanismo funciona.

  • Se o servidor da API estiver sobrecarregado, geralmente significa que muitos clientes acessam o servidor da API ao mesmo tempo. Um único cliente não pode sobrecarregar um servidor da API devido à limitação e ao recurso Prioridade e imparcialidade. Analise a carga de trabalho das seguintes áreas:

    • Funciona no nível do pod. É mais comum criar e esquecer pods por engano do que recursos de nível mais alto.
    • Ajustar o número de réplicas com cálculos incorretos.
    • Um webhook que retorna a solicitação para si ou amplifica a carga ao criar mais solicitações do que processa.

A seguir

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