Soluciona problemas del servidor de la API de Kubernetes

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

Esta página está destinada a administradores de TI y operadores que administran 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 (SLO) o fallan las aplicaciones. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud, consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Tiempos de espera de webhooks y llamadas de webhooks fallidas

Estos errores se pueden ver de varias maneras. Si experimentas alguno de los siguientes problemas, es posible que las llamadas a webhooks no se realicen correctamente:

  • Conexión rechazada: 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 del contexto: Es posible que también 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 experimentas tiempos de espera de webhooks o llamadas a webhooks fallidas, usa uno de los siguientes métodos para confirmar el problema:

  • Verifica el registro del servidor de la API para ver si hay un problema de red.

    • Revisa el registro en busca de 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.

  • Sigue estos pasos para supervisar la latencia del webhook:

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

      Ir a la página Cloud Monitoring

    2. Selecciona Explorador de métricas.

    3. Selecciona la métrica apiserver_admission_webhook_admission_duration_seconds.

Para resolver este problema, realiza las siguientes acciones:

  • Es posible que se requieran reglas de firewall adicionales para el webhook. Para 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 suma a la latencia de la solicitud a la API, por lo que se debe evaluar lo más rápido posible.

  • Si el error del webhook bloquea la disponibilidad del clúster o si quitarlo no es perjudicial y mitiga la situación, verifica si es posible configurar temporalmente failurePolicy como Ignore o quitar el webhook infractor.

Latencia o falla de conexión del servidor de la API

Este error se puede ver de varias maneras:

  • Errores de resolución de nombres externos: Un cliente externo puede mostrar errores que contienen 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 servicio de Kubernetes, por lo que no se requiere resolución.

  • Errores de red: Es posible que el cliente imprima un error de red genérico cuando intente 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 para conectarse al servidor de la API: Es posible que la conexión al servidor de la API sea exitosa, pero el tiempo de espera de las solicitudes se agote del 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 establecer la conexión en el mismo entorno en el que el cliente informa el error. Los contenedores efímeros de Kubernetes se pueden usar para insertar un contenedor de depuración en los espacios de nombres existentes de la siguiente manera:

  1. Desde donde se ejecuta el cliente problemático, usa kubectl para realizar una solicitud con mucha verbosidad. Por ejemplo, una solicitud de GET a /healthz, por lo general, no requiere autenticación:

    kubectl get -v999 --raw /healthz

  2. Si la solicitud falla o kubectl no está disponible, puedes obtener la URL del resultado y realizar la solicitud de forma manual con curl. Por ejemplo, si el host de servicio obtenido del 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

    El resultado de este comando suele indicar la causa raíz de una conexión que falló.

    Si la conexión se realiza correctamente, pero es lenta o se agota el tiempo de espera, significa que hay un servidor de API sobrecargado. Para confirmar, en la consola, consulta API Server Request Rate y solicita las métricas de latencia en Cloud 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 la Red del Contenedor (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 se produce fuera del clúster, verifica si el cliente está configurado correctamente para acceder a él o vuelve a generar la configuración del cliente. Si la conexión pasa por un proxy o una puerta de enlace, verifica si funciona otra conexión que pase por el mismo mecanismo.

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

    • Funciona a nivel del Pod. Es más común crear pods por error y olvidarlos que los recursos de nivel superior.
    • Ajusta la cantidad de réplicas mediante un cálculo erróneo.
    • Un webhook que vuelve a enviar la solicitud a sí mismo o amplifica la carga creando más solicitudes de las que controla.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.