Share via

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.

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 asm-1-18 revisión a asm-1-19. Los pasos son los mismos para todas las actualizaciones secundarias.

  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-systemantes 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-18 de revisión a asm-1-19 mediante az aks mesh upgrade start:

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

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

  4. Compruebe que existen pods del plano de control correspondientes a asm-1-18 y asm-1-19:

    • Compruebe istiod pods:

      kubectl get pods -n aks-istio-system

      Ejemplo:

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

    • 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-18-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-18-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-19-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.

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

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

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

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

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

  7. 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:

    • 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

    • 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:

        kubectl label namespace default istio.io/rev=asm-1-18 --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

  8. 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.

Nota:

Cambiar manualmente el etiquetado de espacios de nombres al moverlos a una nueva revisión puede ser tedioso y propenso a errores. Etiquetas de revisión solucionar este problema. Las etiquetas de revisión son identificadores estables que apuntan a revisiones y se pueden usar para evitar volver a etiquetar los espacios de nombres. En lugar de volver a etiquetar el espacio de nombres, un operador de malla simplemente puede cambiar la etiqueta para que apunte a una nueva revisión. Todos los espacios de nombres etiquetados con esa etiqueta se actualizarán al mismo tiempo. Sin embargo, tenga en cuenta que todavía necesita reiniciar las cargas de trabajo para asegurarse de que se inserta la versión correcta de istio-proxy sidecars.

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. Pero 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 no cambiará 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.

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 pods de entrada y 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.18.2-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless