Leer en inglés

Compartir a través de


Implementación de un clúster de Valkey en Azure Kubernetes Service (AKS)

En este artículo, revisamos los desafíos de usar correctamente las zonas de disponibilidad de Azure al ejecutar un clúster de Valkey en AKS, compartir algunas consideraciones de escalado y proponer una solución.

Importante

El software de código abierto se menciona en toda la documentación y ejemplos de AKS. El software que implemente se excluye de los contratos de nivel de servicio de AKS, la garantía limitada y el soporte técnico de Azure. A medida que usa la tecnología de código abierto junto con AKS, consulte las opciones de soporte técnico disponibles en las comunidades y los mantenedores de proyectos respectivos para desarrollar un plan.

Por ejemplo, el Repositorio Ray de GitHub describe varias plataformas que varían en el tiempo de respuesta, el propósito y el nivel de soporte técnico.

Microsoft asume la responsabilidad de crear los paquetes de código abierto que implementamos en AKS. Esa responsabilidad incluye tener la propiedad completa del proceso de compilación, examen, firma, validación y revisión, junto con el control sobre los archivos binarios en imágenes de contenedor. Para obtener más información, consulte Administración de vulnerabilidades para AKS y cobertura de soporte técnico de AKS.

¿Qué es Valkey?

Valkey es una bifurcación del proyecto Redis que conserva su licencia de código abierto original. Valkey es una base de datos de alto rendimiento que admite un almacén de datos de clave-valor y puede usarla para almacenar en caché, almacenamiento de sesión, colas de mensajes, etc. Un clúster de Valkey tiene varios nodos que son responsables de hospedar los almacenes de datos de Valkey. Valkey particiona los datos en partes más pequeñas y los dispersa entre los nodos. En un clúster de Valkey simplificado que consta de tres nodos principales, un único nodo de réplica admite cada nodo para habilitar las funcionalidades básicas de conmutación por error. Los datos se distribuyen entre los nodos, lo que permite que el clúster siga funcionando incluso si se produce un error en uno de los nodos.

Captura de pantalla de un clúster de Valkey en AKS.

Para obtener más información, vea la documentación de Valkey.

Introducción a la solución Valkey

El objetivo de esta solución es implementar Valkey en AKS con el mismo nivel de servicio que la Azure Cache for Redis nivel Premium.

En la tabla siguiente se enumeran las características clave del nivel Azure Cache for Redis Premium y la solución Valkey propuesta:

Nivel Premium de Azure Cache for Redis Solución Valkey
Memoria de hasta 1,2 TB Con tres Valkey principales que se ejecutan en la SKU de Standard_E64_v5.
Replicación Agregar al menos un pod de réplica por pod principal.
Redundancia de zona Colocación de pods principales y de réplica en diferentes zonas de disponibilidad.

Creamos dos recursos de StatefulSet distintos: uno para las principales de Valkey y otro para las réplicas. spec.affinity de la API StatefulSet coloca los pods principales en dos zonas de disponibilidad diferentes y los pods de réplica en otra tercera zona de disponibilidad. Este enfoque garantiza que un error de zona única no afecte a la disponibilidad de ninguna partición de Valkey.

Nota

Tenga en cuenta que la solución sugerida en este artículo difiere de la documentación de Valkey, donde los pods de clúster pertenecen a una sola StatefulSet, y el spec.affinity solo garantiza que los pods se colocan en nodos diferentes. La inicialización automática del clúster de Valkey presentada en la documentación de Valkey no garantiza que los pods principales y de réplica de la misma partición se coloquen en distintas zonas de disponibilidad.

Pasos siguientes

Colaboradores

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

  • Nelly Kiboi | Ingeniera de servicios
  • Saverio Proto | Ingeniero principal de Experiencia del cliente
  • Don High | Ingeniero principal de clientes
  • LaBrina Loving | Ingeniera principal de servicio
  • Ken Kilty | TPM de entidad de seguridad
  • Russell de Pina | TPM de entidad de seguridad
  • Colin Mixon | Administrador de productos
  • Ketan Chawda | Ingeniero sénior de clientes
  • Naveed Kharadi | Ingeniero de Experiencia del cliente
  • Erin Schaffer | Desarrollador de contenido 2