تعد Kubernetes أداة رائعة لتشغيل حاويات Docker في بيئة إنتاج مجمعة. ومع ذلك، هناك مشاكل لا يستطيع Kubernetes حلها. بالنسبة لعمليات نشر الإنتاج المتكررة، نحتاج إلى نشر أزرق/أخضر مؤتمت بالكامل لتجنب توقف العملية، والذي يحتاج أيضًا إلى التعامل مع طلبات HTTP الخارجية وإجراء عمليات إلغاء تحميل SSL. يتطلب هذا التكامل مع موازن التحميل مثل ha-proxy. التحدي الآخر هو القياس شبه التلقائي لمجموعة Kubernetes نفسها عند التشغيل في بيئة سحابية، على سبيل المثال، توسيع نطاق المجموعة جزئيًا أثناء الليل.
على الرغم من أن Kubernetes لا يحتوي على هذه الميزات، إلا أنه يوفر واجهة برمجة التطبيقات (API) التي يمكنك استخدامها لحل مشكلات مماثلة. تم تطوير أدوات النشر الآلي باللونين الأزرق/الأخضر وتوسيع نطاق مجموعة Kubernetes كجزء من مشروع Cloud RTI، الذي تم إنشاؤه استنادًا إلى المصدر المفتوح.
توضح لك هذه المقالة، وهي نسخة فيديو، كيفية إعداد Kubernetes مع مكونات أخرى مفتوحة المصدر لإنشاء بيئة جاهزة للإنتاج تقبل التعليمات البرمجية من التزام git دون توقف في الإنتاج.
لذلك، بمجرد أن تتمكن من الوصول إلى تطبيقاتك من العالم الخارجي، يمكنك البدء في إعداد الأتمتة بالكامل، أي الوصول بها إلى المرحلة حيث يمكنك تنفيذ التزام git والتأكد من أن التزام git هذا ينتهي في الإنتاج. بطبيعة الحال، عند تنفيذ هذه الخطوات، عند تنفيذ النشر، لا نريد أن نواجه فترة توقف عن العمل. لذا، فإن أي أتمتة في Kubernetes تبدأ بواجهة برمجة التطبيقات (API).
Kubernetes ليست أداة يمكن استخدامها بشكل منتج خارج الصندوق. بالطبع، يمكنك القيام بذلك، واستخدام kubectl وما إلى ذلك، ولكن لا تزال واجهة برمجة التطبيقات (API) هي الشيء الأكثر إثارة للاهتمام والمفيد في هذا النظام الأساسي. باستخدام واجهة برمجة التطبيقات (API) كمجموعة من الوظائف، يمكنك الوصول تقريبًا إلى أي شيء تريد القيام به في Kubernetes. يستخدم kubectl نفسه أيضًا REST API.
هذا هو REST، لذا يمكنك استخدام أي لغة أو أداة للعمل مع واجهة برمجة التطبيقات هذه، ولكن حياتك ستصبح أسهل بكثير بفضل المكتبات المخصصة. كتب فريقي مكتبتين من هذا القبيل: واحدة لـ Java/OSGi والأخرى لـ Go. والثاني لا يستخدم في كثير من الأحيان، ولكن على أي حال لديك هذه الأشياء المفيدة تحت تصرفك. إنها مشروع مفتوح المصدر مرخص جزئيًا. هناك العديد من المكتبات المشابهة للغات المختلفة، لذا يمكنك اختيار المكتبات التي تناسبك أكثر.
لذلك، قبل البدء في أتمتة النشر، يجب عليك التأكد من أن العملية لن تخضع لأي توقف. على سبيل المثال، يقوم فريقنا بإجراء عمليات نشر الإنتاج خلال منتصف اليوم عندما يستخدم الأشخاص التطبيقات بأقصى قدر ممكن، لذلك من المهم تجنب التأخير في هذه العملية. لتجنب التوقف عن العمل، يتم استخدام طريقتين: النشر باللون الأزرق/الأخضر أو التحديث المستمر. في الحالة الأخيرة، إذا كان لديك 2 نسخ متماثلة من التطبيق قيد التشغيل، فسيتم تحديثها بالتسلسل واحدة تلو الأخرى. تعمل هذه الطريقة بشكل رائع، ولكنها غير مناسبة إذا كان لديك إصدارات مختلفة من التطبيق تعمل في وقت واحد أثناء عملية النشر. في هذه الحالة، يمكنك تحديث واجهة المستخدم أثناء تشغيل الواجهة الخلفية للإصدار القديم، وسيتوقف التطبيق عن العمل. لذلك، من وجهة نظر البرمجة، العمل في مثل هذه الظروف أمر صعب للغاية.
وهذا هو أحد الأسباب التي تجعلنا نفضل استخدام النشر الأزرق/الأخضر لأتمتة نشر تطبيقاتنا. باستخدام هذه الطريقة، يجب عليك التأكد من تنشيط إصدار واحد فقط من التطبيق في المرة الواحدة.
تبدو آلية النشر باللون الأزرق/الأخضر هكذا. نستقبل حركة المرور لتطبيقاتنا من خلال ha-proxy، والتي تقوم بإعادة توجيهها لتشغيل النسخ المتماثلة للتطبيق من نفس الإصدار.
عند إجراء عملية نشر جديدة، نستخدم Deployer، الذي يتم إعطاؤه المكونات الجديدة ويقوم بنشر الإصدار الجديد. إن نشر إصدار جديد من التطبيق يعني "رفع" مجموعة جديدة من النسخ المتماثلة، وبعد ذلك يتم إطلاق هذه النسخ المتماثلة من الإصدار الجديد في حاوية جديدة منفصلة. ومع ذلك، لا يعرف ha-proxy شيئًا عنهم ولا يوجه أي عبء عمل إليهم حتى الآن.
لذلك، أولاً وقبل كل شيء، من الضروري إجراء فحص أداء للإصدارات الجديدة من التحقق من الصحة للتأكد من أن النسخ المتماثلة جاهزة لخدمة التحميل.
يجب أن تدعم كافة مكونات النشر شكلاً من أشكال التحقق من الصحة. يمكن أن يكون هذا فحصًا بسيطًا للغاية لمكالمة HTTP، عندما تتلقى رمزًا بالحالة 200، أو فحصًا أكثر تعمقًا، حيث تتحقق من اتصال النسخ المتماثلة بقاعدة البيانات والخدمات الأخرى، واستقرار اتصالات البيئة الديناميكية وما إذا كان كل شيء يبدأ ويعمل بشكل صحيح. يمكن أن تكون هذه العملية معقدة للغاية.
بعد أن يتحقق النظام من عمل كافة النسخ المتماثلة المحدثة، سيقوم Deployer بتحديث التكوين وتمرير confd الصحيح، والذي سيعيد تكوين ha-proxy.
فقط بعد ذلك سيتم توجيه حركة المرور إلى الكبسولة التي تحتوي على نسخ طبق الأصل من الإصدار الجديد، وسوف تختفي الكبسولة القديمة.
هذه الآلية ليست من سمات Kubernetes. لقد كان مفهوم النشر الأزرق/الأخضر موجودًا منذ فترة طويلة وكان يستخدم دائمًا موازن التحميل. أولاً، تقوم بتوجيه كل حركة المرور إلى الإصدار القديم من التطبيق، وبعد التحديث تقوم بنقلها بالكامل إلى الإصدار الجديد. يتم استخدام هذا المبدأ ليس فقط في Kubernetes.
سأقدم لك الآن مكون نشر جديدًا - Deployer، الذي يقوم بإجراء فحوصات السلامة، وإعادة تكوين الوكلاء، وما إلى ذلك. هذا مفهوم لا ينطبق على العالم الخارجي وهو موجود داخل Kubernetes. سأوضح لك كيف يمكنك إنشاء مفهوم Deployer الخاص بك باستخدام أدوات مفتوحة المصدر.
لذلك، أول شيء يفعله Deployer هو إنشاء وحدة تحكم النسخ المتماثل RC باستخدام Kubernetes API. تقوم واجهة برمجة التطبيقات (API) هذه بإنشاء وحدات وخدمات لمزيد من النشر، أي أنها تنشئ مجموعة جديدة تمامًا لتطبيقاتنا. بمجرد اقتناع RC بأن النسخ المتماثلة قد بدأت، ستقوم بإجراء فحص صحي على وظائفها. للقيام بذلك، يستخدم Deployer الأمر GET /health. يقوم بتشغيل مكونات الفحص المناسبة ويفحص كافة العناصر التي تدعم تشغيل المجموعة.
بعد أن أبلغت جميع القرون عن صحتها، يقوم Deployer بإنشاء عنصر تكوين جديد - وما إلى ذلك التخزين الموزع، والذي يستخدم داخليًا بواسطة Kubernetes، بما في ذلك تخزين تكوين موازن التحميل. نكتب البيانات إلى etcd، وأداة صغيرة تسمى confd Monitors etcd للبيانات الجديدة.
إذا اكتشف أي تغييرات في التكوين الأولي، فإنه يقوم بإنشاء ملف إعدادات جديد وينقله إلى ha-proxy. في هذه الحالة، يُعاد تشغيل ha-proxy دون فقدان أي اتصالات ويوجه التحميل إلى خدمات جديدة تمكن الإصدار الجديد من تطبيقاتنا من العمل.
كما ترون، على الرغم من وفرة المكونات، لا يوجد شيء معقد هنا. كل ما عليك فعله هو إيلاء المزيد من الاهتمام لواجهة برمجة التطبيقات (API) وما إلى ذلك. أريد أن أخبركم عن الناشر مفتوح المصدر الذي نستخدمه بأنفسنا - Amdatu Kubernetes Deployer.
إنها أداة لتنظيم عمليات نشر Kubernetes وتتميز بالميزات التالية:
- نشر أزرق/أخضر؛
- إعداد موازن التحميل الخارجي؛
- إدارة واصف النشر؛
- إدارة النشر الفعلي؛
- التحقق من وظائف فحوصات السلامة أثناء النشر؛
- تنفيذ متغيرات البيئة في القرون.
تم إنشاء أداة النشر هذه أعلى واجهة برمجة تطبيقات Kubernetes وتوفر واجهة برمجة تطبيقات REST لإدارة المقابض وعمليات النشر، بالإضافة إلى واجهة برمجة تطبيقات Websocket لتدفق السجلات أثناء عملية النشر.
إنه يضع بيانات تكوين موازن التحميل في إلخ، لذلك لا يتعين عليك استخدام ha-proxy مع دعم جاهز، ولكن يمكنك بسهولة استخدام ملف تكوين موازن التحميل الخاص بك. Amdatu Deployer مكتوب بلغة Go، مثل Kubernetes نفسه، وهو مرخص من Apache.
قبل أن أبدأ في استخدام هذا الإصدار من أداة النشر، استخدمت واصف النشر التالي، والذي يحدد المعلمات التي أحتاجها.
إحدى المعلمات المهمة لهذا الرمز هي تمكين علامة "useHealthCheck". نحن بحاجة إلى تحديد أنه يجب إجراء فحص السلامة أثناء عملية النشر. يمكن تعطيل هذا الإعداد عندما يستخدم النشر حاويات تابعة لجهات خارجية لا تحتاج إلى التحقق منها. يشير هذا الواصف أيضًا إلى عدد النسخ المتماثلة وعنوان URL للواجهة الأمامية التي يحتاجها وكيل ha. في النهاية توجد علامة مواصفات البود "podspec"، والتي تستدعي Kubernetes للحصول على معلومات حول تكوين المنفذ والصورة وما إلى ذلك. هذا واصف JSON بسيط إلى حد ما.
أداة أخرى تشكل جزءًا من مشروع Amdatu مفتوح المصدر هي Deploymentctl. يحتوي على واجهة مستخدم لتكوين عمليات النشر، وتخزين سجل النشر، ويحتوي على خطافات الويب لعمليات الاسترجاعات من مستخدمي ومطوري الجهات الخارجية. لا يجوز لك استخدام واجهة المستخدم نظرًا لأن Amdatu Deployer نفسه عبارة عن REST API، ولكن هذه الواجهة يمكن أن تجعل النشر أسهل بكثير بالنسبة لك دون الحاجة إلى استخدام أي واجهة برمجة تطبيقات. تتم كتابة Deploymentctl في OSGi/Vertx باستخدام Angular 2.
سأقوم الآن بإظهار ما ورد أعلاه على الشاشة باستخدام تسجيل مسجل مسبقًا حتى لا تضطر إلى الانتظار. سنقوم بنشر تطبيق Go بسيط. لا تقلق إذا لم تكن قد جربت Go من قبل، فهو تطبيق بسيط جدًا لذا يجب أن تكون قادرًا على اكتشافه.
نحن هنا نقوم بإنشاء خادم HTTP يستجيب فقط لـ /health، لذلك يقوم هذا التطبيق باختبار التحقق من الصحة فقط ولا شيء غير ذلك. إذا نجح الفحص، فسيتم استخدام بنية JSON الموضحة أدناه. فهو يحتوي على إصدار التطبيق الذي سيتم نشره بواسطة الناشر، والرسالة التي تراها في أعلى الملف، ونوع البيانات المنطقية - سواء كان تطبيقنا يعمل أم لا.
لقد خدعت قليلاً في السطر الأخير، لأنني وضعت قيمة منطقية ثابتة في أعلى الملف، والتي ستساعدني في المستقبل على نشر حتى التطبيقات "غير الصحية". سنتعامل مع هذا لاحقا.
اذا هيا بنا نبدأ. أولاً، نتحقق من وجود أي كبسولات قيد التشغيل باستخدام الأمر ~ kubectl get pods، واستنادًا إلى عدم وجود استجابة من عنوان URL للواجهة الأمامية، نتأكد من عدم إجراء أي عمليات نشر حاليًا.
بعد ذلك، على الشاشة، ترى واجهة Deploymentctl التي ذكرتها، والتي يتم فيها تعيين معلمات النشر: مساحة الاسم، واسم التطبيق، وإصدار النشر، وعدد النسخ المتماثلة، وعنوان URL للواجهة الأمامية، واسم الحاوية، والصورة، وحدود الموارد، ورقم المنفذ للتحقق من الصحة، الخ . تعتبر حدود الموارد مهمة جدًا، لأنها تتيح لك استخدام أكبر قدر ممكن من الأجهزة. هنا يمكنك أيضًا عرض سجل النشر.
إذا كررت الآن الأمر ~ kubectl get pods، فيمكنك أن ترى أن النظام "يتجمد" لمدة 20 ثانية، يتم خلالها إعادة تكوين ha-proxy. بعد ذلك، تبدأ الكبسولة، ويمكن رؤية نسختنا المتماثلة في سجل النشر.
لقد قمت بقص فترة الانتظار لمدة 20 ثانية من الفيديو، والآن يمكنك أن ترى على الشاشة أنه تم نشر الإصدار الأول من التطبيق. تم كل هذا باستخدام واجهة المستخدم فقط.
الآن دعونا نحاول الإصدار الثاني. للقيام بذلك، أقوم بتغيير رسالة التطبيق من "Hello, Kubernetes!" في "Hello, Deployer!"، يقوم النظام بإنشاء هذه الصورة ويضعها في سجل Docker، وبعد ذلك نقوم ببساطة بالنقر فوق الزر "Deploy" مرة أخرى في نافذة Deploymentctl. في هذه الحالة، يتم تشغيل سجل النشر تلقائيًا بنفس الطريقة التي حدث بها عند نشر الإصدار الأول من التطبيق.
يوضح الأمر ~ kubectl get pods أن هناك حاليًا إصدارين من التطبيق قيد التشغيل، لكن الواجهة الأمامية توضح أننا لا نزال نقوم بتشغيل الإصدار 2.
ينتظر موازن التحميل اكتمال فحص السلامة قبل إعادة توجيه حركة المرور إلى الإصدار الجديد. بعد 20 ثانية، ننتقل إلى حليقة ونرى أن لدينا الآن الإصدار 2 من التطبيق منشورًا، وقد تم حذف الإصدار الأول.
كان هذا بمثابة نشر تطبيق "صحي". دعونا نرى ما يحدث إذا قمت، بالنسبة لإصدار جديد من التطبيق، بتغيير المعلمة الصحية من صحيح إلى خطأ، أي أنني أحاول نشر تطبيق غير صحي فشل في التحقق من الصحة. يمكن أن يحدث هذا في حالة حدوث بعض أخطاء التكوين في التطبيق في مرحلة التطوير، وتم إرساله إلى الإنتاج بهذا النموذج.
كما ترون، يمر النشر بجميع الخطوات المذكورة أعلاه ويظهر ~kubectl get pods أن كلا البودتين قيد التشغيل. ولكن على عكس النشر السابق، يعرض السجل حالة المهلة. وهذا يعني أنه بسبب فشل الفحص الصحي، لا يمكن نشر الإصدار الجديد من التطبيق. ونتيجة لذلك، ترى أن النظام قد عاد إلى استخدام الإصدار القديم من التطبيق، وتم إلغاء تثبيت الإصدار الجديد ببساطة.
والشيء الجيد في هذا هو أنه حتى لو كان لديك عدد كبير من الطلبات المتزامنة الواردة إلى التطبيق، فلن يلاحظوا حتى وقت التوقف عن العمل أثناء تنفيذ إجراء النشر. إذا قمت باختبار هذا التطبيق باستخدام إطار عمل جاتلينج، والذي يرسل له أكبر عدد ممكن من الطلبات، فلن يتم إسقاط أي من هذه الطلبات. وهذا يعني أن مستخدمينا لن يلاحظوا حتى تحديثات الإصدار في الوقت الفعلي. إذا فشل، فسيستمر العمل على الإصدار القديم، وإذا نجح، فسيتحول المستخدمون إلى الإصدار الجديد.
هناك شيء واحد فقط يمكن أن يفشل - إذا نجح التحقق من الصحة، ولكن التطبيق يفشل بمجرد تطبيق عبء العمل عليه، أي أن الانهيار سيحدث فقط بعد اكتمال النشر. في هذه الحالة، سيتعين عليك الرجوع يدويًا إلى الإصدار القديم. لذلك، نظرنا في كيفية استخدام Kubernetes مع الأدوات مفتوحة المصدر المصممة لذلك. ستكون عملية النشر أسهل بكثير إذا قمت ببناء هذه الأدوات في مسارات البناء/النشر الخاصة بك. في الوقت نفسه، لبدء النشر، يمكنك استخدام إما واجهة المستخدم أو أتمتة هذه العملية بالكامل باستخدام، على سبيل المثال، الالتزام بالإتقان.
سيقوم خادم البناء الخاص بنا بإنشاء صورة Docker، ودفعها إلى Docker Hub أو أي سجل تستخدمه. يدعم Docker Hub خطاف الويب، حتى نتمكن من تشغيل النشر عن بعد عبر Deployer بالطريقة الموضحة أعلاه. بهذه الطريقة يمكنك أتمتة نشر التطبيق الخاص بك بالكامل إلى الإنتاج المحتمل.
دعنا ننتقل إلى الموضوع التالي - توسيع نطاق مجموعة Kubernetes. لاحظ أن الأمر kubectl هو أمر تغيير الحجم. وبالمزيد من المساعدة، يمكننا بسهولة زيادة عدد النسخ المتماثلة في مجموعتنا الحالية. ومع ذلك، من الناحية العملية، نريد عادة زيادة عدد العقد بدلاً من القرون.
في الوقت نفسه، قد تحتاج إلى زيادة ساعات العمل، وفي الليل، لتقليل تكلفة خدمات أمازون، قد تحتاج إلى تقليل عدد مثيلات التطبيق قيد التشغيل. هذا لا يعني أن زيادة عدد البودات فقط سيكون كافيًا، لأنه حتى إذا كانت إحدى العقد في وضع الخمول، فلا يزال يتعين عليك دفع ثمنها إلى أمازون. وهذا يعني أنه إلى جانب توسيع نطاق القرون، ستحتاج إلى زيادة عدد الأجهزة المستخدمة.
قد يكون هذا أمرًا صعبًا لأننا سواء استخدمنا Amazon أو خدمة سحابية أخرى، فإن Kubernetes لا يعرف شيئًا عن عدد الأجهزة المستخدمة. إنه يفتقر إلى أداة تسمح لك بتوسيع نطاق النظام على مستوى العقدة.
لذلك سيتعين علينا الاهتمام بكل من العقد والقرون. يمكننا بسهولة توسيع نطاق إطلاق العقد الجديدة باستخدام AWS API وأجهزة مجموعة Scaling لتكوين عدد العقد العاملة في Kubernetes. يمكنك أيضًا استخدام cloud-init أو برنامج نصي مشابه لتسجيل العقد في مجموعة Kubernetes.
يبدأ الجهاز الجديد في مجموعة Scaling، ويبدأ نفسه كعقدة، ويسجل في السجل الرئيسي ويبدأ العمل. بعد ذلك، يمكنك زيادة عدد النسخ المتماثلة للاستخدام على العقد الناتجة. يتطلب تقليص الحجم مزيدًا من الجهد، حيث يتعين عليك التأكد من أن مثل هذه الخطوة لا تؤدي إلى تدمير التطبيقات قيد التشغيل بالفعل بعد إيقاف تشغيل الأجهزة "غير الضرورية". لمنع مثل هذا السيناريو، تحتاج إلى تعيين العقد إلى الحالة "غير المجدولة". هذا يعني أن المجدول الافتراضي سيتجاهل هذه العقد عند جدولة كبسولات DaemonSet. لن يقوم المجدول بحذف أي شيء من هذه الخوادم، ولكنه لن يقوم أيضًا بتشغيل أي حاويات جديدة هناك. والخطوة التالية هي إخراج عقدة التصريف، أي نقل القرون الجاري تشغيلها منها إلى جهاز آخر، أو العقد الأخرى التي لديها القدرة الكافية لذلك. بمجرد التأكد من عدم وجود أي حاويات على هذه العقد، يمكنك إزالتها من Kubernetes. بعد ذلك، سوف يتوقفون ببساطة عن الوجود بالنسبة لـ Kubernetes. بعد ذلك، تحتاج إلى استخدام AWS API لتعطيل العقد أو الأجهزة غير الضرورية.
يمكنك استخدام Amdatu Scalerd، وهي أداة قياس أخرى مفتوحة المصدر تشبه AWS API. يوفر CLI لإضافة أو إزالة العقد في المجموعة. الميزة المثيرة للاهتمام هي القدرة على تكوين المجدول باستخدام ملف json التالي.
الكود الموضح يقلل من سعة المجموعة بمقدار النصف خلال فترة الليل. يقوم بتكوين عدد النسخ المتماثلة المتاحة والسعة المطلوبة لمجموعة Amazon. سيؤدي استخدام هذا المجدول تلقائيًا إلى تقليل عدد العقد في الليل وزيادتها في الصباح، مما يوفر تكلفة استخدام العقد من خدمة سحابية مثل Amazon. هذه الميزة ليست مدمجة في Kubernetes، ولكن استخدام Scalerd سيسمح لك بتوسيع نطاق هذا النظام الأساسي كيفما تريد.
أود أن أشير إلى أن الكثير من الناس يقولون لي: "كل هذا جيد وجيد، ولكن ماذا عن قاعدة البيانات الخاصة بي، والتي عادة ما تكون ثابتة؟" كيف يمكنك تشغيل شيء كهذا في بيئة ديناميكية مثل Kubernetes؟ في رأيي، لا ينبغي عليك القيام بذلك، ولا تحاول تشغيل مستودع بيانات في Kubernetes. هذا ممكن تقنيًا، وهناك دروس تعليمية على الإنترنت حول هذا الموضوع، لكنه سيعقد حياتك بشكل خطير.
نعم، هناك مفهوم المخازن الدائمة في Kubernetes، ويمكنك محاولة تشغيل مخازن البيانات مثل Mongo أو MySQL، ولكن هذه مهمة كثيفة العمالة. ويرجع ذلك إلى حقيقة أن مستودعات البيانات لا تدعم بشكل كامل التفاعل مع البيئة الديناميكية. تتطلب معظم قواعد البيانات تكوينًا كبيرًا، بما في ذلك التكوين اليدوي للمجموعة، ولا تحب القياس التلقائي والأشياء المشابهة الأخرى.
لذلك، لا ينبغي عليك تعقيد حياتك بمحاولة تشغيل مستودع بيانات في Kubernetes. تنظيم عملهم بالطريقة التقليدية باستخدام الخدمات المألوفة وتزويد Kubernetes ببساطة بالقدرة على استخدامها.
في ختام الموضوع، أود أن أعرفكم على منصة Cloud RTI المبنية على Kubernetes، والتي يعمل عليها فريقي. فهو يوفر تسجيلًا مركزيًا ومراقبة التطبيقات والمجموعات والعديد من الميزات المفيدة الأخرى التي ستكون مفيدة. يستخدم العديد من الأدوات مفتوحة المصدر مثل Grafana لعرض المراقبة.
كان هناك سؤال حول سبب استخدام موازن التحميل ha-proxy مع Kubernetes. سؤال جيد لأنه يوجد حاليًا مستويان لموازنة التحميل. لا تزال خدمات Kubernetes موجودة على عناوين IP الافتراضية. لا يمكنك استخدامها للمنافذ الموجودة على الأجهزة المضيفة الخارجية لأنه إذا قامت أمازون بتحميل مضيفها السحابي بشكل زائد، فسيتغير العنوان. ولهذا السبب نضع ha-proxy أمام الخدمات - لإنشاء بنية أكثر ثباتًا لحركة المرور للتواصل بسلاسة مع Kubernetes.
سؤال جيد آخر هو كيف يمكنك الاهتمام بتغييرات مخطط قاعدة البيانات عند القيام بالنشر باللون الأزرق/الأخضر؟ والحقيقة هي أنه بغض النظر عن استخدام Kubernetes، فإن تغيير مخطط قاعدة البيانات يعد مهمة صعبة. تحتاج إلى التأكد من توافق المخطط القديم والجديد، وبعد ذلك يمكنك تحديث قاعدة البيانات ثم تحديث التطبيقات نفسها. يمكنك تبديل قاعدة البيانات بسرعة ثم تحديث التطبيقات. أعرف أشخاصًا قاموا بتشغيل مجموعة قواعد بيانات جديدة تمامًا باستخدام مخطط جديد، وهذا خيار إذا كان لديك قاعدة بيانات بدون مخططات مثل Mongo، ولكنها ليست مهمة سهلة على أي حال. إذا لم تكن لديك أسئلة أخرى، شكرًا لك على اهتمامك!
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com