عندما تبدأ في إنشاء المزيد والمزيد من خدمات Kubernetes، تبدأ المهام التي كانت بسيطة في البداية في أن تصبح أكثر تعقيدًا. على سبيل المثال، لا يمكن لفرق التطوير إنشاء خدمات أو عمليات نشر تحت نفس الاسم. إذا كان لديك الآلاف من البودات، فإن مجرد إدراجها سيستغرق الكثير من الوقت، ناهيك عن إدارتها بشكل صحيح. وهذا مجرد غيض من فيض.
دعونا نلقي نظرة على كيفية تسهيل مساحة الاسم لإدارة موارد Kubernetes. إذن ما هي مساحة الاسم؟ يمكن اعتبار مساحة الاسم بمثابة مجموعة افتراضية ضمن مجموعة Kubernetes الخاصة بك. يمكن أن يكون لديك مساحات أسماء متعددة معزولة عن بعضها البعض ضمن مجموعة Kubernetes واحدة. يمكنهم حقًا مساعدتك أنت وفرقك في التنظيم والأمان وحتى أداء النظام.
في معظم توزيعات Kubernetes، تخرج المجموعة من الصندوق بمساحة اسم تسمى "افتراضي". هناك في الواقع ثلاث مساحات أسماء يتعامل معها Kubernetes: الافتراضي، ونظام kube، وkube-public. حاليًا، لا يتم استخدام Kube-public كثيرًا.
يعد ترك مساحة اسم kube بمفردها فكرة جيدة، خاصة على نظام مُدار مثل Google Kubernetes Engine. يستخدم مساحة الاسم "الافتراضية" كمكان يتم فيه إنشاء خدماتك وتطبيقاتك. لا يوجد أي شيء خاص به على الإطلاق، باستثناء أنه تم تكوين Kubernetes خارج الصندوق لاستخدامه، ولا يمكنك إزالته. يعد هذا أمرًا رائعًا للبدء والأنظمة ذات الأداء المنخفض، لكنني لا أوصي باستخدام مساحة الاسم الافتراضية على الأنظمة الكبيرة. في الحالة الأخيرة، يمكن لفريق تطوير واحد بسهولة إعادة كتابة كود شخص آخر وكسر عمل فريق آخر دون أن يدرك ذلك.
لذلك، يجب عليك إنشاء مساحات أسماء متعددة واستخدامها لتقسيم خدماتك إلى وحدات يمكن التحكم فيها. يمكن إنشاء مساحة الاسم باستخدام أمر واحد. إذا كنت تريد إنشاء مساحة اسم باسم test، فاستخدم الأمر $ kubectl create namespace test أو ببساطة قم بإنشاء ملف YAML واستخدمه مثل أي مورد Kubernetes آخر.
يمكنك عرض جميع مساحات الأسماء باستخدام الأمر $ kubectl get namespace.
بمجرد الانتهاء من ذلك، سترى ثلاث مساحات أسماء مضمنة ومساحة اسم جديدة تسمى "اختبار". دعونا نلقي نظرة على ملف YAML بسيط لإنشاء جراب. ستلاحظ أنه لا يوجد ذكر لمساحة الاسم.
إذا كنت تستخدم kubectl لتشغيل هذا الملف، فسيقوم بإنشاء وحدة mypod في مساحة الاسم النشطة حاليًا. ستكون هذه هي مساحة الاسم الافتراضية حتى تقوم بتغييرها. هناك طريقتان لإخبار Kubernetes بمساحة الاسم التي تريد إنشاء المورد الخاص بك فيها. الطريقة الأولى هي استخدام علامة مساحة الاسم عند إنشاء مورد.
الطريقة الثانية هي تحديد مساحة الاسم في إعلان YAML.
إذا قمت بتحديد مساحة اسم في YAML، فسيتم دائمًا إنشاء المورد في مساحة الاسم تلك. إذا حاولت استخدام مساحة اسم مختلفة أثناء استخدام علامة مساحة الاسم، فسيفشل الأمر. الآن إذا حاولت العثور على جرابك، فلن تتمكن من القيام بذلك.
يحدث هذا بسبب تنفيذ كافة الأوامر خارج مساحة الاسم النشطة حاليًا. للعثور على حجرتك، تحتاج إلى استخدام علامة مساحة الاسم، ولكن هذا يصبح مملًا بسرعة، خاصة إذا كنت مطورًا في فريق يستخدم مساحة الاسم الخاصة به ولا يريد استخدام هذه العلامة لكل أمر على حدة. دعونا نرى كيف يمكننا إصلاح هذا.
خارج الصندوق، تسمى مساحة الاسم النشطة الخاصة بك الافتراضي. إذا لم تحدد مساحة اسم في المورد YAML، فستستخدم جميع أوامر Kubernetes مساحة الاسم الافتراضية النشطة هذه. لسوء الحظ، قد تفشل محاولة إدارة مساحة الاسم النشطة باستخدام kubectl. ومع ذلك، هناك أداة جيدة جدًا تسمى Kubens تجعل هذه العملية أسهل بكثير. عند تشغيل الأمر kubens، سترى جميع مساحات الأسماء مع تمييز مساحة الاسم النشطة.
لتبديل مساحة الاسم النشطة إلى مساحة اسم الاختبار، ما عليك سوى تشغيل أمر اختبار $kubens. إذا قمت بعد ذلك بتشغيل الأمر $kubens مرة أخرى، فسترى أنه تم الآن تخصيص مساحة اسم نشطة جديدة - test.
هذا يعني أنك لا تحتاج إلى علامة مساحة الاسم لرؤية الحجرة في مساحة الاسم الاختبارية.
بهذه الطريقة تكون مساحات الأسماء مخفية عن بعضها البعض، ولكن ليست معزولة عن بعضها البعض. يمكن لخدمة في مساحة اسم واحدة التواصل بسهولة تامة مع خدمة في مساحة اسم أخرى، وهو أمر مفيد جدًا في كثير من الأحيان. تعني القدرة على التواصل عبر مساحات أسماء مختلفة أن خدمة المطورين لديك يمكنها التواصل مع خدمة فريق تطوير آخر في مساحة اسم مختلفة.
عادةً، عندما يريد تطبيقك الوصول إلى خدمة Kubernetes، فإنك تستخدم خدمة اكتشاف DNS المضمنة وتعطي تطبيقك اسم الخدمة ببساطة. ومع ذلك، من خلال القيام بذلك، يمكنك إنشاء خدمة تحت نفس الاسم في مساحات أسماء متعددة، وهو أمر غير مقبول.
لحسن الحظ، من السهل الالتفاف حول هذا باستخدام النموذج الموسع لعنوان DNS. تعرض الخدمات في Kubernetes نقاط النهاية الخاصة بها باستخدام قالب DNS شائع. يبدو شيء من هذا القبيل:
عادةً ما تحتاج فقط إلى اسم الخدمة وسيقوم DNS تلقائيًا بتحديد العنوان الكامل.
ومع ذلك، إذا كنت بحاجة إلى الوصول إلى خدمة في مساحة اسم مختلفة، فما عليك سوى استخدام اسم الخدمة بالإضافة إلى اسم مساحة الاسم:
على سبيل المثال، إذا كنت تريد الاتصال بقاعدة بيانات الخدمة في مساحة اسم اختبارية، فيمكنك استخدام قاعدة بيانات العناوين
إذا كنت تريد الاتصال بقاعدة بيانات الخدمة في مساحة اسم المنتج، فاستخدم قاعدة البيانات.prod.
إذا كنت تريد حقًا عزل وتقييد الوصول إلى مساحة الاسم، فإن Kubernetes يتيح لك القيام بذلك باستخدام سياسات شبكة Kubernetes. سأتحدث عن هذا في الحلقة القادمة.
كثيرًا ما يُطرح علي السؤال، ما هو عدد مساحات الأسماء التي يجب علي إنشاؤها ولأي غرض؟ ما هي قطعة البيانات المُدارة؟
إذا قمت بإنشاء عدد كبير جدًا من مساحات الأسماء، فسوف تعترض طريقك. إذا كان هناك عدد قليل جدا منهم، فسوف تفقد كل فوائد هذا الحل. أعتقد أن هناك أربع مراحل رئيسية تمر بها كل شركة عند إنشاء هيكلها التنظيمي. اعتمادًا على مرحلة التطوير التي يمر بها مشروعك أو شركتك، قد ترغب في اعتماد استراتيجية مساحة اسم مناسبة.
تخيل أنك جزء من فريق صغير يعمل على تطوير 5-10 خدمات صغيرة ويمكنك بسهولة جمع كل المطورين في غرفة واحدة. في هذه الحالة، يكون من المنطقي تشغيل جميع خدمات المنتج في مساحة الاسم الافتراضية. بالطبع، لمزيد من المرونة، يمكنك استخدام مساحتي أسماء - بشكل منفصل لكل من prod وdev. وعلى الأرجح، يمكنك اختبار تطويرك على جهاز الكمبيوتر المحلي الخاص بك باستخدام شيء مثل Minikube.
لنفترض أن الأمور تغيرت وأن لديك الآن فريقًا سريع النمو يعمل على أكثر من 10 خدمات صغيرة في المرة الواحدة. يأتي وقت يكون فيه من الضروري استخدام عدة مجموعات أو مساحات أسماء، بشكل منفصل لكل من الإنتاج والتطوير. يمكنك تقسيم الفريق إلى عدة فرق فرعية بحيث يكون لكل منهم خدماته المصغرة الخاصة به ويمكن لكل فريق من هذه الفرق اختيار مساحة الاسم الخاصة به لتسهيل عملية إدارة تطوير البرامج وإصدارها.
مع اكتساب كل عضو في الفريق نظرة ثاقبة حول كيفية عمل النظام ككل، يصبح من الصعب أكثر فأكثر تنسيق كل تغيير مع جميع المطورين الآخرين. تزداد صعوبة محاولة تدوير مكدس كامل على جهازك المحلي كل يوم.
في الشركات الكبيرة، لا يعرف المطورون عمومًا من الذي يعمل على ماذا بالضبط. تتواصل الفرق باستخدام عقود الخدمة أو تستخدم تقنية شبكة الخدمة، التي تضيف طبقة تجريد عبر الشبكة، مثل أداة تكوين Istio. إن محاولة تشغيل مكدس كامل محليًا أمر غير ممكن بكل بساطة، وأنا أوصي بشدة باستخدام منصة التسليم المستمر (CD) مثل Spinnaker على Kubernetes. لذلك، تأتي نقطة يحتاج فيها كل أمر بالتأكيد إلى مساحة الاسم الخاصة به. يمكن لكل فريق أيضًا اختيار مساحات أسماء متعددة لبيئة التطوير وبيئة الإنتاج.
وأخيرا، هناك شركات ريادة الأعمال الكبيرة التي لا تعرف فيها مجموعة واحدة من المطورين حتى عن وجود مجموعات أخرى. قد تقوم مثل هذه الشركة عمومًا بتعيين مطورين خارجيين يتفاعلون معها من خلال واجهات برمجة التطبيقات الموثقة جيدًا. تحتوي كل مجموعة على عدة فرق والعديد من الخدمات الصغيرة. في هذه الحالة، تحتاج إلى استخدام جميع الأدوات التي تحدثت عنها سابقًا.
يجب ألا يقوم المبرمجون بنشر الخدمات يدويًا ويجب ألا يكون لديهم حق الوصول إلى مساحات الأسماء التي لا تهمهم. في هذه المرحلة، من المستحسن أن يكون لديك عدة مجموعات لتقليل "نطاق الانفجار" للتطبيقات سيئة التكوين، لتبسيط عمليات الفوترة وإدارة الموارد.
وبالتالي، فإن الاستخدام الصحيح لمساحات الأسماء من قبل مؤسستك يسمح لك بجعل Kubernetes أكثر قابلية للإدارة والتحكم والأمان والمرونة.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع 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