Solución de problemas de actualización de revisión secundaria del complemento de malla de servicio Istio

Artículo
11/20/2024

En este artículo se describen los escenarios de solución de problemas y las restricciones en los procesos de actualización y reversión de revisiones menores para el complemento de malla del servicio Istio en Microsoft Azure Kubernetes Service (AKS).

Nota:

Istio usa el término "revisiones" para implementar el proceso de actualización controlado y distinguir entre versiones. Cada designación de revisión (escrita como x-y) corresponde a una designación de versión principal.secundaria (x.y). Puede controlar la revisión del plano de control, pero no puede controlar la versión de revisión específica dentro de una banda de revisión.

Requisitos previos

Azure CLI.
La herramienta kubectl de Kubernetes o una herramienta similar para conectarse al clúster. Para instalar kubectl mediante la CLI de Azure, ejecute el comando az aks install-cli .

Matriz de solución de problemas

En la tabla siguiente se enumeran varios problemas y los distintos escenarios y soluciones para esos problemas.

Escenario	Problema	Solución
Las cargas de trabajo del plano de datos se quitan de la malla.	Las revisiones del plano de datos y del plano de control no se correspondieron antes de completar o revertir una actualización.	Siga estos pasos: Vuelva a etiquetar los espacios de nombres que contienen cargas de trabajo especificando la revisión que se espera que exista después de la finalización o reversión de la actualización. Para ello, ejecute el comando kubectl label : kubectl label namespace default istio.io/rev=asm-x-y --overwrite Reinicie las implementaciones de carga de trabajo correspondientes para desencadenar la reinjección sidecar de la revisión correcta. Para ello, ejecute el comando kubectl rollout restart : kubectl rollout restart deployment <deployment name> Compruebe que existen las imágenes sidecar. Para ello, ejecute el comando kubectl get : kubectl get pods --namespace <namespace> --output yaml \| grep mcr.microsoft.com/oss/istio/proxyv2:
Los pods del plano de control están en estado pendiente.	Los pods carecen de capacidad.	Compruebe el estado de los pods mediante la ejecución del comando kubectl describe . Si la capacidad es el problema, puede escalar verticalmente el clúster para agregar otro nodo. Para más información, consulte Escalado manual del número de nodos en un clúster de Azure Kubernetes Service (AKS).
El comando az aks mesh get-upgrades no devuelve actualizaciones disponibles.	La revisión más reciente de Istio podría ser incompatible con la versión actual del clúster de AKS.	Puede usar el comando az aks mesh get-revisions para detectar si existen revisiones de Istio más recientes. La salida incluye una lista de versiones de clúster compatibles para cada revisión de Istio. Por lo tanto, puede determinar si es necesario actualizar un clúster.

Escenario

Problema

Solución

Las cargas de trabajo del plano de datos se quitan de la malla.

Las revisiones del plano de datos y del plano de control no se correspondieron antes de completar o revertir una actualización.

Siga estos pasos:

Vuelva a etiquetar los espacios de nombres que contienen cargas de trabajo especificando la revisión que se espera que exista después de la finalización o reversión de la actualización. Para ello, ejecute el comando kubectl label :
```
kubectl label namespace default istio.io/rev=asm-x-y --overwrite
```
Reinicie las implementaciones de carga de trabajo correspondientes para desencadenar la reinjección sidecar de la revisión correcta. Para ello, ejecute el comando kubectl rollout restart :
```
kubectl rollout restart deployment <deployment name>
```

Compruebe que existen las imágenes sidecar. Para ello, ejecute el comando kubectl get :

kubectl get pods --namespace <namespace> --output yaml | grep mcr.microsoft.com/oss/istio/proxyv2:

Los pods del plano de control están en estado pendiente.

Los pods carecen de capacidad.

Compruebe el estado de los pods mediante la ejecución del comando kubectl describe . Si la capacidad es el problema, puede escalar verticalmente el clúster para agregar otro nodo. Para más información, consulte Escalado manual del número de nodos en un clúster de Azure Kubernetes Service (AKS).

El comando az aks mesh get-upgrades no devuelve actualizaciones disponibles.

La revisión más reciente de Istio podría ser incompatible con la versión actual del clúster de AKS.

Puede usar el comando az aks mesh get-revisions para detectar si existen revisiones de Istio más recientes. La salida incluye una lista de versiones de clúster compatibles para cada revisión de Istio. Por lo tanto, puede determinar si es necesario actualizar un clúster.

Nota:

Para evitar el comportamiento no deseado y la funcionalidad interrumpida, y también asegurarse de que recibe actualizaciones de vulnerabilidades de seguridad, se recomienda encarecidamente actualizar a una versión de AKS compatible y actualizada y revisión del complemento istio. Recuerde que la revisión del complemento también debe estar dentro del intervalo de versiones de Kubernetes compatible para el clúster de AKS determinado. Como se resalta en la sección Actualización de revisión secundaria del artículo Actualización de Istio, puede ejecutar los az aks mesh get-revisions comandos y az aks mesh get-upgrades para obtener información sobre las revisiones, actualizaciones y compatibilidad disponibles del complemento.

Restricciones

No se permite una degradación a una revisión anterior (fuera del proceso de reversión controlada).
La omisión de una revisión a una revisión noconsecutiva solo se permite si AKS ya no admite la revisión actual y la siguiente revisión de actualización. En este momento, la única actualización que está disponible es la revisión más baja admitida.
La etiqueta Istio sidecar.istio.io/inject no habilita la inyección de sidecar para el complemento Istio. Debe usar la istio.io/rev etiqueta cuando etiquete y vuelva a etiquetar los espacios de nombres durante la actualización de valor controlado.
El etiquetado debe producirse en un nivel de espacio de nombres en lugar de en un nivel por implementación. Si desea poder revertir los pods individualmente, puede optar por reiniciar implementaciones individuales en lugar de usar el etiquetado de pods.
Si usa el complemento Istio Shared MeshConfig, debe copiar o transferir la configuración de MeshConfig al nuevo ConfigMap antes de realizar una actualización controlada. Para obtener más información, consulte Configuración y actualizaciones de malla.
El complemento istio implementa pods e implementaciones de puerta de enlace de entrada de Istio por revisión. Si va a realizar una actualización de valor controlado y tiene dos revisiones del plano de control instaladas en el clúster, es posible que tenga que solucionar varios pods de puerta de enlace de entrada en ambas revisiones.

Referencias

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Aviso de declinación de responsabilidades sobre la información de contacto de terceros

Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la precisión de esta información de contacto de terceros.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.

Compartir a través de