Migración desde conjuntos de disponibilidad en Azure Kubernetes Service (AKS)

En este artículo se detalla cómo Azure Kubernetes Service (AKS) está eliminando gradualmente la compatibilidad con los conjuntos de disponibilidad de máquinas virtuales (VMAS) en favor de máquinas virtuales (VM). Se recomienda usar grupos de nodos de máquina virtual para máquinas virtuales optimizadas para AKS.

Grupos de nodos de máquina virtual:

• Permitir que las instancias de máquina virtual se administren, configuren y actualicen centralmente.
• Permita un aumento o disminución del número de instancias de máquina virtual en respuesta a la demanda o a una programación definida.
• Permite controles de nivel de nodo único y combinación de la misma familia de nodos de tamaño diferente, lo que aumenta la flexibilidad y mejora la coherencia.

Introducción a los conjuntos de disponibilidad

Los conjuntos de disponibilidad son agrupaciones lógicas de máquinas virtuales que reducen la posibilidad de errores correlacionados que reducen las máquinas virtuales relacionadas al mismo tiempo. Los conjuntos de disponibilidad colocan máquinas virtuales en distintos dominios de error para mejorar la confiabilidad.

Fases fuera de los conjuntos de disponibilidad

A partir de 2019, ya no se agregan otras características a los conjuntos de disponibilidad en AKS. Las características introducidas desde 2019, como la copia de seguridad de AKS, no se admiten en conjuntos de disponibilidad.

Migración de conjuntos de disponibilidad a grupos de nodos de Virtual Machines

Ahora hay una manera de usar un script para migrar el clúster de AKS desde el uso de conjuntos de disponibilidad a grupos de nodos de Virtual Machines. Este script también actualiza automáticamente los equilibradores de carga de nivel básico del clúster a nivel estándar.

Antes de empezar

Requisitos

• La versión mínima de Kubernetes para este script es la 1.27. Si necesita actualizar el clúster de AKS, consulte Actualización de un clúster de AKS.
• Necesita la versión 2.76.0 la CLI de Azure instalada.
• Si el clúster ejecuta el servicio de administración de claves con el almacén de claves privado, el servicio de administración de claves debe deshabilitarse durante toda la migración.
• Si el clúster usa cualquiera ValidatingAdmissionWebhooks o MutatingAdmissionWebhooks, estos webhooks deben deshabilitarse antes de la migración. Los webhooks predeterminados del plano de control no deben deshabilitarse. Por ejemplo aks-node-mutating-webhook, , webhook-admission-controllery aks-node-validating-webhook.

Preparación para la migración

• Cree un plan de migración para el tiempo de inactividad planeado.
• Una vez iniciada la migración, no se permite la reversión.

Ejecución del script de migración para la migración del conjunto de disponibilidad

En los comandos siguientes, reemplace <myResourceGroup> y <myAKSCluster> por el nombre del grupo de recursos y el nombre del clúster de AKS.

1. El comando siguiente inicia un script para migrar un clúster de mediante conjuntos de disponibilidad a grupos de nodos de Máquinas virtuales mediante el az aks update comando y estableciendo --migrate-vmas-to-vms. Este script también actualiza el Load Balancer básico y la IP básica a Load Balancer estándar e IP estándar, si procede.

   az aks update \
     --name <myAKSCluster> \
     --resource-group <myResourceGroup> \
     --migrate-vmas-to-vms \
   

2. Compruebe que la migración se realizó correctamente mediante el az aks show comando. La salida del comando muestra los detalles del clúster.

   az aks show \
     --name <myAKSCluster> \
     --resource-group <myResourceGroup>
   

   Una migración exitosa se puede verificar cuando los detalles del clúster, mediante el comando az aks show, incluyen un type establecido en VirtualMachines y loadbalancerSku establecido en Standard.

     "type": "VirtualMachines"
     "loadBalancerSku": "standard",
   

3. Compruebe que todos los pods y servicios se ejecutan correctamente mediante los comandos kubectl get pods y kubectl get svc:

   kubectl get svc -A \
   kubectl get pods -A
   

4. Puede confirmar las nuevas direcciones IP asociadas a las reglas de salida enumerando las direcciones IP de salida. Este paso se realiza mediante la confirmación de los identificadores de recursos de las direcciones IP y, a continuación, se enumeran las direcciones IP.

   Use el comando siguiente para obtener el identificador de recurso de las direcciones IP de salida:

   # Get the outbound IP Resource ID
   az aks show \
     --resource-group <myResourceGroup> \
     --name <myAKSCluster> \
     --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id
   

   Use el siguiente comando para obtener cada dirección IP del identificador de recurso y reemplazar por <IPResourceID> el identificador de recurso del comando anterior:

   # get the new IP for each IP Resource ID
   az network public-ip show --ids <IPResourceID> --query ipAddress -o tsv
   

Contenido relacionado

• Más información sobre los grupos de nodos de máquina virtual
• Actualización desde Load Balancer básico en Azure Kubernetes Service