Compartir a través de

Migración de Amazon EKS a Azure Kubernetes Service (AKS)

  • Artículo

En este artículo se proporcionan estrategias para migrar cargas de trabajo típicas sin estado y con estado de Amazon EKS a Azure Kubernetes Service (AKS).

Consideraciones

El proceso de implementación real de una carga de trabajo de producción real puede variar en función de los siguientes factores:

  • Estrategias de implementación: la elección entre GitOps y los métodos tradicionales de integración continua/implementación continua (CI/CD) de DevOps influyen significativamente en el enfoque de implementación. GitOps prioriza la infraestructura declarativa administrada a través de repositorios controlados por versiones, mientras que CI/CD de DEvOps se centra en flujos de trabajo automatizados para la entrega de aplicaciones.

  • Artefactos de implementación: la selección de los artefactos de implementación desempeña un papel fundamental a la hora de definir la estructura de implementación. Los archivos YAML, los archivos de manifiesto, los gráficos de Helm y las configuraciones de Kustomize representan diversos enfoques para especificar y personalizar la configuración de implementación, cada uno con sus puntos fuertes y casos de uso.

  • Autenticación y autorización de cargas de trabajo: en función de la configuración, los métodos de autenticación y autorización pueden diferir. Puede usar roles de Administración de identidades y acceso (IAM) de Amazon Web Services (AWS), mecanismos de identidad de carga de trabajo o cadenas de conexión para el control de acceso.

  • Supervisión: la implementación de soluciones de supervisión es un aspecto crítico que puede implicar diversas herramientas y metodologías para garantizar el rendimiento y el estado de las cargas de trabajo implementadas. Para obtener más información sobre la comparación entre la supervisión de AKS y EKS, consulte Supervisión y registro de Kubernetes.

Antes de comenzar la migración, revise y tenga en cuenta las siguientes instrucciones generales y los recursos de procedimientos recomendados:

Consideraciones sobre la migración de la carga de trabajo

En esta sección se revisan algunos aspectos que debe tener en cuenta antes de migrar las cargas de trabajo de Amazon EKS a AKS.

Descripción del entorno de Amazon EKS existente

Analice el entorno de EKS existente para comprender la arquitectura, los recursos y las configuraciones actuales.

  • Revise la configuración de EKS: evalúe la configuración del clúster de EKS, como los tipos de nodo, el número de nodos, la versión de Kubernetes y la directiva de soporte técnico, y la configuración de escalado.

    Nota:

    EKS permite crear imágenes de AMI personalizadas para nodos de EKS. AKS no permite el uso de imágenes de nodo personalizadas. Si la implementación requiere personalización de nodo, puede aplicar la personalización de kubelet o DaemonSets para personalizar los nodos.

  • Revise las cargas de trabajo de la aplicación: identifique todas las cargas de trabajo de Kubernetes que se ejecutan en el clúster de EKS, incluidas las implementaciones, los servicios, los conjuntos con estado, las configuraciones de entrada y las notificaciones de volumen persistentes. Asegúrese de que tiene una lista completa de las aplicaciones y sus recursos asociados.

  • Compruebe las dependencias: identifique las dependencias de los servicios de AWS específicos de EKS.

    Servicio de AWS Dependencia
    AWS Secret Manager Azure Key Vault
    Agente de AWS Guard Duty Microsoft Defender para contenedores
    Agente de identidad de pod de EKS Identidad de carga de trabajo de Microsoft Entra ID
    Controladores de Container Storage Interface (CSI) de Amazon Elastic File System (EFS) o Elastic Block Store (EBS) Controladores CSI de AKS

  • Realice una copia de seguridad del clúster de EKS: puede usar una herramienta que no sea de Microsoft, como Velero para realizar copias de seguridad y migrar recursos de Kubernetes y volúmenes persistentes.

Preparación del entorno de Azure AKS

La Container Networking Interface (CNI) de Amazon Virtual Private Cloud (VPC) es el complemento de red predeterminado compatible con EKS. Un clúster de AKS admite varios complementos de red y métodos para implementar un clúster en una red virtual, entre los que se incluyen:

Para preparar el clúster de AKS, siga estos pasos:

  1. Cree un nuevo clúster de AKS en Azure y configure las opciones de red deseadas para que coincidan con sus requisitos.
  2. Revise los manifiestos de Kubernetes y los archivos YAML usados en EKS. Busque cualquier posible incompatibilidad de la versión de la API de Kubernetes o configuraciones de EKS específicas que AKS no admita.
  3. Asegúrese de que se pueda acceder a las imágenes de Docker y a la ubicación del registro de imágenes de contenedor desde el clúster de AKS. Compruebe la conectividad de red y la configuración de autenticación y autorización necesarias para acceder a las imágenes.

Siguiendo estos pasos, puede crear correctamente un clúster de AKS y garantizar la compatibilidad con los manifiestos de Kubernetes y las imágenes de Docker, lo que garantiza un proceso de migración sin problemas de EKS a AKS.

Información general sobre la migración

La migración de Amazon EKS a AKS implica varios pasos, como:

  • Migración de imágenes de contenedor: la migración de imágenes de contenedor es un paso fundamental al pasar de EKS a AKS. Puede usar herramientas como kubectl, Docker o registros de contenedor para exportar e importar imágenes.

    1. Exportación de imágenes desde EKS.
    2. Configuración de una instancia de Azure Container Registry y adjuntarla a AKS si aún no lo ha hecho.
    3. Inserción de imágenes en Container Registry

    Las imágenes de contenedor también se pueden importar en Container Registry directamente desde un repositorio público o privado que no sea de Azure. Para obtener más información, consulte Importación de imágenes de contenedor.

  • Migración de manifiestos de Kubernetes: AKS usa el manifiesto de archivo YAML de Kubernetes para definir objetos de Kubernetes. Normalmente, las implementaciones se crean y administran con kubectl create o kubectl apply. Cree una implementación definiendo un archivo de manifiesto en formato YAML. Para obtener más información, consulte este manifiesto de AKS de ejemplo. Para obtener más información sobre cómo funcionan los archivos YAML en Kubernetes, consulte Implementaciones y manifiestos de YAML.

  • Migración de datos: planifique meticulosamente la migración de aplicaciones con estado para evitar la pérdida de datos o tiempos de inactividad inesperados. Para obtener más información, consulte la sección Consideraciones sobre la migración de cargas de trabajo con estado.

Consideraciones sobre la migración de cargas de trabajo sin estado

La migración de los manifiestos de Kubernetes implica adaptar la configuración para que funcione en el entorno de Azure, incluidos estos pasos:

  1. Actualice los manifiestos: actualice los manifiestos de Kubernetes para usar las nuevas ubicaciones de imagen en Container Registry. Sustituya las referencias de imagen en los archivos YAML por la ruta de acceso de Container Registry.

    1. Revise los archivos de manifiesto de Kubernetes existentes para configuraciones específicas de AWS, como roles de VPC e IAM.
    2. Revise los roles de IAM de EKS asociados a nodos, cuentas de servicio y otros recursos. Asígnelos con roles equivalentes de control de acceso basado en rol (RBAC) de Azure AKS. Para obtener más información, consulte Identidad y acceso a la carga de trabajo de Kubernetes.
    3. Modifique los archivos de manifiesto para reemplazar la configuración específica de AWS por la configuración específica de Azure, como las anotaciones.

  2. Aplique los manifiestos a AKS:

    1. Conéctese al clúster de AKS.
    2. Aplique los archivos de manifiesto de Kubernetes modificados mediante kubectl apply -f.

Consideraciones sobre la migración de cargas de trabajo con estado

Si las aplicaciones usan volúmenes persistentes (PVS) o notificaciones de volumen persistente (PVC) para el almacenamiento de datos, asegúrese de realizar una copia de seguridad de estos datos. Puede usar herramientas como Velero para realizar copias de seguridad de clúster, incluidos los datos de PV y PVC. Para obtener más información, consulte Copia de seguridad y restauración de los recursos del clúster de Amazon EKS mediante Velero.

Las aplicaciones con estado suelen tener requisitos de almacenamiento de datos persistentes, lo que agrega complejidad al proceso de migración. Para obtener una comparación de las funcionalidades de almacenamiento de Amazon EKS y AKS, consulte Opciones de almacenamiento para un clúster de Kubernetes.

Siga estos pasos para hacer una copia de seguridad de los datos persistentes:

  1. Configure Velero en el clúster de AKS y EKS.
  2. Realice una copia de seguridad del clúster de EKS.
  3. Copie la copia de seguridad de Velero desde el cubo de S3 a Azure Blob Storage mediante el comando az copy.
  4. Dado que AKS y EKS pueden usar diferentes storageClassNames para las notificaciones de volumen persistente, cree un configMap que traduzca los storageClassNames de origen a un nombre de clase compatible con AKS. Puede omitir este paso si usa la misma solución de almacenamiento en los clústeres de EKS y AKS Kubernetes.
  5. Restaure la copia de seguridad en AKS (mediante el comando de restauración de Velero).
  6. Aplique los cambios necesarios a los objetos restaurados, como referencias a imágenes de contenedor en Amazon Elastic Container Registry (ECR) o acceso a secretos.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

  • Dixit Arora | Ingeniero de clientes sénior, ISV DN CoE
  • Ketan Chawda | Ingeniero sénior de clientes, ISV DN CoE

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes