Rétrospective 2

Rétrospective de l’itération 2

Date: 8 novembre 2023

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Configurer et deployer Gateway API #27 : La configuration de la Gateway API est actuellement en développement.
• Configurer OTEL #60 : La configuration de l’OpenTelemetry Collector est en cours pour permettre la collecte et l’exportation des données de télémétrie.

2.2 Ne sera pas fait

• Configurer/Deployer Linkerd #32 : Nous avons choisi de ne pas aller de l’avant avec Linkerd en tant que maillage de service pour le moment. Nous avons rencontrés des problèmes similaires à des issues ouvertes sur ce projet (11156 & 10994). Sans solution proposé, ont a decidé de se diriger vers une alternative (Kuma).
• Résoudre les problèmes de stabilité Rook/Ceph : Les problèmes récurrents de stabilité avec ceph ne semblait pas se résoudre. Possiblement du au fait que le logiciel est concu pour beaucoup plus de serevurs et disques. Nous avons plutôt décidé d’utiliser Mayastor, qui est beaucoup plus stable pour nous (voir Deployer et configurer Mayastor)

2.3 À faire

• Deployer cluster staging (vcluster) #6 & Deployer cluster sandbox (vcluster) #7 : Le déploiement du cluster de staging et sandbox avec vcluster est prévu.
• Documenter le déploiement avec Omni #17 : La documentation du processus de déploiement en utilisant Omni doit être créée.
• Documenter la configuration d’environnement locale avec Omni #19 : Il est nécessaire de documenter la configuration de l’environnement local pour Omni.
• Configuration des routes sur Talos #0 : La configuration des routes pour le système d’exploitation Talos doit être mise en place.
• Configurer la gestion à distance des serveurs physiques #16 : Pour permettre à l’équipe d’intéragir avec les serveurs à distance.
• Acheter SSDs

3. Problèmes et défis

• Problème 1 : Stabilité de Rook/Ceph. Le redémarrage d’un node rend le cluster ceph non-healthy. Les pods de ceph sur le serveurs associé ne finissent jamais leur processus de démarrage et ces disques ne sont jamais disponible.

  • Cause : Le problème semble être du au fait qu’un nouveau mon est créé puisque celui du node redémarré est mort. Puisqu’on ne permet pas la colocation de mon, il ne redémarre sur aucun autre serveur. Quand on redémarre sur le serveur on dirait que le nouveau et ancien mon se font compétition. Après une investigation approfondie, du au petit scale du cluster ceph (3 nodes), il semble y avoir une complexité et risque additionel.
  • Solution : Nous avons décidé que résoudre tous ces problèmes est trop de problèmes. Après une rapide preuve de concept, nous avons décidé de changer vers Mayastor. Ce système est bati pour kubernetes à partir de 0, ce qui devrait réduire le genre de problèmes opérationnels rencontrés avec ceph. Voir #33 pour plus de détails.

• Problème 2 : Configuration d’un service mesh pour kubernetes

  • Cause : La nécessité de prendre en charge mTLS dans le cadre de la configuration du service mesh. Le choix du service mesh doit aussi supporter Gateway API.
  • Solution : Nous avions prévu d’installer Linkerd comme service mesh, mais nous avons été confrontés à un problème lié à l’erreur #11156, qui n’était pas résolu au moment de notre installation. Face à cette difficulté, nous avons choisi de nous orienter vers Kuma, qui prend également en charge la Gateway API et offre la gestion du mTLS nécessaire pour nos besoins.

• Problème 3 : Installation et configuration du service External-DNS : Le service a été installé selon les instructions, cependant il ne marche pas et offre peu de détails sur l’erreur.

  • Cause : La cause n’a pas été identifiée pour le moment.
  • Solution : Il est possible qu’on fasse quelques enquêtes de plus pour faire fonctionner le service. On est aussi en train de regarder des solutions alternatives comme: Gestion du DNS avec crossplane et/ou migration du DNS vers Google Cloud.

• Problème 4 : Configuration du SSO pour ArgoCD sans gestion sécurisée des secrets. Nous avons rencontré un problème récurrent lors de la recréation des pods d’ArgoCD où les secrets nécessaires à la configuration du SSO ne pouvaient pas être conservés de manière sécurisée. La configuration initiale a été effectuée en utilisant le fichier values d’un Helm chart, incluant un token secret provenant de GitHub pour permettre l’authentification. Cependant, cela posait un problème de sécurité puisque le secret se retrouvait exposé sur GitHub lorsque le fichier values était sauvegardé. De plus, le secret devait être saisi à nouveau via kubectl à chaque fois que le namespace était recréé pour des raisons de débogage, ce qui ajoutait des tâches répétitives et fastidieuses à notre travail.

  • Solution : Pour résoudre ce problème, nous devons configuré le service Vault par HashiCorp, qui permettra de centraliser la gestion des secrets et de les injecter de manière sécurisée dans nos configurations sans les exposer dans notre dépôt GitHub. Cela réduirait considérablement les risques liés à la sécurité et optimiserait notre flux de travail en évitant la resaisie manuelle des secrets à chaque intervention sur l’infrastructure.

• Problème 5: Le bootstrapping de Hashicorp Vault demandait beaucoup d’étapes manuelles, notamment la génération de certificats TLS.

  • Cause: Un déploiement demande plusieurs étapes qui étaient difficiles à connecter ensemble de facon automatiser:
    1. Générer des certificats
    2. Configurer google cloud KMS pour unseal
    3. Générer une configuration Helm de Vault
    4. Déployer avec Helm
    5. Initialiser Vault
    6. Créer manuellement l’authentification Kubernetes
  • Solution: En utilisant des fonctionnalité de terraform permettant de rouler des commandes manuelles sur le client, nous avons réussi à automatiser plusieurs des opérations qui ne s’automatisais pas facilement avec terraform. La solution est un peu complexe et moins “propre” mais elle fonctionne bien. Nous avons aussi décidé que la fin du process terraform est la génération d’un fichier values.yaml qui est commit sur le répertoire git afin de configurer le déploiement Helm de Vault. Enfin, il reste certaines étapes manuelles, mais elles sont minimes et seront bien documenté à l’itération 3.