Haute disponibilité kubernetes
Perte d’un noeud
Grâce au load-balancer, il est actuellement possible en cas d’indisponibilité réseau de pouvoir être redirigé sur un autre noeud.
Lors de la perte de l’un de nos noeuds il est possible de voir que nos pods vont redémarrer.
Cela veut dire que lorsque qu’il y a un noeud qui tombe si le service est sur plusieurs replicas, il n’y aura aucun down time.
Perte de la majorité des noeuds
Si nous perdons la majorité de nos nœuds cela peut nous poser des problèmes. En effet, si nous perdons la majorité des nœuds, cela causerait des soucis d’élection de leader.
En effet, si nous perdons la majorité des nœuds, il est possible que le leader ne soit plus joignable. Cela peut causer des problèmes de disponibilité.
La solution pour prévenir de ce scénario est de mettre en place un système de monitoring qui permet de détecter la perte de la majorité des nœuds.
Cela veut dire que lors de la localisation des machines, il faut que les administrateurs réseau prennent en compte la redondance des nœuds, c’est-à-dire de quels tiers de redondance, ils sont équipé et de combien de nœuds minimum, nous avons besoin pour avoir une majorité.
De répartir les machines dans plusieurs datacenter pour éviter une perte totale du cluster. De demander à l’opérateur de cloud de ne pas mettre les nœuds sur la même machine physique. Donc d’être attentif quant au tiers de disponibilité des nœuds.
Ensuite sur kubernetes, il sera tres important de gérer la répartition master / worker. En effet, si nous avons un cluster avec 3 nœuds, il est important de ne pas mettre les 3 noeuds en master.
Dans le cadre du projet, nous n’avons pas respecté ces consignes, car nous avons mis les 3 nœuds en master par contrainte de ressources et de coût. Cela peut poser des problèmes de disponibilité.
Si nous avons décidé de ne pas respecter ces règles, c’est parce que nous utilisons k3s et que notre cluster ne fait que 3 machines.
K3s étant une version de kubernetes allégée, il est possible de mettre les 3 nœuds en master sans que cela pose de problèmes. K3s est conçu pour être utilisé sur des clusters de petite taille.
Dans le cas d’une enterprises avec plus de nœuds, il est important de respecter ces règles.
Si nous perdons un nœud master, il est possible que le cluster ne soit plus joignable. Il est donc important de bien répartir les nœuds master et worker. Car les masters sont les machines qui gèrent le cluster.
Perte total du cluster
Quels sont les actions à prendre lorsqu’il y a une perte totale du cluster, c’est-à-dire, qu’il est irrécupérable inaccessible et qu’il faut donc le recrée depuis le début. Étant donné que nous nous sommes imposé la méthode de travail Gitops. Cela nous permet de récupérer l’état versionné du cluster et de le reproduire. Tout d’abord la premiere étape sera manuelle sera de réinstaller le cluster. Ensuite une fois cela fait, il faudra installer longhorn et ArgoCD.
Restauration de la configuration
Pour récupérer l’état de la configuration, il suffit de reimporter via git tous les repository configuré antérieurement. Et les intégrer dans Argocd.
Restauration des données persistante
Pour la restauration des backups il va falloir aller chercher les backups sur le stockage minio S3 et les restaurer dans longhorn.