شبكات Kubernetes: القرون

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

السنفات

ما هو تحت (جراب) Kubernetes؟ Sub هو كيان يتكون من حاوية واحدة أو أكثر مستضافة على نفس المضيف وتم تكوينه لمشاركة موارد مكدس الشبكة وموارد أخرى مثل وحدات التخزين. Pods هي لبنات البناء الأساسية التي تشكل التطبيقات التي تعمل على منصة Kubernetes. القرون حصة شبكة مكدس. في الممارسة العملية ، هذا يعني أن جميع الحاويات التي تشكل الموقد يمكنها التواصل مع بعضها البعض من خلال localhost . إذا كانت هناك حاوية في الموقد تقوم بتشغيل nginx للاستماع على المنفذ 80 ، وحاوية أخرى تعمل scrapyd ، يمكن لهذه الحاوية الوصول إلى الحاوية الأولى على http://localhost:80 . لا تبدو صعبة للغاية. الآن دعونا نسأل أنفسنا كيف يعمل هذا في الواقع. دعنا نلقي نظرة على موقف نموذجي عندما يتم تشغيل حاوية Docker على الجهاز المحلي.


حاوية عامل الميناء تعمل على الجهاز المحلي

إذا نظرت إلى هذا المخطط من الأعلى إلى الأسفل ، اتضح أن هناك eth0 لواجهة الشبكة المادية. يتم docker0 جسر docker0 ، ويتم veth0 واجهة الشبكة الافتراضية docker0 بالجسر. لاحظ أن veth0 و veth0 موجودة على نفس الشبكة ، في هذا المثال يكون 172.17.0.0/24 . على هذه الشبكة ، docker0 تعيين واجهة docker0 على عنوان IP 172.17.0.1 ، وهذه الواجهة هي العبارة الافتراضية لواجهة veth0 ، التي تم تعيين العنوان 172.17.0.2 . نظرًا veth0 إعداد مساحات أسماء الشبكات عند بدء تشغيل الحاوية ، لا ترى العمليات داخل الحاوية سوى واجهة veth0 وتتفاعل مع العالم الخارجي من خلال docker0 و eth0 . الآن قم بتشغيل الحاوية الثانية.


حاويات Docker التي تعمل على الجهاز المحلي

كما ترون في الرسم البياني أعلاه ، يتم تعيين واجهة الشبكة الافتراضية الجديدة veth1 إلى الحاوية الثانية ، وهي متصلة بنفس الجسر مثل الحاوية الأولى - docker0 . هذا وصف موجز إلى حد ما لما يحدث بالفعل. بالإضافة إلى ذلك ، تجدر الإشارة إلى أنه تم إنشاء اتصال بين الحاوية والجسر بفضل زوج من واجهات Ethernet الافتراضية المتصلة ، واحدة منها في مساحة اسم الحاوية والآخر في مساحة اسم شبكة الجذر. التفاصيل حول هذا يمكن العثور عليها هنا .

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


تستخدم الحاويات واجهة شبكة مشتركة

الآن تتفاعل الحاوية الثانية مع واجهة veth0 الموجودة بالفعل ، وليس مع واجهة veth1 الخاصة بها ، كما كان في المثال السابق. استخدام مثل هذا المخطط يؤدي إلى عدة عواقب. بادئ ذي بدء ، يمكننا الآن أن نقول أن كلتا الحاويتين 172.17.0.2 خارجيًا على نفس العنوان - 172.17.0.2 ، 172.17.0.2 داخل كل منهما الوصول إلى المنافذ الموجودة في localhost 172.17.0.2 التي فتحتها حاوية أخرى. بالإضافة إلى ذلك ، يعني هذا أن هذه الحاويات لا يمكنها فتح نفس المنافذ. هذا ، بالطبع ، قيد ، لكنه لا يختلف عن وجود قيود مماثلة في الموقف عندما تقوم عدة عمليات بفتح منافذ على نفس المضيف. باستخدام هذا النهج ، تحصل مجموعة من العمليات على جميع المزايا المرتبطة بتشغيل هذه العمليات في حاويات ، مثل ضعف التوصيلية والعزلة ، ولكن في نفس الوقت ، يمكن للعمليات تنظيم التعاون في أبسط بيئات الشبكات الحالية.

تطبق Kubernetes هذا النمط من خلال إنشاء حاوية خاصة لكل موقد الغرض الوحيد منها هو توفير واجهة شبكة لحاويات الموقد الأخرى. إذا قمت بالاتصال بالعقدة في نظام Kubernetes الذي تم تعيينه لغوي معين بواسطة ssh وقمت بتشغيل docker ps ، فسترى حاوية واحدة على الأقل تعمل باستخدام أمر pause . يقوم هذا الأمر بإيقاف العملية الحالية مؤقتًا حتى تصل إشارة SIGTERM . هذه الحاويات لا تفعل شيئًا على الإطلاق ، فهي في حالة "نائمة" وتنتظر هذه الإشارة. على الرغم من حقيقة أن الحاويات "المعلقة" لا تفعل شيئًا ، فهي ، إذا جاز التعبير ، "قلب" الموقد ، حيث توفر الحاويات الأخرى بواجهة شبكة افتراضية يمكن استخدامها للتفاعل مع بعضها البعض أو مع العالم الخارجي. نتيجة لذلك ، اتضح أنه في بيئة افتراضية تشبه ذلك ، فإن مخططنا السابق سيبدو كما هو موضح أدناه.


حاويات افتراضية

شبكة الموقد

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

تتكون كتلة Kubernetes من عقدة واحدة أو أكثر. العقدة هي نظام مضيف ، فعليًا أو افتراضيًا ، يحتوي على أدوات برمجية مختلفة وتبعياتها (بشكل أساسي Docker) ، بالإضافة إلى العديد من مكونات نظام Kubernetes. العقدة متصلة بالشبكة ، مما يسمح لها بتبادل البيانات مع العقد الأخرى في الكتلة. إليك ما قد يبدو عليه نظام المجموعة البسيط ذو العقدين.


كتلة بسيطة اثنين عقدة

إذا كانت المجموعة المعنية قيد التشغيل في بيئة سحابية مثل GCP أو AWS ، فإن هذا المخطط ينقل بدقة جوهر بنية الشبكة الافتراضية للمشاريع الفردية. لأغراض العرض التوضيحي ، 10.100.0.0/24 استخدام الشبكة الخاصة 10.100.0.0/24 في هذا المثال. نتيجة لذلك ، 10.100.0.1 تعيين العنوان 10.100.0.1 إلى 10.100.0.1 ، ويتم تعيين العنوانين 10.100.0.2 و 10.100.0.3 عقدتين. باستخدام هذه البنية ، يمكن لكل عقد التفاعل مع الآخر باستخدام واجهة الشبكة eth0 الخاصة به. الآن دعنا نتذكر أنه ضمن ، تشغيل على المضيف ، ليس على هذه الشبكة الخاصة. إنه متصل بالجسر في شبكة مختلفة تمامًا. هذه شبكة افتراضية موجودة فقط داخل عقدة محددة. لجعلها أكثر وضوحًا ، دعونا نعيد رسم المخطط السابق ، ونضيف إليه ما نسميه موقد افتراضي أعلاه.


القرون والعقد

يحتوي المضيف الموجود على يسار هذا الرسم التخطيطي على واجهة 10.100.0.2 بعنوان 10.100.0.2 ، العبارة الافتراضية التي هي جهاز التوجيه بعنوان 10.100.0.1 . يتم docker0 جسر docker0 بالعنوان 172.17.0.1 بهذه الواجهة ، 172.17.0.1 توصيله ، من خلال الواجهة الظاهرية 172.17.0.2 بالعنوان 172.17.0.2 ، بما نسميه الموقد هنا. تم إنشاء واجهة veth0 في حاوية مع وقف التنفيذ. يكون مرئيًا في الحاويات الثلاثة من خلال مكدس شبكة مشترك. نظرًا لحقيقة أن قواعد التوجيه المحلية قد تم تكوينها عند إنشاء الجسر ، سيتم إعادة توجيه أي حزمة تصل إلى eth0 172.17.0.2 عنوان الوجهة 172.17.0.2 إلى الجسر ، والتي ستعيد توجيهها إلى الواجهة الافتراضية veth0 . في حين أن كل هذا يبدو لائق جدا. إذا كان من المعروف أن المضيف الذي نناقشه يحتوي على العنوان 172.17.0.2 ، فيمكننا إضافة قاعدة إلى إعدادات جهاز التوجيه التي تصف أن الانتقال التالي لهذا العنوان هو 10.100.0.2 ، وبعد ذلك يجب إعادة توجيه الحزم من هناك إلى veth0 . ممتاز الآن دعونا نلقي نظرة على مضيف آخر.

يحتوي المضيف الموضح في الرسم على اليمين على واجهة فعلية eth0 بعنوان 10.100.0.3 . يستخدم نفس العبارة الافتراضية - 10.100.0.1 ، ومرة ​​أخرى ، يتم توصيله بجسر 172.17.0.1 بالعنوان 172.17.0.1 . هناك شعور بأن كل شيء لا يسير على ما يرام. في الواقع ، قد يختلف هذا العنوان عن العنوان المستخدم على المضيف الموجود على اليسار. تكون عناوين الجسور هنا كما هي لإظهار أسوأ سيناريو ممكن ، والذي ، على سبيل المثال ، يمكن أن يحدث إذا قمت بتثبيت Docker فقط واتركته تعمل كما يحلو لها. ولكن حتى لو كانت الشبكات المعنية مختلفة ، فإن مثالنا يبرز مشكلة أعمق ، وهي أن العقد عادةً لا تعرف أي شيء عن العناوين الخاصة المخصصة للجسور الموجودة في العقد الأخرى. ونحن بحاجة إلى معرفة ذلك - حتى نتمكن من إرسال حزم إلى هذه الجسور وللتأكد من أنها ستأتي إلى حيث تحتاج. من الواضح ، نحن هنا بحاجة إلى نوع من الكيان يسمح لنا بضمان التكوين الصحيح للعناوين في العقد المختلفة.

تمنحك منصة Kubernetes حلاً من خطوتين لهذه المشكلة. أولاً ، يقوم هذا النظام الأساسي بتعيين مساحة عنوان مشتركة للجسور في كل عقدة ثم يعين الجسور للعناوين في هذه المساحة استنادًا إلى العقدة التي يوجد بها الجسر. ثانياً ، يضيف Kubernetes قواعد التوجيه إلى البوابة الموجودة ، في حالتنا ، على 10.100.0.1 . تحدد هذه القواعد قواعد توجيه الحزم الموجهة لكل من الجسور. أي أنها تصف من خلالها يمكن الاتصال بالواجهة المادية eth0 مع كل من الجسور. هذا المزيج من واجهات الشبكة الافتراضية والجسور وقواعد التوجيه يسمى عادةً شبكة التراكب . عند الحديث عن Kubernetes ، عادة ما أسمي هذه الشبكة "شبكة الموقد" ، لأنها شبكة تراكب تسمح للقرون الموجودة في عقد مختلفة بالتواصل مع بعضها البعض. إليك الشكل الذي سيبدو عليه المخطط السابق بعد أن تبدأ آليات Kubernetes في العمل.


شبكة الموقد

يلفت الأنظار على الفور أنه يتم تغيير أسماء الجسر من docker0 إلى cbr0 . لا يستخدم Kubernetes جسور Docker القياسية. ما نسميه cbr هو اختصار لـ "جسر مخصص" ، أي أننا نتحدث عن بعض الجسور الخاصة. لست مستعدًا لتقديم قائمة كاملة بالاختلافات بين إطلاق حاويات Docker في أجهزة الكمبيوتر وتشغيلها على أجهزة الكمبيوتر العادية ، ولكن ما نتحدث عنه هنا هو أحد الاختلافات المهمة المماثلة. بالإضافة إلى ذلك ، يلزمك الانتباه إلى أن مساحة العنوان المخصصة للجسور في هذا المثال هي 10.0.0.0/14 . هذا العنوان مأخوذ من إحدى مجموعات التدريج لدينا ، والتي يتم نشرها على منصة Google Cloud ، وبالتالي فإن ما سبق هو مثال حقيقي للغاية على شبكة الموقد. قد يتم تعيين مجموعتك مختلفة تمامًا من العناوين. لسوء الحظ ، في الوقت الحالي ، لا توجد طريقة للحصول على معلومات حول هذه العناوين باستخدام الأداة المساعدة kubectl ، ولكن ، على سبيل المثال ، إذا كنت تستخدم GCP ، فيمكنك تشغيل أمر مثل gcloud container clusters describe <cluster> وإلقاء نظرة على خاصية clusterIpv4Cidr .

بشكل عام ، يمكن الإشارة إلى أنك عادة لا تحتاج إلى التفكير في كيفية عمل شبكة الموقد. عندما تتبادل البيانات الفرعية مع موقد آخر ، يحدث ذلك غالبًا من خلال خدمات Kubernetes. هذا قليلا من وكيل البرمجيات المعرفة. لكن عناوين شبكة الموقد تظهر في السجلات. في بعض الحالات ، خاصة أثناء تصحيح الأخطاء ، قد تحتاج إلى تعيين قواعد التوجيه بشكل صريح في شبكات الموقد. على سبيل المثال ، لا تتم معالجة حركة المرور التي تترك Kubernetes المرتبطة بأي عنوان في النطاق 10.0.0.0/8 افتراضيًا باستخدام NAT. لذلك ، إذا كنت تتفاعل مع الخدمات الموجودة على شبكة خاصة أخرى لها نفس نطاق العناوين ، فقد تحتاج إلى تكوين قواعد التوجيه التي تسمح لك بتنظيم تسليم الحزمة الصحيح.

ملخص

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

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