Version imprimable multipages. Cliquer ici pour imprimer.

Retour à la version par défaut.

Applications

Présente tous nos déploiements que l’on héberge

Application existantes

Système

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

1 -

ApplicationName

Description de l’application

Configuration

  • Paramètres de configuration qui dévient de l’installation standard. Par exemple, si l’application nécessite une configuration de variables d’environnement spéciales, des volumes persistants avec des droits d’accès précis, ou des ajustements de réseau.
  • Détails sur l’intégration avec d’autres services ou applications déjà en place.
  • Instructions pour des paramétrages de sécurité avancés, comme les règles de pare-feu ou les politiques d’accès.

Tester

Instructions pour tester l’application :

  • Étapes pour vérifier que l’installation est fonctionnelle.
  • Les URL ou les endpoints pour accéder à l’application

Autres solutions considérées

Expliquez ici les autres options qui ont été évaluées avant de choisir l’application actuelle. Pour chaque solution alternative envisagée, fournissez les raisons pour lesquelles elle a été rejetée. Cela pourrait inclure :

Manque de fonctionnalités essentielles Complexité d’intégration ou de configuration Considérations de coûts Performances insuffisantes Problèmes de compatibilité Manque de support ou de communauté active

2 - Déployer des applications

Application exemplaire (httpbin)

L’application d’exemple est mise en place afin de documenter la méthodologie qui devrait être utilisée pour déployer des applications en production avec Kustomize et ArgoCD.

Survol des étapes a suivre pour déployer une nouvelle app:

  1. Création d’un dossier pour l’application. Ex.: /apps/new-app
  2. Création de l’arborescence de ressources décrite dans ce document
  3. Ajout d’une référence vers la nouvelle application dans l’application de haut niveau /apps/argo-apps/kustomization.yaml

Fonctionnement avec Kustomize

Base

Chaque application devrait définir un dossier base qui contient toutes les ressources Kubernetes que l’application aurait besoin. Ce dossier doit aussi contenir un Kustomization qui pointe sur toute les fichiers Kubernetes de base:

# base/Kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - network.yaml
  - deployment.yaml

Envrionments

Ensuite, il faut définir les dossiers prod et staging qui auront comme objectif de modifier des propriétés dans base selon les besoins différents et d’ajouter des ressources qui ne seront pas communes a tous les environnements.

Par exemple, voici le fonctionnement pour prod:

# prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../base
  - ingress.yaml
  - dns.yaml

patches:
  - path: patch.yaml

Dans l’extrait ci-haut:

  1. On inclut le base
  2. On inclut les ressources
  3. On applique des patches:
# prod/patches.yaml
# [...]
      replicas: 3
      containers:
      - name: httpbin
        resources:
          requests:
            cpu: "0.1"
            memory: "256Mi"
---
# On peut mettre d'autres patches avec des séparateurs ---
---

On voit qu’ici on applique des requêtes de ressources qui seront différentes de base

Ajout de la nouvelle application dans /argo-apps

Créer les fichiers suivants dans votre répertoire d’application:

# argo.yaml : Contiens la ressource ArgoCD "Application" pour votre application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kustomize-example-app-prod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "2"
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: kustomize-example-app-prod
  source:
    repoURL: https://github.com/ClubCedille/Plateforme-Cedille
    path: apps/samples/kustomize-example-app/prod # On pointe ArgoCD vers notre sous-répertoire pour l'environment prod
    targetRevision: HEAD
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kustomize-example-app-staging
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "2"
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: kustomize-example-app-staging
  source:
    repoURL: https://github.com/ClubCedille/Plateforme-Cedille
    path: apps/samples/kustomize-example-app/staging # On pointe ArgoCD vers notre sous-répertoire pour l'environnement staging
    targetRevision: HEAD 
  syncPolicy:
    syncOptions:
    - CreateNamespace=true

# kustomization.yaml : Kustomization qui contient une seule référence vers le argo.yaml ci-haut
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - argo.yaml

Finalement, on peut modifier le fichier /apps/argo-apps/kustomization.yaml pour inclure notre nouvelle application:

# /apps/argo-apps/kustomization.yaml
kind: Kustomization

resources:
  # System
  - ../../system/crossplane/
  - ../../system/grafana/
  # Workload
  - ../samples/kustomize-example-app/ # Ajout de la nouvelle application.

Structure Globale

Fichiers et Ressources

  [argo.yaml] : ArgoCD Application
  [kustomization.yaml] : Pointeur vers argo.yaml
  ── base
  │  ├── [deployment.yaml]  Deployment httpbin
  │  ├── [kustomization.yaml]  Kustomization
  │  └── [network.yaml]  Service httpbin
  ├── prod
  │   ├── [dns.yaml]  RecordSet prod-dns-record
  │   ├── [ingress.yaml]  Ingress httpbin
  │   ├── [kustomization.yaml]  Kustomization
  │   └── [patch.yaml]  Deployment httpbin
  └── staging
      ├── [dns.yaml]  RecordSet staging-dns-record
      ├── [ingress.yaml]  Ingress httpbin
      ├── [kustomization.yaml]  Kustomization
      └── [patch.yaml]  Deployment httpbin

Aperçu dans ArgoCD Apperçu dans ArgoCD

3 - Déployer des applications système