Haute disponibilité
La mise en place d'une configuration en haute disponibilité (HA) pour l'application GitGuardian nécessite de configurer plusieurs composants.
Cluster Kubernetes
La base d'une configuration en haute disponibilité est un cluster Kubernetes robuste.
Existing cluster
Si vous utilisez un existing cluster déployé via KOTS ou Helm, assurez-vous qu'il est configuré pour la haute disponibilité. Kubernetes prend en charge la haute disponibilité par défaut, tant que les pods sont répartis sur plusieurs nœuds.
Embedded cluster
La haute disponibilité (HA) sur un embedded cluster n'est ni recommandée ni prise en charge par GitGuardian. Pour les configurations en HA, il est conseillé d'utiliser un existing cluster managé.
Mises à jour progressives
Kubernetes prend en charge nativement les mises à jour progressives, ce qui permet des mises à jour d'application transparentes sans interruption de service. Cette fonctionnalité est commune à tous les types d'installation, garantissant que les mises à jour peuvent être appliquées en douceur tout en maintenant la haute disponibilité.
Déploiements et pods
Les configurations des pods sont optimisées pour être réparties uniformément sur les nœuds, minimisant l'impact d'une défaillance de nœud. Aucune configuration supplémentaire n'est requise de votre part.
Bases de données et datastores
Redis et PostgreSQL nécessitent tous deux des configurations en HA. Les versions embarquées de ces services ne prennent pas en charge la haute disponibilité, ce qui rend nécessaire l'utilisation de versions externes configurées en HA.
ClickHouse
ClickHouse fonctionne selon une topologie à nœud unique, qui n'est pas hautement disponible : un redémarrage, une mise à niveau ou une défaillance du nœud le rend indisponible jusqu'à sa récupération.