Solucionar problemas del servidor de la API de Kubernetes

En esta página se explica cómo resolver problemas con el servidor de la API de Kubernetes (kube-apiserver) de Google Distributed Cloud.

Esta página está dirigida a administradores de TI y operadores que gestionan el ciclo de vida de la infraestructura tecnológica subyacente y responden a alertas y páginas cuando no se cumplen los objetivos de nivel de servicio (SLOs) o las aplicaciones fallan. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE. Google Cloud

Tiempos de espera de webhooks y llamadas a webhooks fallidas

Estos errores pueden aparecer de varias formas. Si experimentas alguno de los siguientes síntomas, es posible que las llamadas de webhook estén fallando:

  • Conexión rechazada: si kube-apiserver informa de errores de tiempo de espera al llamar al webhook, se registra el siguiente error:

    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 ha superado el plazo del contexto: también puede aparecer el siguiente error 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 fallidas, usa uno de los siguientes métodos para confirmar el problema:

  • Consulta el registro del servidor de la API para ver si hay algún problema de red.

    • Consulta el registro para ver si hay errores relacionados con la red, como TLS handshake error.
    • Comprueba si la IP o el puerto coinciden con los que el servidor de la API está configurado para responder.

  • Para monitorizar la latencia de webhook, sigue estos pasos:

    1. En la consola, ve a la página Cloud Monitoring.

      Ir a la página Cloud Monitoring

    2. Seleccione Explorador de métricas.

    3. Seleccione la métrica apiserver_admission_webhook_admission_duration_seconds.

Para solucionar este problema, consulta las siguientes sugerencias:

  • Es posible que se necesiten reglas de cortafuegos adicionales para la webhook. Para obtener más información, consulta cómo añadir reglas de cortafuegos para casos prácticos específicos.

  • Si el webhook necesita más tiempo para completarse, puede configurar un valor de tiempo de espera personalizado. La latencia de los webhooks se suma a la latencia de las solicitudes de la API, por lo que debe evaluarse lo antes posible.

  • Si el error del webhook bloquea la disponibilidad del clúster o el webhook no supone ningún riesgo y se puede eliminar para solucionar el problema, comprueba si es posible definir temporalmente failurePolicy como Ignore o eliminar el webhook en cuestión.

Error de conexión o latencia del servidor de la API

Este error puede aparecer de varias formas:

  • Errores de resolución de nombres externos: es posible que un cliente externo devuelva 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 ejecute en el clúster. Se inserta la IP del servicio de Kubernetes, por lo que no se requiere ninguna resolución.

  • Errores de red: es posible que el cliente muestre un error de red genérico al intentar marcar el 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

  • Latencia alta al conectarse al servidor de la API: la conexión al servidor de la API puede establecerse correctamente, pero las solicitudes agotan el tiempo de espera en el lado del cliente. En este caso, el cliente suele imprimir mensajes de error que contienen context deadline exceeded.

Si la conexión con el servidor de la API falla por completo, prueba la conexión en el mismo entorno en el que el cliente informa del error. Los contenedores efímeros de Kubernetes se pueden usar para insertar un contenedor de depuración en los espacios de nombres actuales de la siguiente manera:

  1. Desde donde se ejecuta el cliente problemático, usa kubectl para hacer una solicitud con un nivel de detalle alto. Por ejemplo, una solicitud GET a /healthz no suele requerir autenticación:

    kubectl get -v999 --raw /healthz

  2. Si la solicitud falla o kubectl no está disponible, puedes obtener la URL de la salida y realizar la solicitud manualmente con curl. Por ejemplo, si el host del servicio obtenido en el resultado anterior era https://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

    La salida de este comando suele indicar la causa principal de un error de conexión.

    Si la conexión se realiza correctamente, pero es lenta o se agota el tiempo de espera, significa que el servidor de la API está sobrecargado. Para confirmarlo, consulta las métricas de API Server Request Rate y de latencia de las solicitudes en Cloud Kubernetes > Anthos > Cluster > K8s Control Plane en la consola.

Para resolver estos problemas de conexión o latencia, consulta las siguientes opciones de corrección:

  • Si se produce un error de red en el clúster, puede que haya un problema con el complemento Container Network Interface (CNI). Este problema suele ser transitorio y se resuelve solo después de recrear o reprogramar un pod.

  • Si el error de red se produce fuera del clúster, comprueba si el cliente está configurado correctamente para acceder al clúster o vuelve a generar la configuración del cliente. Si la conexión pasa por un proxy o una pasarela, comprueba si funciona otra conexión que pase por el mismo mecanismo.

  • Si el servidor de la API está sobrecargado, suele significar que muchos clientes acceden al servidor de la API al mismo tiempo. Un solo cliente no puede sobrecargar un servidor de APIs debido a la limitación y a la función Prioridad y equidad. Revisa la carga de trabajo de las siguientes áreas:

    • Funciona a nivel de pod. Es más habitual crear y olvidar Pods por error que recursos de nivel superior.
    • Ajustar el número de réplicas mediante un cálculo erróneo.
    • Un webhook que devuelve la solicitud a sí mismo o amplifica la carga creando más solicitudes de las que gestiona.

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes: