Resuelve problemas de proxy de sidecar/webhook en Cloud Service Mesh
En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos de ellos. Si necesitas asistencia adicional, consulta Obtén asistencia.
La malla de servicios de Cloud Webhooks:
- El webhook de validación garantiza que la configuración de Istio aplicada sea válida.
- El webhook de mutación establece la inserción automática de sidecars en Pods nuevos.
Un problema de configuración en uno de estos webhooks puede provocar que se inicien nuevos Pods o que kubectl apply
genere mensajes de error.
Problemas de inserción del sidecar
Si aprovisionaste Cloud Service Mesh administrado, comunícate con el equipo de asistencia.
La inserción de archivos no funciona de forma correcta si se muestra alguna de las siguientes opciones:
- pods que se programan sin sidecar
- los Pods que deberían tener sidecars insertados nunca aparecen cuando se usa
kubectl get pods
, pero el conjunto de réplicas correspondiente dekubectl get replicaset
existe.
Sigue estos pasos para solucionar los problemas de inyección del sidecar.
Verifica que tu espacio de nombres o Pod tenga la etiqueta de inserción correcta.
Si ejecutas Istio de una sola revisión (la opción predeterminada), verifica que tu espacio de nombres o especificación de pod tenga la etiqueta istio-injection=enabled.
Si ejecutas Istio de varias revisiones (para las migraciones de tiempo de inactividad, varios planos de control, etc.), verifica que tu espacio de nombres o la especificación de pod tenga la etiqueta
istio.io/rev=REVISION
adecuada, en la que REVISION es el número de revisión de Cloud Service Mesh enistiod
que corresponde a la versión de Cloud Service Mesh seleccionada. Para ver más Para obtener información sobre las etiquetas de revisión, consulta Incorpora proxies de sidecar.Verifique que su webhook de inyección del sidecar de Istio esté presente y tenga un paquete de CA.
El webhook de inyector de sidecar (que se usa para la inyección automática de sidecar) requiere un paquete de CA a fin de establecer conexiones seguras con el servidor de la API e
istiod
.istiod
parcha este paquete de CA en la configuración, pero, a veces, se puede reemplazar (por ejemplo, si vuelves a aplicar la configuración de webhook).Puedes verificar la presencia del paquete de AC con el siguiente comando. El comando incluye
istio-sidecar-injector-asm-1232-2
, que es específico de esta versión de Cloud Service Mesh. Asegúrate de usar tu revisar si difiere.kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1232-2 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
Si el resultado no está vacío, el paquete de CA está configurado. Si falta el paquete de CA, reinicia
istiod
para que vuelva a analizar el webhook y reinstale el paquete de CA.Verifica si hay errores de inyección de sidecar.
Si tienes habilitada la inserción, pero no ves los programas en la programación, verifica el estado del siguiente nivel de abstracción superior. Por ejemplo, si ejecutas una implementación, pero no hay Pods en la programación, verifica el estado de los conjuntos de réplicas correspondientes mediante el siguiente comando:
kubectl -n my-namespace describe replicaset your-deployment-name
Si el conjunto de réplicas está presente, revisa los registros de eventos en la parte inferior de la descripción para detectar errores. Si el error se relaciona con la inserción del sidecar, verifica los registros de
istiod
para ver qué causa el error.Si el problema persiste, el problema podría ser cualquiera de las siguientes causas:
- Se pasó la configuración incorrecta al inyector
- Problemas de configuración de firewall
- Un problema en el código de Istio
Consulta Solución de problemas de Istio para obtener pasos adicionales de diagnóstico.
Los proxies de Envoy no reciben la configuración de istiod
Existen varios problemas que pueden evitar que los proxies reciban la configuración de istiod
.
istiod
no enviará la configuración a los proxies de Envoy si tiene problemas, como un problema de RBAC que impide que lea su recurso de configuración.La dirección de detección es incorrecta (errores “sin errores en sentido ascendente”)
La dirección de descubrimiento proporcionada al inyector de sidecar es incorrecta. Si verás registros que mencionan
gRPC config stream closed, no healthy upstream
comprobar que la dirección de descubrimiento en la mallaProxyConfig
es correcta y apunta a tu servicio deistiod
.La configuración no se envía al proxy. En este caso, la configuración se envía de forma correcta al proxy, pero la configuración no es válida. Verás mensajes repetidos similares a los que se muestran a continuación:
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
En este ejemplo,
cds
es el servicio de descubrimiento de clústeres (que informa 1 actualización enviada desdeistiod
) ylds
es el servicio de descubrimiento de objetos de escucha (que informa que 1 actualización rechazada deistiod
). A menudo, verás un mensaje de error anterior que explica el motivo del rechazo, que suele comenzar con una advertencia sobre la configuración de entorno o similar.Para solucionar el problema, investiga la causa de la configuración que se rechazó. Una causa común es la falta de recursos
EnvoyFilter
. Si no hay ninguna razón evidente, envía un informe de errores con un volcado de configuración del proxy.
No se puede crear el Pod
Si observas que los Pods no se crean con éxito, busca los mensajes de error que podrían dar pistas sobre el problema raíz mediante el siguiente comando:
kubectl describe replicaset YOUR_REPLICA_SET
Mensajes de error de webhook comunes
Los mensajes de error que muestra el comando kubectl apply
pueden proporcionar una sugerencia sobre su causa raíz. Consulta la siguiente tabla para ver los mensajes de error comunes, sus causas y posibles soluciones.
Mensaje de error | Causa | Solución |
---|---|---|
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) |
Es posible que se trate de un problema de conectividad de red. | Asegúrate de que tus reglas de firewall proporcionen la conectividad a `istiod` en el puerto 15017. |
no endpoints available for service 'istiod' |
Esto puede ocurrir si el Pod de `istiod` no está disponible o no está listo. | Verifica los Pods de `istiod` para asegurarte de que estén en ejecución y listos. |
Service "istiod" not found |
Esto puede ocurrir si el servicio de `istiod` no existe. | Verifica que la instalación de Istio se haya realizado correctamente. |
x509: certificate signed by unknown authority |
Este podría ser un problema de certificado de webhook. | Comprueba que caBundle esté configurado de forma correcta en el webhook. |
Failed to update validatingwebhookconfiguration
istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail,
resourceVersion=[version]): Operation cannot be fulfilled on
validatingwebhookconfigurations.admissionregistration.k8s.io
"istio-validator-asm-[version-n]-istio-system": the object has been
modified; please apply your changes to the latest version and try
again. |
Un webhook de validación de una versión anterior de Istio o Cloud Service Mesh que se desinstaló puede interferir en una actualización o instalación. | Verifica que todos los webhooks aún estén en el clúster y quita todos los webhooks que hagan referencia a versiones que ya no estén instaladas. |
Error from server (InternalError): Internal error occurred: failed
calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded |
Para los clústeres privados, el puerto 15017 debe estar abierto. Este mensaje de error indica que el puerto 15017 puede no estar abierto. | Asegúrate de que tus reglas de firewall proporcionen la conectividad a Istiod en el puerto 15017. Para obtener más información, consulta Apertura de un puerto en un clúster privado. |