‫الآن بعد أن أصبحت البودات قيد التشغيل ، ستحتاج
‫على الأرجح إلى تعريضها للخدمات الخارجية في وقت ما.
‫هذا يعني السماح لهم بقبول الاتصالات ، بطريقة
‫ما ، في مجموعتك أو من خارج مجموعتك.
‫في Kubernetes ، نستخدم الأمر kubectl
‫expose كأحد الطرق لإنشاء خدمة.
‫لقد ذكرنا الخدمة عدة مرات من قبل ، ولكن دعنا نتأكد من أننا
‫واضحون بشأن ماهية الخدمة. الخدمة هي نقطة نهاية
‫متسقة بحيث يمكن لأشياء أخرى داخل المجموعة
‫أو خارجها الوصول إليها.
‫عندما تقوم بإنشاء pods في Kubernetes
‫، فإنها لا تحصل تلقائيًا على اسم DNS للاتصال الخارجي
‫بعنوان IP ، ضيق.
‫قد ترغب في القيام بذلك من خلال إنشاء خدمة
‫فوق تلك المجموعة الحالية.
‫هناك طرق مختلفة إلى جانب أمر expose هذا
‫لإنشاء خدمة.
‫دعونا نركز على ما هو مشترك.
‫الشيء الشائع هنا هو DNS الأساسي.
‫إذا كنت تتذكر ، فقد ذكرنا ذلك مسبقًا كأحد الميزات الأساسية
‫لطائرة التحكم الخاصة بك.
‫ستكون هذه الخدمة خادم DNS الخاص بك لحل الأسماء
‫لكل هذه الأشياء.
‫علاوة على ذلك ، لاختيار
‫IP والمنفذ وكيفية القيام بذلك
‫، فإن كيفية وصول حركة المرور بشكل أساسي إلى
‫خدمتك هي وظيفة واحدة من أربعة أنواع مختلفة
‫من الخدمات. لنستعرض هذه الأمور بين الحين والآخر
‫، وسنستعرض بعض الأمثلة. لنبدأ بنوع الخدمة ClusterIP
‫، وهو الافتراضي.
‫في هذه الحالة ، فإن الجانب الأكثر أهمية هو أنه متاح
‫فقط في الكتلة.
‫هذا حقًا يتعلق بمجموعة Kubernetes من
‫القرون تتحدث إلى مجموعة أخرى من البودات.
‫هذا يحصل على ضغط DNS الخاص به ، صحيح.
‫سيكون هذا هو عنوان DNS في مستوى تحكم
‫DNS الأساسي. سيحصل على عنوان IP في
‫مساحة عنوان IP الافتراضية داخل الكتلة.
‫يسمح ذلك للبودات الأخرى التي تعمل في
‫الكتلة بالتحدث إلى هذه الخدمة باستخدام
‫منفذ الخدمة. إذا كنت تقوم بتشغيل تطبيق Nginx
‫، وكان يعمل على المنفذ 80 عندما أنشأت الخدمة ، فيمكن أن يكون عنوان
‫IP للخدمة موجودًا أيضًا على المنفذ 80.
‫هذا يحافظ على نوع من الاتساق هناك.
‫إذا فكرت في الأمر ، فهذا مشابه جدًا للطريقة التي تنشئ
‫بها خدمة في Swarm ، والآن بعد أن أصبحت الخدمات مختلفة قليلاً
‫في Swarm. لديهم فكرة مختلفة
‫من حولهم.
‫لكنها متسقة على الأقل عند إنشاء خدمة ، فهي تمنحك
‫عنوان IP الداخلي على موازن التحميل ،
‫إذا كنت تتذكر. يتم تشغيله على المنفذ الذي يعمل عليه التطبيق.
‫في هذه الحالة ، نقوم بشيء مشابه جدًا ، لكن علينا
‫إنشاء هذا الأمر باستخدام أمر كشف أو خيارات أخرى
‫سنتحدث عنها لاحقًا.
‫التالي هنا هو NodePort ، والذي يختلف اختلافًا
‫طفيفًا. إنه مربك بعض الشيء خارج الصندوق.
‫ClusterIP هو الإعداد الافتراضي ويعمل
‫دائمًا داخل الكتلة.
‫لا يحتاج إلى أي شيء خاص. لا يحتاج إلى أي
‫قواعد جدار حماية خارج المجموعة لحركة المرور
‫للوصول إليها. لكن ، ClusterIP جيد فقط في الكتلة.
‫تذكر ذلك. ClusterIP ، جيد في الكتلة.
‫تم تصميم NodePort لشيء خارج
‫المجموعة للتحدث إلى خدمتك من
‫خلال عناوين IP على العقد نفسها.
‫عندما تقوم بإنشاء NodePort ، ستحصل على
‫منفذ عالي على كل عقدة تم تعيينها لهذه
‫الخدمة.
‫بمجرد الحصول على ذلك ، يمكنك تحديث الأشياء الأخرى التي تحتاج إلى معرفتها
‫حول هذا المنفذ.
‫هذا المنفذ سيكون ميناء عالي.
‫لن تستخدم المنفذ 80 ، على سبيل المثال ، عند استخدام
‫هذا النوع. المفتاح لهذين الاثنين هو أنهما
‫متاحان دائمًا في أي مجموعة Kubernetes.
‫سواء كنت تستخدم أحد حلول البائعين السحابيين ، أو تقوم بتدوير
‫Kubernetes الخاصة بك ، أو تقوم بنشر حزمة مجمعة مثل Docker
‫Enterprise أو Rancher.
‫هؤلاء هم الذين سيعملون دائمًا خارج الصندوق.
‫التالي هو نوع موازن التحميل.
‫يستخدم هذا في الغالب في السحابة.
‫الفكرة هنا هي أنك تتحكم في موازن تحميل خارجي
‫من خلال سطر أوامر Kubernetes ، وهو أمر رائع
‫جدًا.
‫في الأساس ، هذه مجموعة من الأتمتة.
‫ما تفعله هنا في الخلفية ، عندما تقوم
‫بإنشاء موازن التحميل هذا ، فإنه سيقوم تلقائيًا
‫بإنشاء ClusterIP في NodePort بحيث
‫تكون متاحة. ثم سيتحدث إلى النظام
‫الخارجي. ربما يكون موازن تحميل AWS
‫أو بائع سحابي آخر. في الأساس ، ستأتي هذه من
‫موفري البنية التحتية الخاصة بك ، وسوف تسمح لـ Kubernetes
‫بالتحدث معهم من خلال بعض واجهات برمجة التطبيقات البعيدة
‫وتهيئتها لك. لذلك ، في حالة احتمال وجود
‫موازن تحميل AWS ، عند إنشاء هذا ، لا يقتصر
‫الأمر على إنشاء NodePorts و ClusterIPs في الخلفية
‫فحسب ، بل يخبر أيضًا موازن تحميل AWS بالتحدث إلى NodePorts.
‫بشكل أساسي ، هذا مجرد أتمتة ، صحيح.
‫يساعدك هذا في حفظ خطوة من الاضطرار إلى تشغيل بعض سطر أوامر
‫AWS ، أو واجهة الويب ، لإعداد موازن التحميل هذا
‫تلقائيًا من أجلك.
‫النتيجتان اللتان لديّهما لهذا الغرض هما التفكير
‫في الأمر لأن هذا مخصص فقط لحركة المرور القادمة إلى
‫مجموعتك من مصدر خارجي.
‫يتطلب موفر بنية تحتية يمنح Kubernetes
‫القدرة على التحدث إليه عن بُعد.
‫آخر أنواع الخدمات الأربعة هو ExternalName.
‫يتم استخدام هذا في كثير من الأحيان
‫، وليس له أي علاقة بالتحكم في حركة المرور
‫الواردة إلى خدماتك.
‫هذا يتعلق أكثر بالأشياء في مجموعتك التي تحتاج إلى التحدث
‫إلى الخدمات الخارجية.
‫تريد إنشاء أسماء DNS في نظام
‫DNS الأساسي بحيث يمكن لمجموعتك حل الأسماء
‫الخارجية التي ربما لم تتحكم
‫بها خارجيًا. أحد أسباب استخدامك
‫ExternalName هو قيامك بترحيل
‫الأشياء. فكر فيما إذا كان لديك تطبيق بعيد.
‫من المحتمل أن يكون لهذا التطبيق البعيد خارج مجموعة
‫Kubernetes اسم DNS بالفعل ، محكم.
‫إذا كنت ستنتقل ، قل شيئًا ما من تلك الخدمات الخارجية
‫إلى الخدمات الداخلية ، فقد تنظر في كيفية استخدام
‫ExternalName كبديل للتحكم في DNS
‫داخل سير عمل Kubernetes الخاص بك.
‫بعد
‫ذلك ، يمكن أن يكون لديك سطر أوامر واحد من Kubernetes بدلاً من القول
‫، أحتاج إلى تغيير DNS الخارجي لشيء ما لذلك يجب علي تشغيل
‫بعض الأدوات المساعدة الأخرى لخدمة DNS هذه.
‫أو ربما حتى شيء لا يوجد خلفه واجهة
‫برمجة تطبيقات. ربما مثل DNS للمؤسسة أو
‫شيء من هذا القبيل. يمكنك استخدام هذا
‫داخل مجموعاتك بحيث تبدأ الخدمات داخل مجموعاتك في
‫حل نقطة نهاية مختلفة عن تلك التي كانت لديهم سابقًا والتي
‫كانت خارجية. أجد أنني أستخدمه فقط
‫عندما أحتاج إلى تغيير كيفية
‫خروج أشيائي من مجموعتي إلى بعض الخدمات الخارجية ،
‫لكن ليس لدي طريقة للتحكم في DNS عن بُعد لتلك الأشياء
‫الأخرى. لذا ، أفضل القيام بذلك
‫داخل Kubernetes وإنشاء بعض الأسماء الخارجية لأشياءي.
‫بعد ذلك ، عندما أرغب في تغييره ديناميكيًا في Kubernetes
‫لأشياءي داخل مجموعتي ، يمكنني القيام بذلك بسهولة تامة دون الحاجة إلى
‫التحدث إلى أي شيء آخر.
‫حسنا. سنختتم أنواع الخدمات
‫الأربعة هذه ، ولكن هناك طريقة أخرى يمكن أن تصل بها حركة المرور
‫إلى داخل مجموعتك.
‫هذا من خلال الدخول.
‫سنتحدث عن ذلك لاحقًا.
‫هذا مصمم خصيصًا لحركة مرور HTTP.
‫عندما نصل إلى هذه المحاضرة ، ستفهم سبب اختلاف ذلك قليلاً
‫عن أنواع الخدمات هذه.