Applications

Application existantes

Système

Mayastor

Description de la configuration actuelle

Mayastor est un système de stockage en blocs distribué implémenté avec le protocole NVMEoF. Entre autres, il permet l’accès et la réplication des données sur tous les noeuds du cluster Kubernetes.

En ce moment, on maintient deux copies de toute donnée en tout temps:

# /system/mayastor/storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
parameters:
  ioTimeout: "30"
  protocol: nvmf
  repl: "2"
  stsAffinityGroup: 'true'
provisioner: io.openebs.csi-mayastor

Justification du choix

Comparé a d’autre solutions comme Ceph:

• est très simple a déployer et configurer
• à une basse complexité de son système et ses composantes
• est concu dès le debut pour l’utilisation dans Kubernetes

Par exemple, on a fait plusieurs tentatives d’installation de Ceph, mais le système n’était pas stable pour la petite taille de cluster et était très mal-adapté pour l’utilisation dans Kubernetes.

References utilisés pour le déploiement

• https://www.talos.dev/v1.5/kubernetes-guides/configuration/storage/#mayastor
• https://mayastor.gitbook.io/introduction/quickstart/deploy-mayastor

Utilisation

Le StorageClass mayastor est selectionné par défault par Kubernetes. Il suffit de créer des PersitentVolumeClaims (https://kubernetes.io/docs/concepts/storage/persistent-volumes) et les volumes seront crées dans Mayastore automatiquement.

ArgoCD

ArgoCD est notre système de GitOps. Il s’occupe de déployer et synchronizer toutes les ressources YAML dans notre repértoire Plateforme-Cedille. Pour le faire, on utiliser Kustomize pour regrouper toutes les ressources de type Application dans le dossier /apps/argo-apps/.

Voici un apercu visuel de cette structure:

TODO: Insérer graphique.

Configuration

Permissions RBAC La configuration RBAC (Role-Based Access Control) dans ArgoCD permet de définir des politiques de sécurité spécifiques pour différents utilisateurs et groupes. Dans notre cas, nous avons défini des rôles au sein de notre organisation Cedille qui correspondent aux différents niveaux d’accès nécessaires.

Les opérateurs (role:org-operators), qui sont membres du groupe ClubCedille:SRE, ont les permissions suivantes :

Obtenir des informations sur les clusters, certificats et dépôts (repositories). Synchroniser, créer et supprimer les applications. Lire, créer, mettre à jour et supprimer les clés GPG. Ces permissions sont configurées via les lignes commençant par p dans le fichier system/argocd/argocd-values.yaml sous policy.csv. Le * indique que l’action est autorisée pour toutes les instances de la ressource spécifiée.

Les relations entre les utilisateurs/groupes GitHub et les rôles ArgoCD sont définies par les lignes commençant par g. Par exemple, tous les membres du groupe ClubCedille:SRE sur GitHub sont assignés au rôle role:org-operators dans ArgoCD et ClubCedille:Exec sont assignés au rôle admin.

Intégration SSO avec GitHub ArgoCD est configuré pour utiliser OAuth2 de GitHub comme fournisseur d’authentification. Cela permet aux membres de notre organisation GitHub de se connecter à ArgoCD avec leurs identifiants GitHub.

Ingress - Contour

Contour est une solution d’Ingress Controller pour Kubernetes. Elle utilise le serveur proxy Envoy comme back-end.

Configuration

Le service proxy de Envoy à été configuré avec un Nodeport pour diriger le traffic externe vers contour qui achemine ensuite les requêtes vers les services dédiés.

Tester

Commencer par déployer une application web comme httpbin. À partir du repertoire du projet :

kubectl apply -f apps/testing/httpbin.yaml

Vérifier ensuite que les 3 pods arrivent à un status Running:

kubectl get po,svc,ing -l app=httpbin

Afin d’utiliser Contour et Envoy, on va utiliser la fonction kubectl port-foward pour diriger le traffic vers envoy :

kubectl -n projectcontour port-forward service/envoy 8888:80

Puis visiter http://local.projectcontour.io:8888/. Pour notre environnement de production, on utiliserait l’adresse du service de Envoy.

Pour plus d’informations sur Contour, consultez la documentation officielle.

Kubevirt

KubeVirt étend les fonctionnalités de Kubernetes en ajoutant des workloads de machines virtuelles à côté des conteneurs.

Configuration

KubeVirt est configuré pour permettre l’exécution et la gestion de machines virtuelles au sein du cluster Kubernetes. Il est nécessaire d’avoir krew installé.

Tester

Pour tester une machine virtuelle Ubuntu, exécutez cette commande:

kubectl virt vnc ubuntu-vm -n vms

Containerized data importer (CDI)

Pour créer votre propre VM à partir d’un ISO, vous devez utiliser le CDI de Kubevirt qui est déjà installé sur notre cluster.

Pour ce faire, créez un PVC (dans cette situation, l’iso d’ubuntu 22.04.3 va être importé dans le PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iso-ubuntu-20-04
  namespace: vms
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://releases.ubuntu.com/jammy/ubuntu-22.04.3-desktop-amd64.iso" # Required. Format: (http||s3)://www.myUrl.com/path/of/data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 6Gi

Une fois les changements appliqués, un pod sera créé dans le namespace respectif. Dans cette situation, le pod sera créé dans vms. Ce pod permet de voir la progression de l’installation de l’ISO dans le PVC. Pour voir le progrès:

kubectl logs <nom-du-pod> -n vms -f

Lorsque le téléchargement est terminé, vous pouvez créer votre vm basée sur l’ISO que vous venez de télécharger.

Grafana

Grafana est une plateforme d’analyse et de visualisation de données pour la surveillance des systèmes informatiques.

Configuration

Grafana a été configuré pour collecter, analyser et visualiser les métriques, les logs et les traces des applications de notre infrastructure.

Tester

Visiter https://grafana.omni.cedille.club pour voir ce qui a été fait.

Clickhouse

Clickhouse est un système de gestion de base de données analytique orienté colonnes, optimisé pour les requêtes rapides.

Configuration

Clickhouse est configuré pour collecter et stocker les métriques ainsi que les journaux (logs) provenant d’OpenTelemetry, contribuant directement à une meilleure observabilité. L’intégration avec Grafana, permet d’exploiter ces données à travers des tableaux de bord interactifs pour un suivi précis des systèmes.

Tester

Rendez-vous sur https://grafana.omni.cedille.club. Laissez l’onglet ouvert.

Créez les PV et le déploiement d’un simple serveur clickhouse (si ce n’est pas déjà fait. Pour verifier kubectl get all -n clickhouse-system):

kubectl apply -f apps/samples/clickhouse/pv.yml -n clickhouse-system &&
kubectl apply -f apps/samples/clickhouse/simple.yml -n clickhouse-system

Ensuite, faites un port-forward et tester la connection sur http://localhost:9000/:

kubectl port-forward svc/chi-simple-example-deployment-pv-1-1 9000:9000 -n clickhouse-system # Garder la connection ouverte

Installer le cli de clickhouse et connectez-vous au serveur pour créer une simple table users:

clickhouse-client -h 127.0.0.1 --port 9000 --user default --password <votre-password>

Créer la table users qui va accepter le contenu de script.py

CREATE TABLE users (
    id Int32,
    name String,
    email String,
    preferred_number Int32
) ENGINE = MergeTree()
ORDER BY id;

Ensuite, insérer des données en executant le script:

python3 script.py

Par la suite, il sera possible de voir les changements en faisant un SELECT * from users;

Service Mesh - Kuma

Kuma est une plateforme de gestion de services (Service Mesh) conçue pour le microservice et l’orchestration de réseaux.

Configuration

Kuma est configuré pour orchestrer, sécuriser et observer les communications entre les services du cluster Kubernetes. Il y a uniquement un “meshes” qui a été configurer pour le moment (defaut).

Tester

Commencez par déployer un exemple de service:

kubectl apply -f apps/samples/kuma-demo/demo.yaml -n kuma-demo &&
kubectl apply -f apps/samples/kuma-demo/demo-v2.yaml -n kuma-demo # Permet d'avoir un UI

Ensuite aller visiter l’application déployée:

kubectl port-forward svc/demo-app 5000:5000 -n kuma-demo

Rendez-vous sur http://localhost:5000/.

Finalement, analysez le comportement de Kuma:

kubectl port-forward svc/kuma-control-plane -n kuma-system 5681:5681

Rendez-vous sur http://localhost:5681/gui/.

Merbridge

Merbridge peut être utilisé avec Kuma pour accélérer le routage du trafic réseau entre les pods en utilisant eBPF, ce qui permet de contourner kube-proxy pour des performances améliorées. Lorsqu’il est intégré à Kuma, Merbridge facilite une communication inter-pods plus rapide et plus efficace, en se synchronisant avec les fonctionnalités de gestion de Kuma. La configuration de Merbridge se fait à l’installation de Kuma pour une amélioration directe du débit et de la latence réseau.

Pour tester Merbridge, il faut simplement vérifier que les pods continuent de communiquer au sein du service mesh après son intégration.

Autres solutions considérées

Linkerd.

Problème: Complexité d’intégration ou de configuration. Voir https://github.com/linkerd/linkerd2/issues/11156

Workloads

apps/sample/kustomize-example-app

Application qui démontre la structure de base a prendre pour déployer une nouvelle application avec Kustomize avec des environments prod et staging.

Pour plus de détails, voir: Déployer des applications