Cargas de trabajo con estado en Azure Kubernetes Service (AKS)

En este artículo se proporciona información general sobre la ejecución y migración de cargas de trabajo con estado en Azure Kubernetes Service (AKS): patrones de diseño, opciones de almacenamiento y rampas de migración para bases de datos y servicios con estado.

¿Qué son las cargas de trabajo con estado?

Una carga de trabajo con estado es una aplicación que usa el almacenamiento de datos persistente para conservar el estado en varias instancias, lo que garantiza una experiencia de usuario sin problemas y personalizada. Este diseño es fundamental para servicios como la banca electrónica, las compras en línea y el correo electrónico, donde la coherencia de los datos, el historial de sesiones y la fiabilidad son cruciales. Las cargas de trabajo con estado también son eficaces en situaciones de procesamiento de alto rendimiento y casi en tiempo real que se benefician de características avanzadas como la conmutación por error y la recuperación, lo que garantiza la continuidad de la actividad empresarial.

Aunque las cargas de trabajo con estado ofrecen muchas ventajas, también presentan ciertos desafíos. Por ejemplo, las cargas de trabajo con estado suelen introducir patrones de procesamiento complejos que pueden provocar un aumento de la sobrecarga y de los costes de rendimiento. Es importante que comprenda y considere las necesidades específicas de su aplicación para ayudar a determinar el equilibrio adecuado entre el estado y la ausencia de estado.

Dado el papel fundamental de las cargas de trabajo con estado, Azure ofrece varios enfoques para ejecutarlas de forma eficaz. En esta sección se describen los procedimientos recomendados para implementar cargas de trabajo con estado en Azure Kubernetes Service (AKS), lo que ayuda a los desarrolladores y organizaciones a elegir la opción más adecuada para sus necesidades.

Migración de cargas de trabajo con estado a AKS

Si va a migrar aplicaciones con estado existentes a AKS, siga esta breve guía inicial de migración para reducir el riesgo y acelerar la entrega:

  1. Evaluar los requisitos de almacenamiento y disponibilidad: IOPS de documentos, rendimiento, latencia, durabilidad y necesidades de alta disponibilidad para los datos. Identifique si su carga de trabajo necesita almacenamiento en bloques (Azure Disk), almacenamiento de archivos (Azure Files) o almacenamiento especializado respaldado por CSI.
  2. Elija un controlador CSI y una topología de almacenamiento: elija el controlador CSI compatible con AKS que coincida con esos requisitos (por ejemplo, Azure CSI de disco para el almacenamiento en bloque, Azure Files CSI para el almacenamiento de archivos compartido o un CSI de terceros para características avanzadas). Compruebe que se admiten los requisitos de instantáneas de volumen y replicación.
  3. Implementar con StatefulSets o un operador: migrar réplicas con StatefulSets o usar un operador de base de datos para gestionar la conmutación por error, la pertenencia al clúster y las copias de seguridad. Valide el comportamiento de la restauración, la conmutación por error y la actualización escalonada en un entorno de prueba antes de la puesta en producción.

Para más información, consulte Consideraciones para migrar cargas de trabajo con estado a AKS.

Escenarios comunes de migración con estado

  • PostgreSQL: evalúe las necesidades de IOPS de almacenamiento y alta disponibilidad, elija almacenamiento en bloques o almacenamiento replicado respaldado por CSI, y despliéguelo con un StatefulSet o un operador de PostgreSQL. Consulte la guía de PostgreSQL.
  • MongoDB: Valide la confirmación de escritura, el journaling y la topología del conjunto de réplicas; seleccione un almacenamiento que cumpla los requisitos de rendimiento y durabilidad, e implemente mediante StatefulSets o el operador de MongoDB. Consulte la guía de MongoDB.

Pila de base del marco de trabajo con estado de Kubernetes

El marco con estado de Kubernetes comienza con una pila de base común. En este caso, use la pila KATE , una pila popular normalizada que se usa para muchos proyectos de infraestructura. La pila KATE usa las siguientes herramientas de código abierto:

Las guías de AKS no implementan ArgoCD ni Terraform porque están diseñadas para las operaciones del día 1. Sin embargo, a medida que tu implementación crece y evolucionan los requisitos, te resultará más fácil integrar ArgoCD y Terraform, ya que las guías se basan en parte de la pila KATE.

Marco con estado de Kubernetes para Azure

Con la pila de base establecida, ahora es necesario mejorar el marco para admitir cargas de trabajo con estado en Azure, específicamente mediante la integración de los recursos esenciales para ejecutar la infraestructura de datos en Azure Kubernetes Service (AKS).

Admitir cargas de trabajo complejas con estado, como bases de datos o colas de mensajes, requiere funcionalidades de almacenamiento que superen las opciones efímeras. En concreto, necesita sistemas que ofrecen una mayor resistencia y disponibilidad para abordar varios eventos, como errores de aplicación o reasignaciones de cargas de trabajo a distintos hosts. Puede lograr esta resistencia mediante el subsistema PersistentVolume, que consta de tres recursos de Kubernetes interconectados: PersistentVolumes, PersistentVolumeClaims y StorageClasses. Este subsistema proporciona una API para que usuarios y administradores puedan abstraer los detalles de cómo se proporciona el almacenamiento de cómo se consume el almacenamiento.

La mayoría de las cargas de trabajo con estado necesitan datos de secretos, como cadenas de conexión, nombres de usuario, contraseñas y certificados. Azure Key Vault proporciona un almacén seguro de secretos que usamos para guardar los secretos de marcos con estado necesarios.

También necesitamos un controlador de Kubernetes o un operador de Kubernetes, como Secrets Store CSI Driver o External Secrets Operator, para sincronizar los secretos del almacén de secretos como Secretos de Kubernetes.

Recorte de pantalla de un diagrama que muestra el marco con estado de Kubernetes para Azure.

Diseñar e implementar cargas de trabajo con estado en Azure

Si va a migrar una carga de trabajo con estado existente a AKS, comience con la guía de incorporación para migrar cargas de trabajo con estado a AKS para revisar los pasos de evaluación y validación específicos de la migración.

En las secciones siguientes se proporcionan vínculos a información de diseño e implementación para escenarios de carga de trabajo con estado en Azure.

MongoDB

PostgreSQL

Valkey

Airflow de Apache

Apache Kafka con Strimzi

Acciones de GitHub con Azure Files

Note

Aunque StatefulSets proporcionan identidades y almacenamiento persistentes, no se recomiendan los grupos de nodos de Azure Spot para cargas de trabajo con estado críticas para la producción. Las máquinas virtuales Spot pueden ser desalojadas con poco margen de aviso cuando Azure recupera capacidad, lo que provoca la finalización abrupta del nodo y posibles retrasos en la recuperación del volumen o la reprogramación de pods. En el caso de las cargas de trabajo que dependen de datos persistentes y alta disponibilidad, use grupos de nodos normales y mecanismos de resistencia de almacenamiento adecuados. Los grupos de nodos de Azure Spot deben reservarse para cargas de trabajo interrumpibles que puedan tolerar la pérdida inesperada de nodos.

Colaboradores

Microsoft se encarga del mantenimiento de este artículo. Originalmente lo escribieron los siguientes colaboradores:

  • Don High | Ingeniero principal de clientes
  • Colin Mixon | Administrador de productos
  • Erin Schaffer | Desarrollador de contenido 2
  • Last updated on