‫إذا كنت تفكر في عمليات النشر الخاصة
‫بك وخدماتك عليها ، فربما تكون قد
‫أدركت أنه حتى الآن ، لم نتحدث عن OSI Layer 7 أو
‫توجيه اسم HTTP
‫أو توجيه DNS أو أي شيء تريد تسميته.
‫في
‫الأساس ، فكرة أنك إذا كنت على خادم به مواقع متعددة تحتاج إلى استخدام
‫نفس المنافذ ، صحيح. المنفذ 80 و 443 ، فأنت بحاجة
‫إلى شيء هناك يوجه إلى حاويات مختلفة ، بناءً
‫على شيء آخر غير الميناء فقط.
‫يُعرف ذلك في Kubernetes باسم Ingress.
‫إنه مورد محدد ، وليس بالضرورة موازن
‫تحميل أو أي شيء تنسبه إلى
‫خدمة ما.
‫إنه من الناحية الفنية شيء آخر يركز
‫حقًا على المشكلة الشائعة لمعظم المجموعات التي تريد
‫تشغيل الكثير من مواقع الويب المختلفة
‫، أو الحاويات المختلفة لعناوين URL
‫وأسماء مختلفة. هذا هو المكان الذي يركز عليه هذا المشروع
‫بأكمله هو مشروع Ingress.
‫لم يتم تثبيته ، افتراضيًا ، على مجموعة
‫Kubernetes الخاصة بك ، ولكن هناك ميزات رسمية له.
‫الطريقة التي يعمل بها هذا هي أن Kubernetes
‫لم يخترع وكيل HTTP.
‫إنهم يوفرون فقط آليات للوكلاء الآخرين التابعين
‫لجهات خارجية لاستخدام الميزات بحيث تقوم بتثبيت
‫الإدخال في المجموعة الخاصة بك.
‫بعد ذلك ، يمكنك إخبار تطبيقاتك ، بناءً على التطبيق الذي
‫تستخدمه ، بكيفية استخدام هذا الوكيل للوصول إلى الحاوية
‫الخاصة بك.
‫من الأمثلة الجيدة على ذلك أن يكون لديك موقع ويب أ. com ولديك موقع ويب
‫B. كوم.
‫ستكون هذه عمليتي نشر مختلفتين.
‫تحتاج إلى الحصول على نفس المنافذ بطريقة ما على جميع العقد الخاصة
‫بك ... 80443.
‫تحتاج إلى نقل المواقع المختلفة إلى الحاويات
‫المختلفة. هذا ما هو Ingress.
‫في Swarm ، لم يكن لدينا هذه الميزة خارج الصندوق.
‫لذلك ، كان عليك فقط نشر بعض الوكلاء
‫كحاوية ولم يكن لها أي علاقة خاصة بهذه
‫الحاوية. لم يفهم ما كان Ingress.
‫لكن ، Kubernetes يفعل ذلك.
‫عندما تذهب لإلقاء نظرة على الوثائق ، فإن النوع الافتراضي
‫للمثال الذي يتحدث عنه الجميع هو Nginx.
‫لقد استخدمنا Nginx خلال هذه الدورة التدريبية.
‫ربما يجب أن يكون هذا هو الشخص الذي يجب أن تجربه أولاً.
‫أنا أفضل شيء آخر.
‫أنا في الواقع أحب Traefik وسترى ذلك في بعض الأمثلة
‫، خاصة في دورة Swarm الخاصة بي.
‫عندما تراني أتحدث في المؤتمرات ، سأتحدث
‫غالبًا عن Traefik لأنه كان وكيلًا تم إنشاؤه في
‫عالم الحاويات.
‫كانت البداية تدور حول فكرة أن لدينا كل هذه
‫الحاويات سريعة الزوال تدور وتغلق ، ونحتاج
‫إلى إعادة برمجة وكيل ، وعلينا أن نقلق بشأن
‫SSL وجميع الأشياء الأخرى التي نحتاجها لمواقع
‫ويب متعددة في مجموعة الحاويات.
‫لذلك ، قاموا بتصميم هذا المنتج الجديد الذي ينتج الآن
‫منتجات أخرى. لديها شركة كاملة وراءها
‫الآن وعقود الدعم. قد ترغب في التحقق
‫من ذلك. هناك الكثير من البائعين الذين يصنعون هذه المكونات
‫الإضافية لـ Kubernetes ، بما في ذلك المكونات الرئيسية ، على حق.
‫يدعم HAProxy و F5 واللاعبون
‫الجدد مثل Envoy و Istio أيضًا أنواع الدخول.
‫سأقول
‫، كما تعلمون ، من الناحية الفنية ، لا تزال ميزة الإدخال نفسها تجريبية في 1. 15.
‫كل واحد من هؤلاء سيكون له تطبيقه الخاص اعتمادًا
‫على أي واحد تختاره.
‫F5 هو موازن خارجي لتحميل الأجهزة وهو أمر شائع
‫حقًا في المؤسسة.
‫من الواضح أن وحدة التحكم في Ingress الخاصة بها ستساعد
‫في التحكم في هذا المورد الخارجي من داخل Kubernetes.
‫بيت القصيد من كل هذا هو أنه عندما
‫تقوم مطوري التطبيقات بكتابة YAML
‫مع موظفي DevOps ، أو ربما مع فريق Ops
‫نفسه ، فإنهم قادرون على وضع التعليقات التوضيحية
‫في YAML التي يحتاجونها للدخول تحكم لمعرفة ما
‫يجب القيام به معهم.
‫في الأساس ، كيف أقوم بتوجيههم؟
‫ما هي الطرق الصحيحة؟ إلى أين آخذه؟
‫ما المنافذ التي أستخدمها؟ هل أنا أحصل على SSL
‫من أجلك؟ هل أحصل على شهادات؟ هل ستزودني
‫ببعض؟ تم التعامل مع كل تلك الأشياء.
‫أولاً ، أقترح عليك البحث في الموارد.
‫ربما فقط جرب Nginx بشكل افتراضي.
‫بالتأكيد ، إذا لم يكن لديك رأي ، فجرّب Traefik
‫لأنه سهل الاستخدام ، ولديه الكثير من الميزات ، بما
‫في ذلك Let's Encrypt للحصول تلقائيًا على شهادات لك ولمواقع الويب
‫الخاصة بك مباشرة خارج الصندوق.
‫إذا كنت تعرف متطلبات الأجهزة الخاصة بك ، أو متطلبات البرامج
‫لما تريد القيام به مع Ingress ، فهناك قائمة في الوثائق
‫التي يمكنك رؤيتها في الموارد هنا لجميع
‫خيارات Ingress المختلفة.