Actualizar desde Basic Load Balancer en Azure Kubernetes Service (AKS)

En este artículo, aprenderá a actualizar las instancias básicas de Load Balancer a Standard Load Balancer en Azure Kubernetes Services (AKS). Se recomienda usar Standard Load Balancer para todas las instancias de producción. Proporciona muchas diferencias clave a su infraestructura. Para obtener instrucciones sobre cómo actualizar de Load Balancer básico a Standard Load Balancer fuera de AKS, consulte las instrucciones oficiales para la actualización básica de Load Balancer.

Importante

A partir del 30 de septiembre de 2025, Azure Kubernetes Service (AKS) ya no admite Basic Load Balancer. Para evitar posibles interrupciones del servicio, se recomienda usar Standard Load Balancer para nuevas implementaciones y actualizar las implementaciones existentes a Standard Load Balancer. Para obtener más información sobre esta retirada, consulte la Incidencia sobre retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.

Note

En el caso de los clústeres que usan los conjuntos de disponibilidad y el equilibrador de carga básico, hay un comando independiente az aks update que debe ejecutar para realizar ambas migraciones a la vez (conjuntos de disponibilidad en grupos de nodos de máquina virtual y Equilibrador de carga básico en Standard Load Balancer). Para conocer los pasos para realizar esta migración, consulte la guía de migración de conjuntos de disponibilidad .

Antes de empezar

Antes de comenzar la migración, revise la siguiente información:

  • El tiempo de inactividad se produce durante la migración. Planee el tiempo de inactividad en consecuencia.
  • Una vez que se inicia la migración, no se permite la reversión.
  • Este proceso también migra la dirección IP básica a una dirección IP estándar, al tiempo que mantiene las direcciones IP de entrada asociadas al equilibrador de carga de igual manera. Se crean nuevas direcciones IP públicas y se asocian a las reglas de salida de Standard Load Balancer para atender el tráfico de salida del clúster.

Prerrequisitos

El clúster debe cumplir los siguientes requisitos previos para poder realizar la migración:

  • 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 tener Instalada la CLI de Azure. La versión mínima que necesita es 2.76.0.
  • Si el clúster ejecuta key Management Service con el almacén de claves privado, debe deshabilitar el servicio de administración de claves antes de realizar la migración. Para obtener más información, consulte Desactivar KMS.
  • Debe deshabilitar cualquiera ValidatingAdmissionWebhooks o MutatingAdmissionWebhooks antes de realizar la migración.

Actualización de Load Balancer Básico a Load Balancer Estándar

  1. Actualice su equilibrador de carga básico a un equilibrador de carga estándar mediante el comando az aks update con la bandera --load-balancer-sku establecida en Standard.

    az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku=Standard

  2. Compruebe que la migración se realizó correctamente mediante el az aks show comando .

    az aks show \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP

    En la salida, confirme que el tipo load-balancer está establecido a Standard.

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

    kubectl get svc -A
kubectl get pods -A

Confirmación de nuevas direcciones IP salientes

Para confirmar las nuevas direcciones IP asociadas a las reglas de salida, verifique los identificadores de los recursos de las direcciones IP y, a continuación, enumere las direcciones IP.

  1. Obtenga el identificador de recurso de las direcciones IP de salida mediante el az aks show comando .

    az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id

  2. Obtenga la nueva dirección IP para cada identificador de recurso mediante el az network public-ip show comando .

    az network public-ip show --ids $IP_RESOURCE_ID --query ipAddress -o tsv

Preguntas más frecuentes

¿Por qué obtengo Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'. al crear un nuevo clúster de AKS o actualizarlo?

La SKU básica de Load Balancer de Microsoft ha quedado obsoleta para ciertas operaciones de AKS y la creación ahora está bloqueada en algunas regiones.

Para resolver este problema, asegúrese de especificar --load-balancer-sku standard al crear un nuevo clúster. Por ejemplo:

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku standard

¿Por qué no puedo cambiar mi Load Balancer Básico a Standard Load Balancer local?

La SKU de Load Balancer es inmutable después de la creación en AKS, ya que es un recurso administrado propiedad del clúster.

Puede resolverlo con una de las siguientes opciones:

¿Por qué no puedo encontrar mi dirección IP pública después de actualizar de Basic a Standard Load Balancer?

El objeto Load Balancer perdió la referencia al recurso de dirección IP pública durante la migración. Esto puede ocurrir si la dirección IP estaba vinculada a Load Balancer de SKU básica y no se volvió a enlazar.

Para solucionar este problema:

  1. Asegúrese de que la nueva dirección IP pública estándar existe en el grupo de recursos correcto.

  2. Vuelva a asociarlo en el manifiesto de servicio mediante la siguiente configuración:

    annotations:
  service.beta.kubernetes.io/azure-load-balancer-ipv4: <your-ip>

Al migrar el equilibrador de carga en un clúster privado sin una dirección IP pública, ¿por qué se sigue creando una dirección IP pública durante la migración?

Si outboundType es LoadBalancer, AKS aprovisiona automáticamente una dirección IP pública (PIP), independientemente de la SKU de Load Balancer.

Para solucionar este problema:

  1. Cambie outboundType a userDefinedRouting para un clúster totalmente privado.
  2. Asegúrese de que el enrutamiento de salida personalizado está configurado a través de Azure Firewall o NVA.

¿Por qué se produce un error en la migración en la configuración interna de Load Balancer?

Las herramientas de migración actuales no admiten equilibradores de carga internos de red virtual (VNet) de Básico a Estándar en situ.

Para solucionar este problema:

  1. Vuelva a crear el clúster en la misma red virtual con Standard Load Balancer.
  2. Implemente cargas de trabajo y valide la resolución de nombres interna.

Mis grupos de nodos usan conjuntos de disponibilidad. ¿Todavía tengo problemas incluso después de la migración de Load Balancer?

Sí. Si los grupos de nodos usan conjuntos de disponibilidad, también están en desuso en AKS después del 30 de septiembre de 2025.

Para solucionar este problema:

  1. En el caso de los clústeres que usan los conjuntos de disponibilidad y el equilibrador de carga básico, hay un comando independiente az aks update que debe ejecutar para realizar ambas migraciones a la vez (conjuntos de disponibilidad en grupos de nodos de máquina virtual y Equilibrador de carga básico en Standard Load Balancer). Para conocer los pasos para realizar esta migración, consulte la guía de migración de conjuntos de disponibilidad .
  2. Después de la actualización, la CLI de Azure o las API REST deben usarse para realizar operaciones CRUD o administrar el grupo. Compruebe las limitaciones.

¿Es necesario eliminar webhooks predeterminados antes de actualizar?

No. Si no hay otros ValidatingAdmissionWebhooks o MutatingAdmissionWebhooks presentes en el cluster, los webhooks predeterminados del plano de control son adecuados para ser conservados durante la migración.

Los webhooks predeterminados incluyen:

  • aks-node-mutating-webhook
  • webhook-admission-controller
  • node-validating-webhook

¿Qué acceso es necesario para ejecutar los comandos de migración?

Para ejecutar los comandos de migración, necesita:

  • Rol Colaborador o Propietario en la suscripción o en el grupo de recursos.
  • La versión de la CLI de Azure debe ser ≥ 2.72.0.
  • La versión preliminar de la extensión de AKS debe ser ≥ 0.5.170.

¿Cómo puedo ver si el cifrado del Servicio de administración de claves (KMS) está deshabilitado?

Puede comprobar si el cifrado de KMS está habilitado en el clúster de AKS mediante el az aks list comando .

az aks list --query "[].{Name:name, KmsEnabled:securityProfile.azureKeyVaultKms.enabled, KeyId:securityProfile.azureKeyVaultKms.keyId}"

  • Si la salida muestra "KmsEnabled": null, significa que el cifrado de KMS no está habilitado para ese clúster y puede omitir los pasos para deshabilitarlo. Por ejemplo:

      {

    "KeyId": null,

    "KmsEnabled": null,

    "Name": "myAKSCluster"

  },
...

  • Si KMS está habilitado y desea deshabilitarlo, consulte Desactivar el cifrado de KMS.

Pasos siguientes

Para más información sobre las redes de AKS, consulte Conceptos de redes para Azure Kubernetes Service (AKS).

  • Last updated on