تكوين تخزين الكائنات باستخدام مشغل 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: