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


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 :

Architecture de déploiement Qdrant

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 :

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 Google Cloud CLI.

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud 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
  9. Create or select a Google Cloud 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: roles/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:USER_IDENTIFIER" --role=ROLE
    • Replace PROJECT_ID with your project ID.
    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.

    • 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 Google Cloudprojet.
  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.

Cluster GKE Autopilot

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.

Cluster GKE standard

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é. Un StatefulSet est un contrôleur Kubernetes qui conserve une identité unique persistante pour chacun de ses pods.
  • 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:
      service:
        enable_tls: false
      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.27
        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. Ajoutez un libellé au statefulset Qdrant:

    kubectl label statefulset qdrant-database examples.ai.gke.io/source=qdrant-guide -n qdrant
    
  7. Déployez un équilibreur de charge interne pour accéder à votre base de données Qdrant qui s'exécute dans le même VPC que votre cluster GKE:

    kubectl apply -n qdrant -f manifests/02-values-file/ilb.yaml
    

    Le fichier manifeste ilb.yaml décrit le service LoadBalancer:

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        #cloud.google.com/neg: '{"ingress": true}'
        networking.gke.io/load-balancer-type: "Internal"
      labels:
        app.kubernetes.io/name: qdrant
      name: qdrant-ilb
    spec:
      ports:
      - name: http
        port: 6333
        protocol: TCP
        targetPort: 6333
      - name: grpc
        port: 6334
        protocol: TCP
        targetPort: 6334
      selector:
        app: qdrant
        app.kubernetes.io/instance: qdrant-database
      type: LoadBalancer
  8. 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
    
  9. 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.

  10. 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
    
  11. 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.
  12. 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-database -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
    

Exécuter des requêtes avec le notebook Vertex AI Colab Enterprise

Qdrant organise les vecteurs et les charges utiles dans des collections. L'embedding vectoriel 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.

Dans cet exemple, vous utilisez un ensemble de données issu d'un fichier CSV contenant une liste de livres de différents genres. Vous créez un notebook Colab Enterprise pour effectuer une requête de recherche dans la base de données Qdrant.

Créer un modèle d'environnement d'exécution

Pour créer un modèle d'exécution, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Modèles d'exécution de Colab Enterprise et assurez-vous que votre projet est sélectionné:

    Accéder aux modèles d'exécution

  2. Cliquez sur  Nouveau modèle. La boîte de dialogue Créer un modèle d'exécution s'affiche.

  3. Dans la section Principes de base de l'exécution:

    • Dans le champ Nom à afficher, saisissez qdrant-connect.
    • Dans la liste déroulante Région, sélectionnez us-central1. Il s'agit de la même région que votre cluster GKE.
  4. Dans la section Configurer le calcul:

    • Dans la liste déroulante Type de machine, sélectionnez e2-standard-2.
    • Dans le champ Taille de disque disponible, saisissez 30.
  5. Dans la section Mise en réseau et sécurité:

    • Dans la liste déroulante Réseau, sélectionnez le réseau sur lequel se trouve votre cluster GKE.
    • Dans la liste déroulante Sous-réseau, sélectionnez un sous-réseau correspondant.
    • Décochez la case Activer l'accès à l'Internet public.
  6. Cliquez sur Créer pour terminer la création du modèle d'exécution. Votre modèle d'exécution apparaît dans la liste sur l'onglet Modèles d'exécution.

Créer un environnement d'exécution

Pour créer un environnement d'exécution, procédez comme suit :

  1. Dans la liste des modèles d'environnement d'exécution, cliquez sur dans la colonne Actions pour le modèle que vous venez de créer, puis sur Créer un environnement d'exécution. Le volet Créer un environnement d'exécution Vertex AI s'affiche.

  2. Cliquez sur Créer pour créer un environnement d'exécution basé sur votre modèle.

  3. Dans l'onglet Environnements d'exécution qui s'affiche, attendez que l'état passe à Sains.

Importer le notebook

Pour importer le notebook:

  1. Accédez à l'onglet Notebooks (Notebooks), puis cliquez sur Importer un notebook à partir d'URL.

  2. Dans Source d'importation, sélectionnez URL.

  3. Sous Notebook URLs (URL des notebooks), saisissez le lien suivant:

    https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/databases/qdrant/manifests/04-notebook/vector-database.ipynb
    
  4. Cliquez sur Importer.

Se connecter à l'environnement d'exécution et exécuter des requêtes

Pour vous connecter à l'environnement d'exécution et exécuter des requêtes:

  1. Dans le notebook, à côté du bouton Connecter, cliquez sur Options de connexion supplémentaires. Le volet Se connecter à l'environnement d'exécution Vertex AI s'affiche.

  2. Sélectionnez Se connecter à un environnement d'exécution, puis Se connecter à un environnement d'exécution existant.

  3. Sélectionnez l'environnement d'exécution que vous avez lancé, puis cliquez sur Connect (Se connecter).

  4. Cliquez sur le bouton Run cell (Exécuter la cellule) à gauche de chaque cellule de code pour exécuter les cellules du notebook.

Le notebook contient des cellules de code et du texte qui décrit chaque bloc de code. L'exécution d'une cellule de code exécute ses commandes et affiche une sortie. Vous pouvez exécuter les cellules dans l'ordre ou exécuter des cellules individuelles si nécessaire.

Pour en savoir plus sur Vertex AI Colab Enterprise, consultez la documentation Colab Enterprise.

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 :

Collecte de métriques Prometheus

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.

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/
    

Étape suivante