تكوين تخزين الكائنات باستخدام مشغل Milvus

يستخدم Milvus MinIO أو S3 كمخزن كائنات لاستمرار الملفات واسعة النطاق، مثل ملفات الفهرس والسجلات الثنائية. يقدم هذا الموضوع كيفية تكوين تبعيات تخزين الكائنات عند تثبيت Milvus مع مشغل Milvus. لمزيد من التفاصيل، راجع تكوين تخزين الكائنات مع مشغل Milvus في مستودع مشغل Milvus.

يفترض هذا الموضوع أنك قمت بنشر مشغل Milvus.

تحتاج إلى تحديد ملف تكوين لاستخدام مشغل Milvus لبدء تشغيل مجموعة Milvus.

kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml

تحتاج فقط إلى تحرير قالب التعليمات البرمجية في milvus_cluster_default.yaml لتكوين تبعيات الطرف الثالث. تقدم الأقسام التالية كيفية تكوين تخزين الكائنات و etcd وPulsar على التوالي.

تكوين تخزين الكائنات

تستخدم مجموعة Milvus العنقودية MinIO أو S3 كمخزن كائنات لاستمرار الملفات واسعة النطاق، مثل ملفات الفهرس والسجلات الثنائية. أضف الحقول المطلوبة ضمن spec.dependencies.storage لتكوين تخزين الكائنات، الخيارات الممكنة هي external و inCluster.

تخزين الكائنات الداخلية

بشكل افتراضي، يقوم مشغل Milvus بنشر MinIO داخل المجموعة لـ Milvus. فيما يلي مثال على التكوين لتوضيح كيفية استخدام MinIO كمخزن كائنات داخلي.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    storage:
      inCluster:
        values:
          mode: standalone
          resources:
            requests:
              memory: 100Mi
        deletionPolicy: Delete # Delete | Retain, default: Retain
        pvcDeletion: true # default: false

بعد تطبيق التكوين أعلاه، سيتم تشغيل MinIO داخل الكتلة في الوضع المستقل مع حد ذاكرة يصل إلى 100 ميغابايت. لاحظ أن

• يحدد الحقل deletionPolicy سياسة الحذف الخاصة بـ MinIO داخل الكتلة. يتم تعيينه افتراضيًا على Delete ولديه Retain كخيار بديل.

  • Delete يشير إلى أن تخزين الكائنات داخل الكتلة يتم حذفه عند إيقاف مثيل Milvus الخاص بك.
  • Retain يشير إلى أنه يتم الاحتفاظ بمخزن الكائنات داخل الكتلة كخدمة تبعية لبدء تشغيل مثيل Milvus الخاص بك في وقت لاحق.

• يحدد الحقل pvcDeletion ما إذا كان سيتم حذف PVC(مطالبة وحدة التخزين الدائمة) عند حذف وحدة تخزين الكائنات داخل الكتلة MinIO.

الحقول الموجودة ضمن inCluster.values هي نفسها الموجودة في مخطط Milvus Helm، ويمكنك العثور عليها هنا.

تخزين الكائنات الخارجية

يشير استخدام external في ملف YAML القالب إلى استخدام خدمة تخزين كائنات خارجية. لاستخدام وحدة تخزين كائنات خارجية، تحتاج إلى تعيين الحقول بشكل صحيح ضمن spec.dependencies.storage و spec.config.minio في ملف Milvus CRD.

استخدام خدمة الويب Amazon Web Service (AWS) S3 كمخزن كائنات خارجي

• تكوين الوصول إلى AWS S3 بواسطة AK/SK

  يمكن الوصول إلى دلو S3 عادةً عن طريق زوج من مفتاح وصول ومفتاح سري للوصول. يمكنك إنشاء كائن Secret لتخزينها في Kubernetes الخاص بك على النحو التالي:

  # # change the <parameters> to match your environment
  apiVersion: v1
  kind: Secret
  metadata:
    name: my-release-s3-secret
  type: Opaque
  stringData:
    accesskey: <my-access-key>
    secretkey: <my-secret-key>
  

  ثم يمكنك تكوين دلو AWS S3 كمخزن كائن خارجي:

  # # change the <parameters> to match your environment
  apiVersion: milvus.io/v1beta1
  kind: Milvus
  metadata:
    name: my-release
    labels:
      app: milvus
  spec:
    # Omit other fields ...
    config:
      minio:
        # your bucket name
        bucketName: <my-bucket>
        # Optional, config the prefix of the bucket milvus will use
        rootPath: milvus/my-release
        useSSL: true
    dependencies:
      storage:
        # enable external object storage
        external: true
        type: S3 # MinIO | S3
        # the endpoint of AWS S3
        endpoint: s3.amazonaws.com:443
        # the secret storing the access key and secret key
        secretRef: "my-release-s3-secret"
  

• تكوين الوصول إلى AWS S3 بواسطة AssumeRole

  وبدلاً من ذلك، يمكنك جعل Milvus يصل إلى دلو AWS S3 الخاص بك باستخدام AssumeRole، بحيث يتم تضمين بيانات الاعتماد المؤقتة فقط بدلاً من AK/SK الفعلي الخاص بك.

  إذا كان هذا هو ما تفضله، فأنت بحاجة إلى إعداد دور على وحدة تحكم AWS الخاصة بك والحصول على ARN الخاص به، والذي عادةً ما يكون على شكل arn:aws:iam::<your account id>:role/<role-name>.

  ثم قم بإنشاء كائن ServiceAccount لتخزينه في Kubernetes الخاص بك على النحو التالي:

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: my-release-sa
    annotations:
      eks.amazonaws.com/role-arn: <my-role-arn>
  

  بمجرد تعيين كل شيء، قم بالرجوع إلى ServiceAccount أعلاه في ملف YAML القالب، وقم بتعيين spec.config.minio.useIAM إلى true لتمكين AssumeRole.

  apiVersion: milvus.io/v1beta1
  kind: Milvus
  metadata:
    name: my-release
    labels:
      app: milvus
  spec:
    # Omit other fields ...
    components:
      # use the above ServiceAccount
      serviceAccountName: my-release-sa
    config:
      minio:
        # enable AssumeRole
        useIAM: true
        # Omit other fields ...
    dependencies:
      storage:
        # Omit other fields ...
        # Note: you must use regional endpoint here, otherwise the minio client that milvus uses will fail to connect
        endpoint: s3.<my-bucket-region>.amazonaws.com:443
        secretRef: "" # we don't need to specify the secret here
  

استخدم Google Cloud Storage (GCS) كمخزن كائنات خارجي

تخزين كائنات AWS S3 ليس الخيار الوحيد. يمكنك أيضًا استخدام خدمة تخزين الكائنات من موفري السحابة العامة الآخرين، مثل Google Cloud.

• تكوين الوصول إلى GCS بواسطة AK/SK

  يشبه التكوين في الغالب تكوين استخدام AWS S3. ما زلت بحاجة إلى إنشاء كائن Secret لتخزين بيانات الاعتماد الخاصة بك في Kubernetes الخاص بك.

  # # change the <parameters> to match your environment
  apiVersion: v1
  kind: Secret
  metadata:
    name: my-release-gcp-secret
  type: Opaque
  stringData:
    accesskey: <my-access-key>
    secretkey: <my-secret-key>
  

  بعد ذلك، ما عليك سوى تغيير endpoint إلى storage.googleapis.com:443 وتعيين spec.config.minio.cloudProvider إلى gcp على النحو التالي:

  # # change the <parameters> to match your environment
  apiVersion: milvus.io/v1beta1
  kind: Milvus
  metadata:
    name: my-release
    labels:
      app: milvus
  spec:
    # Omit other fields ...
    config:
      minio:
        cloudProvider: gcp
    dependencies:
      storage:
        # Omit other fields ...
        endpoint: storage.googleapis.com:443
  

• تكوين وصول GCS عن طريق AssumeRole

  على غرار AWS S3، يمكنك أيضًا استخدام هوية عبء العمل للوصول إلى GCS ببيانات اعتماد مؤقتة إذا كنت تستخدم GKE كمجموعة Kubernetes الخاصة بك.

  يختلف الشرح التوضيحي لـ ServiceAccount عن ذلك الخاص بـ AWS EKS. تحتاج إلى تحديد اسم حساب خدمة GCP بدلاً من الدور ARN.

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: my-release-sa
    annotations:
      iam.gke.io/gcp-service-account: <my-gcp-service-account-name>
  

  بعد ذلك، يمكنك تهيئة مثيل Milvus الخاص بك لاستخدام ServiceAccount أعلاه وتمكين AssumeRole عن طريق تعيين spec.config.minio.useIAM إلى true على النحو التالي:

  labels:
      app: milvus
  spec:
    # Omit other fields ...
    components:
      # use the above ServiceAccount
      serviceAccountName: my-release-sa
    config:
      minio:
        cloudProvider: gcp
        # enable AssumeRole
        useIAM: true
        # Omit other fields ...  
  

ما التالي

تعرف على كيفية تكوين تبعيات Milvus الأخرى باستخدام مشغل Milvus:

• تكوين التخزين التعريفي باستخدام مشغل Milvus
• تكوين تخزين الرسائل باستخدام مشغل Milvus