Compartir a través de

Actualización del complemento de malla de servicio basado en Istio para Azure Kubernetes Service

  • Artículo

En este artículo se tratan las experiencias de actualización del complemento de malla de servicio basado en Istio para Azure Kubernetes Service (AKS).

Los anuncios sobre las nuevas revisiones secundarias o revisiones del complemento de malla de servicio basado en Istio se publican en las Notas de la versión de AKS. Para obtener más información sobre la programación de versión y la compatibilidad con las revisiones del complemento de malla de servicio, lea la directiva de compatibilidad.

Actualización de revisión secundaria

El complemento Istio permite actualizar la revisión secundaria mediante proceso de actualización valor controlado. Cuando se inicia una actualización, el plano de control de la nueva revisión (valor controlado) se implementa junto con el plano de control de la revisión anterior (estable). Después, puede revertir manualmente las cargas de trabajo del plano de datos al usar herramientas de supervisión para realizar un seguimiento del estado de las cargas de trabajo durante este proceso. Si no observa ninguna incidencia con el estado de las cargas de trabajo, puede completar la actualización para que solo la nueva revisión permanezca en el clúster. De lo contrario, puede revertir a la revisión anterior de Istio.

Si el clúster usa actualmente una revisión secundaria admitida de Istio, las actualizaciones solo se permiten una revisión secundaria a la vez. Si el clúster usa una revisión no admitida de Istio, debes actualizar a la revisión secundaria admitida más baja de Istio para esa versión de Kubernetes. Después de eso, las actualizaciones pueden volver a realizar una revisión secundaria a la vez.

En el ejemplo siguiente se muestra cómo actualizar de revisión asm-1-22 a asm-1-23 con todas las cargas de trabajo del espacio de nombres default. Los pasos son los mismos para todas las actualizaciones secundarias y se pueden usar para cualquier número de espacios de nombres.

  1. Use el comando az aks mesh get-upgrades para comprobar qué revisiones están disponibles para el clúster como destinos de actualización:

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    Si espera ver una revisión más reciente no devuelta por este comando, es posible que tenga que actualizar primero el clúster de AKS para que sea compatible con la revisión más reciente.

  2. Si ha configurado la configuración de malla para la revisión de malla existente en el clúster, debe crear un ConfigMap independiente correspondiente a la nueva revisión en el espacio de nombres aks-istio-system antes de iniciar la actualización de valor controlado en el paso siguiente. Esta configuración es aplicable en el momento en que se implementa el nuevo plano de control de la revisión en el clúster. Se pueden encontrar más detalles aquí.

  3. Inicie una actualización de valor controlado desde el asm-1-22 de revisión a asm-1-23 mediante az aks mesh upgrade start:

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-23

    Una actualización controlada significa que el plano de control 1.23 se implementa junto con el plano de control 1.22. Continúan coexistiendo hasta que complete o revierte la actualización.

  4. Opcionalmente, se pueden usar etiquetas de revisión para revertir el plano de datos a la nueva revisión sin necesidad de volver a etiquetar manualmente cada espacio de nombres. Cambiar manualmente el etiquetado de espacios de nombres al moverlos a una nueva revisión puede ser tedioso y propenso a errores. Las etiquetas de revisión resuelven este problema al servir como identificadores estables que apuntan a las revisiones.

    En lugar de volver a etiquetar cada espacio de nombres, un operador de clúster puede cambiar la etiqueta para que apunte a una nueva revisión. Todos los espacios de nombres etiquetados con esa etiqueta se actualizan al mismo tiempo. Sin embargo, todavía debe reiniciar las cargas de trabajo para asegurarse de que se inserta la versión correcta de istio-proxy sidecars.

    Para usar etiquetas de revisión durante una actualización:

    1. Instalar la CLI de istioctl

    2. Cree una etiqueta de revisión para la revisión inicial. En este ejemplo, se le asigna el nombre prod-stable:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system

    3. Crear una etiqueta de revisión para la revisión instalada durante la actualización. En este ejemplo, se le asigna el nombre prod-canary:

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system

    4. Etiquete los espacios de nombres de aplicación para asignar a etiquetas de revisión:

      # label default namespace to map to asm-1-22
kubectl label ns default istio.io/rev=prod-stable --overwrite

      También puede etiquetar espacios de nombres con istio.io/rev=prod-canary para la revisión más reciente. Sin embargo, las cargas de trabajo de esos espacios de nombres no se actualizan a un nuevo sidecar hasta que se reinician.

      Si se crea una nueva aplicación en un espacio de nombres después de etiquetarla, se insertará un sidecar correspondiente a la etiqueta de revisión en ese espacio de nombres.

  5. Compruebe que existen pods del plano de control correspondientes a asm-1-22 y asm-1-23:

    1. Compruebe istiod pods:

      kubectl get pods -n aks-istio-system

      Ejemplo:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-22-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-22-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-23-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-23-f85f46bf5-8p9qx             1/1     Running   0          51m

    2. Si la entrada está habilitada, compruebe los pods de entrada:

      kubectl get pods -n aks-istio-ingress

      Ejemplo:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-krq9w   1/1     Running   0          51m

      Observe que los pods de puerta de enlace de entrada de ambas revisiones se implementan en paralelo. Sin embargo, el servicio y su dirección IP permanecen inmutables.

  6. Vuelva a etiquetar el espacio de nombres para que los pods nuevos se asignen al sidecar de Istio asociado a la nueva revisión y su plano de control:

    1. Si usa etiquetas de revisión, sobrescriba la etiqueta prod-stable para cambiar su asignación:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      Compruebe las asignaciones de etiquetas a revisiones:

      istioctl tag list

      Ambas etiquetas deben apuntar a la revisión recién instalada:

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-23   default
prod-stable   asm-1-23   ...

      En este caso, no es necesario volver a etiquetar cada espacio de nombres individualmente.

    2. Si no usa etiquetas de revisión, se deben volver a etiquetar los espacios de nombres del plano de datos para que apunten a la nueva revisión:

      kubectl label namespace default istio.io/rev=asm-1-23 --overwrite

    La reetiquetación no afecta a las cargas de trabajo hasta que se reinician.

  7. Reinicie individualmente cada una de las cargas de trabajo de sus aplicaciones. Por ejemplo:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  8. Compruebe las herramientas y paneles de supervisión para determinar si todas las cargas de trabajo se ejecutan en un estado de mantenimiento después del reinicio. En base del resultado, tiene dos opciones:

    1. Completar la actualización de valor controlado: si está satisfecho de que todas las cargas de trabajo se ejecutan en un estado de mantenimiento según lo previsto, puede completar la actualización de valor controlado. La finalización de la actualización quita el plano de control de la revisión anterior y deja atrás el plano de control de la nueva revisión en el clúster. Ejecute el siguiente comando para completar la actualización de valor controlado:

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    2. Revertir la actualización de valor controlado: en caso de que observe incidencias con el estado de las cargas de trabajo, puede revertir a la revisión anterior de Istio:

    • Vuelva a etiquetar el espacio de nombres en la revisión anterior: si usa etiquetas de revisión:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite

      O bien, si no usa etiquetas de revisión:

      kubectl label namespace default istio.io/rev=asm-1-22 --overwrite

    • Revierte las cargas de trabajo para usar el sidecar correspondiente a la revisión anterior de Istio reiniciando estas cargas de trabajo de nuevo:

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>

    • Revierta el plano de control a la revisión anterior:

      az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER

    La etiqueta de revisión prod-canary se puede quitar:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. Si la configuración de malla se configuró previamente para las revisiones, ahora puede eliminar el ConfigMap para la revisión que se eliminó del clúster durante la finalización/reversión.

Actualizaciones de revisiones secundarias con la puerta de enlace de entrada

Si actualmente usas puertas de enlace de entrada de Istio y realizas una actualización de revisión secundaria, ten en cuenta que los pods o implementaciones de puerta de enlace de entrada de Istio se implementan por revisión. Sin embargo, proporcionamos un único servicio LoadBalancer en todos los pods de puerta de enlace de entrada en varias revisiones, por lo que la dirección IP externa o interna de las puertas de enlace de entrada permanece sin cambios durante el transcurso de una actualización.

Por lo tanto, durante la actualización de valor controlado, cuando existen dos revisiones simultáneamente en el clúster, el tráfico entrante se atenderá mediante los pods de puerta de enlace de entrada de ambas revisiones.

Actualizaciones de revisión secundarias con personalizaciones de escalado automático horizontal de pods

Si ha personalizado la configuración de escalado automático horizontal de pods (HPA) para Istiod o las puertas de enlace de entrada, tenga en cuenta el siguiente comportamiento en cuanto a cómo se aplica la configuración de HPA en ambas revisiones para mantener la coherencia durante una actualización de valor controlado:

  • Si actualiza la especificación de HPA antes de iniciar una actualización, la configuración de la revisión existente (estable) se aplicará a los HPA de la revisión de valor controlado cuando se instale el nuevo plano de control.
  • Si actualiza la especificación de HPA mientras una actualización de valor controlado está en curso, la especificación de HPA de la revisión estable tendrá prioridad y se aplicará al HPA de la revisión de valor controlado.
    • Si actualiza el HPA de la revisión estable durante una actualización, la especificación de HPA de la revisión de valor controlado se actualizará para reflejar la nueva configuración aplicada a la revisión estable.
    • Si actualiza el HPA de la revisión de valor controlado durante una actualización, la especificación de HPA de la revisión de valor controlado se revertirá a la especificación de HPA de la revisión estable.

Actualización de la versión de revisión

  • La información de disponibilidad de la versión de revisión del complemento istio se publica en las notas de la versión de AKS.
  • Las revisiones se implementan automáticamente para los pods de entrada e istiod como parte de estas versiones de AKS, que respetan la defaultventana de mantenimiento planeado configurada para el clúster.
  • El usuario debe iniciar revisiones en el proxy de Istio en sus cargas de trabajo reiniciando los pods para reinyección:

    • Compruebe la versión del proxy de Istio destinada a pods nuevos o reiniciados. Esta versión es la misma que la versión de los pods de entrada Istio e istiod después de ser revisados:

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Salida de ejemplo:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"

    • Compruebe la versión de la imagen de proxy de Istio para todos los pods de un espacio de nombres:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Ejemplo:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

    • Para desencadenar la reinjección, reinicie las cargas de trabajo. Por ejemplo:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Para comprobar que están ahora en las versiones más recientes, vuelva a comprobar la versión de la imagen de proxy de Istio para todos los pods del espacio de nombres:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Salida de ejemplo:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

Nota:

En caso de que se produzcan problemas durante las actualizaciones, consulte artículo sobre la solución de problemas de actualizaciones de revisiones de malla