Problema

Los entornos de producción en Azure dependen de imágenes de sistema, configuraciones de almacenamiento y políticas de acceso que pueden quedar obsoletas por decisiones de ciclo de vida de los servicios. Cuando Azure anuncia la retirada de una imagen de nodo, la introducción de un nuevo método de migración de SMB a Azure Files o la disponibilidad de SAS delegados vinculados a usuarios, los equipos de operaciones se enfrentan a tres retos recurrentes:

  1. Identificar qué recursos están afectados antes de que la fecha de retirada cause fallos inesperados.
  2. Planificar y ejecutar la migración sin interrumpir la carga de trabajo.
  3. Validar que las nuevas configuraciones cumplen con los requisitos de seguridad y rendimiento.

Estos patrones aparecen tanto en clústers de AKS como en soluciones de almacenamiento híbrido y en pipelines que generan SAS para clientes internos. Ignorar la alerta de ciclo de vida suele terminar en errores de despliegue, pérdida de acceso a datos o degradación del rendimiento.

Causa

Los retiros y cambios de funcionalidad en Azure provienen de tres fuentes típicas:

Fuente Qué provoca el problema Escenarios frecuentes
Retiro de imágenes de nodo (p. ej., Azure Linux con OS Guard en AKS) El agente del nodo deja de recibir actualizaciones y, tras la eliminación de la imagen, los nodos no pueden reiniciarse. Clústers que no han actualizado su nodepool a una imagen soportada.
Nuevas rutas de migración de datos (Agentless SMB → Azure Files) El proceso de copia depende de conectividad privada y de la configuración del Storage Mover. Si la red o los permisos no están alineados, la migración falla silenciosamente. Entornos on‑prem que usan SMB tradicional y quieren mover datos a la nube sin cambiar la topología de red.
Cambios en el modelo de autorización (User‑bound delegation SAS) Los tokens SAS generados sin vínculo a identidad de usuario pueden seguir funcionando después de una política de restricción, exponiendo datos. Scripts automatizados que crean SAS genéricos y no se actualizan a la nueva API.

En la práctica, la causa raíz suele ser falta de inventario actualizado y ausencia de pruebas de impacto antes de que la fecha límite sea inminente.

Solución

Una estrategia reutilizable se basa en tres fases: Inventario, Migración y Validación. Cada fase incluye pasos concretos que pueden aplicarse a cualquier recurso afectado por un retiro o una nueva característica.

1. Inventario automatizado

Utiliza Azure CLI o Azure PowerShell para generar una lista de los recursos que usan la entidad en cuestión.

# AKS node pools que usan la imagen retirada
az aks nodepool list \
  --resource-group MyRG \
  --cluster-name MyAKS \
  --query "[?osDiskImage.type=='AzureLinuxOSGuard'].{name:name, vmSize:vmSize}" \
  -o table

# Shares SMB on‑prem que todavía apuntan a una cuenta de Azure Files
az storage account list \
  --resource-group MyRG \
  --query "[?contains(name, 'fileshare')].{name:name, sku:sku.name}" \
  -o table

# SAS tokens creados sin user delegation
az storage container generate-sas \
  --account-name mystorage \
  --name mycontainer \
  --permissions rwdl \
  --expiry 2027-01-01 \
  --output tsv

Exporta los resultados a CSV para revisarlos con el equipo de desarrollo.

2. Plan de migración

a) AKS – Cambio de imagen de nodo

  1. Crear una imagen de reemplazo: Azure Container Linux es la alternativa recomendada.
  2. Probar en un clúster de staging: Usa az aks nodepool add con --node-image-only para validar que los pods se programan correctamente.
  3. Actualizar gradualmente: Cambia los nodepools en producción uno a uno, usando az aks nodepool upgrade con --max-surge para evitar downtime.

b) SMB → Azure Files (Agentless)

  1. Verificar conectividad privada: Asegúrate de que el Storage Mover tenga acceso a la red on‑prem mediante ExpressRoute o VPN.
  2. Crear un migrationJob: Usa la API de Storage Mover en modo preview.
  3. Ejecutar una prueba de 5 %: Selecciona un subconjunto de carpetas y valida integridad con md5sum.
  4. Escalar al 100 %: Una vez aprobada la prueba, lanza la migración completa.

c) User‑bound delegation SAS

  1. Actualizar los scripts: Cambia la generación de SAS a --auth-mode login y pasa el --delegated-key del usuario.
  2. Re‑emitir tokens: Invalida los SAS antiguos usando az storage account update --allow-shared-key-access false.
  3. Implementar rotación automática: Programa una Azure Function que renueve los SAS cada 30 días.

3. Validación post‑migración

Recurso Métrica de éxito Herramienta
AKS node pool Todos los pods en estado Running y sin eventos de ImagePullBackOff. kubectl get pods -A
Azure Files md5sum de archivos origen = destino, latencia < 5 ms. az storage file download + md5sum
SAS delegados Acceso concedido solo al usuario esperado, auditoría sin fallos. Azure Monitor logs, az storage blob show

Cuándo aplicar esta solución

Aplica cuando recibas una notificación de Azure sobre:

  • Retiro de imágenes de nodo, discos efímeros o componentes de AKS.
  • Lanzamiento de una nueva vía de migración de datos (p. ej., Storage Mover).
  • Cambios en la generación de SAS o en los modelos de autorización.

Señales típicas:

  • Alertas de ImageNotFound en eventos de nodo.
  • Fallos de copia de archivos con códigos de error 0x80070005 (acceso denegado).
  • Logs de auditoría que muestran SAS sin userObjectId.

No aplica si tu arquitectura está completamente desacoplada de los recursos afectados (p. ej., usas solo Azure SQL sin dependencias de storage) o si ya migraste a versiones soportadas en la última revisión de infraestructura.

Código

# Paso 1: Listar node pools con la imagen retirada
az aks nodepool list \
  --resource-group MyRG \
  --cluster-name MyAKS \
  --query "[?osDiskImage.type=='AzureLinuxOSGuard'].name" \
  -o tsv > pools_to_update.txt

# Paso 2: Actualizar cada pool al nuevo OS
while read pool; do
  az aks nodepool upgrade \
    --resource-group MyRG \
    --cluster-name MyAKS \
    --name $pool \
    --node-image-only \
    --max-surge 1
done < pools_to_update.txt

# Paso 3: Generar SAS delegada para un contenedor
az storage container generate-sas \
  --account-name mystorage \
  --name mycontainer \
  --permissions rwdl \
  --expiry $(date -d "+30 days" -I) \
  --auth-mode login \
  --delegated-key $(az ad user show --id [email protected] --query objectId -o tsv) \
  -o tsv

Verificación

  1. AKS

    • Ejecuta kubectl get nodes -o wide y confirma que la columna OS-Image muestra AzureContainerLinux.
    • Revisa los eventos con kubectl describe node <node>; no debe haber mensajes de FailedMount relacionados con la imagen antigua.

  2. Azure Files

    • Descarga un archivo de prueba desde la cuenta de destino y compara su hash con el origen.
    • Usa Azure Monitor para observar la métrica SuccessfulFileTransfers del Storage Mover; debería estar por encima del 99 %.

  3. SAS delegada

    • Intenta acceder al contenedor con una cuenta distinta a la delegada; la operación debe fallar con AuthorizationFailure.
    • Consulta los logs de Azure Activity para confirmar que el token incluye la propiedad signedOid.

Notas adicionales

  • Plan de rollback: Siempre conserva una copia de la configuración original (por ejemplo, exporta los nodepool a JSON) antes de iniciar la actualización. Si algo falla, puedes volver a crear el pool con la imagen anterior mientras se resuelve el problema.
  • Impacto en costos: La migración a Azure Container Linux puede requerir un redimensionamiento de VM para mantener el mismo nivel de rendimiento, especialmente si habilitas el Ephemeral OS Disk con full caching. Revisa la tabla de precios antes de escalar.
  • Automatización: Integra los scripts de inventario y actualización en tu pipeline de CI/CD usando Azure DevOps o GitHub Actions. Un job típico incluye: az account set, az aks get-credentials, y los pasos de upgrade descritos arriba.
  • Seguridad: Cuando habilites TLS/SSL en Azure Functions Flex Consumption, verifica que el certificado está asociado al dominio correcto mediante az functionapp config ssl bind. Un certificado mal enlazado provocará errores 502 en producción.
  • Monitorización continua: Configura alertas en Azure Monitor para que te avisen cuando una nueva versión de imagen sea marcada como Deprecated. Esto te da tiempo suficiente para planificar la próxima migración sin sorpresas.