En esta página, se muestra cómo resolver problemas con el servidor de la API de Kubernetes (kube-apiserver
) para Google Distributed Cloud.
Tiempos de espera de webhooks y llamadas de webhook con errores
Estos errores pueden verse de diferentes maneras. Si experimentas alguno de los siguientes síntomas, es posible que fallen las llamadas de webhook:
Se rechazó la conexión: Si
kube-apiserver
informa errores de tiempo de espera para llamar al webhook, se informa el siguiente error en los 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
Se superó el plazo de contexto: También es posible que veas el siguiente error informado en los 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"
Si crees que estás experimentando tiempos de espera de webhook o llamadas de webhook con errores, usa uno de los siguientes métodos para confirmar el problema:
Revisa el registro del servidor de la API para ver si hay un problema en la red.
- Revisa el registro para ver si hay errores relacionados con la red, como
TLS handshake error
. - Verifica si la IP o el puerto coinciden con lo que el servidor de la API está configurado para responder.
- Revisa el registro para ver si hay errores relacionados con la red, como
Supervisa la latencia de webhook con los siguientes pasos:
En la consola, ve a la página Cloud Monitoring.
Selecciona Explorador de métricas.
Selecciona la métrica
apiserver_admission_webhook_admission_duration_seconds
.
Para resolver este problema, revisa las siguientes sugerencias:
Es posible que se requieran reglas de firewall adicionales para el webhook. Si deseas obtener más información, consulta cómo agregar reglas de firewall para casos de uso específicos.
Si el webhook requiere más tiempo para completarse, puedes configurar un valor de tiempo de espera personalizado. La latencia de los webhooks se agrega a la latencia de la solicitud a la API, por lo que se debe evaluar lo más rápido posible.
Si el error de webhook bloquea la disponibilidad del clúster o el webhook es inofensivo para quitar y mitigar la situación, verifica si es posible establecer de forma temporal el
failurePolicy
enIgnore
o quitar el webhook infractor.
Falla de llamada o latencia del servidor de la API
Este error puede verse de las siguientes maneras:
Errores de resolución de nombres externos: un cliente externo puede mostrar errores que contengan
lookup
en el mensaje, como los siguientes:dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host
Este error no se aplica a un cliente que se ejecuta dentro del clúster. Se inserta la IP del Service de Kubernetes, por lo que no se necesita una resolución.
Errores de red: El cliente puede imprimir un error de red genérico cuando intenta llamar al servidor de la API, como en los siguientes ejemplos:
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
Alta latencia de conexión al servidor de la API: la conexión al servidor de la API puede ser exitosa, pero el tiempo de espera de las solicitudes se agota en el lado del cliente. En esta situación, el cliente suele imprimir mensajes de error que contienen
context deadline exceeded
.
Si la conexión al servidor de la API falla por completo, intenta establecerla dentro del mismo entorno en el que el cliente informa el error. Los contenedores efímeros de Kubernetes se pueden usar para inyectar un contenedor de depuración en los espacios de nombres existentes de la siguiente manera:
Desde donde se ejecute el cliente problemático, usa
kubectl
para realizar una solicitud con verbosidad alta. Por ejemplo, una solicitudGET
a/healthz
no suele requerir autenticación:kubectl get -v999 --raw /healthz
Si la solicitud falla o
kubectl
no está disponible, puedes obtener la URL del resultado y realizar la solicitud de forma manual concurl
. Por ejemplo, si el host de servicio obtenido del resultado anterior erahttps://192.0.2.1:36917/
, puedes enviar una solicitud similar de la siguiente manera:# 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
Por lo general, el resultado de este comando indica la causa raíz de una conexión fallida.
Si la conexión es exitosa, pero es lenta o se agota el tiempo de espera, significa que el servidor de la API está sobrecargado. Para confirmar, en la consola, observa
API Server Request Rate
y solicita las métricas de latencia enCloud Kubernetes > Anthos > Cluster > K8s Control Plane
.
Para resolver estas fallas de conexión o problemas de latencia, revisa las siguientes opciones de solución:
Si se produce un error de red dentro del clúster, es posible que haya un problema con el complemento de la interfaz de red de contenedores (CNI). Este problema suele ser transitorio y se resuelve después de una recreación o reprogramación del pod.
Si el error de red proviene del exterior del clúster, verifica si el cliente está configurado de forma correcta para acceder al clúster o genera la configuración del cliente de nuevo. Si la conexión pasa por un proxy o una puerta de enlace, verifica si funciona otra conexión que pasa por el mismo mecanismo.
Por lo general, si el servidor de la API está sobrecargado, significa que muchos clientes acceden al servidor de la API al mismo tiempo. Un solo cliente no puede sobrecargar un servidor de API debido a la limitación y a la función de Prioridad y equidad. Revisa la carga de trabajo en las siguientes áreas:
- Funciona a nivel del Pod. Es más común crear y olvidar Pods por error que recursos de nivel superior.
- Ajusta la cantidad de réplicas a través de cálculos erróneos.
- Un webhook que repite la solicitud en bucle o amplía la carga mediante la creación de más solicitudes de las que controla.