Migrar a Azure Kubernetes Service (AKS)

Artículo
10/31/2024

Para ayudarle a planear y ejecutar una migración correcta a Azure Kubernetes Service (AKS), en esta guía se proporcionan detalles para la configuración de AKS que se recomienda actualmente. Aunque en este artículo no se tratan todos los escenarios, se incluyen vínculos a información más detallada para planear una migración correcta.

En este artículo se proporciona un resumen de los detalles de la migración para:

Incluir aplicaciones en contenedores a través de Azure Migrate
AKS con Azure Load Balancer (Estándar) y Virtual Machine Scale Sets
Servicios de Azure asociados existentes
Garantizar cuotas válidas
Alta disponibilidad y continuidad empresarial
Consideraciones sobre las aplicaciones sin estado
Consideraciones sobre las aplicaciones con estado
Implementación de la configuración del clúster

Nota

Dependiendo del escenario, las siguientes herramientas de código abierto pueden ayudar con la migración:ón:

Velero (requiere Kubernetes 1.7+)
Extensión de la CLI de Azure Kube

Antes de empezar

Asegúrese de que la versión de Kubernetes de destino se encuentre en la ventana admitida para AKS. Es posible que las versiones anteriores no estén dentro del intervalo admitido y requieran una actualización de versión para la compatibilidad con AKS. Para más información, consulte Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS).
Si va a migrar a una versión más reciente de Kubernetes, consulte Versión de Kubernetes y directiva de soporte de asimetría de versiones.

Una práctica importante que debe incluir como parte del proceso de migración es recordar seguir los patrones de prueba e implementación usados habitualmente. Probar la aplicación antes de la implementación es un paso importante para garantizar su calidad, funcionalidad y compatibilidad con el entorno de destino. Puede ayudarle a identificar y corregir los errores o problemas que podrían afectar al rendimiento, la seguridad o la facilidad de uso de la aplicación o la infraestructura subyacente.

Use Azure Migrate para migrar sus aplicaciones a AKS

Azure Migrate ofrece una plataforma unificada para evaluar y migrar a servidores, infraestructura, aplicaciones y datos locales de Azure. En el caso de AKS, puede usar Azure Migrate para las tareas siguientes:

AKS con Standard Load Balancer y Virtual Machine Scale Sets

AKS es un servicio administrado que ofrece funcionalidades únicas con una sobrecarga de administración menor. Como AKS es un servicio administrado, debe seleccionar un conjunto de regiones que admita AKS. Quizá deba modificar las aplicaciones existentes para mantenerlas en buen estado en el plano de control administrado por AKS durante la transición del clúster existente a AKS.

Se recomienda el uso de clústeres de AKS respaldados por Virtual Machine Scale Sets y Load Balancer (Estándar) para garantizar las siguientes características:

Varios grupos de nodos
Zonas de disponibilidad
Intervalos IP autorizados
Escalador automático de clústeres
Azure Policy para AKS
Otras características nuevas que vayan saliendo.

Los clústeres de AKS respaldados por conjuntos de disponibilidad de la máquina virtual (VM) no tienen compatibilidad con muchas de estas características.

Creación de un clúster de AKS con Load Balancer (Estándar) y Virtual Machine Scale Sets

CLI de Azure
Terraform

En el ejemplo siguiente se crea un clúster de AKS con un único grupo de nodos respaldado por un Virtual Machine Scale Set. Habilita la escalabilidad automática del clúster en el grupo de nodos para el clúster y establece un mínimo de uno y un máximo de tres nodos.

Cree un grupo de recursos con el comando az group create.

az group create --name myResourceGroup --location eastus

Cree un clúster de AKS con el comando az aks create.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 1 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

El código siguiente crea un grupo de recursos y un clúster de Kubernetes en Azure, con el escalado automático habilitado y una configuración de red específica, mediante Terraform.

Nota:

El código de ejemplo de este artículo se encuentra en el repositorio de GitHub de Azure Terraform. Puedes ver el archivo de registro que contiene los resultados de las pruebas de las versiones actuales y anteriores de Terraform.

Consulte más artículos y código de ejemplo sobre el uso Terraform para administrar recursos de Azure.

Cree un directorio en el que probar y ejecutar el código de ejemplo de Terraform y conviértalo en el directorio actual.

Cree un archivo llamado main.tf e inserte el siguiente código:

resource "random_pet" "rg_name" {
  prefix = var.resource_group_name_prefix
}

resource "azurerm_resource_group" "rg" {
  location = var.resource_group_location
  name     = random_pet.rg_name.id
}

resource "random_string" "aks_cluster_name" {
  length  = 12
  special = false
}

resource "azurerm_kubernetes_cluster" "aks_cluster" {
  name                = random_string.aks_cluster_name.result
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  dns_prefix          = "myakscluster"

  default_node_pool {
    type                = "VirtualMachineScaleSets"
    name                = "default"
    node_count          = 1
    max_count           = 3
    min_count           = 1
    vm_size             = "Standard_DS2_v2"
    enable_auto_scaling = true
    upgrade_settings {
      drain_timeout_in_minutes      = 90
      max_surge                     = "10%"
      node_soak_duration_in_minutes = 0
    }
  }

  network_profile {
    network_plugin    = "azure"
    load_balancer_sku = "standard"
  }

  identity {
    type = "SystemAssigned"
  }

  tags = {
    Environment = "Production"
  }
}

Cree un archivo llamado outputs.tf e inserte el siguiente código:

output "resource_group_name" {
  value = azurerm_resource_group.rg.name
}

output "aks_cluster_name" {
  value = azurerm_kubernetes_cluster.aks_cluster.name
}

Cree un archivo llamado providers.tf e inserte el siguiente código:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>3.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~>3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Cree un archivo llamado variables.tf e inserte el siguiente código:

variable "resource_group_location" {
  type        = string
  default     = "eastus"
  description = "Location of the resource group."
}

variable "resource_group_name_prefix" {
  type        = string
  default     = "rg"
  description = "Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription."
}

Inicialice Terraform.

Para inicializar la implementación de Terraform, ejecute terraform init. Este comando descarga el proveedor de Azure necesario para administrar los recursos de Azure.
```
terraform init -upgrade
```
Puntos clave:
- El parámetro -upgrade actualiza los complementos de proveedor necesarios a la versión más reciente que cumpla con las restricciones de versión de la configuración.
Creación de un plan de ejecución de Terraform.

Ejecute terraform plan para crear un plan de ejecución.
```
terraform plan -out main.tfplan
```
Puntos clave:
- El comando terraform plan crea un plan de ejecución, pero no lo ejecuta. En su lugar, determina qué acciones son necesarias para crear la configuración especificada en los archivos de configuración. Este patrón le permite comprobar si el plan de ejecución coincide con sus expectativas antes de realizar cambios en los recursos reales.
- El parámetro -out opcional permite especificar un archivo de salida para el plan. El uso del parámetro -out garantiza que el plan que ha revisado es exactamente lo que se aplica.
Aplique un plan de ejecución de Terraform.

Ejecute terraform apply para aplicar el plan de ejecución a su infraestructura en la nube.
```
terraform apply main.tfplan
```
Puntos clave:
- El comando terraform apply de ejemplo asume que ejecutó terraform plan -out main.tfplan previamente.
- Si especificó un nombre de archivo diferente para el parámetro -out, use ese mismo nombre de archivo en la llamada a terraform apply.
- Si no ha utilizado el parámetro -out, llame a terraform apply sin ningún parámetro.

Servicios de Azure asociados existentes

Al migrar clústeres quizá haya asociado servicios externos de Azure. Aunque los siguientes servicios no requieren la recreación de los recursos, requieren la actualización de las conexiones de los clústeres anteriores a los nuevos para mantener la funcionalidad:

Azure Container Registry
Azure Log Analytics
Azure Application Insights
Administrador de tráfico de Azure
Cuenta de Azure Storage
Bases de datos externas

Garantizar cuotas válidas

Dado que otras máquinas virtuales se implementan en su suscripción durante la migración, debe comprobar que los límites y las cuotas sean suficientes para estos recursos. Si es necesario, solicite un aumento de la cuota de CPU virtual.

Es posible que tenga que solicitar un aumento de las cuotas de red para asegurarse de no agotar las direcciones IP. Para más información, consulte Redes e intervalos IP para AKS.

Para más información, consulte Azure subscription and service limits (Límites de suscripción y servicio de Azure). Para comprobar las cuotas actuales, en Azure Portal, vaya a la hoja de suscripciones, seleccione la suscripción y seleccione Uso y cuotas.

Alta disponibilidad y continuidad empresarial

Si la aplicación no puede controlar el tiempo de inactividad, debe seguir los procedimientos recomendados para los escenarios de migración de alta disponibilidad. Más información sobre los Procedimientos recomendados para la planeación de la continuidad empresarial compleja, la recuperación ante desastres y la maximización del tiempo de actividad en Azure Kubernetes Service (AKS).

Normalmente, las aplicaciones complejas se migran en varias veces en lugar de en una sola vez, por lo que los entornos antiguos y los nuevos quizá deban comunicarse a través de la red. Es posible que aplicaciones que anteriormente usaban servicios ClusterIP para comunicarse deban exponerse como tipo LoadBalancer y protegerse adecuadamente.

Para completar la migración, quiere dirigir a los clientes a los nuevos servicios que se ejecutan en AKS. Se recomienda redirigir el tráfico mediante la actualización de DNS para que apunte al equilibrador de carga que se encuentra frente al clúster de AKS.

Azure Traffic Manager puede dirigir a los clientes a la instancia de la aplicación y los clústeres de Kubernetes deseados. Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS que puede distribuir el tráfico de red entre regiones. Para conseguir los máximos niveles de rendimiento y redundancia, dirija todo el tráfico de la aplicación con Traffic Manager antes de que pase al clúster de AKS.

En una implementación de varios clústeres, los clientes deben conectarse a un nombre DNS de Traffic Manager que apunte a los servicios en cada clúster de AKS. Para definir estos servicios, use los puntos de conexión de Traffic Manager. Cada punto de conexión es la dirección IP del equilibrador de carga del servicio. Use esta configuración para dirigir el tráfico de red desde el punto de conexión de Traffic Manager de una región al punto de conexión de otra.

AKS con Traffic Manager

Azure Front Door es otra opción para enrutar el tráfico de los clústeres de AKS. Con Azure Front Door podrá definir, administrar y supervisar el enrutamiento global para el tráfico web mediante la optimización para obtener mejor rendimiento y conmutación por error global instantánea para la alta disponibilidad.

Consideraciones sobre las aplicaciones sin estado

La migración de aplicaciones sin estado implica los pasos siguientes:

Aplique las definiciones de recurso (YAML o Helm) al nuevo clúster.
Asegúrese de que todo funciona según lo previsto.
Redirija el tráfico para activar el nuevo clúster.

Consideraciones sobre las aplicaciones con estado

Planee meticulosamente la migración de aplicaciones con estado para evitar la pérdida de datos o tiempos de inactividad inesperados.

Si usa Azure Files, puede montar el recurso compartido de archivos como un volumen en el nuevo clúster. Consulte Montaje de instancias estáticas de Azure Files como volumen.
Si usa Azure Managed Disks, solo podrá montar el disco si no está conectado a ninguna máquina virtual. Consulte Montaje de disco estático de Azure como volumen.
Si ninguno de estos métodos funciona, puede usar las opciones de copia de seguridad y restauración. Consulte Velero en Azure.

Archivos de Azure

A diferencia de los discos, Azure Files puede montarse simultáneamente en varios hosts. En el clúster de AKS, Azure y Kubernetes no impiden crear un pod que el clúster de AKS siga usando. Para evitar la pérdida de datos y un comportamiento inesperado, asegúrese de que los clústeres no escriben en los mismos archivos simultáneamente.

Si la aplicación puede hospedar varias réplicas que apunten al mismo recurso compartido de archivos, siga los pasos de la migración sin estado e implemente las definiciones de YAML en el nuevo clúster.

Si no es así, un posible enfoque de migración implica los pasos siguientes:

Compruebe que la aplicación funciona correctamente.
Apunte el tráfico en directo al nuevo clúster de AKS.
Desconecte el clúster anterior.

Si quiere comenzar con un recurso compartido vacío y luego realizar una copia de los datos de origen, puede usar el comando az storage file copy para migrar los datos.

Migración de volúmenes persistentes

Si migra volúmenes persistentes existentes a AKS, generalmente seguirá estos pasos:

Desactivar las escrituras en la aplicación.
- Este paso es opcional y requiere tiempo de inactividad.
Tomar instantáneas de los discos.
Crear discos administrados nuevos a partir de las instantáneas.
Crear volúmenes persistentes en AKS.
Actualizar las especificaciones de pod para usar volúmenes existentes en lugar de PersistentVolumeClaims (aprovisionamiento estático).
Implemente la aplicación en AKS.
Compruebe que la aplicación funciona correctamente.
Apunte el tráfico en directo al nuevo clúster de AKS.

Importante

Si decide no desactivar las escrituras, debe replicar los datos en la nueva implementación. En caso contrario, perderá los datos que se escriban después de tomar las instantáneas de disco.

Las siguientes herramientas de código abierto pueden ayudarle a crear discos administrados y a migrar volúmenes entre clústeres de Kubernetes:

La extensión de copia de disco de la CLI de Azure copia y convierte los discos entre grupos de recursos y regiones de Azure.
La extensión de la CLI de Azure Kube enumera los volúmenes de ACS Kubernetes y los migra a un clúster de AKS.

Implementación de la configuración del clúster

Se recomienda usar la canalización existente de integración continua y entrega continua para implementar una configuración válida conocida en AKS. Puede usar Azure Pipelines para compilar e implementar las aplicaciones en AKS. Clone las tareas de implementación existentes y asegúrese de que kubeconfig apunta al nuevo clúster de AKS.

Si no es posible, exporte las definiciones de recursos desde el clúster de Kubernetes existente y luego aplíquelas a AKS. Puede usar kubectl para exportar objetos. Por ejemplo:

kubectl get deployment -o yaml > deployments.yaml

Asegúrese de examinar la salida y de quitar los campos de datos activos innecesarios.

Movimiento de recursos existentes a otra región

Puede que quiera trasladar el clúster de AKS a otra región compatible con AKS. Se recomienda crear un nuevo clúster en la otra región e implementar los recursos y las aplicaciones en el nuevo clúster.

Si tiene servicios en ejecución en el clúster de AKS, debe instalar y configurar esos servicios en el clúster en la nueva región.