Migrar a Azure Kubernetes Service (AKS)
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
- 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.
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:
- Inclusión de aplicaciones ASP.NET en contenedores y migración a AKS.
- Inclusión de aplicaciones web de Java en contenedores y migración a AKS.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: