Configuration de Qdrant Hybrid Cloud

Vous avez déjà choisi Hybrid Cloud (plan de contrôle géré sur votre infrastructure). Si vous hésitez encore, c'est la compétence qdrant-deployment-options. La plupart des échecs de configuration proviennent de deux sources : le stockage (le pilote CSI ne peut pas faire ce dont Qdrant a besoin) ou la connectivité (l'agent ne peut pas atteindre Qdrant Cloud). Diagnostiquez d'abord laquelle avant de toucher à autre chose.

Préparation du cluster Kubernetes (à faire en premier)

À utiliser : juste avant de créer l'environnement, ou si l'installation/provisionnement du cluster a échoué sur le stockage.

• Qdrant a besoin d'un pilote CSI de stockage en bloc. Le stockage réseau (NFS) et le stockage objet (S3) ne sont pas supportés : un cluster configuré avec ceux-ci échouera, ne se dégradra pas Prérequis.
• Créez la StorageClass (avec allowVolumeExpansion: true) et la VolumeSnapshotClass au préalable, pas après. Sans expansion de volume vous ne pourrez pas augmenter la taille du disque ultérieurement ; sans VolumeSnapshotClass et le contrôleur de snapshot CSI vous ne pourrez pas faire de sauvegarde.
• N'importe quel Kubernetes conforme aux normes fonctionne, et il y a une guide de configuration spécifique à chaque plateforme gérée : Akamai (Linode/LKE), AWS (EKS), Civo, DigitalOcean (DOKS), Gcore, GCP (GKE), Azure (AKS), Oracle (OKE), OVHcloud, Red Hat OpenShift, Scaleway, STACKIT, et Vultr Plateformes de déploiement.
• La plateforme compte pour le stockage supporté : certaines (ex. Linode/LKE, Vultr) ne supportent pas du tout les snapshots de volume CSI, donc les sauvegardes n'y sont pas disponibles. Consultez la page snapshot de votre fournisseur et préférez ses types d'instance et de disque recommandés (ex. gp3 sur EKS, Premium SSD v2 sur AKS) avant de vous engager.
• Confirmez la connectivité sortante : l'agent ouvre des connexions à grpc.cloud.qdrant.io et api.cloud.qdrant.io sur le port 443. Les pare-feu/mandataires de sortie bloquent cela silencieusement : un agent « bloqué en installation » c'est généralement ça.
• Vous avez besoin de cluster-admin plus kubectl et helm configurés pour le cluster cible.

Créer l'environnement

À utiliser : lors de l'exécution de l'assistant d'installation dans la Console Cloud.

• L'espace de noms Kubernetes est permanent : c'est le seul choix que vous ne pouvez pas changer ultérieurement. Tout le reste (sélecteurs de nœud, tolérances, URLs de registre, proxy) est modifiable après la création, ne les réfléchissez pas trop maintenant.
• L'assistant génère une commande d'installation à usage unique qui crée des secrets et installe l'agent + l'opérateur via Helm. Vous n'en avez besoin que pour l'installation initiale ; les mises à jour se font ensuite depuis la Console Guide de configuration.
• Le comportement avancé de l'opérateur (planification des pods, contexte de sécurité, ingress, réseau, et gestion des snapshots) est réglé dans la configuration de l'opérateur au niveau de l'environnement, et peut être changé après l'installation Configuration de l'opérateur.
• Air-gapped ou registre restreint ? Copiez les images /qdrant/ et les graphiques /qdrant-charts/ dans votre propre registre et définissez les URLs de conteneur + graphique dans la section avancée de l'environnement. Synchronisez toutes les architectures (ou la bonne) ou les nœuds ARM/x86 échoueront à télécharger.

Créer un cluster dans l'environnement

À utiliser : l'environnement existe et vous provisionnez une base de données.

• Choisissez ici la Classe de stockage de base de données et la Classe de snapshot de volume. Définir la Classe de snapshot de volume sur None désactive les sauvegardes ; emptyDir pour le volume snapshot le rend éphémère (perdu au redémarrage du pod) : des choix délibérés, pas des défauts à accepter aveuglément Création de cluster.
• Par défaut, Qdrant Cloud réserve ~20% du CPU/mémoire par pod pour le système d'exploitation et les composants système. Les petits nœuds peuvent en avoir besoin de plus ; les gros nœuds moins. Visez un pod de base de données par nœud.
• Utilisez des sélecteurs de nœud / tolérances / contraintes de diffusion de topologie pour garder les bases de données sur des nœuds dédiés et les répartir entre les zones.

Exposer et sécuriser un cluster

À utiliser : les applications en dehors du cluster Kubernetes doivent atteindre Qdrant, ou vous avez des questions sur les clés API/TLS.

• Le défaut est un service ClusterIP : interne uniquement, pas de clé API. Le moment où vous l'exposez (LoadBalancer, NodePort, ou Ingress) vous DEVEZ configurer une clé API, fournie en tant que secret Kubernetes référencé dans la configuration du cluster Réseau & sécurité.
• Le gRPC interne nœud-à-nœud utilise le port 6335 et n'est jamais protégé par clé API ou TLS. Il ne doit jamais être accessible publiquement ; Hybrid Cloud embarque une NetworkPolicy la restreignant, donc ne la relâchez pas.
• TLS : déchargez au niveau du ingress/LB, ou terminez dans Qdrant via un secret TLS. Ne faites pas les deux par accident.

Journalisation

À utiliser : lors de la configuration des niveaux de log ou du câblage des logs du cluster dans votre stack. (Pour les métriques/Prometheus/Grafana, utilisez plutôt la compétence qdrant-monitoring.)

• Les niveaux de log sont définis à deux endroits différents : par base de données dans la page détails du cluster, mais pour l'Agent et Opérateur dans la configuration de l'environnement Hybrid Cloud, pas par cluster Réseau, Journalisation & Monitoring.
• Les logs sont des logs simples de pod sans format spécifique à Qdrant. Pointez n'importe quel collecteur de logs compatible Kubernetes sur tous les pods de l'espace de noms Qdrant ; rien de spécifique à Qdrant à configurer.

Ce qu'il NE FAUT PAS faire

• Approvisionner sur NFS, S3, ou tout stockage non-bloc : c'est non supporté et échouera purement et simplement, pas juste lentement.
• Créer la StorageClass/VolumeSnapshotClass (ou activer allowVolumeExpansion) après coup, puis découvrir que vous ne pouvez pas augmenter la taille du disque ou faire de sauvegarde. Elles doivent exister au préalable.
• Supposer que les sauvegardes « marchent juste » sur Linode ou Vultr : vérifiez d'abord le support des snapshots CSI pour votre plateforme.
• Exposer un cluster via LoadBalancer/Ingress sans définir une clé API, ou laisser le port 6335 accessible publiquement.
• Régénérer la commande d'installation (ou faire tourner des secrets) et oublier de la réappliquer : le lien agent-vers-Cloud se casse silencieusement jusqu'à ce que vous le fassiez.
• Supprimer un environnement Hybrid Cloud avant de supprimer ses clusters : démontez d'abord les clusters, puis l'environnement, puis exécutez le script de nettoyage, sinon vous laisserez des ressources orphelines dans le cluster.