Déployer un cluster Valkey sur Azure Kubernetes Service (AKS)

Dans cet article, nous examinons les défis liés à l’utilisation correcte des zones de disponibilité Azure lors de l’exécution d’un cluster Valkey sur AKS, partageons certaines considérations relatives à la mise à l’échelle et proposons une solution.

Important

Les logiciels open source sont mentionnés dans la documentation et les exemples AKS. Les logiciels que vous déployez sont exclus des contrats de niveau de service AKS, de la garantie limitée et du support Azure. Quand vous utilisez une technologie open source avec AKS, consultez les options de support disponibles auprès des communautés et responsables de projet respectifs pour élaborer un plan.

Par exemple, le dépôt GitHub Ray décrit plusieurs plateformes qui varient en fonction du temps de réponse, de la finalité et du niveau de support.

Microsoft assume la responsabilité de la génération des packages open source que nous déployons sur AKS. Cette responsabilité comprend la maîtrise complète des processus de génération, d’analyse, de signature et de validation ainsi que l’application de correctifs logiciels et le contrôle des fichiers binaires présents dans les images conteneur. Pour plus d’informations, consultez Gestion des vulnérabilités pour AKS et Couverture du support AKS.

Qu’est-ce que Valkey ?

Valkey est une duplication du projet Redis qui conserve sa licence open source d’origine. Valkey est une base de données hautes performances qui prend en charge un magasin de données clé-valeur. Vous pouvez l’utiliser pour la mise en cache, le stockage de session, les files d’attente de messages, etc. Un cluster Valkey a plusieurs nœuds qui sont responsables de l’hébergement de vos magasins de données Valkey. Valkey partitionne les données en portions plus petites et les disperse parmi les nœuds. Dans un cluster Valkey simplifié composé de trois nœuds principaux, un nœud réplica unique prend en charge chaque nœud pour activer les fonctionnalités de basculement de base. Les données sont distribuées sur les nœuds, ce qui permet au cluster de continuer à fonctionner même si l’un des nœuds échoue.

Pour plus d’informations, consultez la documentation Valkey.

Vue d’ensemble de la solution Valkey

L’objectif de cette solution est de déployer Valkey sur AKS avec le même niveau de service que le niveau Premium Azure Cache pour Redis.

Le tableau suivant répertorie les principales fonctionnalités du niveau Premium Azure Cache pour Redis et la solution Valkey proposée :

Niveau Premium Azure Cache pour Redis	Solution Valkey
Mémoire jusqu’à 1,2 To	Utilisation de trois principaux Valkey exécutés sur la référence SKU Standard_E64_v5.
Réplication	Ajout d’au moins un pod de réplica par pod principal.
Redondance de zone	En plaçant des pods principaux et réplicas dans différentes zones de disponibilité.

Nous créons deux ressources StatefulSet distinctes : une pour les principaux Valkey et une pour les réplicas. Le spec.affinity de l’API StatefulSet place les pods principaux dans deux zones de disponibilité et les pods réplicas dans une troisième zone de disponibilité. Cette approche garantit qu’un échec d’une zone unique n’a pas d’impact sur la disponibilité d’une partition Valkey.

Remarque

Notez que la solution suggérée dans cet article diffère de la documentation Valkey, où les pods de cluster appartiennent à un seul StatefulSet, et spec.affinity garantit que les pods sont placés sur différents nœuds. L’initialisation automatique du cluster Valkey présentée dans la documentation Valkey ne garantit pas que les pods principaux et réplicas pour la même partition sont placés dans différentes zones de disponibilité.

Étapes suivantes

Créer les ressources d’infrastructure pour l’exécution d’un cluster Valkey sur AKS

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont rédigé sa version d’origine :

• Nelly Kiboi | Ingénieure de service
• Saverio Proto | Ingénieur principal de l’expérience client
• Don High | Ingénieur client principal
• LaBrina Loving | Ingénieur principal du service
• Ken Kitty | Responsable de programme technique principal
• Russell de Pina | Responsable de programme technique principal
• Colin Mixon | Responsable produit
• Ketan Chawda | Ingénieur client senior
• Naveed Kharadi | Ingénieur expérience client
• Erin Schaffer | Développeuse de contenu 2