مرحبا ، habrozhiteli! لقد نشرنا مؤخرًا كتابًا عن الإصدار 1.10 من Kubernetes. استعرض المنشور المقطع "حلول الشبكات لل Kubernetes"
الشبكات هي موضوع واسع النطاق. هناك العديد من الطرق لتكوين شبكة بأجهزة وموقد وحاويات. Kubernetes لا يحد لك هذا. كل ما يصفه هذا النظام الأساسي هو نموذج شبكة رفيع المستوى مع مساحة عنوان مسطحة للموقد. ضمن هذه المساحة ، يمكنك تنفيذ العديد من الحلول الجيدة بقدرات مختلفة وبيئات مختلفة. في هذا القسم ، سوف ننظر إلى بعضها وسنحاول فهم مدى ملاءمتها لنموذج شبكة Kubernetes.
إنشاء جسور في مجموعات الأجهزة
أبسط بيئة هي مجموعة معدنية عارية ، وهي شبكة فعلية على مستوى L2. لتوصيل الحاويات بمثل هذه الشبكة ، يمكنك استخدام جسر Linux القياسي. هذا إجراء شاق إلى حد ما ، يتطلب تجربة مع أوامر شبكة Linux ذات المستوى المنخفض ، مثل brctl ، و ip addr ، و ip route ، و ip link ، و nsenter ، وما إلى ذلك. يمكنك البدء في تنفيذ هذا الحل مع الدليل التالي: blog.oddbit.com/
2014/08/11 / Four-to-to-Connect-a-do-doer / (ابحث عن قسم أجهزة Linux Bridge).
Contiv
Contiv هي شبكة للأغراض العامة الإضافية. وهي مصممة لربط الحاويات عبر CNI ويمكن استخدامها مع Docker (مباشرة) ، Mesos ، Docker Swarm ، وبطبيعة الحال ، Kubernetes. تتعامل Contiv مع سياسات الشبكة وتكرر جزئيًا كائنًا مشابهًا في Kubernetes. فيما يلي بعض ميزات هذه الشبكة الإضافية:
- دعم CNM في libnetwork ومواصفات CNI ؛
- محرك سياسة غني بالميزات يوفر الأمان ونشر التطبيق الذي يمكن التنبؤ به.
- أفضل أداء في الحاوية ؛
- شبكات متعددة ، عزل ، وشبكات فرعية متداخلة ؛
- تكامل IPAM واكتشاف الخدمة ؛
- مجموعة واسعة من الطوبولوجيا المادية:
أ) بروتوكولات الطبقة 2 (VLAN) ؛
ب) بروتوكولات الطبقة 3 (BGP) ؛
ج) شبكات التراكب ؛
د) Cisco SDN (ACI) ؛ - دعم IPv6 ؛
- سياسة قابلة للتخصيص وتخصيص المسار ؛
- التكامل مع قوالب التطبيق ، بما في ذلك ما يلي:
أ) تكوين عامل الميناء ؛
ب) مدير نشر Kubernetes ؛
ج) موازنة الحمل على الخدمات ، المضمنة في موازن الخدمات الصغيرة من النوع "الشرق والغرب" (شرق - غرب) ؛
د) عزل حركة المرور أثناء التخزين والتحكم في الوصول (على سبيل المثال ، الخ / القنصل) ونقل الشبكة وإدارتها.
يحتوي Contiv على العديد من الميزات. تنفذ هذه الأداة مجموعة واسعة من المهام وتدعم العديد من المنصات ، لذلك لست متأكدًا مما إذا كان سيكون الخيار الأفضل ل Kubernetes.
فتح vswitch
Open vSwitch هو حل ناضج لإنشاء محولات (برامج) افتراضية ، يدعمها العديد من اللاعبين الرئيسيين في السوق. يسمح لك نظام شبكة المحاكاة الافتراضية (OVN) ببناء طوبولوجيات الشبكات الافتراضية المختلفة. لديها وظيفة إضافية خاصة بـ Kubernetes ، ولكن من الصعب للغاية تكوينها (انظر دليل
github.com/openvswitch/ovn-kubernetes ). تحتوي الوظيفة الإضافية Linen CNI على ميزات أقل ، لكن تكوينها أسهل بكثير:
github.com/John-Lin/linen-cni . يظهر هيكل الكتان CNI في الشكل. 10.6.
يمكن لـ vSwitch دمج الخوادم الفعلية وأجهزة VM و pods / حاويات في شبكة منطقية واحدة. يدعم هذا النظام كل من التراكب والأوضاع المادية.
فيما يلي بعض ميزاته الرئيسية:
- معيار شبكة محلية ظاهرية 802.1Q مع جذع والموانئ العامة
- الربط NIC مع أو بدون LACP لتبديل مستوى أعلى
- NetFlow و sFlow® والنسخ المتطابق لتحسين الرؤية ؛
- سياسات جودة الخدمة (جودة الخدمة) زائد
- نفق عبر جنيف ، GRE ، VXLAN ، STT و LISP ؛
- كسر السيطرة في 802.1ag.
- OpenFlow 1.0 بالإضافة إلى العديد من الوظائف الإضافية ؛
- قاعدة بيانات المعاملات لتخزين التكوين مع الربط ل C و Python ؛
- إعادة توجيه عالية الأداء باستخدام وحدات Linux kernel.
Nuage Networks VCS
تعد الخدمات السحابية الافتراضية (VCS) نتاجًا من Nuage ، وهي عبارة عن منصة جيدة التطوير وقائمة على السياسة لبناء الشبكات المعرفة بالبرمجيات (الشبكات المعرفة بالبرمجيات ، SDN). هذا هو الحل على مستوى المؤسسة ، والذي يعتمد على النظام المفتوح Open vSwitch (لإعادة توجيه البيانات) ووحدة تحكم SDN متعددة الوظائف تعتمد على المعايير المفتوحة.
تجمع منصة Nuage بين قرون Kubernetes وبيئات الجهات الخارجية (الافتراضية والأجهزة) في شبكات تراكب شفافة وتتيح لك وصف السياسات التفصيلية للتطبيقات المختلفة. يمكّنك محرك التحليل في الوقت الفعلي من مراقبة رؤية وأمن تطبيقات Kubernetes.
بالإضافة إلى ذلك ، يمكن تثبيت جميع مكونات VCS كحاويات. لا توجد متطلبات أجهزة محددة.
قناة
القناة عبارة عن مزيج من مشروعين مفتوحين المصدر: كاليكو وفانيلا. ومن هنا الاسم. يتعامل مشروع Flannel ، الذي طوره فريق CoreOS ، مع إمكانات الربط الشبكي للحاويات ، في حين أن Calico مسؤولة عن سياسات الشبكة. في البداية ، تم تطويرها بشكل منفصل عن بعضها البعض ، ولكن المستخدمين أرادوا استخدامها معًا. أصبح مشروع Canal مفتوح المصدر الآن قالب نشر لتثبيت Calico و Flannel كإضافات CNI منفصلة. قامت شركة Tigera ، التي أنشأها مؤسسو Calico ، بدعم كلا المشروعين وحتى التخطيط المتكامل الأكثر تشددًا ، ولكن منذ إطلاق حلها الخاص للتواصل الآمن بين التطبيقات في Kubernetes ، تحولت الأولوية نحو تبسيط تكوين وتكامل Flannel و Calico بدلاً من تطوير حل موحد. في التين. 10.7 يوضح الوضع الحالي لنظام القناة ومدى ارتباطه بمنصات تزامن مثل Kubernetes و Mesos.
لاحظ أنه عند الدمج مع Kubernetes ، فإن Canal لا تصل إلى etcd مباشرة ، ولكن خادم Kubernetes API.
الفانيلا
Flannel هي شبكة افتراضية تزود كل عقدة بشبكة افتراضية للعمل مع أوقات تشغيل الحاوية. على كل عقدة ، يتم إطلاق وكيل flaneld ، مما يؤدي إلى رفع الشبكة الفرعية استنادًا إلى مساحة العنوان المحجوزة المخزنة في كتلة etcd. يتم تبادل الرزم بين الحاويات ، وبشكل عام ، العقدة بواسطة أحد الخوادم المتعددة. في أغلب الأحيان ، يستخدم الخادم UDP عبر جهاز TUN ، والذي يتم افتراضيًا المرور عبر الأنفاق عبر المنفذ 8285 (لا تنسَ فتحه في جدار الحماية الخاص بك).
في التين. يصف 10.8 بالتفصيل المكونات المختلفة لشبكة Flannel ، وأجهزة الشبكة الافتراضية التي تنشئها ، وكيف يتواصلون مع المضيف والموقد عبر جسر docker0. هنا يمكنك أيضًا مشاهدة عملية تغليف حزم UDP وحركتها بين العقد.
تقنيات الشبكات الأخرى مدعومة:
- vxlan - تغلف الحزم باستخدام VXLAN داخل النواة ؛
- host-gw - ينشئ مسارات IP للشبكات الفرعية من خلال عناوين IP للخادم البعيد. تجدر الإشارة إلى أن هذا يتطلب اتصالًا مباشرًا في طبقة الشبكة الثانية بين الخوادم التي تقوم بتشغيل Flannel ؛
- aws-vpc - إنشاء طرق IP في جدول توجيه Amazon VPC
- gce - تنشئ طرق IP في شبكة Google Compute Engine
- تخصيص - يؤدي تخصيص الشبكة الفرعية فقط ، ولكن ليس إعادة توجيه الحزمة ؛
- ali-vpc - لإنشاء مسارات IP في جدول توجيه Alicloud VPC.
مشروع كاليكو
Calico هو الحل الكامل للتواصل بين الحاويات وأمن الشبكة. يمكن دمجها مع جميع منصات التزامن الرئيسية وأنظمة التشغيل:
- Kubernetes (الوظيفة الإضافية لـ CNI) ؛
- Mesos (الوظيفة الإضافية لـ CNI) ؛
- عامل الميناء (إضافة على libnework) ؛
- OpenStack (الوظيفة الإضافية لـ Neutron).
يمكن أيضًا نشر Calico محليًا أو في سحابة عامة مع الحفاظ على جميع الميزات. يمكن أن يعتمد تطبيق سياسات الشبكة على الحمل ، والذي يوفر تحكمًا واضحًا في حركة المرور ويضمن وصول الحزم دائمًا إلى الوجهات المطلوبة. يمكن لـ Calico استيراد سياسات الشبكة تلقائيًا من منصات التنسيق. في الواقع ، فهو مسؤول عن تنفيذ سياسات الشبكة في Kubernetes.
رومانا
رومانا هو الحل الحديث للتواصل بين الحاويات. تم تصميمه في الأصل للاستخدام في السحابة ، ويعمل عند طبقة الشبكة الثالثة ، بالاعتماد على الطرق القياسية لإدارة عناوين IP. يسمح لك Romana بعزل الشبكات بالكامل عن طريق إنشاء بوابات وطرق لها باستخدام خوادم تستند إلى Linux. العمل في طبقة الشبكة الثالثة لا يتطلب التغليف. يتم تطبيق سياسة الشبكة على جميع نقاط النهاية والخدمات كجدار حماية موزع. يعمل Romana على تسهيل عمليات النشر الداخلية والهجينة بين الأنظمة الأساسية السحابية المختلفة ، حيث لم تعد بحاجة إلى تكوين شبكات تراكب افتراضية.
سمحت مؤخرًا في عناوين IP الظاهرية في Romana للمستخدمين المحليين بفتح الوصول إلى خدماتهم في الشبكات المحلية من المستوى الثاني ، باستخدام العناوين الخارجية ومواصفات الخدمة.
يدعي مطورو رومانا أن أسلوبهم يحسن الأداء بشكل كبير. في التين. يوضح الشكل 10.9 كيف يمكنك ، بالإضافة إلى تجنب تغليف VXLAN ، التخلص من الكثير من النفقات العامة.
نسج صافي
الملامح الرئيسية لمشروع Weave Net هي سهولة الاستخدام وقلة التهيئة. يستخدم تغليف VXLAN ويقوم بتثبيت DNS الصغير على كل عقدة. كمطور ، سوف تتعامل مع مستوى عالٍ من التجريد. بعد تسمية حاوياتك ، سيسمح لك Weave Net بالاتصال بالمنافذ القياسية وتمكين الخدمات المناسبة. يساعد هذا في نقل التطبيقات الحالية إلى منصات microservice و containerization. يوفر Weave Net وظيفة إضافية CNI للعمل مع Kubernetes و Mesos. بدءًا من Kubernetes 1.4 ، يمكن تحقيق التكامل مع Weave Net باستخدام أمر واحد ينشر DaemonSet:
kubectl apply -f https://git.io/weave-kube
تكون قرون Weave Net المستضافة على كل عقدة مسؤولة عن توصيل أي من حالات pod الأخرى بشبكة Weave. يدعم Weave Net واجهات برمجة التطبيقات مع سياسات الشبكة ، مما يوفر حلاً كاملاً وسهلاً للتكوين.
الاستخدام الفعال لسياسات الشبكة
تم تصميم سياسة شبكة Kubernetes للتحكم في حركة المرور التي يتم توجيهها إلى مدونات ومساحات أسماء محددة. عند إدارة المئات من الخدمات المصغرة التي تم نشرها (كما هو الحال غالبًا مع Kubernetes) ، فإن التواصل بين الموقد يحتل مكان الصدارة. من المهم أن نفهم أن هذه الآلية مرتبطة بشكل غير مباشر بالأمان فقط. إذا كان المهاجم قادرًا على اختراق الشبكة الداخلية ، فمن المحتمل أن يكون قادرًا على إنشاء مثيل خاص به من الموقد الذي يتوافق مع سياسة الشبكة ويسمح بالتواصل المجاني مع المداخل الأخرى. في القسم السابق ، نظرنا في حلول الشبكات المختلفة في Kubernetes ، مع التركيز على واجهات الشبكة. سنركز هنا على سياسة الشبكة المطبقة على رأس هذه الحلول ، على الرغم من أن كلا المكونين مترابطان بشكل وثيق.
هندسة سياسات الشبكة في Kubernetes
تحدد سياسة الشبكة كيف يمكن لمجموعات فرعية من المداخلات أن تتفاعل مع بعضها البعض ومع نقاط نهاية الشبكة الأخرى. يستخدم مورد NetworkPolicy العلامات لتحديد الموقد ويحدد قائمة بقواعد الأذونات التي تسمح بتوجيه حركة المرور إلى حالات الموقد المحددة (بالإضافة إلى ما هو مسموح به بالفعل من قبل سياسة العزل في مساحة الاسم المحددة).
»يمكن الاطلاع على مزيد من المعلومات حول الكتاب على
موقع الناشر»
المحتويات»
مقتطفاتحسم 20٪ على كوبون لـ
Khabrozhitel -
Kubernetesعند دفع النسخة الورقية من الكتاب ، يتم إرسال نسخة إلكترونية من الكتاب عن طريق البريد الإلكتروني.
ملاحظة: 7٪ من تكلفة الكتاب ستذهب إلى ترجمة كتب الكمبيوتر الجديدة ، قائمة الكتب التي سلمت إلى المطبعة
هنا .