Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Resolver problemas de proxy sidecar o webhook en Cloud Service Mesh

En esta sección se explican los problemas habituales de Cloud Service Mesh y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener asistencia.

Cloud Service Mesh contiene dos webhooks:

El webhook de validación se asegura de que la configuración de Istio aplicada sea válida.
El webhook de mutación define la inyección automática de sidecar en los pods nuevos.

Si hay un problema de configuración en uno de estos webhooks, es posible que los nuevos pods no se inicien o que kubectl apply genere mensajes de error.

Problemas de inyección de sidecar

Si has aprovisionado Cloud Service Mesh gestionado, ponte en contacto con el equipo de Asistencia.

La inyección de Sidecar no funciona correctamente si se da alguna de las siguientes situaciones:

pods que se están programando sin sidecars
Los pods en los que se deberían insertar sidecars nunca aparecen al usar kubectl get pods, pero el conjunto de réplicas correspondiente de kubectl get replicaset sí.

Sigue estos pasos para solucionar problemas de inyección de sidecar.

Verifica que tu espacio de nombres o pod tenga la etiqueta de inyección correcta.

Si estás ejecutando Istio de una sola revisión (el valor predeterminado), verifica que tu espacio de nombres o especificación de pod tengan la etiqueta istio-injection=enabled.

Si estás ejecutando Istio de varias revisiones (para migraciones sin tiempo de inactividad, varios planos de control, etc.), verifica que tu espacio de nombres o especificación de pod tenga la etiqueta istio.io/rev=REVISION adecuada, donde REVISION es el número de revisión de Cloud Service Mesh en istiod que corresponde a la versión de Cloud Service Mesh que has seleccionado. Para obtener más información sobre las etiquetas de revisión, consulta Inyectar proxies sidecar.
Verifica que el webhook de inyección de sidecar de Istio esté presente y tenga un paquete de CA.

El webhook del inyector de sidecar (que se usa para la inyección automática de sidecar) requiere un paquete de AC para establecer conexiones seguras con el servidor de APIs y istiod. istiod aplica este paquete de CA a la configuración, pero a veces se puede sobrescribir (por ejemplo, si vuelves a aplicar la configuración del webhook).

Puedes verificar la presencia del paquete de CA con el siguiente comando. El comando incluye istio-sidecar-injector-asm-1264-1, que es específico de esta versión de Cloud Service Mesh. Asegúrate de usar tu revisión real si es diferente.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1264-1 -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.
Comprueba si se han producido errores de inyección de sidecar.

Si tienes habilitada la inyección, pero no ves la programación de pods, comprueba el estado del siguiente nivel de abstracción. Por ejemplo, si estás ejecutando una implementación, pero no se programa ningún pod, comprueba el estado de los conjuntos de réplicas correspondientes con el siguiente comando:
```
kubectl -n my-namespace describe replicaset your-replicaset-name
```
Si el conjunto de réplicas está presente, comprueba si hay errores en el registro de eventos situado en la parte inferior de la descripción.

El error Service Mesh injection is not yet ready. Please try again soon. indica que Cloud Service Mesh sigue aplicando las configuraciones de usuario. Por lo tanto, no se pueden implementar cargas de trabajo nuevas en este momento. Este es el comportamiento esperado de los clústeres recién aprovisionados. Normalmente, se trata de un proceso breve que se resuelve en cuestión de minutos mediante reintentos automáticos. Espera un poco a que se complete el proceso de configuración.

Si el error está relacionado con otro problema de inyección de sidecar, consulta los registros de istiod para ver qué lo está provocando.
Si el problema persiste, puede deberse a lo siguiente:
- Se ha pasado una configuración incorrecta al inyector
- Problemas de configuración del cortafuegos
- Un problema en el propio código de Istio
Consulta Solucionar problemas de Istio para ver más pasos de diagnóstico.

Los proxies de Envoy no reciben configuración de `istiod`

Hay varios problemas que pueden impedir 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 le impida leer su recurso de configuración.
La dirección de descubrimiento es incorrecta (errores "no healthy upstream")
La dirección de descubrimiento proporcionada al inyector sidecar es incorrecta. Si ves registros que mencionan gRPC config stream closed, no healthy upstream, comprueba que la dirección de descubrimiento de la malla ProxyConfig sea correcta y apunte a tu servicio istiod.
Se está enviando una configuración no válida al proxy. En este caso, la configuración se envía correctamente al proxy, pero no es válida. Verás mensajes repetidos similares a los siguientes:
```
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 de 1 actualización enviada desde istiod) y lds es el servicio de descubrimiento de listeners (que informa de 1 actualización rechazada de istiod). A menudo, verás un mensaje de error anterior que explica el motivo del rechazo, que suele empezar con una advertencia sobre la configuración de Envoy o similar.

Para solucionar el problema, investiga la causa del rechazo de la configuración. Una causa habitual es que los recursos EnvoyFilter no sean válidos. Si no hay ningún motivo obvio, 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 correctamente, busca mensajes de error que puedan darte pistas sobre el problema principal con el siguiente comando:

kubectl describe replicaset YOUR_REPLICA_SET

Mensajes de error habituales de webhooks

Los mensajes de error que genera el comando kubectl apply pueden darte una pista sobre la causa principal. En la siguiente tabla se muestran los mensajes de error habituales, sus causas y las posibles soluciones.

Mensaje de error	Causa	Resolución
`net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	Puede que se trate de un problema de conectividad de red.	Asegúrate de que las reglas de tu cortafuegos proporcionen conectividad a `istiod` en el puerto 15017.
`no endpoints available for service 'istiod'`	Esto puede ocurrir si el pod `istiod` no está disponible o no está listo.	Comprueba los pods `istiod` para asegurarte de que se están ejecutando y están listos.
`Service "istiod" not found`	Esto puede ocurrir si el servicio `istiod` no existe.	Verifica que la instalación de Istio se haya realizado correctamente.
`x509: certificate signed by unknown authority`	Puede que se trate de un problema con el certificado del webhook.	Comprueba que `caBundle` esté configurado correctamente 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.`	Es posible que un webhook de validación de una versión antigua de Istio o Cloud Service Mesh que se haya desinstalado esté interfiriendo con una actualización o instalación.	Comprueba que todos los webhooks sigan en el clúster y elimina los 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`	En el caso de los clústeres privados, el puerto 15017 debe estar abierto. Este mensaje de error indica que es posible que el puerto 15017 no esté abierto.	Asegúrate de que las reglas de tu cortafuegos permitan la conectividad con Istiod en el puerto 15017. Para obtener más información, consulta Abrir un puerto en un clúster privado.
`Error from server: error when creating "service.yaml": admission webhook "validation.istio.io" denied the request: Unsupported service entry fields: [serviceEntry.endpoints.network]`	El mensaje de error debe incluir detalles sobre la configuración incorrecta. Ten en cuenta que la compatibilidad con las APIs de Cloud Service Mesh a veces puede ser más restrictiva que la de OSS.	Corrige la configuración infractora antes de volver a intentar aplicarla.