Nesta página, mostramos como resolver problemas com o servidor da API Kubernetes
(kube-apiserver) para o Google Distributed Cloud.
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-apiserverrelatar 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 refusedPrazo 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.
- Verifique se há erros relacionados à rede no registro, como
Monitore a latência do webhook de acordo com as seguintes etapas:
No console, acesse a página do Cloud Monitoring.
Selecione Metrics Explorer.
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
failurePolicycomoIgnoreou 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
lookupna mensagem, como:dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such hostEsse 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 timeoutConexã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 existentes da seguinte maneira:
No local em que o cliente com problemas é executado, use
kubectlpara realizar uma solicitação com alto nível de detalhes. Por exemplo, uma solicitaçãoGETpara/healthzgeralmente não requer autenticação:kubectl get -v999 --raw /healthzSe a solicitação falhar ou
kubectlnão estiver disponível, será possível extrair o URL da saída e executar manualmente a solicitação comcurl. Por exemplo, se o host de serviço recebido da saída anterior forhttps://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/healthzA 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 Ratee solicite métricas de latência emCloud 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 de API devido à limitação e ao recurso de 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.