Resuelve problemas de proxy de sidecar y webhook en Cloud Service Mesh

En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.

Cloud Service Mesh contiene dos 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

La inserción de archivos no funciona de forma correcta si se muestra alguna de las siguientes opciones:

pods que se programan sin sidecar
pods que deben tener sidecar inyectados nunca aparecen cuando se usa kubectl get pods, pero la réplica correspondiente del kubectl 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 en istiod que corresponde a la versión de Cloud Service Mesh seleccionada. Para obtener más información sobre las etiquetas de revisión, consulta Inyección de 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-1167-22, que es específico de esta versión de Cloud Service Mesh. Asegúrate de usar la revisión real si difiere.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1167-22 -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 ves registros que mencionan gRPC config stream closed, no healthy upstream, verifica que la dirección de descubrimiento en la malla ProxyConfig sea correcta y apunte a tu servicio de istiod.
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 que se envió 1 actualización desde istiod), y lds es el servicio de detección de objetos de escucha (que informa que se rechazó 1 actualización desde istiod). A menudo, verás un mensaje de error anterior que explica el motivo del rechazo, que, por lo general, comienza con una advertencia sobre la configuración de Envoy 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`	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 tus reglas de firewall proporcionen la conectividad a Istiod en el puerto 15017. Para obtener más información, consulta Abre un puerto en un clúster privado.