Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, mostramos como resolver problemas com o servidor da API Kubernetes
(kube-apiserver) para o Google Distributed Cloud.
Esta página é destinada a administradores de TI e operadores que gerenciam o
ciclo de vida da infraestrutura tecnológica e respondem a alertas e páginas
quando os objetivos de nível de serviço (SLO) não são atendidos ou os aplicativos falham. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte
Tarefas e funções de usuário comuns do GKE Enterprise.
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:
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:
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:
kubectlget-v999--raw/healthz
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.pemhttps://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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-12-17 UTC."],[],[],null,["This page shows you how to resolve issues with the Kubernetes API server\n(`kube-apiserver`) for Google Distributed Cloud.\n\nThis page is for IT administrators and Operators who manage the\nlifecycle of the underlying tech infrastructure, and respond to alerts and pages\nwhen service level objectives (SLOs) aren't met or applications fail. To learn\nmore about common roles and example tasks that we reference in Google Cloud\ncontent, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nWebhook timeouts and failed webhook calls\n\nThese errors might be seen in a few different ways. If you experience any of the\nfollowing symptoms, it's possible that webhook calls are failing:\n\n- **Connection refused:** If `kube-apiserver` reports timeout errors for\n calling the webhook, the following error is reported in the logs:\n\n failed calling webhook \"server.system.private.gdc.goog\":\n failed to call webhook: Post \"https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s\":\n dial tcp 10.202.1.18:443: connect: connection refused\n\n- **Context deadline exceeded:** You might also see the following error reported\n in the logs:\n\n failed calling webhook \"namespaces.hnc.x-k8s.io\": failed to call webhook: Post\n \"https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\\\":\n context deadline exceeded\"\n\nIf you think that you are experiencing webhook timeouts or failed webhook calls,\nuse one of the following methods to confirm the issue:\n\n- Check the API server log to see if there is network issue.\n\n - Check the log for network-related errors like `TLS handshake error`.\n - Check if the IP/Port matches what the API server is configured to respond on.\n- Monitor webhook latency with the following steps:\n\n 1. In the console, go to the Cloud Monitoring page.\n\n [Go to the Cloud Monitoring page](https://console.cloud.google.com/monitoring/)\n 2. Select **Metrics explorer**.\n\n 3. Select the `apiserver_admission_webhook_admission_duration_seconds` metric.\n\nTo resolve this issue, review the following suggestions:\n\n- Additional firewall rules might be required for the webhook. For more\n information, see how to\n [add firewall rules for specific use cases](/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules).\n\n- If the webhook requires more time to complete, you can\n [configure a custom timeout value](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#timeouts).\n The webhooks latency adds to API request latency, so should be evaluated as\n quickly as possible.\n\n- If the webhook error blocks cluster availability or the webhook is harmless\n to remove and mitigates the situation, check if it's possible to temporarily\n set the `failurePolicy` to `Ignore` or remove the offending webhook.\n\nAPI server dial failure or latency\n\nThis error might be seen in a few different ways:\n\n- **External name resolution errors:** An external client might return errors\n that contain `lookup` in the message, such as:\n\n dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host\n\n This error doesn't apply to a client running within the cluster. The\n Kubernetes Service IP is injected, so no resolution is required.\n- **Network errors:** The client might print a generic network error when trying\n to dial the API server, like the following examples:\n\n dial tcp 10.96.0.1:443: connect: no route to host\n dial tcp 10.96.0.1:443: connect: connection refused\n dial tcp 10.96.0.1:443: connect: i/o timeout\n\n- **High latency connecting to API server:** The connection to API server might\n be successful, but the requests timeout on the client side. In this scenario,\n the client usually prints error messages containing `context deadline\n exceeded`.\n\nIf the connection to the API server fails completely, try the connection within\nthe same environment where the client reports the error.\n[Kubernetes ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/)\ncan be used to inject a debugging container to the existing namespaces as\nfollows:\n\n1. From where the problematic client runs, use `kubectl` to perform a request\n with high verbosity. For example, a `GET` request to `/healthz` usually\n requires no authentication:\n\n kubectl get -v999 --raw /healthz\n\n2. If the request fails or `kubectl` is unavailable, you can obtain the URL from\n the output and manually perform the request with `curl`. For example, if the\n service host obtained from the previous output was `https://192.0.2.1:36917/`,\n you can send a similar request as follows:\n\n # Replace \"--ca-cert /path/to/ca.pem\" to \"--insecure\" if you are accessing\n # a local cluster and you trust the connection cannot be tampered.\n # The output is always \"ok\" and thus contains no sensentive information.\n\n curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz\n\n The output from this command usually indicates the root cause of a failed\n connection.\n | **Note:** You can't use the `ping` or `traceroute` commands to the IP address. A Kubernetes Service IP doesn't accept ICMP or protocols outside the list defined in the Service resource.\n\n If the connection is successful but is slow or times out, it indicates an\n overloaded API server. To confirm, in the console look at `API\n Server Request Rate` and request latency metrics in `Cloud Kubernetes \u003e Anthos \u003e\n Cluster \u003e K8s Control Plane`.\n\nTo resolve these connection failures or latency problems, review the following\nremediation options:\n\n- If a network error occurs within the cluster, there might be problem with the\n Container Network Interface (CNI) plugin. This problem is usually transient\n and resolves itself after a Pod recreation or reschedule.\n\n- If the network error is from outside the cluster, check if the client is\n properly configured to access the cluster, or generate the client\n configuration again. If the connection goes through a proxy or gateway, check\n if another connection that goes through the same mechanism works.\n\n- If the API server is overloaded, it usually means that many clients access the\n API server at the same time. A single client can't overload an API server due\n to throttling and the\n [Priority and Fairness](https://kubernetes.io/docs/concepts/cluster-administration/flow-control/)\n feature. Review the workload for the following areas:\n\n - Works at Pod level. It's more common to mistakenly create and forget Pods than higher level resources.\n - Adjust the number of replicas through erroneous calculation.\n - A webhook that loops back the request to itself or amplifies the load by creating more requests than it handles.\n\nWhat's next\n\nIf you need additional assistance, reach out to\n\n[Cloud Customer Care](/support-hub).\n\nYou can also see\n[Getting support](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support) for more information about support resources, including the following:\n\n- [Requirements](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#support_requirements) for opening a support case.\n- [Tools](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#support_tools) to help you troubleshoot, such as logs and metrics.\n- Supported [components](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#whats_supported), [versions](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#version_support_policy), and [features](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#supported_features) of Google Distributed Cloud for VMware (software only)."]]
