Sprints

• 1: Rétrospectives
• 2: Rétrospective 1
• 3:
• 4: Rétrospective 2

1 - Rétrospectives

Liste des Rétrospectives

1. Rétrospective du Sprint 1 - 11 octobre 2023
2. Rétrospective du Sprint 2 - 8 novembre 2023

2 - Rétrospective 1

Rétrospective de le l’itération 1

Date: 11 octobre 2023

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Achat des nouveaux disques : L’évaluation de nos besoins a été complétée, la requête au TI est sur le point d’être envoyée.

2.2 Ne sera pas fait

• Ajouter le réseautage pour le provideur Terraform XCP-NG : Nous avons pris la décision de ne pas utiliser XCP-NG comme hyperviseur pour nos serveurs. Cette décision s’explique par le fait que nous désirons minimiser la complexité de l’infrastructure et qu’il n’y avait pas assez de valeurs ajoutées pour justifier cette configuration. Nous avons opté pour l’outil Vcluster comme alternative pour permettre de configurer différents environnements virtuels à l’intérieur de notre cluster Kubernetes.

3. Problèmes et défis

• Installation (bootstrap) du cluster Kubernetes / Talos: Installation du OS Talos Linux a partir de l’ISO généré par Sidero Omni et creation du cluster avec toutes les machines.

  • Problème: Impossibilité de décrypter les disques durant le premier démmrarage après l’installation d’une machine.
    • Cause: Malheuresement, après plusieurs ré-installation, on n’a pas pu identifier la cause.
    • Solution: Désactiver l’option de cryptage avant l’installation.
  • Problème: L’installation est brisée dès que la clé USB est retirée de la machine après l’installation.
    • Cause: L’identifiant du disque avec l’OS /dev/sdb n’est plus valide si la clé USB est retirée.
    • Solution: Ré-installation du cluster en spécifiant des identifiants de disque durable (/dev/disk/by-id/...) pour chaque machine.

• Configuration d’un ISO/image dans un PVC pour KubeVirt: Utiliser un ISO ubuntu dans un PVC pour l’utiliser comme CD-ROM lors du boot de la VM.

  • Solution : Installer le CDI de KubeVirt qui permet d’importer des images disque depuis un serveur web ou un registre de conteneurs, de cloner des volumes persistants existants, et de télécharger des images disque locales, le tout vers un DataVolume. Bref, il simplifie et optimise l’utilisation des revendications de volumes persistants (PVCs) comme disques pour les machines virtuelles.

• Installation initiale de Rook-Ceph : Installation initiale de rook-ceph (système de fichiers distribué) comme preuve de concept sur notre cluster Kubernetes.

  • Problème : Le cluster Ceph est inutilisable
  • Cause : La configuration des OSD (Object Storage Daemons) échoue.
  • Solution : Manuellement effacer tous les disques et redémarrer l’opérateur rook-ceph.

• Problème 2 : Description détaillée du problème et de son impact.

  • Solution envisagée : Description de la solution ou des étapes pour résoudre le problème.

• Défi 3 : Description du défi et pourquoi il a été un obstacle.

  • Solution envisagée : Mesures ou étapes pour surmonter ce défi à l’avenir.

3 -

Rétrospective de l’itération #X

Date: [Date de la réunion]

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Exemple de tâche 3 : Détails sur l’avancement et ce qui reste à faire.

2.2 Ne sera pas fait

• Exemple de tâche 4 : Raison pour laquelle la tâche n’a pas été réalisée.

3. Problèmes et défis

• Problème 1 : Description détaillée du problème et de son impact.

  • Cause : Desription de la cause du problème
  • Solution : Description de la solution ou des étapes pour résoudre le problème.

• Défi 2 : Description du défi et pourquoi il a été un obstacle.

  • Solution : Mesures ou étapes pour surmonter ce défi à l’avenir.

4 - 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.