مشاركة عبر

ترقية الوظيفة الإضافية لشبكة الخدمة المستندة إلى Istio لخدمة Azure Kubernetes

  • مقالة

تتناول هذه المقالة تجارب الترقية للوظيفة الإضافية لشبكة الخدمة المستندة إلى Istio لخدمة Azure Kubernetes (AKS).

يتم نشر الإعلانات حول إصدارات المراجعات الثانوية الجديدة أو التصحيحات إلى الوظيفة الإضافية شبكة الخدمة المستندة إلى Istio في ملاحظات إصدار AKS. لمعرفة المزيد حول جدول الإصدار ودعم مراجعات الوظيفة الإضافية الشبكات الخدمة، اقرأ نهج الدعم.

ترقية مراجعة ثانوية

تسمح الوظيفة الإضافية Istio بترقية المراجعة الثانوية باستخدام عملية ترقية الكناري. عند بدء الترقية، يتم نشر مستوى التحكم للمراجعة الجديدة (الكناري) جنبا إلى جنب مع مستوى التحكم الأولي (الثابت). يمكنك بعد ذلك تمرير أحمال عمل مستوى البيانات يدويا أثناء استخدام أدوات المراقبة لتتبع صحة أحمال العمل أثناء هذه العملية. إذا لم تلاحظ أي مشكلات في صحة أحمال العمل الخاصة بك، يمكنك إكمال الترقية بحيث تظل المراجعة الجديدة فقط على نظام المجموعة. وإلا، يمكنك العودة إلى المراجعة السابقة ل Istio.

تعتمد الترقيات المتوفرة على ما إذا كانت مراجعة Istio الحالية وإصدار نظام مجموعة AKS مدعومين:

  • يمكنك الترقية إلى المراجعة المدعومة التالية (n+1) أو تخطي مراجعة واحدة والترقية إلى n+2، طالما أن كليهما مدعوم ومتوافق مع إصدار نظام المجموعة.
  • إذا كانت المراجعة الحالية (n) والمراجعة التالية (n+1) غير مدعومة، يمكنك الترقية فقط إلى أقرب مراجعة معتمدة (n+2 أو أعلى)، ولكن ليس خارجها.
  • إذا كان إصدار نظام المجموعة ومراجعة Istio غير مدعومين، فيجب ترقية إصدار نظام المجموعة قبل بدء ترقية Istio.

إشعار

يمكن أن تكون الترقية من مراجعة غير مدعومة عرضة للخطأ، لذلك يوصى بإبقاء مراجعة Istio محدثة في جميع الأوقات. راجع تقويم دعم الوظيفة الإضافية Istio للتواريخ المقدرة للإصدار وانتهاء العمر الافتراضي وملاحظات إصدار Istio الأولية للمراجعة الجديدة للتغييرات الملحوظة.

يوضح المثال التالي كيفية الترقية من المراجعة asm-1-22 إلى asm-1-23 مع كافة أحمال العمل في default مساحة الاسم. الخطوات هي نفسها لجميع الترقيات الثانوية ويمكن استخدامها لأي عدد من مساحات الأسماء.

  1. استخدم الأمر az aks mesh get-upgrades للتحقق من المراجعات المتوفرة لنظام المجموعة كأهداف للترقية:

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    إذا كنت تتوقع أن ترى مراجعة أحدث لم يتم إرجاعها بواسطة هذا الأمر، فقد تحتاج إلى ترقية نظام مجموعة AKS أولا بحيث تكون متوافقة مع أحدث مراجعة.

  2. إذا قمت بإعداد تكوين شبكة لمراجعة الشبكة الموجودة على نظام المجموعة الخاص بك، تحتاج إلى إنشاء ConfigMap منفصلة مطابقة للمراجعة الجديدة في aks-istio-system مساحة الاسم قبل بدء ترقية الكناري في الخطوة التالية. ينطبق هذا التكوين في اللحظة التي يتم فيها نشر وحدة التحكم في المراجعة الجديدة على نظام المجموعة. يمكن العثور على مزيد من التفاصيل عن هذا الموضوع هنا.

  3. بدء ترقية الكناري من المراجعة asm-1-22 إلى asm-1-23 استخدام az aks mesh upgrade start:

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-23

    تعني ترقية الكناري نشر وحدة التحكم 1.23 جنبا إلى جنب مع وحدة التحكم 1.22. وهي تستمر في التعايش حتى تكمل الترقية أو تعيدها إلى حالتها السابقة.

  4. اختياريا، يمكن استخدام علامات المراجعة لتدحرج مستوى البيانات إلى المراجعة الجديدة دون الحاجة إلى إعادة تسمية كل مساحة اسم يدويا. يمكن أن تكون إعادة تسمية مساحات الأسماء يدويا عند نقلها إلى مراجعة جديدة مملة وعرضة للخطأ. تحل علامات المراجعة هذه المشكلة من خلال العمل كمعرفات مستقرة تشير إلى المراجعات.

    بدلا من إعادة تسمية كل مساحة اسم، يمكن لعامل تشغيل نظام المجموعة تغيير العلامة للإشارة إلى مراجعة جديدة. يتم تحديث جميع مساحات الأسماء المسماة بهذه العلامة في نفس الوقت. ومع ذلك، لا تزال بحاجة إلى إعادة تشغيل أحمال العمل للتأكد من إدخال الإصدار الصحيح من istio-proxy sidecars.

    لاستخدام علامات المراجعة أثناء الترقية:

    1. تثبيت istioctl CLI

    2. إنشاء علامة مراجعة للمراجعة الأولية. في هذا المثال، قمنا بتسمية :prod-stable

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system

    3. إنشاء علامة مراجعة للمراجعة المثبتة أثناء الترقية. في هذا المثال، قمنا بتسمية :prod-canary

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system

    4. تسمية مساحات أسماء التطبيقات لتعيين علامات المراجعة:

      # label default namespace to map to asm-1-22
kubectl label ns default istio.io/rev=prod-stable --overwrite

      يمكنك أيضا تسمية مساحات الأسماء مع istio.io/rev=prod-canary للمراجعة الأحدث. ومع ذلك، لا يتم تحديث أحمال العمل في مساحات الأسماء هذه إلى sidecar جديد حتى تتم إعادة تشغيلها.

      إذا تم إنشاء تطبيق جديد في مساحة اسم بعد تسميته، إدخال sidecar مقابل علامة المراجعة على مساحة الاسم هذه.

  5. تحقق من وحدات وحدة التحكم المقابلة لكل من asm-1-22 و asm-1-23 الموجودة:

    1. تحقق من istiod pods:

      kubectl get pods -n aks-istio-system

      مثال على الإخراج:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-22-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-22-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-23-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-23-f85f46bf5-8p9qx             1/1     Running   0          51m

    2. إذا تم تمكين الدخول، تحقق من pods الدخول:

      kubectl get pods -n aks-istio-ingress

      مثال على الإخراج:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-krq9w   1/1     Running   0          51m

      لاحظ أن جرابات بوابة الدخول لكلا المراجعتين يتم نشرها جنبا إلى جنب. ومع ذلك، تظل الخدمة وعنوان IP الخاص بها غير قابلين للتغيير.

  6. إعادة تسمية مساحة الاسم بحيث يتم تعيين أي جرابات جديدة إلى Sidecar Istio المقترنة بالمراجعة الجديدة ولوحة التحكم الخاصة بها:

    1. إذا كنت تستخدم علامات المراجعة، فاستبدل العلامة prod-stable نفسها لتغيير تعيينها:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      تحقق من تعيينات العلامة إلى المراجعة:

      istioctl tag list

      يجب أن تشير كلتا العلامتين إلى المراجعة المثبتة حديثا:

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-23   default
prod-stable   asm-1-23   ...

      في هذه الحالة، لا تحتاج إلى إعادة تسمية كل مساحة اسم على حدة.

    2. إذا لم تستخدم علامات المراجعة، يجب إعادة تسمية مساحات أسماء مستوى البيانات للإشارة إلى المراجعة الجديدة:

      kubectl label namespace default istio.io/rev=asm-1-23 --overwrite

    لا تؤثر إعادة التسمية على أحمال العمل حتى تتم إعادة تشغيلها.

  7. قم بتدحرج كل من أحمال عمل التطبيق بشكل فردي عن طريق إعادة تشغيلها. على سبيل المثال:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  8. تحقق من أدوات المراقبة ولوحات المعلومات لتحديد ما إذا كانت جميع أحمال العمل الخاصة بك تعمل في حالة صحية بعد إعادة التشغيل. استنادا إلى النتيجة، لديك خياران:

    1. إكمال ترقية الكناري: إذا كنت راضيا عن تشغيل جميع أحمال العمل في حالة صحية كما هو متوقع، يمكنك إكمال ترقية الكناري. يؤدي إكمال الترقية إلى إزالة مستوى التحكم الخاص بالمراجعة السابقة ويترك وراءه مستوى التحكم الخاص بالمراجعة الجديدة على نظام المجموعة. قم بتشغيل الأمر التالي لإكمال ترقية الكناري:

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    2. التراجع عن ترقية الكناري: في حالة ملاحظة أي مشكلات في صحة أحمال العمل الخاصة بك، يمكنك العودة إلى المراجعة السابقة ل Istio:

    • إعادة تسمية مساحة الاسم إلى المراجعة السابقة: إذا كنت تستخدم علامات المراجعة:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite

      أو، إذا لم تكن تستخدم علامات المراجعة:

      kubectl label namespace default istio.io/rev=asm-1-22 --overwrite

    • التراجع عن أحمال العمل لاستخدام sidecar المطابق لمراجعة Istio السابقة عن طريق إعادة تشغيل أحمال العمل هذه مرة أخرى:

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>

    • التراجع عن مستوى التحكم إلى المراجعة السابقة:

      az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER

    يمكن إزالة علامة المراجعة prod-canary :

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. إذا تم إعداد تكوين الشبكة مسبقا للمراجعات، يمكنك الآن حذف ConfigMap للمراجعة التي تمت إزالتها من نظام المجموعة أثناء الإكمال/التراجع.

ترقيات المراجعة الثانوية مع بوابة الدخول

إذا كنت تستخدم حاليا بوابات دخول Istio وتجري ترقية طفيفة للمراجعة، فضع في اعتبارك أن وحدات الجراب / عمليات النشر الخاصة ببوابة دخول Istio يتم نشرها لكل مراجعة. ومع ذلك، نقدم خدمة LoadBalancer واحدة عبر جميع جرابات بوابة الدخول عبر مراجعات متعددة، لذلك يظل عنوان IP الخارجي/الداخلي لبوابات الدخول دون تغيير طوال عملية الترقية.

وبالتالي، أثناء ترقية الكناري، عند وجود مراجعتين في وقت واحد على نظام المجموعة، تخدم جرابات بوابة الدخول لكلا المراجعتين حركة المرور الواردة.

ترقيات المراجعة الثانوية مع تخصيصات التحجيم التلقائي للجراب الأفقي

إذا قمت بتخصيص إعدادات التحجيم التلقائي للحجيرة الأفقية (HPA) ل Istiod أو بوابات الدخول، فلاحظ السلوك التالي لكيفية تطبيق إعدادات HPA عبر كلا المراجعتين للحفاظ على التناسق أثناء ترقية الكناري:

  • إذا قمت بتحديث مواصفات HPA قبل بدء الترقية، تطبيق الإعدادات من المراجعة الحالية (المستقرة) على HPAs لمراجعة الكناري عند تثبيت وحدة التحكم الجديدة.
  • إذا قمت بتحديث مواصفات HPA أثناء ترقية الكناري قيد التقدم، فإن مواصفات HPA للمراجعة المستقرة ستكون لها الأسبقية وسيتم تطبيقها على HPA لمراجعة الكناري.
    • إذا قمت بتحديث HPA للمراجعة الثابتة أثناء الترقية، تحديث مواصفات HPA لمراجعة الكناري لتعكس الإعدادات الجديدة المطبقة على المراجعة الثابتة.
    • إذا قمت بتحديث HPA لمراجعة الكناري أثناء الترقية، سيتم إرجاع مواصفات HPA لمراجعة الكناري إلى مواصفات HPA للمراجعة الثابتة.

ترقية إصدار التصحيح

  • يتم نشر معلومات توفر إصدار التصحيح الإضافي Istio في ملاحظات إصدار AKS.
  • يتم طرح التصحيحات تلقائيا لوحدات istiod و ingress كجزء من إصدارات AKS هذه، والتي تحترم defaultنافذة الصيانة المخطط لها التي تم إعدادها للمجموعة.
  • يحتاج المستخدم إلى بدء التصحيحات إلى وكيل Istio في أحمال العمل الخاصة به عن طريق إعادة تشغيل pods لإعادة التشغيل:

    • تحقق من إصدار وكيل Istio المخصص للقرون الجديدة أو التي تمت إعادة تشغيلها. هذا الإصدار هو نفس إصدار istiod و Istio ingress pods بعد تصحيحها:

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      مثال على الإخراج:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"

    • تحقق من إصدار صورة وكيل Istio لجميع pods في مساحة الاسم:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      مثال على الإخراج:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

    • لتشغيل إعادة التشغيل، أعد تشغيل أحمال العمل. على سبيل المثال:

      kubectl rollout restart deployments/productpage-v1 -n default

    • للتحقق من أنها الآن على الإصدارات الأحدث، تحقق من إصدار صورة وكيل Istio مرة أخرى لجميع pods في مساحة الاسم:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      مثال على الإخراج:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

إشعار

في حالة مواجهة أي مشكلات أثناء الترقيات، راجع مقالة حول استكشاف أخطاء ترقيات مراجعة الشبكة وإصلاحها