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 Virtual for Bare Metal.

Si necesitas asistencia adicional, comunícate con Atención al cliente de 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 las llamadas de webhook estén fallando:

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 excedió 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 estás experimentando tiempos de espera de webhook o llamadas de webhook fallidas, 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 de red.
- Revisa el registro para ver si hay errores relacionados con la red, como TLS handshake error.
- Verifica si la IP/puerto coincide con la que el servidor de la API está configurado para responder.
Supervisa la latencia de webhook mediante los siguientes pasos:
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 el problema, revisa las siguientes sugerencias:

Es posible que se requieran reglas de firewall adicionales para el webhook. Si quieres 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 la situación y mitigar la situación, verifica si es posible establecer de forma temporal failurePolicy en Ignore o quitar el webhook ofensivo.

Latencia o falla de marcado del servidor de la API

Este error puede verse de diferentes 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. La IP del servicio de Kubernetes se inserta, por lo que no se requiere 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

Conexión de latencia alta al servidor de la API: La conexión al servidor de la API puede ser exitosa, pero el tiempo de espera de las solicitudes es del lado del cliente. En este caso, por lo general, el cliente imprime mensajes de error que contienen context deadline exceeded.

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

Desde donde se ejecuta el cliente problemático, usa kubectl para realizar una solicitud con alta verbosidad. Por ejemplo, una solicitud GET a /healthz, por lo general, no requiere 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 con curl. Por ejemplo, si el host del 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
```
Por lo general, el resultado de este comando indica la causa raíz de una conexión fallida.

Nota: No puedes usar los comandos ping ni traceroute para la dirección IP. Una IP de Service de Kubernetes no acepta ICMP ni protocolos fuera de la lista definida en el recurso Service.

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 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, podría haber un problema con el complemento de interfaz de red de contenedor (CNI). Este problema suele ser transitorio y se resuelve solo después de una recreación o reprogramación de Pod.
Si el error de red proviene de fuera del clúster, verifica si el cliente está configurado de forma correcta para acceder al clúster o vuelve a generar la configuración del cliente. Si la conexión se realiza mediante un proxy o una puerta de enlace, comprueba si funciona otra conexión que pasa por el mismo mecanismo.
Si el servidor de la API está sobrecargado, generalmente significa que muchos clientes acceden al servidor de la API al mismo tiempo. Un solo cliente no puede sobrecargar el servidor de la API debido a la regulació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 y olvidar Pods por error que los recursos de nivel superior.
- Ajustar la cantidad de réplicas mediante el cálculo erróneo
- Un webhook que repite la solicitud a sí mismo o amplifica la carga mediante la creación de más solicitudes de las que controla.

¿Qué sigue?

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