قدمت Amazon EKS مؤخرًا دعمًا لعمليات التراجع عن إصدار Kubernetes، مما يسمح للممارسين بإعادة مستوى التحكم في المجموعة إلى إصدار Kubernetes السابق خلال 7 أيام من الترقية في حالة ظهور مشكلات. تعمل هذه الميزة على تقليل مخاطر ترقيات المجموعة في مكانها من خلال منح الفرق شبكة أمان للتعافي بسرعة من التحديثات التي بها مشكلات.
تقوم EKS بإرجاع مكونات خادم Kubernetes API ومستوى التحكم مع الحفاظ على الكل etcd البيانات وأحمال العمل والأحجام المستمرة. وفقًا للوثائق، بالنسبة للمجموعات التي تقوم بتشغيل EKS Auto Mode، يقوم EKS تلقائيًا بإرجاع العقد العاملة ذات الوضع التلقائي قبل الرجوع إلى مستوى التحكم، مع خيارات لتسريع العملية أو إلغائها.
يوضح ميكاه والتر، كبير مهندسي الحلول في AWS، موضحًا السبب في أن “ترقية مستوى التحكم في Kubernetes كانت منذ فترة طويلة بمثابة باب ذو اتجاه واحد”:
مع إطلاق Kubernetes لثلاثة إصدارات ثانوية سنويًا، فإن الفرق التي تدير مئات المجموعات، خاصة في البيئات المنظمة، غالبًا ما تؤخر الترقيات تمامًا لأنهم غير واثقين من قدرتهم على التعافي إذا حدث خطأ ما. والنتيجة هي بقاء المجموعات على الإصدارات الأقدم، وفقدان تصحيحات الأمان، وتشغيلها في النهاية مقابل الجداول الزمنية الممتدة للدعم.
على عكس Amazon ECS، منسق الحاويات الخاص بـ AWS، فإن EKS عبارة عن خدمة AWS مُدارة تعمل على تشغيل مستوى التحكم Kubernetes والحفاظ عليه، مما يسمح للمطورين بنشر التطبيقات الموجودة في حاويات وتشغيلها.
تعمل عمليات التراجع عن إصدار واحد ثانوي في كل مرة، مما يعكس مسار الترقية المتزايد لـ EKS. يقوم EKS بتشغيل رؤى المجموعة للتحقق من جاهزية العودة إلى الحالة السابقة، وإظهار المشكلات مثل عدم تطابق إصدار العقدة أو تبعيات الوظائف الإضافية قبل المتابعة. يستخدم --force لتخطي هذه الشيكات.
افتقرت Kubernetes مفتوحة المصدر إلى التراجع عن مستوى التحكم، حيث أضاف KEP-4330 إصدارات تمت محاكاتها لتمكين التراجع، ولكن هذا القيد دفع المؤسسات إلى اعتماد حلول بديلة مثل فترات الخبز، والمجموعات المتداخلة، والتسجيلات التلقائية، ودورات الترقية الطويلة. لقد كانت إمكانية العودة إلى الحالة السابقة في EKS بمثابة طلب طويل الأمد من مجتمع AWS، حيث ناقش المطورون سابقًا العديد من الحلول البديلة. يعلق إسماعيل بيج، كبير مسؤولي السحابة وDevOps في Uniphore:
لقد أعطت AWS فرق EKS شيئًا كنا نطالب به منذ سنوات: العودة إلى الحالة السابقة لـ Kubernetes الأصلية (…) قبل ذلك، كان لدى الفرق حلان، وكلاهما باهظ الثمن: عمليات نشر المجموعة الزرقاء/الخضراء التي تضاعف تكلفة الأشعة تحت الحمراء أثناء الترقيات. اللقطات اليدوية التي استهلكت ساعات عمل هندسية وما زالت غير مضمونة للعمل بشكل نظيف.
AWS ليس أول مزود سحابي يضيف ميزات التراجع إلى مجموعات Kubernetes المُدارة: بينما يقدم Azure AKS دعمًا جزئيًا فقط، يقتصر على عمليات التراجع عن مجمع العقد، قدمت GKE عمليات التراجع عن الإصدار الثانوي لمستوى التحكم مع GKE 1.33، المبنية على قدرة Kubernetes الأولية التي طورتها Google مع المجتمع. يضيف والتر:
لمنحك التحكم في هذه العملية، قدمنا إلغاء واجهة برمجة التطبيقات (API) التي تتيح لك إيقاف التراجع عن العقدة في أي وقت. إذا قررت أن التراجع يستغرق وقتًا طويلاً أو كنت تريد تغيير النهج الذي تتبعه، فيمكنك إلغاء ميزانيات التعطيل وضبطها لتسريع الأمور، أو اختيار مسار مختلف للمضي قدمًا.
كتب كوري كوين، كبير الاقتصاديين السحابيين في The Duckbill Group، في رسالته الإخبارية:
زر التراجع عن ترقيات Kubernetes، لا يصل إلا بعد سنوات من قيام فرق العمليات ببناء فترات خبز واحتفالات لمدة شهر لتجنب الباب ذو الاتجاه الواحد.
يضيف أشرف قمودي، مهندس DevOps في Tnker، على LinkedIn:
قامت AWS بحل واحدة من أكبر مخاوف كل مهندسي Kubernetes.
تتوفر الآن عمليات التراجع عن إصدار Kubernetes دون أي تكلفة إضافية في جميع المناطق التي يتوفر فيها EKS. تنطبق عمليات التراجع عن مستوى التحكم على جميع مجموعات EKS، في حين تقتصر عمليات التراجع عن العقدة على المجموعات التي تستخدم الوضع التلقائي EKS. يتم دعم عمليات التراجع لإصدارات Kubernetes في كل من الدعم القياسي والموسع لـ EKS.
