Zones de disponibilité

Références externes :

• https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone labels de topologie kubernetes
• https://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html AZ AWS
• https://registry.terraform.io/providers/scaleway/scaleway/latest/docs/guides/regions_and_zones AZ Scaleway

Contexte et description de la problématique

Problèmes rencontrés

• Besoin de tagger des ressources par zone de disponibilité pour planifier la réplication et les déploiements
• Existant incomplet et peu évolutif, basé sur le nom du membre seul
• Besoin de conserver l’anonymat des membres dans l’hébergement, en décorrélant de la réalité physique
• Besoin d’introduire la notion de région pour matérialiser l’hébergement sur le territoire français pour l’essentiel, et hors du territoire justement pour ce qui l’est

Alternatives considérées

• Géographique pur, basé sur la ville, façon Scaleway : fr-par-1
• Géographique général, basé sur l’orientation, façon AWS : fr-north-1
• Basé sur la seule AZ, sur le nom du membre : kaiyou-1, ou kai-1
• Géographique et basé sur le nom du membre : fr-kai-1

Eléments moteurs de la décision

• Un nom de ville est déjà trop précis pour certains membres, probablement à exclure
• La mention du pays est utile, donc le seul nom du membre ne suffit plus
• Le raccourcis en 3 lettres façon Scaleway est assez pertinent pour éviter les prises de tête

Conclusion

• ✅Adoption d’un format pour les AZ de type cc-mbr-1, avec CC le code pays, mbr le raccourci du nom du membre en 3 lettres, et le nombre incrémenté pour un même membre dans un même pays
• ✅Utilisation du label de topologie recommandé par kubernetes

Conséquences

• 👍 Possibilité de faire du déploiement géographique
• 👍 Plus facile pour intégrer de nouveaux noeuds
• 👎 Topologie Garage à ré-éditer