Cursos
Módulo
Aplique las actualizaciones y revisiones de la versión más reciente a los clústeres de Azure Kubernetes Service.
Este explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
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.
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.
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.
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í.
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.
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:
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
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
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.
Compruebe que existen pods del plano de control correspondientes a asm-1-22
y asm-1-23
:
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
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.
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:
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.
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.
Reinicie individualmente cada una de las cargas de trabajo de sus aplicaciones. Por ejemplo:
kubectl rollout restart deployment <deployment name> -n <deployment namespace>
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: 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
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.
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.
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:
default
ventana de mantenimiento planeado configurada para el clúster.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
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Cursos
Módulo
Aplique las actualizaciones y revisiones de la versión más reciente a los clústeres de Azure Kubernetes Service.