ترقية مجموعة Milvus باستخدام Milvus Operator

يصف هذا الدليل كيفية ترقية مجموعة Milvus 2.6.x إلى الإصدار v3.0.3 باستخدام Milvus Operator.

المتطلبات الأساسية

• مجموعة Kubernetes تحتوي على مجموعة Milvus 2.6.x تديرها Milvus Operator
• kubectl الوصول إلى المجموعة
• بيان الموارد المخصصة (CR) الكامل لـ Milvus المستخدم في النشر الحالي
• طريقة التثبيت وقوائم البيانات المستخدمة لـ Milvus Operator الحالي
• نسخة احتياطية حديثة من بيانات Milvus الوصفية والبيانات الدائمة

قيود قائمة انتظار الرسائل: عند الترقية إلى Milvus v3.0.3، يجب الحفاظ على اختيارك الحالي لقائمة انتظار الرسائل. لا يُدعم التبديل بين أنظمة قوائم انتظار الرسائل المختلفة أثناء الترقية. سيتوفر دعم تغيير أنظمة قوائم انتظار الرسائل في الإصدارات المستقبلية.

عملية الترقية

الخطوة 1: قم بعمل نسخة احتياطية من CR الحالي لـ Milvus

احفظ CR الحالي قبل تغيير النشر:

kubectl get milvus <instance-name> \
  --namespace <namespace> \
  --output yaml > milvus-before-upgrade.yaml

استخدم ملف البيانات المرجعية (manifest) المصدر للنشر الحالي الخاص بك كملف بيانات مرجعية للترقية. لا تقم بتطبيق ملف النسخ الاحتياطي المصدَّر مباشرةً دون إزالة البيانات الوصفية التي يديرها الخادم وحقول الحالة أولاً.

الخطوة 2: تأكيد إصدار Milvus Operator

تحقق من الصورة المستخدمة بواسطة Milvus Operator المثبت:

kubectl get deployments --all-namespaces \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.template.spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep milvus-operator

أبقت عملية الترقية التي تم التحقق من صحتها على إصدار Milvus Operator عند 1.3.0. احتفظ بإصدار Operator الذي يدير حاليًا نشر Milvus 2.6.x الخاص بك ما لم تتطلب سياسة الدعم الخاصة بك ترقية Operator منفصلة. لا تقم بتخفيض إصدار Operator الأحدث إلى الإصدار الذي تم اختباره. إذا كنت بحاجة إلى تغيير إصدار Operator، فاستخدم نفس طريقة التثبيت Helm أو kubectl ونفس اسم الإصدار ومساحة الاسم مثل التثبيت الحالي، ثم قم بالتحقق من صحة تغيير Operator قبل تحديث Milvus CR.

الخطوة 3: تحديث صورة Milvus

في بيان Milvus CR الكامل، قم بتغيير spec.components.image إلى الإصدار المستهدف. احتفظ بالوضع الحالي، وطوبولوجيا المكونات، وقائمة انتظار الرسائل، وetcd، والتخزين، وإعدادات التبعية الأخرى. يوضح المقتطف التالي الحقول التي يجب تأكيدها؛ لا تستبدل CR الكامل الخاص بك بهذا المقتطف.

قبل تطبيق CR المستهدف، تأكد من أن indexNode.replicas هو 0. استخدمت تهيئة Milvus 2.6.20 التي تم التحقق من صحتها هذا الإعداد بالفعل. احتفظ بالإعداد الصريح لعدم وجود نسخ متماثلة في CR المستهدف.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: <instance-name>
  namespace: <namespace>
spec:
  components:
    image: milvusdb/milvus:v3.0.3
    indexNode:
      replicas: 0

قم بتطبيق ملف CR الكامل:

kubectl apply --filename milvus.yaml

تحقق من الترقية

تحقق من حالة CR وحالة Pod وصور الحاويات:

kubectl get milvus <instance-name> \
  --namespace <namespace> \
  --output jsonpath='{.status.status}{"\t"}{.status.currentImage}{"\n"}'

kubectl get pods --namespace <namespace>

kubectl get pods --namespace <namespace> \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'

تأكد من أن CR الخاص بـ Milvus يُبلغ عن Healthy ، وأن جميع مكونات Milvus تستخدم milvusdb/milvus:v3.0.3 ، وأنه لا يوجد أي Pod لـ IndexNode قيد التشغيل، وأن المجموعات الحالية لا تزال قابلة للاستعلام والبحث. أكمل هذه الفحوصات قبل تمكين أي ميزة خاصة بالإصدار v3.0.3.