KUBERNETES À L'OSUG REGARDS CROISÉS ADMINISTRATEURS/UTILISATEURS - JRES 2021/22

KUBERNETES À L’OSUG
REGARDS CROISÉS ADMINISTRATEURS/UTILISATEURS

R. Cailletaud - C. Coussot - J. Schaeffer - G. Mella - L. Bourgès - V. Chaffard
18 mai 2022

JRES 2022

ϟ L’OSUG

    • 9 unités de recherche, 5 équipes de recherche associées, 2 unités d’appui et de recherche
      (UAR)
    • 28 Services Nationaux d’Observation (SNO)
    • UAR OSUG : soutien au service info des laboratoires et aux SNO
    • À la frontière des métiers ASR/Dev

ĸ POURQUOI KUBERNETES

 Ð Gestion de conf                                Ī Les conteneurs
    • Peu de pratiques communes                     • De plus en plus de demandes
    • Trop de tâches d’administration pour les      • Difficulté de gestion
     développeurs                                   • Questions de sécurité

                           ß Une plateforme pour les développeurs

ǀ L’INFRASTRUCTURE

ͱ KUBERNETES À L’OSUG

     • Trois ans de production, une trentaine d’applications métiers
     • Utilisation de Packer pour construire les images des VMs
     • Utilisation de Salt-Cloud pour déployer les VM
     • Utilisation de Rancker Kubernetes Engine pour déployer Kubernetes
     • Clusters de test, pré-production et production
     • Clusters et applications déployés en quelques minutes
     • Utilisation de l’interface web Rancher pour les RBAC

I. THEIA|OZCAR

     • Portail et services pour l’interopérabilité
       et la réutilisabilité des données
       d’observation des surfaces continentales
     • Greenfield
     • Architecture complexe
     • La problématique du stockage persistant
                                                     Figure 2: Architecture logicielle du SI Theia|OZCAR

Ɓ LE STOCKAGE : VSAN

     • Volumes dynamiques, intégration aux infrastructures sous-jacentes
     • Support communautaire minimal
     • Problèmes fréquents lors des mises à jour
     • Kubernetes In-Tree CSI désormais dépréciés

Ɓ LE STOCKAGE : NETAPP ASTRA TRIDENT

     • Utilisation de SUMMER, la solution de stockage mutualisée de l’UGA
     • Utilisation impossible de certaines fonctionnalités offertes par l’intégration Trident
     • Déploiement demandant des étapes manuelles ≠ Infrastructure As Code

Ɓ LE STOCKAGE : NFS CLIENT PROVISIONER

     • Maintenant Kubernetes NFS Subdir External Provisioner
     • Le provisionneur du pauvre
     • Simple création de répertoires
     • Utilisation de SUMMER
     • Simple, fonctionne partout : un serveur NFS suffit
     • … mais les soucis inhérents à NFS

Ɓ LE CAS DES BASES DE DONNÉES

     • Solutions existantes (opérateurs Kubernetes)
     • Manque de maturité à l’époque… Frilosité de l’administrateur !
     • Service d’hébergement PostgreSQL mutualisé à l’OSUG
     • Effet structurant sur les architectures logicielles

II. LES APPLICATIONS DU LABORATOIRE D’ÉCOLOGIE ALPINE

      • Applications relativement simples (Symfony, Django), stateless
      • Équipes de développement réduites
      • Connaissances systèmes limitées
      • Accompagnement indispensable !
      • Candidates idéales pour l’expérimentation… ɰ

ċ L’ARCHITECTURE LOGICIELLE

      • Pas dogmatique : langage, framework, IDE non imposés !
      • Des architectures similaires
      • Des bonnes pratiques : méthodologie Twelve-Factor
           • Utilisation de format déclaratif
           • Portabilité et abstraction de l’OS
           • Code identique entre développement et production
           • Configuration via des variables d’environnement
           • Application stateless et services externes accessible via le réseau

ü CI/CD/GITOPS

     • Environnement idéal pour la mise en place d’automatisation
     • Automatisation via des opérations Git
     • Passage du développement à la production facilité
     • Limitation des erreurs humaines
     • Grande liberté pour les développeurs

ü CI/CD/GITOPS : LE SCHÉMA !

Ī LES IMAGES DE CONTENEURS

     • Multiplication des images «maison» : danger !
     • Des bonnes pratiques :
          • USER non root
          • Choix de images de base
          • Utilisation de build multistage et limitation du nombre de couches
          • Un conteneur == un processus
          • Twelve-Factor (pas de configuration, journalisation sur la sortie standard…)
            → L’occasion d’un dialogue entre développeurs et administrateurs
     • Utilisation de scanner de vulnérabilités (Trivy)

III. JMMC ET RESIF

 L’univers à très haute résolution spatiale : Services logiciels et
 support utilisateur pour les plus grands interféromètres optiques
 du monde

 Hébergement et distribution des données sismologiques de
 l’Infrastructure de Recherche Résif-EPOS

ʊ LA MIGRATION D’APPLICATION

      • StatefulSets et RollingUpdate strategy (ex : eXist-db)
      • Utilisation de volumes NFS statiques
      • Utilisation d’un large panel des fonctionnalités : probes, cronjob
      • Utilisation de kustomize pour staging/production et blue/green
      • Une forme d’autodocumentation… pas toujours suffisante
      • Un effort considérable mais largement récompensé !

IV. DES CLUSTER «JETABLES» !

       • Des développeurs heureux
       • Nouveaux problèmes pour les administrateurs : cluster «pets»
       • Mises à jour (OS, Kubernetes) et modification (configuration, services, ajout de nœuds)
         stressantes
       • Solutions : des clusters «cattle»
       • De zéro aux applications métiers !

ċ L’ARCHITECTURE GÉNÉRALE

IJ INFRASTRUCTURE AS CODE

     • Gestion de l’infrastructure (nos cluster K8s) via des fichiers descripteurs
     • Utilisation de Packer pour les images de VM
     • Utilisation de Terraform pour décrire l’infrastructure :
          • IPAM (EfficientIP SOLIDserver)
          • Hashicorp Vault
          • Grafana
          • vSphere
          • terraform-vsphere-rke2

Ð ÉTAPES DU DÉPLOIEMENT

{ DÉPLOIEMENT CONTINU

     • Utilisation d’ArgoCD, solution GitOps
     • Un contrôleur Kubernetes (Application Controller) et ses Custom Resources Definitions
     • App of Apps
     • Utilisation d’une image légèrement modifiée pour la gestion des secrets

Ư LA GESTION DES SECRETS

     • Utilisation de Hashicorp Vault et Mozilla Sops
     • Secrets chiffrés dans le dépôt git du code de déploiement
     • Utilisation de clés de transit :
          • Accès à l’endpoint de chiffrement pour les développeurs
          • Accès à l’endpoint de déchiffrement pour la solution de déploiement continu

                                     Figure 6: Clé de transit avec Vault

ǔ CONCLUSION

    • Séparation des rôles…
    • … qui n’empêche pas le dialogue !
    • Effet structurant
    • Des développeurs heureux
    • Séparation des usages : cluster “pets” ≠ cluster “cattle”

Ū PERSPECTIVES

     • Utilisation de stockage objet
     • Intégration plus profonde des primitives (utilisation de Job, …)
     • Environnement de dev K8s (k3d, okteto)
     • Utilisation pour analyse de données (OpenStack)

ĸ QUESTIONS

              Présentation à l’aide de Pandoc, Metropolis
              Beamer Theme and FontAwesome
 Merci !
              É ƨ ư