Déployer une base de données vectorielle Qdrant sur GKE

Autopilot Standard

---

Ce guide explique comment déployer un cluster de base de données vectorielle Qdrant sur Google Kubernetes Engine (GKE).

Les bases de données vectorielles sont des data stores spécialement conçus pour gérer de vastes collections de vecteurs de grande dimension et faire des recherches dans celles-ci. Ces vecteurs représentent des données telles que du texte, des images, de l'audio, des vidéos ou toute autre donnée pouvant être encodée numériquement. Contrairement aux bases de données traditionnelles qui reposent sur des correspondances exactes, les bases de données vectorielles sont spécialisées dans la recherche d'éléments similaires ou dans l'identification de modèles dans des ensembles de données volumineux. Ces caractéristiques font de Qdrant un choix adapté pour diverses applications, y compris pour la mise en correspondance de réseaux de neurones ou basée sur la sémantique, et la recherche par attribut. Qdrant fonctionne non seulement comme une base de données vectorielle, mais également comme un moteur de recherche de similarités vectorielles.

Ce tutoriel est destiné aux administrateurs et architectes de plate-forme cloud, aux ingénieurs en ML et aux professionnels du MLOps (DevOps) qui souhaitent déployer des clusters de base de données Qdrant sur GKE.

Avantages

Qdrant offre les avantages suivants :

• Large éventail de bibliothèques pour différents langages de programmation et API ouverte à intégrer à d'autres services
• Scaling horizontal, et compatibilité avec la segmentation et la réplication afin de faciliter le scaling et la haute disponibilité
• Compatibilité avec les conteneurs et Kubernetes permettant le déploiement et la gestion dans des environnements cloud natifs modernes
• Charges utiles flexibles avec filtrage avancé pour adapter les critères de recherche avec précision
• Différentes options de quantification et autres optimisations permettant de réduire les coûts d'infrastructure et d'améliorer les performances

Objectifs

Dans ce tutoriel, vous allez apprendre à effectuer les opérations suivantes :

• Planifier et déployer l'infrastructure GKE pour Qdrant
• Déployer l'opérateur StatefulHA pour garantir la haute disponibilité de Qdrant
• Déployer et configurer le cluster Qdrant
• Importer un ensemble de données de démonstration et exécuter une requête de recherche simple
• Collecter des métriques et exécuter un tableau de bord

Architecture de déploiement

Cette architecture configure un cluster GKE évolutif et tolérant aux pannes pour Qdrant sur plusieurs zones de disponibilité, ce qui garantit le temps d'activité et la disponibilité avec des mises à jour progressives et des interruptions minimales. Cela inclut l'utilisation de l'opérateur StatefulHA pour une gestion efficace du basculement. Pour en savoir plus, consultez la page clusters régionaux.

Schéma de l'architecture

Le schéma suivant montre un cluster Qdrant s'exécutant sur plusieurs nœuds et zones dans un cluster GKE :

Dans cette architecture, le StatefulSet Qdrant est déployé sur trois nœuds dans trois zones différentes.

• Vous pouvez contrôler la manière dont GKE répartit les pods entre les nœuds en configurant les règles d'affinité des pods et les contraintes de répartition de la topologie requises dans le fichier de valeurs du chart Helm.
• En cas de défaillance d'une zone, GKE replanifie les pods sur de nouveaux nœuds en fonction de la configuration recommandée.

Pour assurer la persistance des données, l'architecture décrite dans ce tutoriel présente les caractéristiques suivantes :

• Elle utilise des disques SSD régionaux (StorageClass regional-pd personnalisée) pour assurer la persistance des données. Nous vous recommandons d'utiliser des disques SSD régionaux pour les bases de données en raison de leur faible latence et du nombre élevé d'IOPS.
• Toutes les données du disque sont répliquées entre les zones principale et secondaire de la région, ce qui augmente la tolérance aux défaillances potentielles de la zone.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• GKE
• Google Cloud Managed Service for Prometheus
• Backup for GKE

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Dans ce tutoriel, vous utilisez Cloud Shell pour exécuter des commandes. Cloud Shell est un environnement shell permettant de gérer les ressources hébergées sur Google Cloud. Il est doté des outils de ligne de commande préinstallés suivants : Google Cloud CLI, kubectl, Helm et Terraform. Si vous n'utilisez pas Cloud Shell, vous devez installer la Google Cloud CLI.

1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

5. Make sure that billing is enabled for your Google Cloud project.

6. Enable the Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE APIs:

   gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

7. Install the Google Cloud CLI.

8. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

10. Make sure that billing is enabled for your Google Cloud project.

11. Enable the Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE APIs:

    gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

12. Grant roles to your user account. Run the following command once for each of the following IAM roles: role/storage.objectViewer, roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer

    gcloud projects add-iam-policy-binding PROJECT_ID --member="USER_IDENTIFIER" --role=ROLE

    • Replace PROJECT_ID with your project ID.

    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:[e-mail].

    • Replace ROLE with each individual role.

Configurer votre environnement

Pour configurer votre environnement avec Cloud Shell, procédez comme suit :

1. Définissez des variables d'environnement pour votre projet, une région et un préfixe de ressource de cluster Kubernetes :

   Pour les besoins de ce tutoriel, utilisez la région us-central1 pour créer les ressources de déploiement.

   export PROJECT_ID=PROJECT_ID
   export KUBERNETES_CLUSTER_PREFIX=qdrant
   export REGION=us-central1
   

   • Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

2. Vérifiez la version de Helm :

   helm version
   

   Mettez à jour la version si elle est antérieure à la version 3.13 :

   curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
   

3. Clonez l'exemple de dépôt de code depuis GitHub :

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   

4. Accédez au répertoire qdrant pour commencer à créer des ressources de déploiement :

   cd kubernetes-engine-samples/databases/qdrant
   

Créer l'infrastructure de votre cluster

Cette section implique l'exécution d'un script Terraform pour créer un cluster GKE régional, privé et à disponibilité élevée afin de déployer votre base de données Qdrant.

Vous pouvez choisir de déployer Qdrant à l'aide d'un cluster Standard ou Autopilot. Chacun présente ses propres avantages et différents modèles de tarification.

Autopilot

Le schéma suivant présente un cluster GKE régional Autopilot déployé dans trois zones différentes.

Pour déployer l'infrastructure du cluster, exécutez les commandes suivantes dans Cloud Shell :

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Les variables suivantes sont remplacées au moment de l'exécution :

• GOOGLE_OAUTH_ACCESS_TOKEN : remplacé par un jeton d'accès récupéré par la commande gcloud auth print-access-token pour authentifier les interactions avec différentes API Google Cloud.
• PROJECT_ID, REGION et KUBERNETES_CLUSTER_PREFIX sont les variables d'environnement définies dans la section Configurer votre environnement et attribuées aux nouvelles variables pertinentes pour le cluster Autopilot que vous êtes en train de créer.

Lorsque vous y êtes invité, saisissez yes.

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 9 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials qdrant-cluster --region us-central1"

Terraform crée les ressources suivantes :

• Un réseau VPC personnalisé et un sous-réseau privé pour les nœuds Kubernetes
• Un routeur cloud pour accéder à Internet via la traduction d'adresse réseau (NAT)
• Un cluster GKE privé dans la région us-central1.
• Un ServiceAccount avec les autorisations de journalisation et de surveillance pour le cluster
• Configuration de Google Cloud Managed Service pour Prometheus pour la surveillance et les alertes relatives au cluster.

Standard

Le schéma suivant présente un cluster GKE régional privé Standard déployé dans trois zones différentes.

Pour déployer l'infrastructure du cluster, exécutez les commandes suivantes dans Cloud Shell :

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Les variables suivantes sont remplacées au moment de l'exécution :

• GOOGLE_OAUTH_ACCESS_TOKEN est remplacé par un jeton d'accès récupéré par la commande gcloud auth print-access-token pour authentifier les interactions avec différentes API Google Cloud.
• PROJECT_ID, REGION et KUBERNETES_CLUSTER_PREFIX sont les variables d'environnement définies dans la section Configurer votre environnement et attribuées aux nouvelles variables pertinentes pour le cluster Standard que vous êtes en train de créer.

Lorsque vous y êtes invité, saisissez yes. L'exécution de ces commandes et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials qdrant-cluster --region us-central1"

Terraform crée les ressources suivantes :

• Un réseau VPC personnalisé et un sous-réseau privé pour les nœuds Kubernetes
• Un routeur cloud pour accéder à Internet via la traduction d'adresse réseau (NAT)
• Un cluster GKE privé dans la région us-central1 avec l'autoscaling activé (un à deux nœuds par zone)
• Un ServiceAccount avec les autorisations de journalisation et de surveillance pour le cluster
• Configuration de Google Cloud Managed Service pour Prometheus pour la surveillance et les alertes relatives au cluster.

Se connecter au cluster

Configurez kubectl pour récupérer les identifiants et communiquer avec votre nouveau cluster GKE :

gcloud container clusters get-credentials \
    ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}

Déployer la base de données Qdrant sur votre cluster

Dans ce tutoriel, vous allez déployer la base de données Qdrant (en mode distribué) et l'opérateur HA avec état dans votre cluster GKE à l'aide du chart Helm.

Le déploiement crée un cluster GKE avec la configuration suivante :

• Trois instances répliquées des nœuds Qdrant.
• Les tolérances, les affinités de nœuds et les contraintes de répartition de la topologie sont configurées pour garantir une distribution appropriée entre les nœuds Kubernetes. Cela permet d'exploiter les pools de nœuds et les différentes zones de disponibilité.
• Un volume RePD avec le type de disque SSD est provisionné pour le stockage des données.
• Un opérateur HA avec état permet de gérer les processus de basculement et d'assurer une haute disponibilité.
• Pour l'authentification, la base de données crée un secret Kubernetes contenant la clé API.

Pour déployer la base de données Qdrant à l'aide du chart Helm, procédez comme suit :

1. Activez le module complémentaire StatefulHA :

   Autopilot

   GKE active automatiquement le module complémentaire StatefulHA lors de la création du cluster.

   Standard

   Exécutez la commande ci-dessous.

   gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
       --project=${PROJECT_ID} \
       --region=${REGION} \
       --update-addons=StatefulHA=ENABLED
   

   L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre 15 minutes.

2. Ajoutez le dépôt du chart Helm de la base de données Qdrant pour pouvoir le déployer sur votre cluster GKE :

   helm repo add qdrant https://qdrant.github.io/qdrant-helm
   

3. Créez l'espace de noms qdrant pour la base de données :

   kubectl create ns qdrant
   

4. Appliquez le fichier manifeste pour créer un disque SSD persistant régional StorageClass :

   kubectl apply -n qdrant -f manifests/01-regional-pd/regional-pd.yaml
   

   Le fichier manifeste regional-pd.yaml décrit le disque SSD persistant StorageClass :

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   allowVolumeExpansion: true
   metadata:
     name: ha-regional
   parameters:
     replication-type: regional-pd
     type: pd-ssd
     availability-class: regional-hard-failover
   provisioner: pd.csi.storage.gke.io
   reclaimPolicy: Retain
   volumeBindingMode: WaitForFirstConsumer

5. Déployez un ConfigMap Kubernetes avec une configuration side-car metrics et un cluster Qdrant à l'aide de Helm :

   kubectl apply -n qdrant -f manifests/03-prometheus-metrics/metrics-cm.yaml
   helm install qdrant-database qdrant/qdrant -n qdrant \
   -f manifests/02-values-file/values.yaml
   

   Le fichier manifeste metrics-cm.yaml décrit le metrics side-car ConfigMap :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: nginx-conf
   data:
     default.conf.template: |
       server {
         listen 80;
         location / {
           proxy_pass http://localhost:6333/metrics;
           proxy_http_version 1.1;
           proxy_set_header Host $http_host;
           proxy_set_header api-key ${QDRANT_APIKEY};
           proxy_set_header X-Forwarded-For $remote_addr;
         }
       }

   Le fichier manifeste values.yaml décrit la configuration du cluster Qdrant :

   replicaCount: 3
   
   config:
     cluster:
       enabled: true
     storage:
       optimizers:
         deleted_threshold: 0.5
         vacuum_min_vector_number: 1500
         default_segment_number: 2
         max_segment_size_kb: null
         memmap_threshold_kb: null
         indexing_threshold_kb: 25000
         flush_interval_sec: 5
         max_optimization_threads: 1
   
   livenessProbe:
     enabled: true
     initialDelaySeconds: 60
   
   resources:
     limits:
       cpu: "2"
       memory: 4Gi
     requests:
       cpu: "1"
       memory: 4Gi
   
   tolerations:
     - key: "app.stateful/component"
       operator: "Equal"
       value: "qdrant"
       effect: NoSchedule
   
   affinity:
     nodeAffinity:
       preferredDuringSchedulingIgnoredDuringExecution:
       - weight: 1
         preference:
           matchExpressions:
           - key: "app.stateful/component"
             operator: In
             values:
             - "qdrant"
   
   topologySpreadConstraints:
     - maxSkew: 1
       topologyKey: "topology.kubernetes.io/zone"
       whenUnsatisfiable: ScheduleAnyway
       labelSelector:
         matchLabels:
           app.kubernetes.io/name: qdrant
           app.kubernetes.io/instance: qdrant
   
   podDisruptionBudget:
     enabled: true
     maxUnavailable: 1
   
   persistence:
     accessModes: ["ReadWriteOnce"]
     size: 10Gi
     storageClassName: ha-regional
   
   apiKey: true
   
   sidecarContainers:
     - name: metrics
       image: nginx:1.26
       resources:
         requests:
           memory: "128Mi"
           cpu: "250m"
         limits:
           memory: "128Mi"
           cpu: "500m"
       ports:
       - containerPort: 80
       env:
       - name: QDRANT_APIKEY 
         valueFrom:
           secretKeyRef:
             name: qdrant-database-apikey          
             key: api-key
       volumeMounts:
           - name: nginx-conf
             mountPath: /etc/nginx/templates/default.conf.template
             subPath: default.conf.template
             readOnly: true
   additionalVolumes:
     - name: nginx-conf
       configMap:
         name: nginx-conf
         items:
           - key: default.conf.template
             path: default.conf.template 

   Cette configuration active le mode du cluster, ce qui vous permet de configurer un cluster Qdrant à disponibilité élevée et distribué.

6. Vérifiez l'état du déploiement :

   helm ls -n qdrant
   

   Le résultat ressemble à ce qui suit, si la base de données qdrant est bien déployée :

   NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
   qdrant-database  qdrant          1               2024-02-06 20:21:15.737307567 +0000 UTC deployed        qdrant-0.7.6    v1.7.4
   

7. Attendez que GKE démarre les charges de travail requises :

   kubectl wait pods -l app.kubernetes.io/instance=qdrant-database --for condition=Ready --timeout=300s -n qdrant
   

   L'exécution de cette commande peut prendre quelques minutes.

8. Une fois que GKE a démarré les charges de travail, vérifiez qu'il a créé les charges de travail Qdrant :

   kubectl get pod,svc,statefulset,pdb,secret -n qdrant
   

9. Démarrez la ressource HighAvailabilityApplication (HAA) pour Qdrant :

   kubectl apply -n qdrant -f manifests/01-regional-pd/ha-app.yaml
   

   Le fichier manifeste ha-app.yaml décrit la ressource HighAvailabilityApplication :

   kind: HighAvailabilityApplication
   apiVersion: ha.gke.io/v1
   metadata:
     name: qdrant-database
     namespace: qdrant
   spec:
     resourceSelection:
       resourceKind: StatefulSet
     policy:
       storageSettings:
         requireRegionalStorage: true
       failoverSettings:
         forceDeleteStrategy: AfterNodeUnreachable
         afterNodeUnreachable:
           afterNodeUnreachableSeconds: 20 # 60 seconds total

   Les ressources GKE suivantes sont créées pour le cluster Qdrant :

   • Le StatefulSet Qdrant qui contrôle trois instances répliquées de pod.
   • A PodDisruptionBudget, qui garantit qu'une seule instance répliquée est indisponible.
   • Le service qdrant-database, qui expose le port Qdrant pour les connexions entrantes et la réplication entre les nœuds.
   • Le service qdrant-database-headless, qui fournit la liste des pods Qdrant en cours d'exécution.
   • Le secret qdrant-database-apikey, qui facilite la connexion sécurisée à la base de données.
   • Le pod de l'opérateur HA avec état et la ressource HighlyAvailableApplication, qui surveillent activement l'application Qdrant. La ressource HighlyAvailableApplication définit les règles de basculement à appliquer à Qdrant.

10. Pour vérifier si les règles de basculement sont appliquées, décrivez la ressource et confirmez Status: Message: Application is protected.

    kubectl describe highavailabilityapplication qdrant-ha-app -n qdrant
    

    Le résultat ressemble à ce qui suit :

    Status:
    Conditions:
        Last Transition Time:  2023-11-30T09:54:52Z
        Message:               Application is protected
        Observed Generation:   1
        Reason:                ApplicationProtected
        Status:                True
        Type:                  Protected
    

Importer l'ensemble de données et exécuter des requêtes de recherche avec un notebook Jupyter

Qdrant organise les vecteurs et les charges utiles dans des collections. La représentation vectorielle continue est une technique qui représente des mots ou des entités sous forme de vecteurs numériques tout en conservant leurs relations sémantiques. Cette pratique est importante pour les recherches de similarités, car elle permet de trouver des similarités basées sur la signification plutôt que sur des correspondances exactes, ce qui rend des tâches (par exemple, systèmes de recherche et de recommandation) plus efficaces et plus nuancées.

Cette section explique comment importer des vecteurs dans une nouvelle collection Qdrant et exécuter des requêtes de recherche simples.

Dans cet exemple, vous utilisez un ensemble de données issu d'un fichier CSV contenant une liste de livres de différents genres. Qdrant sert de moteur de recherche, et le pod de notebook Jupyter que vous créez sert de client interrogeant la base de données Qdrant.

1. Créez les ConfigMaps books-dataset et demo-app, puis déployez le notebook Jupyter :

   kubectl create -n qdrant configmap books-dataset --from-file=manifests/04-notebook/dataset.csv
   kubectl create -n qdrant configmap notebook --from-file=manifests/04-notebook/vector-database.ipynb
   kubectl apply -n qdrant -f manifests/04-notebook/jupyter.yaml
   

   • Le secret qdrant-apikey créé précédemment est installé sur le pod client en tant que variable d'environnement APIKEY.
   • Le ConfigMap books-dataset contient un fichier csv avec les données associées aux livres de la collection Qdrant.
   • Le fichier ConfigMap notebook contient le notebook Jupyter permettant de créer la collection Qdrant à partir de books-dataset.

2. Attendez que GKE démarre le pod Jupyter :

   kubectl wait pods -l app=jupyter-notebook --for condition=Ready --timeout=300s -n qdrant
   

3. Ouvrez cette URL et cliquez sur le fichier vector-database.ipynb. Appuyez sur Exécuter -> Exécuter toutes les cellules. Jupyter exécute tout le code et effectue une requête de recherche.

   Cette requête effectue une recherche sémantique sur votre collection my_books dans Qdrant, et récupère jusqu'à deux résultats ayant le score de correspondance le plus élevé par rapport au texte de votre requête.

   Elle imprime chaque résultat séparé par une ligne de tirets, au format suivant :

   • Title : titre du livre
   • Author : auteur du livre
   • Description : telle que stockée dans le champ de métadonnées description de votre document
   • Published : date de publication du livre
   • Score : score de pertinence de Qdrant

   Le résultat ressemble à ce qui suit :

   Title: Romeo and Juliet
   Author: William Shakespeare, Paul Werstine (Editor), Barbara A. Mowat (Editor),
   Paavo Emil Cajander (Translator)
   Description: In Romeo and Juliet, Shakespeare creates a violent world, in which
   two young people fall in love. It is not simply that their families disapprove;
   the Montagues and the Capulets are engaged in a blood feud.In this death-filled
   setting, the movement from love at first sight to the lovers' final union in
   death seems almost inevitable. And yet, this play set in an extraordinary world
   has become the quintessential story of young love. In part because of its exquisite
   language, it is easy to respond as if it were about all young lovers. Published: 01/01/04
   Score: 0.8935013
   -----
   Title: The Unbearable Lightness of Being
   Author: Milan Kundera, Michael Henry Heim (Translator)
   Description: In The Unbearable Lightness of Being, Milan Kundera tells the story
   of a young woman in love with a man torn between his love for her and his incorrigible
   womanizing and one of his mistresses and her humbly faithful lover. This magnificent
   novel juxtaposes geographically distant places, brilliant and playful reflections,
   and a variety of styles, to take its place as perhaps the major achievement of
   one of the world's truly great writers. Published: 10/27/09
   Score: 0.8931863
   -----
   

Afficher les métriques Prometheus pour votre cluster

Le cluster GKE est configuré avec Google Cloud Managed Service pour Prometheus, ce qui permet de collecter des métriques au format Prometheus. Ce service fournit une solution entièrement gérée pour la surveillance et les alertes, permettant la collecte, le stockage et l'analyse des métriques du cluster et de ses applications.

Le schéma suivant montre comment Prometheus collecte les métriques pour votre cluster :

Le cluster privé GKE du schéma contient les composants suivants :

• Pods Qdrant qui exposent des métriques sur le chemin d'accès / et le port 80. Ces métriques sont fournies par le conteneur side-car nommé metrics.
• Collecteurs basés sur Prometheus qui traitent les métriques à partir des pods Qdrant.
• Une ressource PodMonitoring qui envoie des métriques à Cloud Monitoring.

Pour exporter et afficher les métriques, procédez comme suit :

1. Créez la ressource PodMonitoring pour extraire les métriques par labelSelector :

   kubectl apply -n qdrant -f manifests/03-prometheus-metrics/pod-monitoring.yaml
   

   Le fichier manifeste pod-monitoring.yaml décrit la ressource PodMonitoring :

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: qdrant
   spec:
     selector:
       matchLabels:
         app: qdrant
         app.kubernetes.io/instance: qdrant-database
     endpoints:
     - port: 80
       interval: 30s
       path: / 

2. Créez un tableau de bord Cloud Monitoring avec les configurations définies dans dashboard.json :

   gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json
   

3. Une fois la commande exécutée, accédez aux tableaux de bord Cloud Monitoring :

   Accéder à la page de présentation des tableaux de bord

4. Dans la liste des tableaux de bord, ouvrez le tableau de bord Qdrant Overview. La collecte et l'affichage des métriques peuvent prendre une à deux minutes.

   Le tableau de bord affiche le nombre de métriques clés :

   • Collections
   • Vecteurs intégrés
   • Opérations en attente
   • Nœuds en cours d'exécution

Sauvegarder la configuration de votre cluster

La fonctionnalité Sauvegarde pour GKE vous permet de planifier des sauvegardes régulières de l'intégralité de la configuration de votre cluster GKE, y compris les charges de travail déployées et leurs données.

Dans ce tutoriel, vous allez configurer un plan de sauvegarde pour votre cluster GKE afin d'effectuer des sauvegardes de toutes les charges de travail, y compris les secrets et les volumes, tous les jours à 3h. Pour assurer une gestion efficace du stockage, les sauvegardes de plus de trois jours sont automatiquement supprimées.

Pour configurer des plans de sauvegarde, procédez comme suit :

1. Activez la fonctionnalité Sauvegarde pour GKE pour votre cluster :

   gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
   --project=${PROJECT_ID} \
   --region=${REGION} \
   --update-addons=BackupRestore=ENABLED
   

2. Créez un plan de sauvegarde avec une programmation quotidienne pour tous les espaces de noms du cluster :

   gcloud beta container backup-restore backup-plans create ${KUBERNETES_CLUSTER_PREFIX}-cluster-backup \
   --project=${PROJECT_ID} \
   --location=${REGION} \
   --cluster="projects/${PROJECT_ID}/locations/${REGION}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster" \
   --all-namespaces \
   --include-secrets \
   --include-volume-data \
   --cron-schedule="0 3 * * *" \
   --backup-retain-days=3
   

   La commande utilise les variables d'environnement pertinentes lors de l'exécution.

   Le format du nom du cluster est associé à votre projet et à votre région, comme suit :

   projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME
   

   Lorsque vous y êtes invité, saisissez y.. Le résultat ressemble à ce qui suit :

   Create request issued for: [qdrant-cluster-backup]
   Waiting for operation [projects/PROJECT_ID/locations/us-central1/operations/operation-1706528750815-610142ffdc9ac-71be4a05-f61c99fc] to complete...⠹
   

   Cette opération peut prendre quelques minutes. Une fois l'exécution terminée, le résultat ressemble à ce qui suit :

   Created backup plan [qdrant-cluster-backup].
   

3. Vous pouvez voir le plan de sauvegarde qdrant-cluster-backup que vous venez de créer dans la console Sauvegarde pour GKE.

   Accéder à Sauvegarde pour GKE

Si vous souhaitez restaurer les configurations de sauvegarde enregistrées, consultez la page Restaurer une sauvegarde.

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Si vous avez supprimé le projet, le nettoyage est terminé. Si vous n'avez pas supprimé le projet, suivez les étapes ci-après afin de supprimer les ressources individuelles.

Supprimer des ressources individuelles

1. Définissez les variables d'environnement.

   export PROJECT_ID=${PROJECT_ID}
   export KUBERNETES_CLUSTER_PREFIX=qdrant
   export REGION=us-central1
   

2. Exécutez la commande terraform destroy :

   export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
   terraform  -chdir=terraform/FOLDER destroy \
   -var project_id=${PROJECT_ID} \
   -var region=${REGION} \
   -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
   

   Remplacez FOLDER par gke-autopilot ou gke-standard, selon le type de cluster GKE que vous avez créé.

   Lorsque vous y êtes invité, saisissez yes.

3. Recherchez tous les disques non associés :

   export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,region)")
   

4. Supprimez les disques :

   for i in $disk_list; do
    disk_name=$(echo $i| cut -d'|' -f1)
    disk_region=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
    echo "Deleting $disk_name"
    gcloud compute disks delete $disk_name --region $disk_region --quiet
   done
   

5. Supprimez le dépôt GitHub :

   rm -r ~/kubernetes-engine-samples/
   

Étapes suivantes

• Découvrez les logiciels Open Source Qdrant.
• Essayez l'opérateur Qdrant qui permet de gérer les clés API, de garantir la compatibilité TLS avec la gestion des certificats et de planifier des sauvegardes.
• Découvrez les bonnes pratiques pour le déploiement de bases de données sur GKE.
• Découvrez des solutions pour exécuter des charges de travail utilisant beaucoup de données avec GKE.