أفضل ممارسات Kubernetes. رسم خرائط الخدمات الخارجية

أفضل ممارسات Kubernetes. إنشاء
أفضل الممارسات Kubernetes حاويات صغيرة . منظمة Kubernetes مع
مساحة اسم أفضل ممارسات Kubernetes . اختبار الجدوى Kubernetes مع اختبارات الاستعداد والحيوية
أفضل الممارسات Kubernetes . تحديد الاستعلامات وحدود الموارد
أفضل ممارسات Kubernetes. قطع الاتصال الصحيح بالإنهاء

إذا كنت مثل معظم الأشخاص ، فمن المرجح أن تستخدم الموارد التي تعمل خارج مجموعتك. ربما تستخدم Taleo API لإرسال رسائل نصية أو تحليل الصور باستخدام Google Cloud Vision API.

إذا كنت تستخدم نفس نقطة النهاية - نقطة استقبال الطلب من جانب الخادم في جميع بيئاتك ولا تخطط لترحيل خوادمك إلى Kubernetes ، فمن الطبيعي تمامًا أن يكون لديك خدمة نقطة نهاية في التعليمات البرمجية مباشرة. ومع ذلك ، هناك العديد من السيناريوهات الأخرى. في سلسلة Kubernetes Best Practices هذه ، ستتعلم كيفية استخدام آليات Kubernetes المدمجة لاكتشاف الخدمات داخل وخارج المجموعة.

مثال على خدمة خارجية واسعة النطاق هي قاعدة بيانات تعمل خارج كتلة Kubernetes. على عكس قواعد البيانات السحابية مثل Google Cloud Data Store أو Google Cloud Spanner ، التي تستخدم نفس نقطة النهاية لجميع أنواع الوصول ، فإن معظم قواعد البيانات لها نقاط نهاية منفصلة لظروف مختلفة.
عادةً ما تتطلب منك أفضل الممارسات لاستخدام قواعد البيانات التقليدية ، مثل MySQL و MongoDB ، الاتصال بمكونات مختلفة لبيئات مختلفة. قد يكون لديك جهاز كبير لبيانات الإنتاج وآلة أصغر لبيئة الاختبار. سيكون لكل منهم عنوان IP الخاص به أو اسم المجال ، ولكن ربما لن ترغب في تغيير التعليمات البرمجية الخاصة بك عند الانتقال من بيئة إلى أخرى. لذلك ، بدلاً من الترميز الثابت لهذه العناوين ، يمكنك استخدام خدمة Kubernetes المدمجة لاكتشاف الخدمات الخارجية المستندة إلى DNS بنفس الطريقة المستخدمة في خدمات Kubernetes الأصلية.



افترض أنك تقوم بتشغيل قاعدة بيانات MongoDB في Google Compute Engine. ستظل عالقًا في هذا العالم المختلط حتى تتمكن من نقله إلى مجموعة.

لحسن الحظ ، يمكنك استخدام خدمات Kubernetes الثابتة لجعل حياتك أسهل قليلاً. في هذا المثال ، أنشأت خادم MongoDB باستخدام Google Cloud Launcher. نظرًا لأنه تم إنشاؤه على نفس الشبكة (أو مجموعة Kubernetes VPC) ، يتم الوصول إليه باستخدام عنوان IP داخلي عالي الأداء.



هذا هو الإعداد الافتراضي على Google Cloud ، لذا لا يتعين عليك تكوين أي شيء. الآن بعد أن أصبح لديك عنوان IP ، فإن الخطوة الأولى هي إنشاء خدمة. قد تلاحظ أنه لا يوجد محددات موقد لهذه الخدمة. أي أننا أنشأنا خدمة لن تعرف إلى أين نرسل حركة المرور. سيسمح لك ذلك بإنشاء كائن نقطة نهاية يدويًا ، والذي سيتلقى حركة المرور من هذه الخدمة.



يوضح المثال التالي من التعليمات البرمجية أن نقاط النهاية تحدد عنوان IP لقاعدة البيانات باستخدام نفس اسم mongo الخاص بالخدمة.



سيستخدم Kubernetes جميع عناوين IP للعثور على نقاط النهاية كما لو كانت حوامل Kubernetes عادية ، لذا يمكنك الآن الوصول إلى قاعدة البيانات باستخدام سلسلة اتصال بسيطة بالاسم أعلاه mongodb: // mongo. ومع ذلك ، ليست هناك حاجة لاستخدام عناوين IP في التعليمات البرمجية الخاصة بك على الإطلاق.

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

إذا كنت تستخدم قاعدة بيانات مستضافة على مضيف جهة خارجية ، فمن المرجح أن مالكي المضيف قدموا لك معرف مورد موحدًا لمعرف الموارد المنتظم (URI). لذلك إذا تم إعطاؤك عنوان IP ، يمكنك ببساطة استخدام الطريقة السابقة. يوضح هذا المثال أن لدي قاعدتي بيانات MongoDB مستضافة على مضيف mLab.



واحد منهم هو قاعدة بيانات للمطورين ، والآخر هو قاعدة بيانات الإنتاج. سلاسل الاتصال لقواعد البيانات هذه هي كما يلي - يوفر لك mLab معرف URI ديناميكي ومنفذ ديناميكي. كما ترون ، هم مختلفون.



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



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



ولكن نظرًا لأن الاسم الخارجي يستخدم إعادة توجيه CNAME ، فلا يمكنه تنفيذ إعادة توجيه المنفذ. لذلك ، لا ينطبق هذا الحل إلا على المنافذ الثابتة ولا يمكن استخدامه مع المنافذ الديناميكية. لكن المستوى المجاني من mLab Free ، يوفر للمستخدم رقم منفذ ديناميكي ، ولا يمكنك تغيير هذا. هذا يعني أنه من أجل التطوير والتحفيز ، تحتاج إلى أسطر أوامر اتصال مختلفة. الأخبار السيئة هي أنك ستحتاج إلى ترميز رقم المنفذ. إذن كيف تحصل على إعادة توجيه المنفذ للعمل؟

الخطوة الأولى هي الحصول على عنوان IP من URI. إذا قمت بتشغيل الأمر nslookup أو اسم المضيف أو ping لـ URI ، يمكنك الحصول على عنوان IP لقاعدة البيانات. إذا قامت الخدمة في نفس الوقت بإعادة العديد من عناوين IP إليك ، فيمكن عندئذٍ استخدام جميع هذه العناوين في نقاط نهاية الكائن.



ضع في اعتبارك أن عناوين IP الخاصة بـ URI قد تتغير بدون إشعار مسبق ، لذا فمن الخطر جدًا استخدامها في الإنتاج. باستخدام عنوان IP هذا ، يمكنك الاتصال بقاعدة بيانات بعيدة دون تحديد منفذ. وبالتالي ، تقوم خدمة Kubernetes بإعادة توجيه المنفذ بشفافية تامة.



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

يتبع قريبا جدا ...

القليل من الدعاية :)

أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟