פריסת מסד נתונים וקטורי של Qdrant ב-GKE

Autopilot Standard

במדריך הזה נסביר איך לפרוס אשכול של מסד נתונים וקטורי של Qdrant ב-Google Kubernetes Engine ‏ (GKE).

מסדי נתונים וקטוריים הם מאגרי נתונים שתוכננו במיוחד לניהול ולחיפוש באוספים גדולים של וקטורים עם הרבה מאפיינים. הווקטורים האלה מייצגים נתונים כמו טקסט, תמונות, אודיו, וידאו או כל נתון שאפשר לקודד באופן מספרי. בניגוד למסדי נתונים מסורתיים שמסתמכים על התאמות מדויקות, מסדי נתונים וקטוריים מתמחים במציאת פריטים דומים או בזיהוי דפוסים במערכי נתונים עצומים. המאפיינים האלה הופכים את Qdrant לבחירה מתאימה למגוון רחב של אפליקציות, כולל התאמה שמבוססת על רשתות עצביות או על סמנטיקה, חיפוש עם היבטים ועוד. ‫Qdrant לא פועל רק כמאגר נתונים וקטורי, אלא גם כמנוע חיפוש של דמיון וקטורי.

המדריך הזה מיועד לאדמינים ולארכיטקטים של פלטפורמת הענן, למהנדסי למידת מכונה ולמומחי MLOps ‏(DevOps) שרוצים לפרוס אשכולות של מסדי נתונים של Qdrant ב-GKE.

יתרונות

היתרונות של Qdrant:

• מגוון רחב של ספריות לשפות תכנות שונות ו-API פתוח לשילוב עם שירותים אחרים.
• מדרגיות אופקית ותמיכה בחלוקה למקטעים (sharding) ובשכפול (replication) שמפשטים את המדרגיות והזמינות הגבוהה.
• תמיכה בקונטיינרים וב-Kubernetes שמאפשרת פריסה וניהול בסביבות מודרניות מבוססות-ענן.
• מטענים גמישים עם סינון מתקדם כדי להתאים את קריטריוני החיפוש בצורה מדויקת.
• אפשרויות שונות של קוונטיזציה ואופטימיזציות אחרות להפחתת עלויות התשתית ולשיפור הביצועים.

מטרות

במדריך הזה תלמדו איך:

• תכנון ופריסה של תשתית GKE ל-Qdrant.
• פורסים את האופרטור StatefulHA כדי להבטיח זמינות גבוהה של Qdrant.
• פורסים ומגדירים את אשכול Qdrant.
• העלאה של קבוצת נתונים לדוגמה והרצת שאילתת חיפוש פשוטה.
• לאסוף מדדים ולהפעיל מרכז בקרה.

ארכיטקטורת פריסה

הארכיטקטורה הזו מגדירה אשכול GKE עמיד בכשלים וניתן להרחבה עבור Qdrant בכמה אזורי זמינות, כדי להבטיח זמן פעולה וזמינות עם עדכונים מתגלגלים ושיבושים מינימליים. הוא כולל שימוש בStatefulHA operator לניהול יעיל של מעבר לגיבוי. מידע נוסף זמין במאמר בנושא אשכולות אזוריים.

דיאגרמת ארכיטקטורה

הדיאגרמה הבאה מציגה אשכול Qdrant שפועל בכמה צמתים ואזורים באשכול GKE:

באדריכלות הזו, Qdrant StatefulSet נפרס על פני שלושה צמתים בשלושה אזורים שונים.

• כדי לקבוע איך GKE יפיץ את ה-Pods בין הצמתים, צריך להגדיר את כללי הקרבה והאילוצים של פיזור הטופולוגיה הנדרשים של ה-Pod בקובץ הערכים של תרשים Helm.
• אם אזור אחד נכשל, GKE מתזמן מחדש את ה-Pods בצמתים חדשים על סמך ההגדרות המומלצות.

כדי לשמור את הנתונים, הארכיטקטורה במדריך הזה כוללת את המאפיינים הבאים:

• הוא משתמש בדיסקי SSD אזוריים (StorageClass מותאם אישיתregional-pd) כדי לשמור את הנתונים. מומלץ להשתמש בדיסקי SSD אזוריים למסדי נתונים בגלל זמן האחזור הנמוך וערך ה-IOPS הגבוה שלהם.
• כל הנתונים בדיסק משוכפלים בין אזורים ראשיים ומשניים באזור, וכך משפרים את הסבילות לכשלים פוטנציאליים באזור.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אתם יכולים להשתמש במחשבון התמחור.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

במדריך הזה משתמשים ב-Cloud Shell כדי להריץ פקודות. ‫Cloud Shell היא סביבת מעטפת לניהול משאבים שמתארחים ב- Google Cloud. הוא מגיע עם כלי שורת הפקודה Google Cloud CLI, ‏ kubectl,‏ Helm ו- Terraform שכבר מותקנים בו. אם אתם לא משתמשים ב-Cloud Shell, אתם צריכים להתקין את Google Cloud CLI.

נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים Google Cloud פרויקט.

תפקידים שנדרשים כדי לבחור או ליצור פרויקט

• Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
• יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

• יוצרים Google Cloud פרויקט:

  gcloud projects create PROJECT_ID

  מחליפים את PROJECT_ID בשם של הפרויקט ב- Google Cloud שאתם יוצרים.

• בוחרים את הפרויקט שיצרתם: Google Cloud

  gcloud config set project PROJECT_ID

  מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

מפעילים את ממשקי ה-API הבאים, אם הם עדיין לא מופעלים: Resource Manager,‏ Compute Engine,‏ GKE,‏ פרטי כניסה לחשבון שירות של IAM ו-Backup for GKE.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

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

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים Google Cloud פרויקט.

תפקידים שנדרשים כדי לבחור או ליצור פרויקט

• Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
• יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

• יוצרים Google Cloud פרויקט:

  gcloud projects create PROJECT_ID

  מחליפים את PROJECT_ID בשם של הפרויקט ב- Google Cloud שאתם יוצרים.

• בוחרים את הפרויקט שיצרתם: Google Cloud

  gcloud config set project PROJECT_ID

  מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

מפעילים את ממשקי ה-API הבאים, אם הם עדיין לא מופעלים: Resource Manager,‏ Compute Engine,‏ GKE,‏ פרטי כניסה לחשבון שירות של IAM ו-Backup for GKE.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

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

1. מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM: 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

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט.
   • ‫USER_IDENTIFIER: המזהה של חשבון המשתמש . לדוגמה, [e-mail].
   • ‫ROLE: תפקיד ה-IAM שאתם מקצים לחשבון המשתמש.

מגדירים את הסביבה

כדי להגדיר את הסביבה באמצעות Cloud Shell:

1. מגדירים משתני סביבה לפרויקט, לאזור ולקידומת של משאב אשכול Kubernetes:

   לצורך המדריך הזה, משתמשים באזור us-central1 כדי ליצור את משאבי הפריסה.

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

   • מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

2. בודקים את הגרסה של Helm:

   helm version
   

   אם הגרסה ישנה יותר מ-3.13, צריך לעדכן אותה:

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

3. משכפלים את מאגר המקורות של הקוד לדוגמה מ-GitHub:

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

4. כדי להתחיל ליצור משאבי פריסה, עוברים לספרייה qdrant:

   cd kubernetes-engine-samples/databases/qdrant
   

יצירת תשתית האשכול

בקטע הזה תריצו סקריפט של Terraform כדי ליצור אשכול GKE אזורי פרטי עם זמינות גבוהה, שבו תפרסו את מסד הנתונים של Qdrant.

אפשר לבחור לפרוס את Qdrant באמצעות אשכול רגיל או אשכול במצב Autopilot. לכל אחד מהם יש יתרונות משלו ומודלים שונים של תמחור.

טייס אוטומטי

התרשים הבא מציג אשכול GKE אזורי של Autopilot שנפרס בשלושה אזורים שונים.

כדי לפרוס את תשתית האשכול, מריצים את הפקודות הבאות ב-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}

המשתנים הבאים מוחלפים בזמן הריצה:

• ‫GOOGLE_OAUTH_ACCESS_TOKEN: מוחלף באסימון גישה שאוחזר על ידי הפקודה gcloud auth print-access-token לאימות אינטראקציות עם ממשקי Google Cloud API שונים
• ‫PROJECT_ID,‏ REGION ו-KUBERNETES_CLUSTER_PREFIX הם משתני הסביבה שמוגדרים בקטע הגדרת הסביבה ומוקצים למשתנים הרלוונטיים החדשים עבור אשכול Autopilot שאתם יוצרים.

כשמופיעה בקשה, מקלידים yes.

הפלט אמור להיראות כך:

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

Outputs:

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

‫Terraform יוצר את המשאבים הבאים:

• רשת VPC בהתאמה אישית ורשת משנה פרטית לצומתי Kubernetes.
• ‫Cloud Router כדי לגשת לאינטרנט באמצעות תרגום כתובת רשת (NAT).
• אשכול GKE פרטי באזור us-central1.
• ServiceAccount עם הרשאות רישום ביומן ומעקב עבור האשכול.
• הגדרת השירות המנוהל של Google Cloud ל-Prometheus למעקב אחרי אשכולות ולהתראות.

רגילה

בתרשים הבא מוצג אשכול GKE פרטי רגיל שנפרס בשלושה אזורים שונים.

כדי לפרוס את תשתית האשכול, מריצים את הפקודות הבאות ב-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}

המשתנים הבאים מוחלפים בזמן הריצה:

• ‫GOOGLE_OAUTH_ACCESS_TOKEN מוחלף בטוקן גישה שאוחזר על ידי הפקודה gcloud auth print-access-token כדי לאמת אינטראקציות עם ממשקי Google Cloud API שונים.
• ‫PROJECT_ID,‏ REGION ו-KUBERNETES_CLUSTER_PREFIX הם משתני הסביבה שהוגדרו בקטע הגדרת הסביבה והוקצו למשתנים הרלוונטיים החדשים של אשכול Standard שאתם יוצרים.

כשמופיעה בקשה, כותבים yes. יכול להיות שיחלפו כמה דקות עד שהפקודות האלה יסתיימו והאשכול יציג סטטוס מוכן.

הפלט אמור להיראות כך:

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

Outputs:

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

‫Terraform יוצר את המשאבים הבאים:

• רשת VPC בהתאמה אישית ורשת משנה פרטית לצומתי Kubernetes.
• ‫Cloud Router כדי לגשת לאינטרנט דרך תרגום כתובות רשת (NAT).
• אשכול GKE פרטי באזור us-central1 עם התאמה אוטומטית לעומס (צומת אחד עד שני צמתים לכל אזור).
• ServiceAccount עם הרשאות רישום ביומן ומעקב עבור האשכול.
• הגדרת השירות המנוהל של Google Cloud ל-Prometheus לצורך מעקב והתראות לגבי אשכולות.

התחברות לאוסף

מגדירים את kubectl כדי לאחזר פרטי כניסה ולתקשר עם אשכול GKE החדש:

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

פריסת מסד הנתונים של Qdrant באשכול

במדריך הזה תפרסו את מסד הנתונים Qdrant (במצב מבוזר) ואת אופרטור ה-HA עם שמירת מצב באשכול GKE באמצעות תרשים Helm.

הפריסה יוצרת אשכול GKE עם ההגדרות הבאות:

• שלוש רפליקות של צמתי Qdrant.
• הגדרות Tolerations,‏ node affinities ו-topology spread constraints מוגדרות כדי להבטיח חלוקה נכונה בין צמתי Kubernetes. השיטה הזו מתבססת על מאגרי הצמתים ואזורי הזמינות השונים.
• נפח RePD עם סוג הדיסק SSD מוקצה לאחסון נתונים.
• אופרטור HA עם שמירת מצב משמש לניהול תהליכי מעבר לגיבוי (failover) ולהבטחת זמינות גבוהה. ‫StatefulSet הוא בקר Kubernetes ששומר על זהות ייחודית קבועה לכל אחד מה-Pods שלו.
• לצורך אימות, מסד הנתונים יוצר סוד של Kubernetes שמכיל את מפתח ה-API.

כדי לפרוס את מסד הנתונים של Qdrant באמצעות תרשים Helm:

1. מפעילים את התוסף StatefulHA:

   טייס אוטומטי

   ‫GKE מפעיל באופן אוטומטי את התוסף StatefulHA כשיוצרים את האשכול.

   רגילה

   מריצים את הפקודה הבאה:

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

   יכול להיות שיחלפו 15 דקות עד שהפקודה הזו תושלם ועד שהאשכול יציג סטטוס מוכן.

2. כדי לפרוס את מאגר התרשימים של Qdrant database Helm באשכול GKE, צריך להוסיף אותו קודם:

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

3. יוצרים את מרחב השמות qdrant למסד הנתונים:

   kubectl create ns qdrant
   

4. מחילים את המניפסט כדי ליצור דיסק SSD אזורי לאחסון מתמיד StorageClass:

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

   regional-pd.yaml קובץ המניפסט מתאר את דיסק ה-SSD המתמיד 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. פריסת configmap של Kubernetes עם הגדרת קובץ עזר metrics ואשכול Qdrant באמצעות 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
   

   קובץ המניפסט metrics-cm.yaml מתאר את קובץ ה-sidecar metrics 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;
         }
       }

   המניפסט values.yaml מתאר את ההגדרות של אשכול 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.29
       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 

   ההגדרה הזו מפעילה את מצב האשכול, ומאפשרת להגדיר אשכול Qdrant זמין מאוד ומבוזר.

6. מוסיפים תווית ל-StatefulSet של Qdrant:

   kubectl label statefulset qdrant-database examples.ai.gke.io/source=qdrant-guide -n qdrant
   

7. פורסים מאזן עומסים פנימי כדי לגשת למסד הנתונים של Qdrant שפועל באותו VPC כמו אשכול GKE:

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

   במניפסט ilb.yaml מתואר שירות 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. בודקים את סטטוס הפריסה:

   helm ls -n qdrant
   

   אם מסד הנתונים qdrant נפרס בהצלחה, הפלט אמור להיראות כך:

   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. מחכים שעומסי העבודה הנדרשים יופעלו ב-GKE:

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

   יכול להיות שיחלפו כמה דקות עד שהפקודה הזו תסתיים בהצלחה.

10. אחרי ש-GKE מתחיל את עומסי העבודה, מוודאים ש-GKE יצר את עומסי העבודה של Qdrant:

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

11. מפעילים את המשאב HighAvailabilityApplication (HAA) עבור Qdrant:

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

    המניפסט ha-app.yaml מתאר את המשאב 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

    אלה המשאבים של GKE שנוצרים בשביל אשכול Qdrant:

    • ‫Qdrant StatefulSet ששולט בשלושה עותקים של Pod.
    • ‫A PodDisruptionBudget, כדי לוודא שרק רפליקה אחת לא תהיה זמינה.
    • שירות qdrant-database, שחושף את יציאת Qdrant לחיבורים נכנסים ולשכפול בין צמתים.
    • השירות qdrant-database-headless מספק את רשימת ה-Pods של Qdrant שפועלים.
    • הסוד qdrant-database-apikey, שמאפשר חיבור מאובטח למסד הנתונים.
    • Pod של מפעיל HA עם שמירת מצב ומשאב HighlyAvailableApplication, שעוקבים באופן פעיל אחרי אפליקציית Qdrant. המשאב HighlyAvailableApplication מגדיר את כללי יתירות הכשל שחלים על Qdrant.

12. כדי לבדוק אם כללי יתירות הכשל הוחלו, מתארים את המשאב ומאשרים את Status: Message: Application is protected.

    kubectl describe highavailabilityapplication qdrant-database -n qdrant
    

    הפלט אמור להיראות כך:

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

הרצת שאילתות באמצעות Vertex AI Colab Enterprise notebook

‫Qdrant מארגן וקטורים ומטענים ייעודיים (payloads) באוספים. הטמעת וקטורים היא טכניקה שמייצגת מילים או ישויות כווקטורים מספריים, תוך שמירה על הקשרים הסמנטיים שלהם. זה חשוב לחיפושים של דמיון, כי זה מאפשר למצוא דמיון על סמך משמעות ולא על סמך התאמות מדויקות. כך אפשר לשפר את המערכות של חיפוש והמלצות, ולהפוך אותן ליעילות ומדויקות יותר.

בקטע הזה מוסבר איך מעלים וקטורים לאוסף חדש של Qdrant ומריצים שאילתות חיפוש.

בדוגמה הזו, אתם משתמשים בקבוצת נתונים מקובץ CSV שמכיל רשימה של ספרים בז'אנרים שונים. אתם יוצרים מסמך Notebook ב-Colab Enterprise כדי להריץ שאילתת חיפוש במסד הנתונים של Qdrant.

מידע נוסף על Vertex AI Colab Enterprise זמין במאמרי העזרה של Colab Enterprise.

יצירת תבנית בזמן ריצה

כדי ליצור תבנית של סביבת זמן ריצה ב-Colab Enterprise:

1. במסוף Google Cloud , נכנסים לדף Runtime Templates ב-Colab Enterprise ומוודאים שהפרויקט נבחר:

   כניסה לתבניות של סביבת זמן הריצה

2. לוחצים על תבנית חדשה. מופיע הדף Create new runtime template.

3. בקטע Runtime basics (יסודות זמן הריצה):

   • בשדה השם המוצג, מזינים qdrant-connect.
   • בתפריט הנפתח Region, בוחרים באפשרות us-central1. זהו אותו אזור כמו באשכול GKE.

4. בקטע Configure compute (הגדרת מחשוב):

   • בתפריט הנפתח Machine type, בוחרים באפשרות e2-standard-2.
   • בשדה גודל הדיסק, מזינים 30.

5. בקטע רשתות ואבטחה:

   • ברשימה הנפתחת Network, בוחרים את הרשת שבה נמצא אשכול GKE.
   • ברשימה הנפתחת Subnetwork, בוחרים את רשת המשנה המתאימה.
   • מבטלים את הסימון של התיבה הפעלת גישה לאינטרנט לכולם.

6. כדי לסיים את יצירת תבנית זמן הריצה, לוחצים על יצירה. תבנית זמן הריצה תופיע ברשימה בכרטיסייה תבניות זמן ריצה.

יצירת סביבת זמן ריצה

כדי ליצור סביבת זמן ריצה ב-Colab Enterprise:

1. ברשימת תבניות זמן הריצה של התבנית שיצרתם, בעמודה פעולות, לוחצים על ואז על יצירת זמן ריצה. מופיעה החלונית Create Vertex AI Runtime.

2. כדי ליצור סביבת זמן ריצה שמבוססת על התבנית, לוחצים על Create.

3. בכרטיסייה Runtimes (זמני ריצה) שנפתחת, מחכים שהסטטוס ישתנה ל-Healthy (תקין).

ייבוא ה-Notebook

כדי לייבא את ה-notebook ב-Colab Enterprise:

1. עוברים לכרטיסייה המחברות שלי ולוחצים על ייבוא. מופיעה החלונית Import notebooks.

2. בקטע ייבוא מקור, בוחרים באפשרות כתובת URL.

3. בקטע כתובות URL של Notebook, מזינים את הקישור הבא:

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

4. לוחצים על Import.

התחברות לסביבת זמן הריצה והרצת שאילתות

כדי להתחבר לסביבת זמן הריצה ולהריץ שאילתות:

1. במחברת, ליד הלחצן Connect (חיבור), לוחצים על Additional connection options (אפשרויות חיבור נוספות). החלונית Connect to Vertex AI Runtime מופיעה.

2. לוחצים על התחברות לסביבת זמן ריצה ואז על התחברות לסביבת זמן ריצה קיימת.

3. בוחרים את זמן הריצה שהפעלתם ולוחצים על Connect (חיבור).

4. כדי להריץ את התאים ב-notebook, לוחצים על הלחצן Run cell לצד כל תא קוד.

ה-notebook מכיל גם תאי קוד וגם טקסט שמתאר כל בלוק קוד. הרצה של תא קוד מפעילה את הפקודות שלו ומציגה פלט. אפשר להריץ את התאים לפי הסדר, או להריץ תאים ספציפיים לפי הצורך.

הצגת מדדי Prometheus של האשכול

אשכול GKE מוגדר עם השירות המנוהל של Google Cloud ל-Prometheus, שמאפשר איסוף מדדים בפורמט Prometheus. השירות הזה מספק פתרון מנוהל באופן מלא למעקב ולהתראות, שמאפשר לאסוף, לאחסן ולנתח מדדים מהאשכול ומהאפליקציות שלו.

בתרשים הבא אפשר לראות איך Prometheus אוסף מדדים לגבי האשכול:

האשכול הפרטי של GKE בתרשים מכיל את הרכיבים הבאים:

• ‫Qdrant Pods שחושפים מדדים בנתיב / ובפורט 80. המדדים האלה מסופקים על ידי קונטיינר ה-sidecar שנקרא metrics.
• אוספים מבוססי-Prometheus שמעבדים את המדדים מה-Pods של Qdrant.
• משאב PodMonitoring ששולח את המדדים ל-Cloud Monitoring.

כדי לייצא את המדדים ולראות אותם, פועלים לפי השלבים הבאים:

1. יוצרים את המשאב PodMonitoring כדי לגרד מדדים לפי labelSelector:

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

   המניפסט pod-monitoring.yaml מתאר את המשאב 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. יוצרים לוח בקרה של Cloud Monitoring עם ההגדרות שצוינו ב-dashboard.json :

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

3. אחרי שהפקודה מורצת בהצלחה, עוברים אל לוחות הבקרה ב-Cloud Monitoring:

   לסקירה הכללית של מרכזי הבקרה

4. ברשימת לוחות הבקרה, פותחים את לוח הבקרה Qdrant Overview. יכול להיות שיעברו דקה או שתיים עד שהמדדים ייאספו ויוצגו.

   בלוח הבקרה מוצגות ספירות של מדדים מרכזיים:

   • אוספים
   • וקטורים מוטמעים
   • פעולות בהמתנה
   • צמתים פעילים

גיבוי של הגדרות האשכול

התכונה גיבוי ל-GKE מאפשרת לתזמן גיבויים קבועים של כל ההגדרות של אשכול GKE, כולל עומסי העבודה שנפרסו והנתונים שלהם.

במדריך הזה מוגדרת תוכנית גיבוי לאשכול GKE כדי לבצע גיבויים של כל עומסי העבודה, כולל Secrets ו-Volumes, מדי יום בשעה 3:00. כדי להבטיח ניהול יעיל של האחסון, גיבויים בני יותר משלושה ימים יימחקו באופן אוטומטי.

כדי להגדיר תוכניות גיבוי:

1. מפעילים את התכונה 'גיבוי ל-GKE' באשכול:

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

2. יוצרים תוכנית גיבוי עם תזמון יומי לכל מרחבי השמות באשכול:

   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
   

   הפקודה משתמשת במשתני הסביבה הרלוונטיים בזמן הריצה.

   הפורמט של שם האשכול הוא יחסי לפרויקט ולאזור שלכם, באופן הבא:

   projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME
   

   כשמופיעה הבקשה, מקלידים y.הפלט אמור להיראות כך:

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

   יכול להיות שיחלפו כמה דקות עד שהפעולה הזו תושלם בהצלחה. אחרי שההרצה מסתיימת, הפלט אמור להיראות כך:

   Created backup plan [qdrant-cluster-backup].
   

3. תוכנית הגיבוי החדשה שיצרתם, qdrant-cluster-backup, מופיעה במסוף Backup for GKE.

   מעבר לגיבוי ל-GKE

אם רוצים לשחזר את הגדרות הגיבוי השמורות, אפשר לעיין במאמר בנושא שחזור גיבוי.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים הנפרדים.

מחיקת הפרויקט

הדרך הכי קלה להימנע מחיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך הזה.

זהירות: כשמוחקים פרויקט:

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

אם אתם מתכננים להיעזר בכמה ארכיטקטורות, מדריכים או מדריכים למתחילים, מומלץ להשתמש שוב באותו פרויקט כדי לא לחרוג ממכסות הפרויקטים.

כדי למחוק פרויקט ב- Google Cloud :

gcloud projects delete PROJECT_ID

אם מחקתם את הפרויקט, סיימתם את הניקוי. אם לא מחקתם את הפרויקט, צריך למחוק את המשאבים בנפרד.

מחיקת משאבים ספציפיים

1. מגדירים משתני סביבה.

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

2. מריצים את הפקודה 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}
   

   מחליפים את FOLDER ב-gke-autopilot או ב-gke-standard, בהתאם לסוג אשכול GKE שיצרתם.

   כשמופיעה בקשה, כותבים yes.

3. כדי למצוא את כל הדיסקים שלא צורפו:

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

4. מוחקים את הדיסקים:

   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. מחיקת המאגר ב-GitHub:

   rm -r ~/kubernetes-engine-samples/
   

המאמרים הבאים

• מידע נוסף על Qdrant ב-GKE Marketplace
• מידע נוסף על תוכנת Qdrant בקוד פתוח
• נסו את האופרטור של Qdrant, שמציע ניהול מפתחות API, תמיכה ב-TLS עם ניהול אישורים ותזמון גיבויים.
• מידע ולמידה על שיטות מומלצות לפריסת מסדי נתונים ב-GKE
• פתרונות להרצת עומסי עבודה עתירי נתונים באמצעות GKE