Compartir vía

Migrar la carga de trabajo de Service Fabric a AKS

  • Artículo

Muchas organizaciones se mueven a aplicaciones en contenedores como parte de una inserción para adoptar el desarrollo moderno de aplicaciones, los procedimientos recomendados de mantenimiento y las arquitecturas nativas de la nube. Dado que las tecnologías siguen evolucionando, las organizaciones deben evaluar las muchas plataformas de aplicaciones en contenedor que están disponibles en la nube pública.

No existe una solución única para las aplicaciones, pero las organizaciones a menudo descubren que Azure Kubernetes Service (AKS) cumple los requisitos de muchas de sus aplicaciones en contenedores. AKS es un servicio de Kubernetes administrado que simplifica las implementaciones de aplicaciones a través de Kubernetes mediante la administración del plano de control para proporcionar servicios principales para cargas de trabajo de aplicaciones. Muchas organizaciones usan AKS como su plataforma de infraestructura principal y las cargas de trabajo de transición hospedadas en otras plataformas en AKS.

En este artículo se describe cómo migrar aplicaciones en contenedores de Azure Service Fabric a AKS. En este artículo se presupone que está familiarizado con Service Fabric, pero le interesa saber cómo se comparan sus características y funcionalidad con las de AKS. El artículo también proporciona procedimientos recomendados que debe tener en cuenta durante la migración.

Comparación entre AKS y Service Fabric

Para empezar, revise Elección de un servicio de proceso de Azure, junto con otros servicios de proceso de Azure. En esta sección se destacan las similitudes y diferencias notables que son relevantes para la migración.

Tanto Service Fabric como AKS son orquestadores de contenedores. Service Fabric proporciona compatibilidad con varios modelos de programación, pero AKS solo admite contenedores.

  • Modelos de programación: Service Fabric admite múltiples formas de escribir y administrar los servicios, incluidos contenedores Linux y Windows, Reliable Services, Reliable Actors, ASP.NET Core y ejecutables invitados.

  • Contenedores en AKS: AKS solo admite la contenedorización con contenedores de Windows y Linux que se ejecutan en el contenedor en tiempo de ejecución del contenedor, que se administra automáticamente.

Tanto Service Fabric como AKS proporcionan integraciones con otros servicios de Azure, como Azure Pipelines, Azure Monitor, Azure Key Vault e id. de Microsoft Entra.

Principales diferencias

Al implementar un clúster de Service Fabric tradicional, en lugar de un clúster administrado, debe definir explícitamente un recurso de clúster junto con muchos recursos auxiliares en las plantillas de Azure Resource Manager (plantillas de ARM) o módulos de Bicep. Estos recursos incluyen un conjunto de escalado de máquinas virtuales para cada tipo de nodo de clúster, grupos de seguridad de red y equilibradores de carga. Es su responsabilidad asegurarse de que estos recursos están correctamente configurados. En cambio, el modelo de encapsulación para clústeres administrados de Service Fabric consta de un único recurso de clúster administrado. Todos los recursos subyacentes del clúster se abstraen y son administrados por Azure.

AKS simplifica la implementación de un clúster de Kubernetes administrado en Azure descargando la sobrecarga operativa en Azure. Dado que AKS es un servicio Kubernetes hospedado, Azure se encarga de tareas críticas como la supervisión y el mantenimiento del estado de la infraestructura. Azure administra los nodos maestros de Kubernetes, por lo que solo necesita administrar y mantener los nodos del agente.

Para mover la carga de trabajo de Service Fabric a AKS, debe comprender las diferencias en la infraestructura subyacente para poder migrar con confianza las aplicaciones en contenedores. La siguiente tabla compara las capacidades y características de las dos plataformas de hospedaje.

Capacidad o componente Service Fabric AKS
Aplicaciones no contenedorizadas Sí No
Contenedores de Linux y Windows Sí Sí
Plano de control administrado por Azure No Sí
Compatibilidad con cargas de trabajo con y sin estado Sí Sí
Colocación de nodos de trabajo Microsoft Azure Virtual Machine Scale Sets, configurados por el cliente Microsoft Azure Virtual Machine Scale Sets, administrados por Azure
Manifiesto de configuración XML YAML
Integración de Azure Monitor Sí Sí
Compatibilidad nativa con los patrones Reliable Services y Reliable Actor Sí No
Pila de comunicación basada en WCF de Reliable Services Sí No
Almacenamiento persistente Controlador de volumen de Azure Files Compatibilidad con varios sistemas de almacenamiento, como discos administrados, Azure Files y Azure Blob Storage a través de clases de almacenamiento CSI, volumen persistente y reclamaciones de volumen persistente
Modos de red Integración de Azure Virtual Network Compatibilidad con varios complementos de red (Azure CNI, kubenet, BYOCNI), políticas de red (Azure, Calico) y controladores de entrada (Application Gateway Ingress Controller, NGINX, etc.)
Controladores de entrada Un proxy inverso integrado en Service Fabric. Ayuda a los microservicios que se ejecutan en un clúster de Service Fabric a descubrir y comunicarse con otros servicios que tienen puntos de conexión HTTP. También puede usar Traefik en Service Fabric. Controlador de entrada DE NGINX administrado, entrada BYO código abierto y controladores comerciales que usan equilibradores de carga internos o públicos administrados por la plataforma, como el controlador de entrada NGINX y el controlador de entrada de Application Gateway

Nota:

Si usa contenedores de Windows en Service Fabric, se recomienda usarlos en AKS para facilitar la migración.

Pasos de migración

En general, los pasos de migración de Service Fabric a AKS son los siguientes.

Diagrama que muestra los pasos de migración de Service Fabric a AKS.

  1. Establezca la arquitectura de implementación y cree el clúster de AKS. AKS proporciona varias opciones para configurar el acceso al clúster, la escalabilidad de nodos y pods, el acceso a la red y la configuración, etc. Para obtener más información sobre una arquitectura de implementación típica, consulte Arquitectura de ejemplo. La arquitectura de línea de base de AKS también proporciona instrucciones de implementación y supervisión del clúster. La construcción de AKS proporciona plantillas de inicio rápido para implementar el clúster de AKS en función de los requisitos empresariales y técnicos.

  2. Rediseñe la aplicación de Service Fabric. Si usa modelos de programación como Reliable Services o Reliable Actors, o si usa otras construcciones específicas de Service Fabric, es posible que tenga que rediseñar la aplicación. Para implementar la administración de estado al migrar desde Reliable Services, use Distributed Application Runtime (Dapr). Kubernetes proporciona patrones y ejemplos para migrar desde Reliable Actors.

  3. Empaquete la aplicación como contenedores. Visual Studio proporciona opciones para generar el Dockerfile y empaquetar la aplicación como contenedores. Inserte las imágenes de contenedor que cree en Azure Container Registry.

  4. Vuelva a escribir archivos XML de configuración de Service Fabric como archivos YAML de Kubernetes. La aplicación se implementa en AKS mediante archivos YAML o como paquete mediante gráficos de Helm. Para obtener más información, consulte Manifiesto de aplicación y servicio.

  5. Implemente la aplicación en el clúster de AKS.

  6. Cambie el tráfico al clúster de AKS en función de las estrategias de implementación y supervise el comportamiento, la disponibilidad y el rendimiento de la aplicación.

Arquitectura de ejemplo

AKS y Azure proporcionan flexibilidad para configurar su entorno de forma que se adapte a sus necesidades empresariales. AKS está bien integrado con otros servicios de Azure. La arquitectura de línea de base de AKS es un ejemplo.

Diagrama que muestra una arquitectura base AKS.

Como punto de partida, familiarícese con algunos conceptos clave de Kubernetes y, a continuación, revise algunas arquitecturas de ejemplo:

Nota

Al migrar una carga de trabajo de Service Fabric a AKS, puede sustituir Service Fabric Reliable Actors por el bloque de creación de actores de Dapr. Puede sustituir Service Fabric Reliable Collections por el bloque de creación administración de estado de Dapr.

Dapr proporciona API que simplifican la conectividad de microservicios. Para obtener más información, vea Introducción a Dapr. Se recomienda instalar Dapr como una extensión de AKS.

Manifiestos de aplicación y servicio

Service Fabric y AKS tienen diferentes tipos y estructuras de archivos de manifiesto de aplicaciones y servicios. Service Fabric usa archivos XML para la definición de aplicaciones y servicios. AKS usa el manifiesto del archivo YAML de Kubernetes para definir los objetos de Kubernetes. No existen herramientas específicamente diseñadas para migrar un archivo XML de Service Fabric a un archivo YAML de Kubernetes. Sin embargo, puede obtener información sobre cómo funcionan los archivos YAML en Kubernetes revisando los siguientes recursos.

Puede usar Helm para definir manifiestos YAML con parámetros y crear plantillas genéricas reemplazando valores estáticos y codificados de forma rígida por marcadores de posición que puede reemplazar por valores personalizados que se proporcionan en tiempo de implementación. Las plantillas resultantes que contienen los valores personalizados se convierten en manifiestos válidos para Kubernetes.

Kustomize introduce una forma libre de plantillas para personalizar la configuración de la aplicación que simplifica el uso de aplicaciones estándar. Puede usar Kustomize junto con Helm o como alternativa a Helm.

Para obtener más información sobre Helm y Kustomize, consulte los siguientes recursos:

Redes

AKS proporciona dos opciones para la red subyacente:

  • Traiga su propia red virtual de Azure para aprovisionar los nodos del clúster de AKS en una subred desde una red virtual que proporcione.

  • Deje que el proveedor de recursos de AKS cree una nueva red virtual de Azure en el grupo de recursos de nodo que contiene todos los recursos de Azure que usa un clúster.

Si elige la segunda opción, Azure administra la red virtual.

Service Fabric no proporciona una opción de complementos de red. Si usa AKS, debe elegir una de las siguientes opciones:

  • kubenet. Si usa kubenet, los nodos obtienen una dirección IP de la subred de la red virtual de Azure. Los pods reciben una dirección IP de un espacio de direcciones que es lógicamente diferente del de la subred de red virtual Azure de los nodos. A continuación, se configura la traducción de direcciones de red (NAT) para que los pods puedan acceder a los recursos en la red virtual de Azure. La dirección IP de origen del tráfico se traduce mediante NAT a la dirección IP primaria del nodo. Este enfoque reduce significativamente el número de direcciones IP que necesita reservar en su espacio de red para que las usen los pods.

  • Azure CNI Si usa container Networking Interface (CNI), cada pod obtiene una dirección IP de la subred y se puede acceder directamente a ella. Estas direcciones IP deben ser únicas en el espacio de red y deben planearse de antemano. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. A continuación, se reserva el número equivalente de direcciones IP para cada nodo. Este enfoque requiere más planificación y a menudo lleva al agotamiento de direcciones IP o a la necesidad de volver a generar los clústeres en una subred mayor, a medida que crecen las exigencias de la aplicación. Puede configurar el número máximo de pods que se pueden implementar en un nodo al crear el clúster o al crear nuevos grupos de nodos.

  • Redes Azure CNI Overlay. Si usa Azure CNI Overlay, los nodos del clúster se implementan en una subred de Azure Virtual Network. A los pods se les asignan direcciones IP de un CIDR privado que son lógicamente diferentes de la dirección de la red virtual que hospeda los nodos. El tráfico de nodos y pods dentro del clúster usa una red superpuesta. NAT usa la dirección IP del nodo para llegar a los recursos fuera del clúster. Esta solución ahorra un número significativo de direcciones IP de red virtual y le ayuda a escalar sin problemas el clúster a tamaños grandes. Una ventaja añadida es que puede reutilizar el CIDR privado en diferentes clústeres AKS, lo que amplía el espacio IP disponible para aplicaciones contenedorizadas en AKS.

  • Uso de Azure CNI con tecnología de Cilium Azure CNI Powered by Cilium combina el sólido plano de control de Azure CNI con el plano de datos de Cilium para ayudar a proporcionar redes de alto rendimiento y seguridad mejorada.

  • Aporte su propio complemento CNI. Kubernetes no proporciona un sistema de interfaz de red de manera predeterminada. Los complementos de red proporcionan esta funcionalidad. AKS proporciona varios complementos CNI compatibles. Para obtener más información sobre los complementos admitidos, consulte Conceptos de red para aplicaciones en AKS.

Actualmente, los contenedores Windows solo admiten el complemento Azure CNI. Hay disponibles varias opciones para las directivas de red y los controladores de entrada.

En AKS, puede usar las políticas de red de Kubernetes para segregar y ayudar a proteger las comunicaciones entre servicios controlando qué componentes pueden comunicarse entre sí. De manera predeterminada, todos los pods de un clúster de Kubernetes pueden enviar y recibir tráfico sin limitaciones. Para mejorar la seguridad, puede usar Políticas de red de Azure o Políticas de red de Calico para definir reglas que controlen el flujo de tráfico entre microservicios.

Si desea usar Azure Network Policy Manager, debe usar el complemento Azure CNI. Puede usar las políticas de red de Calico tanto con el complemento Azure CNI como con el complemento kubenet CNI. El uso de Azure Network Policy Manager para nodos Windows solo se admite en Windows Server 2022. Para más información, consulte Protección del tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS). Para más información sobre redes AKS, consulte Redes en AKS.

En Kubernetes, un ingress controller actúa como proxy de servicio e intermediario entre un servicio y el mundo exterior, lo que permite que el tráfico externo acceda al servicio. El proxy de servicio suele proporcionar diversas funcionalidades como la terminación TLS, el enrutamiento de solicitudes basado en rutas, el equilibrio de carga y funciones de seguridad como la autenticación y la autorización. Los controladores de entrada también proporcionan otra capa de abstracción y control para enrutar el tráfico externo a los servicios de Kubernetes en función de las reglas HTTP y HTTPS. Esta capa proporciona un control más específico sobre el flujo de tráfico y la administración del tráfico.

En AKS, hay varias opciones para implementar, ejecutar y operar un controlador de entrada. Una opción es el controlador de entrada de Application Gateway, que permite usar App de Azure lication Gateway como controlador de entrada para la terminación TLS, el enrutamiento basado en rutas de acceso y como firewall de acceso web. Otra opción es el controlador de entrada NGINX administrado, que proporciona la opción administrada por Azure para el controlador de entrada NGINX ampliamente usado. El controlador de entrada de Traefik es otro conocido controlador de entrada para Kubernetes.

Cada uno de estos controladores de entrada tiene puntos positivos y negativos. Para decidir cuál usar, tenga en cuenta los requisitos de la aplicación y el entorno. Asegúrese de usar la versión más reciente de Helm y tenga acceso al repositorio de Helm adecuado al instalar un controlador de entrada no administrado.

Almacenamiento persistente

Tanto Service Fabric como AKS disponen de mecanismos para proporcionar almacenamiento persistente a las aplicaciones en contenedores. En Service Fabric, el controlador de volumen de Azure Files, que es un complemento de volumen de Docker, proporciona volúmenes de Azure Files para contenedores de Linux y Windows. Se empaqueta como una aplicación de Service Fabric que puede implementar en un clúster de Service Fabric para proporcionar volúmenes a otras aplicaciones contenedorizadas de Service Fabric dentro del clúster Para más información, consulte Controlador de volumen de Azure Files para Service Fabric.

Es posible que las aplicaciones que se ejecutan en AKS necesiten almacenar y recuperar datos de un sistema de almacenamiento de archivos persistente. AKS se integra con servicios de Azure Storage, como Discos administrados de Azure, Azure Files, Blob Storage y Azure NetApp Storage (ANF). También se integra con sistemas de almacenamiento que no son de Microsoft, como Rook y GlusterFS a través de controladores de container Storage Interface (CSI).

CSI es un estándar para exponer sistemas de almacenamiento de bloques y archivos a cargas de trabajo en contenedores en Kubernetes. Los proveedores de almacenamiento que no son de Microsoft que usan CSI pueden escribir, implementar y actualizar complementos para exponer nuevos sistemas de almacenamiento en Kubernetes o mejorar los existentes, sin necesidad de cambiar el código principal de Kubernetes y esperar a sus ciclos de lanzamiento.

La compatibilidad del controlador de almacenamiento CSI en AKS permite usar de forma nativa estos servicios de almacenamiento de Azure:

  • Azure Disks. Puede usar Azure Disks para crear un recurso Kubernetes DataDisk. Los discos pueden usar Azure Premium Storage respaldado por SSD de alto rendimiento o almacenamiento estándar de Azure respaldado por discos HDD o SSD estándar de Azure. Para la mayoría de las cargas de trabajo de producción y desarrollo, utilice almacenamiento premium. Los discos de Azure se montan como ReadWriteOnce y solo están disponibles para un único nodo en AKS. Para los volúmenes de almacenamiento a los que pueden acceder varios pods simultáneamente, use Azure Files.

    En cambio, Service Fabric admite la creación de un clúster o un tipo de nodo que usa discos administrados, pero no aplicaciones que crean discos administrados conectados dinámicamente mediante un enfoque declarativo. Para más información, consulte Implementar un tipo de nodo de clúster de Service Fabric con discos de datos administrados.

  • Azure Files. Puede usar Azure Files para montar un recurso compartido SMB 3.0 o 3.1 respaldado por una cuenta de almacenamiento Azure en pods. Con Azure Files, puede compartir datos entre varios nodos y pods. Azure Files puede usar el almacenamiento estándar de Azure respaldado por discos duros estándar o el almacenamiento premium de Azure respaldado por discos SSD de alto rendimiento.

    Service Fabric proporciona un controlador de volumen de Azure Files como complemento de volumen de Docker que proporciona volúmenes de Azure Files para contenedores de Docker. Service Fabric proporciona una versión del controlador para clústeres Windows y otra para clústeres Linux.

  • Blob Storage. Puede usar Blob Storage para montar almacenamiento blob (o almacenamiento de objetos) como un sistema de archivos en un contenedor o pod Blob Storage le permite que un clúster AKS admita aplicaciones que trabajan con grandes conjuntos de datos no estructurados, como datos de archivos de registro, imágenes o documentos, y cargas de trabajo HPC. Si ingiere datos en Azure Data Lake Storage, puede montar directamente el almacenamiento y usarlo en AKS sin configurar otro sistema de archivos provisional. Service Fabric no admite ningún mecanismo para montar el almacenamiento blob en modo declarativo.

Para más información sobre las opciones de almacenamiento, consulte Almacenamiento en AKS.

Supervisión de aplicaciones y clústeres

Tanto Service Fabric como AKS proporcionan integración nativa con Azure Monitor y sus servicios, como Log Analytics. La supervisión y el diagnóstico son fundamentales para desarrollar, probar e implementar cargas de trabajo en cualquier entorno en la nube. La supervisión incluye la supervisión de infraestructuras y aplicaciones.

Por ejemplo, puede realizar un seguimiento de cómo se usan sus aplicaciones, las acciones que realiza la plataforma Service Fabric, la ocupación de sus recursos mediante contadores de rendimiento y el estado general de su clúster. Puede usar esta información para diagnosticar y corregir problemas y evitar que se produzcan en el futuro. Para más información, consulte Supervisión y diagnóstico de Service Fabric. Cuando hospede y opere aplicaciones en contenedores en un clúster de Service Fabric, necesitará configurar la solución de supervisión de contenedores para ver los eventos y registros de los contenedores.

Sin embargo, AKS tiene integración integrada con Azure Monitor y Container Insights, que está diseñado para supervisar el rendimiento de las cargas de trabajo en contenedor implementadas en la nube. Container Insights proporciona visibilidad del rendimiento mediante la recopilación de métricas de memoria y procesador de controladores, nodos y contenedores que están disponibles en Kubernetes a través de la API de métricas.

Después de habilitar la supervisión desde clústeres Kubernetes, las métricas y los registros de contenedores se recopilan automáticamente a través de una versión en contenedores del agente Log Analytics para Linux. Las métricas se envían a la base de datos de métricas en Azure Monitor. Los datos de registro se envían al área de trabajo de Log Analytics. Esto le permite obtener datos de supervisión y telemetría para el clúster de AKS y las aplicaciones en contenedores que se ejecutan sobre él. Para más información, consulte Supervisar AKS con Azure Monitor.

Como alternativa o solución complementaria a Container Insights, puede configurar su clúster AKS para recopilar métricas en el Servicio administrado Azure Monitor para Prometheus. Puede usar esta configuración para recopilar y analizar métricas a escala mediante una solución de supervisión compatible con Prometheus, que se basa en el proyecto de Prometheus . El servicio totalmente administrado permite usar el lenguaje de consulta Prometheus (PromQL) para analizar el rendimiento de las cargas de trabajo y la infraestructura supervisadas. También le permite recibir alertas sin necesidad de operar la infraestructura subyacente.

El servicio administrado Azure Monitor para Prometheus es un componente de Azure Monitor Metrics. Proporciona más flexibilidad en los tipos de datos métricos que puede recopilar y analizar mediante Azure Monitor. Las métricas de Prometheus comparten algunas características con métricas personalizadas y de plataforma, pero tienen características adicionales para admitir mejor herramientas de código abierto, como PromQLy Grafana.

Puede configurar el servicio administrado Azure Monitor para Prometheus como fuente de datos tanto para Azure Managed Grafana como para Grafana autoalojado, que puede ejecutarse en una máquina virtual de Azure. Para más información, consulte Usar el servicio administrado Azure Monitor para Prometheus como fuente de datos para Grafana mediante la identidad del sistema administrado.

Complementos para AKS

Al migrar de Service Fabric a AKS, debe considerar el uso de complementos y extensiones. AKS proporciona funcionalidad adicional admitida para los clústeres a través de complementos y extensiones como el escalado automático controlado por eventos (KEDA) de Kubernetes y GitOps Flux v2. Muchas más integraciones proporcionadas por proyectos de código abierto y terceros se usan habitualmente con AKS. La directiva de soporte técnico de AKS no cubre las integraciones de código abierto y que no son de Microsoft. Para más información, consulte Complementos, extensiones y otras integraciones con AKS.

Colaboradores

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

Creadores de entidad de seguridad:

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

Pasos siguientes