Compartir a través de

Reubicación de un clúster de Azure Kubernetes Service (AKS) en otra región

  • Artículo

En este artículo se describen las instrucciones para reubicar un clúster de Azure Kubernetes Service en otra región.

Hay varias razones por las que sería conveniente mover los recursos de Azure existentes de una región a otra. Quizá también desea:

  • Aproveche las ventajas de una nueva región de Azure.
  • Implemente características o servicios que solo están disponibles en regiones determinadas.
  • Cumpla requisitos internos de gobernanza y directivas.
  • Alineación con fusiones y adquisiciones de la empresa
  • Cumplir los requisitos de planeamiento de capacidad.

Nota:

Los clientes con ciclos de versión rápidos suelen aprovechar las canalizaciones de CI/CD. En esos casos, podría considerar la posibilidad de modificar las canalizaciones de compilación y versión en lugar de volver a implementar los clústeres de AKS en la región de destino.

Requisitos previos

Antes de comenzar la fase de planeamiento de reubicación, revise primero los siguientes requisitos previos:

  • Asegúrese de que la región de destino tiene suficiente capacidad (SKU de máquina virtual) para dar cabida a los nuevos nodos de clúster.

  • Compruebe que tiene permisos de creación de recursos en la suscripción de destino. Compruebe que Azure Policy no restringe las regiones a las que se puede implementar AKS.

  • (Opcional) Recopile las plantillas o scripts de infraestructura como código (IaC) con los que aprovisionó el clúster de AKS de origen.

  • Recopile los manifiestos de Kubernetes para volver a crear la carga de trabajo de la aplicación en el clúster de destino.

    Sugerencia

    Evalúe un enfoque de GitOps para la implementación de cargas de trabajo en la que los manifiestos de configuración de Kubernetes se almacenan en un repositorio de Git y se aplican automáticamente mediante un operador de GitOps que se ejecuta en el clúster, como Flux. Un enfoque de GitOps hace que las cargas de trabajo se vuelvan a implementar en distintos clústeres tan simples como instalar el controlador de GitOps y apuntarlas al repositorio.

  • Revise la implementación de entrada del clúster.

  • Documente los cambios de DNS necesarios para apuntar un dominio público al punto de conexión de entrada del clúster.

  • Revise si el clúster almacena datos de estado, como los volúmenes persistentes, que debe migrar al clúster de destino.

  • Documente la distribución y administración de certificados TLS públicos.

  • Capture las direcciones IP definidas en la lista de permitidos del servicio de API de AKS.

  • Comprender todos los recursos dependientes. Algunos de los recursos podrían ser:

    • Colas, buses de mensajes, motores de caché
    • Azure Key Vault
    • Identidad administrada
    • Configuración de redes virtuales. Definición de tamaños de subred suficientes para permitir el crecimiento de ip de contenedor si se usa el modelo de redes avanzadas de Azure
    • Dirección IP pública
    • Puerta de enlace de red virtual (VPN). Si se requiere comunicación de sitio a sitio en un entorno local de la región de destino, se debe crear un VNG en la red virtual de destino.
    • Punto de conexión privado de Azure. Los recursos de PaaS de Azure que usan puntos de conexión de vínculo privado deben revisarse y se deben revisar las nuevas instancias de private link creadas en la región de destino, como ACR, Azure SQL DB, KeyVault, etc.
    • Introducción a Puerta de enlace de aplicaciones
    • Azure DNS
    • Azure Firewall
    • Azure Monitor (Container Insights)
    • Azure Container Registry puede replicar imágenes entre instancias de ACR. Para obtener un rendimiento óptimo al extraer imágenes, el registro debe existir en la región de destino.

      Nota:

      Si usa Azure Container Registry para autenticarse en el registro de contenedor, la nueva identidad administrada del clúster de AKS puede ser el rol RBAC concedido AcrPull.

    • Azure Managed Disks
    • Azure Files

Preparación

Antes de comenzar el proceso de reubicación del clúster, asegúrese de completar los siguientes preparativos:

  1. Para dar cabida a los nodos y pods del clúster de AKS, si usa redes de Azure CNI, implemente la red virtual con muchas subredes de tamaño suficiente.

  2. Si usa Azure Key Vault, implemente Key Vault.

  3. Asegúrese de que los certificados de entrada TLS pertinentes están disponibles para la implementación, idealmente en un almacén seguro, como Azure Key Vault.

  4. Implemente un registro de contenedores. Sincronice automáticamente las imágenes del Registro de origen o recompile e inserte nuevas imágenes en el registro de destino mediante una canalización o script de CI/CD.

  5. Crear un área de trabajo Azure Monitor.

  6. (Opcional) La implementación de Azure Application Gateway para controlar el tráfico de entrada del controlador de entrada de Application Gateway (AGIC) puede integrarse estrechamente con el clúster

  7. Implemente los orígenes de datos necesarios para la carga de trabajo del clúster y restaure o sincronice los datos de origen.

  8. Ejecute artefactos iaC existentes definidos en una canalización de CI/CD que se usaron para implementar el clúster de origen y los servicios de los que depende. Cambie los parámetros de entrada de código o plantilla para volver a implementar en otro grupo de recursos y región de Azure.

Volver a implementar

Para implementar el clúster de AKS sin ninguna migración de datos, siga estos pasos:

  1. Para crear el entorno de destino en Azure, ejecute manualmente los artefactos iaC existentes en una estación de trabajo local.

  2. Si no hay recursos de IaC existentes, la configuración del clúster actual se puede exportar como una plantilla de ARM y ejecutarse en la región de destino. Las plantillas de IaC se crean desde cero o se modifican versiones de plantillas de ejemplo mediante Bicep, JSON, Terraform u otra solución.

    Nota:

    • Las conexiones de Private Link, los registros conectados a ACR y los orígenes de datos del área de trabajo de Azure Monitor no se exportan actualmente mediante este método y, por tanto, deben quitarse de la plantilla generada antes de la ejecución.

  3. Implemente la carga de trabajo de contenedor en el clúster de AKS, lo que se puede lograr de dos maneras:

    • Los manifiestos de extracción se extraen de un repositorio y se aplican mediante un controlador que se ejecuta dentro del clúster, conocido como enfoque de GitOps.
    • Inserción. Los manifiestos se insertan en el clúster mediante el servicio de API de Kubernetes y la herramienta de línea de comandos kubectl, ya sea desde una canalización de CI/CD o una estación de trabajo local.

  4. Para asegurarse de que el nuevo clúster funciona según lo previsto, realice pruebas y validación.

  5. Cambie las entradas DNS públicas para que apunten a la dirección IP de entrada externa del clúster de destino (IP pública de Azure Load Balancer o IP pública de Application Gateway).

  6. Una implementación mediante una solución de equilibrio de carga global, como Azure DNS o Azure Traffic Manager, debe agregar la región a la configuración.

Reimplementación con la migración de datos

Las cargas de trabajo de AKS que usan almacenamiento local, como volúmenes persistentes, para almacenar datos o servicios de base de datos host dentro del clúster se pueden realizar copias de seguridad en un clúster de origen y restaurarlos en un clúster de destino. Para obtener información sobre cómo realizar copias de seguridad y restauración, consulte Copia de seguridad de Azure Kubernetes Service mediante la CLI de Azure.

Contenido relacionado