مقارنة شبكة خدمة Kubernetes

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

في الواقع ، أصبحت بنية الخدمات المصغرة و Kubernetes (غالبًا ما تكون "K8s") هي المعيار للتطبيقات القابلة للتطوير ، مما يجعل مشكلة إدارة الاتصالات بين الخدمات موضوعًا ساخنًا - وشبكات الخدمة حلًا جذابًا. لقد استخدمت بنفسي شبكات الخدمة في الإنتاج ، وتحديداً Linkerd و Istio وشكل سابق من السفراء. ولكن ماذا تفعل شبكات الخدمة بالضبط؟ أيهما أفضل للاستخدام؟ كيف تعرف ما إذا كان يجب عليك استخدام واحد على الإطلاق؟

للإجابة على هذه الأسئلة ، من المفيد فهم سبب تطوير شبكات الخدمة. تاريخيا ، كانت البنية التحتية التقليدية لتكنولوجيا المعلومات لها تطبيقات تعمل كوحدات متجانسة. تعمل خدمة واحدة على خادم واحد ؛ إذا احتاجت إلى سعة أكبر ، كان الحل هو توسيعها عموديًا من خلال توفير آلة أكبر.

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

للسماح بالاتصال بين الخدمات ، طورت هذه الشركات مكتبات داخلية: Finagle at Twitter و Hystrix at Netflix و Stubby at Google (التي أصبحت gRPC في 2016). تهدف هذه المكتبات إلى إصلاح المشكلات التي تثيرها بنية الخدمات المصغرة: الأمان بين الخدمات ووقت الاستجابة والمراقبة وموازنة التحميل. لكن إدارة مكتبة كبيرة تبعية - بلغات متعددة - أمر معقد ويستغرق وقتًا طويلاً.

في النهاية ، تم استبدال هذا النوع من المكتبات بوكيل سهل الاستخدام وخفيف الوزن. كانت هذه الوكلاء مستقلة خارجيًا عن طبقة التطبيق - يحتمل أن تكون شفافة بالنسبة للتطبيق - وأسهل في التحديث والصيانة والنشر. وهكذا ، ولدت شبكة الخدمة.

ما هي شبكة الخدمة؟

شبكة الخدمة هي طبقة البنية التحتية للبرامج للتحكم في الاتصال بين الخدمات ؛ يتكون بشكل عام من مكونين:

1. مستوى البيانات ، الذي يتعامل مع الاتصالات بالقرب من التطبيق. عادةً ما يتم نشر هذا مع التطبيق كمجموعة من وكلاء الشبكة ، كما هو موضح سابقًا.
2. مستوى التحكم ، وهو "عقل" شبكة الخدمة. يتفاعل مستوى التحكم مع الوكلاء لدفع التكوينات وضمان اكتشاف الخدمة ومركزية المراقبة.

لشبكات الخدمة ثلاثة أهداف رئيسية حول الاتصال بين الخدمات:

1. الاتصال
2. حماية
3. الملاحظة

الاتصال

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

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

أخيرًا ، توفر شبكات الخدمة التحكم في التوجيه في شكل تحويل حركة المرور والانعكاس.

حماية

في بنية الخدمات المصغرة التقليدية ، تتواصل الخدمات فيما بينها من خلال حركة مرور غير مشفرة. تعتبر حركة المرور الداخلية غير المشفرة في الوقت الحاضر ممارسة سيئة من حيث الأمان ، لا سيما بالنسبة للبنية التحتية السحابية العامة وشبكات الثقة الصفرية.

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

يمكن لشبكات الخدمة حتى فرض مصفوفات معقدة لسياسة التفويض ، مما يسمح أو يرفض حركة المرور بناءً على السياسات التي تستهدف بيئات وخدمات معينة.

الملاحظة

الهدف من شبكات الخدمة هو إبراز الاتصالات بين الخدمات. من خلال التحكم في الشبكة ، تفرض شبكة الخدمة إمكانية المراقبة ، وتوفر مقاييس الطبقة السابعة ، والتي بدورها تسمح بتنبيهات تلقائية عندما تصل حركة المرور إلى حد معين قابل للتخصيص.

عادةً ما يتم دعمه بواسطة أدوات خارجية أو مكونات إضافية مثل Jaeger أو Zipkin ، ويسمح هذا التحكم أيضًا بالتتبع عن طريق حقن رؤوس تتبع HTTP .

مزايا شبكة الخدمة

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

توفر إمكانية مراقبة شبكة الخدمة ، على وجه الخصوص ، أساليب تصحيح أخطاء وتحسين متعددة الاستخدامات. بفضل الرؤية الدقيقة والكاملة على التبادلات بين الخدمات ، يمكن للمهندسين - خاصةً SREs - استكشاف الأخطاء المحتملة وإصلاح أخطاء النظام بشكل أسرع . من خلال تتبع شبكة الخدمة ، يمكنهم متابعة طلب من دخوله إلى النظام (في موازن تحميل أو وكيل خارجي) وصولاً إلى الخدمات الخاصة داخل الحزمة. يمكنهم استخدام التسجيل لتعيين طلب وتسجيل وقت الاستجابة الذي يواجهه في كل خدمة. النتيجة النهائية: رؤى تفصيلية لأداء النظام .

توفر إدارة حركة المرور إمكانيات قوية قبل تكثيف الإصدار الكامل لإصدارات جديدة من الخدمة:

1. قم بإعادة توجيه النسب المئوية الصغيرة للطلبات.
2. والأفضل من ذلك ، عكس طلبات الإنتاج إلى إصدار جديد لاختبار سلوكه مع حركة المرور في الوقت الفعلي.
3. أ / ب اختبار أي خدمة أو مجموعة من الخدمات.

تعمل شبكات الخدمة على تبسيط جميع السيناريوهات المذكورة أعلاه ، مما يسهل تجنب و / أو التخفيف من أي مفاجآت في الإنتاج.

مقارنة شبكة خدمة Kubernetes

من نواحٍ عديدة ، تعتبر شبكات الخدمة هي المجموعة النهائية من الأدوات لبنية الخدمات المصغرة ؛ يعمل العديد منها على واحدة من أفضل أدوات تنسيق الحاويات ، Kubernetes. لقد اخترنا ثلاثة من شبكات الخدمة الرئيسية التي تعمل على Kubernetes اليوم: Linkerd (v2) و Istio و Consul Connect. سنناقش أيضًا بعض شبكات الخدمة الأخرى: Kuma و Traefik Mesh و AWS App Mesh. على الرغم من أنها أقل بروزًا حاليًا من حيث الاستخدام والمجتمع ، إلا أنها تعد بما يكفي للمراجعة هنا والحفاظ على علامات التبويب بشكل عام.

ملاحظة سريعة حول وكلاء Sidecar

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

هناك ميزتان رئيسيتان للنهج الجانبي لشبكات الخدمة:

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

لكن الصور الجانبية هي نعمة مختلطة بسبب تأثيرها المباشر على التطبيق:

• قد يؤدي تهيئة Sidecar إلى تعطيل آلية بدء التطبيق.
• تضيف وكلاء Sidecar وقت استجابة محتملاً أعلى تطبيقك.
• تضيف وكلاء Sidecar أيضًا بصمة موارد يمكن أن تكلف مبلغًا كبيرًا من المال على نطاق واسع.

بالنظر إلى هذه المزايا والعيوب ، غالبًا ما يكون النهج الجانبي موضوعًا للنقاش في مجتمع شبكة الخدمة. ومع ذلك ، فإن أربعة من شبكات الخدمة الست التي تمت مقارنتها هنا تستخدم وكيل Envoy sidecar ، ويستخدم Linkerd التنفيذ الجانبي الخاص به ؛ لا تستخدم Traefik Mesh العربات الجانبية في تصميمها.

مراجعة Linkerd

تعتبر Linkerd ، التي ظهرت لأول مرة في عام 2017 ، أقدم شبكة خدمة متداخلة في السوق. تم إنشاء Linkerd v1 بواسطة Buoyant (شركة بدأها مهندسان سابقان في Twitter) ، وكان مبنيًا على Finagle و Netty.

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

مع ذلك ، حصل Buoyant على فرصة للعمل مع نموذج إنتاج كامل واكتساب الخبرة منه وتطبيق هذه الحكمة. كانت النتيجة Conduit ، وهي إعادة كتابة Linkerd الكاملة للشركة التي تم إصدارها في 2018 وأعيدت تسميتها Linkerd v2 في وقت لاحق من ذلك العام. جلب Linkerd v2 معه العديد من التحسينات الجذابة ؛ منذ توقف التطوير النشط لـ Buoyant لـ Linkerd v1 منذ فترة طويلة ، تشير إشاراتنا لـ "Linkerd" في بقية هذه المقالة إلى الإصدار 2.

مفتوح المصدر بالكامل ، يعتمد Linkerd على وكيل محلي الصنع مكتوب في Rust لمستوى البيانات وعلى كود المصدر المكتوب في Go لمستوى التحكم.

الاتصال

وكلاء Linkerd لديهم ميزات إعادة المحاولة وانتهاء المهلة ولكن ليس لديهم كسر في الدائرة أو تأخير الحقن حتى كتابة هذه السطور. دعم الدخول واسع النطاق ؛ تفتخر Linkerd بالتكامل مع وحدات التحكم في الدخول التالية:

• ترافيك
• Nginx
• GCE
• سفير
• جلو
• محيط شكل
• كونغ

تقدم ملفات تعريف الخدمة في Linkerd إمكانات توجيه محسّنة ، مما يمنح المستخدم مقاييس وإعادة المحاولة وإعدادات المهلة ، كل ذلك على أساس كل مسار. بالنسبة لموازنة الحمل ، تقدم Linkerd حقنًا آليًا للوكيل ولوحة القيادة الخاصة بها ودعمًا أصليًا لـ Grafana.

حماية

يعد دعم mTLS في Linkerd ملائمًا من حيث أن إعداده الأولي يكون تلقائيًا ، كما هو الحال مع الدوران التلقائي اليومي للمفاتيح.

الملاحظة

من خارج الصندوق ، يمكن ملاحظة إحصائيات ومسارات Linkerd عبر CLI. على جانب واجهة المستخدم الرسومية ، تشمل الخيارات لوحات معلومات Grafana معدة مسبقًا ولوحة معلومات Linkerd أصلية.

يمكن لـ Linkerd التوصيل بمثيل بروميثيوس.

يمكن تمكين التتبع عبر وظيفة إضافية باستخدام OpenTelemetry (المعروف سابقًا باسم OpenCensus) باعتباره المُجمع ، ويقوم Jaeger بالتتبع بنفسه.

تثبيت

يتم تثبيت Linkerd عن طريق حقن وكيل جانبي ، ويتم ذلك عن طريق إضافة تعليق توضيحي إلى مواردك في Kubernetes. هناك طريقتان للذهاب حول هذا الموضوع:

1. باستخدام مخطط هيلم. (بالنسبة للكثيرين ، يعد Helm مدير التكوين والقالب الانتقال لموارد Kubernetes.)
2. تثبيت Linkerd CLI ، ثم استخدامه لتثبيت Linkerd في مجموعة.

الطريقة الثانية تبدأ بتنزيل وتشغيل برنامج نصي للتثبيت:

 curl -sL https://run.linkerd.io/install | sh

من هناك ، يوفر رابط أداة linkerd CLI مجموعة أدوات مفيدة تساعد في تثبيت باقي Linkerd والتفاعل مع مجموعة التطبيقات ومستوى التحكم.

linkerd check --pre سيقوم بإجراء جميع عمليات الفحص الأولية اللازمة لتثبيت Linkerd الخاص بك ، مما يوفر سجلات واضحة ودقيقة حول سبب عدم نجاح تثبيت Linkerd المحتمل حتى الآن. بدون --pre ، يمكن استخدام هذا الأمر لتصحيح الأخطاء بعد التثبيت.

الخطوة التالية هي تثبيت Linkerd في الكتلة عن طريق تشغيل:

 linkerd install | kubectl apply -f -

سيقوم Linkerd بعد ذلك بتثبيت العديد من المكونات المختلفة ذات بصمة موارد صغيرة جدًا ؛ ومن ثم ، فإنهم هم أنفسهم لديهم نهج الخدمات المصغرة:

• linkerd-controller ، والذي يوفر واجهة برمجة التطبيقات العامة التي يتفاعل معها CLI ولوحة القيادة
• linkerd-Identi ، الذي يوفر المرجع المصدق لتنفيذ mTLS
• حاقن البروكسي linkerd ، الذي يتولى حقن البروكسي عن طريق تغيير تكوين الكبسولة
• linkerd-web ، الذي يخدم لوحة تحكم تسمح بمراقبة عمليات النشر والبودات ، بالإضافة إلى مكونات Linkerd الداخلية

يؤسس Linkerd معظم تكوينه على CustomResourceDefinitions (CRDs). تعتبر هذه أفضل ممارسة عند تطوير برنامج إضافي لـ Kubernetes - إنها مثل تثبيت مكون إضافي بشكل دائم في مجموعة Kubernetes.

تتطلب إضافة التتبع الموزع - الذي قد يكون أو لا يكون ما يسعى إليه مستخدمو Linkerd بالفعل ، بسبب بعض الخرافات الشائعة - خطوة أخرى مع linkerd-collector و linkerd-jaeger. لذلك ، سننشئ أولاً ملف تكوين:

 cat >> config.yaml << EOF tracing: enabled: true EOF

لتمكين التتبع ، سنقوم بتشغيل:

 linkerd upgrade --config config.yaml | kubectl apply -f -

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

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

Flagger هي أداة تسليم تقدمية من شأنها تقييم ما يسميه Linkerd المقاييس "الذهبية" : "حجم الطلب ، ومعدل النجاح ، وتوزيعات زمن الوصول". (في الأصل ، استخدمت Google SREs مصطلح الإشارات الذهبية وتضمنت مصطلحًا رابعًا - التشبع - لكن Linkerd لا يغطيها لأن ذلك يتطلب مقاييس لا يمكن الوصول إليها بشكل مباشر ، مثل استخدام وحدة المعالجة المركزية والذاكرة.) يتتبع المُخبر هذه الإشارات أثناء تقسيم حركة المرور باستخدام حلقة التغذية الراجعة ؛ ومن ثم ، يمكنك تنفيذ إصدارات كناري مؤتمتة ومتوافقة مع المقاييس.

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

ملخص شبكة خدمة Linkerd

مزايا:

تستفيد Linkerd من خبرة منشئيها ، وهما مهندسان سابقان في Twitter عملوا على الأداة الداخلية Finagle ، وتعلموا لاحقًا من Linkerd v1. باعتبارها واحدة من شبكات الخدمة الأولى ، تتمتع Linkerd بمجتمع مزدهر (يضم Slack أكثر من 5000 مستخدم ، بالإضافة إلى أنه يحتوي على قائمة بريدية نشطة وخادم Discord) ومجموعة واسعة من الوثائق والبرامج التعليمية. أصبحت Linkerd ناضجة بإصدارها الإصدار 2.9 ، كما يتضح من اعتمادها من قبل الشركات الكبرى مثل Nordstrom و eBay و Strava و Expedia و Subspace. يتوفر دعم مدفوع على مستوى المؤسسات من Buoyant لـ Linkerd.

عيوب:

هناك منحنى تعليمي قوي جدًا لاستخدام شبكات خدمة Linkerd إلى أقصى إمكاناتها. يتم دعم Linkerd فقط داخل حاويات Kubernetes (على سبيل المثال ، لا يوجد وضع "عالمي" يعتمد على VM). وكيل Linkerd الجانبي ليس Envoy. في حين أن هذا يسمح لـ Buoyant بضبطه كما يراه مناسبًا ، فإنه يزيل القابلية للتوسعة الكامنة التي يوفرها Envoy. هذا يعني أيضًا أن Linkerd يفتقد الدعم لكسر الدائرة وحقن التأخير وتحديد السرعة. لا يتعرض أي API خاص للتحكم في مستوى التحكم Linkerd بسهولة. (يمكنك العثور على رابط gRPC API ، بالرغم من ذلك).

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

مراجعة Consul Connect

يعتبر منافسنا التالي للشبكات ، Consul Connect ، مزيجًا فريدًا من نوعه. يُعرف القنصل من HashiCorp بتخزينه ذي القيمة الأساسية للهياكل الموزعة ، والذي كان موجودًا منذ سنوات عديدة. بعد تطور Consul إلى مجموعة كاملة من أدوات الخدمة ، قررت HashiCorp بناء شبكة خدمات فوقها: Consul Connect.

لكي تكون دقيقًا بشأن طبيعتها الهجينة:

يعتمد مستوى بيانات Consul Connect على Envoy ، وهو مكتوب بلغة C ++. تمت كتابة طائرة التحكم الخاصة بـ Consul Connect في Go. هذا هو الجزء المدعوم من Consul KV ، وهو متجر ذو قيمة رئيسية.

مثل معظم شبكات الخدمة الأخرى ، يعمل Consul Connect عن طريق حقن وكيل جانبي داخل جراب التطبيق الخاص بك. فيما يتعلق بالهندسة المعمارية ، يعتمد Consul Connect على الوكلاء والخوادم . من خارج الصندوق ، يُقصد بـ Consul Connect أن يكون لديه توافر عالٍ (HA) باستخدام ثلاثة أو خمسة خوادم كمجموعة StatefulSet تحدد pod anti-affinity. مكافحة التقارب القرنة هي ممارسة للتأكد من أن قرون نظام البرامج الموزع لن ينتهي بها الأمر على نفس العقدة (الخادم) ، وبالتالي ضمان التوافر في حالة فشل أي عقدة واحدة.

الاتصال

ليس هناك الكثير مما يجعل Consul Connect متميزًا في هذا المجال ؛ إنه يوفر ما تفعله أي شبكة خدمة ( وهو قليل جدًا) ، بالإضافة إلى ميزات الطبقة السبعة للتوجيه القائم على المسار ، وتحويل حركة المرور ، وموازنة الحمل.

حماية

كما هو الحال مع شبكات الخدمة الأخرى ، يوفر Consul Connect إمكانات mTLS الأساسية. كما أنه يتميز بالتكامل الأصلي بين Consul و Vault (أيضًا بواسطة HashiCorp) ، والذي يمكن استخدامه كمزود CA لإدارة الشهادات وتوقيعها في مجموعة.

الملاحظة

يتبع Consul Connect نهج المراقبة الأكثر شيوعًا من خلال دمج Envoy كوكيل جانبي لتوفير إمكانات الطبقة السابعة. يتضمن تكوين واجهة المستخدم الخاصة بـ Consul Connect لجلب المقاييس تغيير ملف تكوين مضمن وكذلك تمكين موفر قياس مثل Prometheus. من الممكن أيضًا تكوين بعض لوحات معلومات Grafana لإظهار المقاييس الخاصة بالخدمة ذات الصلة.

تثبيت

يتم تثبيت Consul Connect في مجموعة Kubernetes باستخدام مخطط Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

ستحتاج إلى تعديل القيم الافتراضية values.yaml إذا كنت تريد تمكين واجهة المستخدم أو جعل وحدة Consul Connect تضخ وكيلها الجانبي:

 helm install -f consul-values.yml hashicorp hashicorp/consul

لاستشارة الأعضاء والتحقق من العقد المختلفة ، يوصي exec في إحدى الحاويات ثم استخدام consul أداة CLI.

لتقديم واجهة مستخدم الويب الجاهزة التي يوفرها Consul ، قم بتشغيل kubectl port-forward service/hashicorp-consul-ui 18500:80 .

ملخص شبكة خدمة Consul Connect

مزايا:

• القنصل مدعوم من HashiCorp ؛ كمنتج freemium ، هناك أيضًا إصدار مؤسسي مع ميزات إضافية تقدم دعمًا على مستوى المؤسسة. من حيث خبرة فريق التطوير ، يعتبر Consul أحد أقدم الأدوات في السوق.
• لدى القنصل مجتمع مؤسسي قوي ومن المعروف أنه يعمل على البنية التحتية مع 50000 عقدة. أيضًا ، كان موجودًا منذ عام 2014 ، مما يجعله منتجًا ناضجًا بالنسبة للسوق.
• يعمل Consul Connect جيدًا داخل جهاز افتراضي ، وذلك بفضل الدعم المحلي.
• مع Consul Connect ، من الممكن تحقيق تكامل التطبيقات في عمق تطبيقات الشبكة قبل الخدمة في شركات التكنولوجيا من الدرجة الأولى. هذا بفضل الكشف عن واجهة برمجة تطبيقات على مستوى المكتبة موثقة بالكامل.

عيوب:

• لدى Consul Connect منحنى تعليمي أكثر حدة من شبكات الخدمة الأخرى وسيحتاج إلى مزيد من الضبط لتشغيل لوحات المعلومات والمقاييس المرئية.
• وثائق HashiCorp ليست مباشرة ، مما يترك للمستخدمين للحفر والتجربة لتكوينها بشكل صحيح.
• يصعب العثور على وثائق إدارة حركة المرور وتتكون في الغالب من روابط لوثائق Envoy ، والتي لا تقدم تفاصيل حول إدارة حركة مرور Consul Connect على وجه الخصوص.
• لا تزال واجهة SMI الخاصة بـ Consul Connect قيد التجربة.

يمكن أن يكون Consul Connect خيارًا جيدًا جدًا لأولئك الذين يسعون للحصول على منتج على مستوى المؤسسات. تشتهر HashiCorp بجودة منتجاتها ، و Consul Connect ليس استثناءً. أستطيع أن أرى ميزتين قويتين هنا مقارنةً بشبكات الخدمات الأخرى: الدعم القوي من الشركة بإصدار المؤسسة وأداة جاهزة لجميع أنواع البنى (وليس فقط Kubernetes).

مراجعة Istio

في مايو 2017 ، أعلنت Google و IBM و Lyft عن Istio. عندما دخلت Istio في سباق أدوات شبكة الخدمة ، اكتسبت شهرة جيدة جدًا في مجال التكنولوجيا. أضاف مؤلفوها ميزات بناءً على تعليقات المستخدمين طوال الطريق من خلال الإصدار 1.9.

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

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

ومع ذلك ، على طول الطريق اكتسب Istio سمعة سيئة لامتلاكه أحد أكبر مجلدات إصدارات GitHub المفتوحة. حتى كتابة هذه السطور ، بلغ العدد حوالي 800 إصدار مفتوح وتم إغلاق حوالي 12000. على الرغم من أن عدد المشكلات قد يكون خادعًا ، إلا أنه في هذه الحالة يمثل تحسنًا ذا مغزى من حيث الميزات التي تم كسرها سابقًا واستخدام الموارد الخارج عن نطاق السيطرة.

الاتصال

Istio قوي جدًا في إدارة حركة المرور مقارنةً بـ Consul Connect و Linkerd. هذا بفضل العرض الشامل للميزات الفرعية: توجيه الطلب ، وحقن الأعطال ، وتحويل حركة المرور ، وانتهاء مهلة الطلب ، وقطع الدائرة ، والتحكم في حركة الدخول والخروج إلى شبكة الخدمة. إن فكرة الخدمات الافتراضية وقواعد الوجهة تجعلها مكتملة للغاية من حيث إدارة حركة المرور.

ومع ذلك ، تأتي كل هذه الاحتمالات مع منحنى تعليمي ، بالإضافة إلى إدارة تلك الموارد الجديدة في مجموعة Kubernetes الخاصة بك.

حماية

تفتخر Istio بمجموعة شاملة من الأدوات المتعلقة بالأمان ، مع محورين رئيسيين: المصادقة والترخيص. يمكن أن يفرض Istio مستويات مختلفة من السياسات على نطاقات مختلفة: خاص بحجم العمل ، أو على مستوى الاسم ، أو على مستوى الشبكة. تتم إدارة جميع موارد الأمان هذه من خلال Istio CRDs مثل AuthorizationPolicy أو PeerAuthentication .

بالإضافة إلى دعم mTLS القياسي ، يمكن أيضًا تكوين Istio لقبول أو رفض حركة المرور غير المشفرة.

الملاحظة

هنا ، Istio متقدم جدًا خارج الصندوق ، مع عدة أنواع من القياس عن بعد تقدم رؤى قوية في شبكة الخدمة. تستند المقاييس إلى الإشارات الذهبية الأربع (زمن الوصول ، وحركة المرور ، والأخطاء ، وإلى حد ما ، التشبع).

والجدير بالذكر أن Istio يوفر مقاييس لمستوى التحكم نفسه. كما أنه يخدم التتبع الموزع وسجلات الوصول ، ويتميز بالتوافق الواضح مع Jaeger و Lightstep و Zipkin لتمكين التتبع.

لا توجد لوحة تحكم أصلية ، ولكن يوجد دعم رسمي لوحدة تحكم إدارة Kiali.

تثبيت

التثبيت مباشر مثل اتباع الخطوات الرسمية. تم أيضًا دمج Istio أصلاً في GKE كميزة تجريبية ، ولكن هناك يستخدم GKE Istio 1.4.X ، إصدار الخدمات المصغرة الأقدم بدلاً من الإصدار الأحدث من monolith.

يبدأ التثبيت الأصلي بتنزيل أحدث إصدار:

 curl -L https://istio.io/downloadIstio | sh -

بعد إدخال cd إلى المجلد istio-* الذي تم إنشاؤه حديثًا ، يمكنك إضافته إلى المسار الخاص بك حتى تتمكن من استخدام الأداة المساعدة istioctl :

 export PATH=$PWD/bin:$PATH

من هناك ، يمكنك تثبيت Istio على مجموعة Kubernetes الخاصة بك عبر istioctl :

 istioctl install

سيؤدي هذا إلى تثبيت Istio بملف تعريف default . تسمح لك ملفات تعريف istioctl بإنشاء تكوينات تثبيت مختلفة والتبديل بينها إذا لزم الأمر. ولكن حتى في سيناريو الملف الشخصي الفردي ، يمكنك تخصيص تثبيت Istio بعمق عن طريق تعديل بعض CRDs.

سيكون من الصعب إدارة موارد Istio حيث ستحتاج إلى إدارة عدة أنواع من CRDs - VirtualService و DestinationRule و Gateway على الأقل - للتأكد من إدارة حركة المرور في مكانها الصحيح.

• مورد VirtualService هو تكوين يعلن عن خدمة وقواعد التوجيه المختلفة التي يتم تطبيقها على الطلبات.
• يتم استخدام مورد DestinationRule لتجميع سياسات حركة المرور الخاصة بالهدف وفرضها.
• يتم إنشاء مورد Gateway لإدارة حركة مرور شبكة الخدمة الواردة والصادرة (على سبيل المثال ، وكلاء Envoy الإضافيون ، ولكن يتم تشغيلهم عند الحافة بدلاً من السيارات الجانبية.)

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

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

يمكن أن تكون DestinationRule المقابلة بعد ذلك:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

أخيرًا ، Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

مع وجود هذه الملفات الثلاثة في مكانها الصحيح ، سيكون تثبيت Istio جاهزًا للتعامل مع حركة المرور الأساسية.

ملخص شبكة خدمة Istio

مزايا:

• من بين شبكات الخدمة المختلفة ، Istio هو أكبر مجتمع على الإنترنت حتى كتابة هذه السطور. مع أكثر من 10 أضعاف نتائج Stack Overflow كأي من منافسيها الرئيسيين ، فهي شبكة الخدمة الأكثر شيوعًا على الويب ؛ المساهمون في GitHub هم بالمثل ترتيب من حيث الحجم يتجاوز مساهمات Linkerd.
• يدعم Istio كلاً من أوضاع Kubernetes و VM ؛ الأخير في مرحلة تجريبية اعتبارًا من الإصدار 1.9.

عيوب:

• الاستيو ليس حرا من ناحيتين:
  • متطلباته عالية من حيث الوقت اللازم لقراءة الوثائق ، وإعدادها ، وجعلها تعمل بشكل صحيح ، والحفاظ عليها. اعتمادًا على حجم البنية التحتية وعدد الخدمات ، سيستغرق Istio عدة أسابيع إلى عدة أشهر من العمل بدوام كامل حتى يعمل بكامل طاقته ودمجها في الإنتاج.
  • كما أنه يضيف قدرًا كبيرًا من النفقات العامة للموارد: سيستغرق الأمر 350 ميليكور (mCPU) لحاوية Envoy لكل 1000 طلب في الثانية (RPS). حتى مستوى التحكم نفسه يمكن أن يكون مستهلكًا للموارد. (في السابق ، كان من الصعب التنبؤ باستخدام الموارد ، ولكن بعد بعض الجهد ، istiod حول استخدام وحدة معالجة مركزية واحدة و 1.5 جيجا بايت من الذاكرة.)
• لا يحتوي على لوحة تحكم مشرف أصلية ، على عكس Linkerd.
• يتطلب Istio استخدام بوابة الدخول الخاصة به.
• يتم دعم مستوى التحكم Istio فقط داخل حاويات Kubernetes (على سبيل المثال ، لا يوجد وضع VM ، على عكس مستوى بيانات Istio).

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

مراجعة كوما السريعة

تم إنشاؤه بواسطة Kong ومن ثم مفتوح المصدر ، وصل Kuma إلى 1.0 في أواخر عام 2020. إلى حد ما ، تم إنشاؤه استجابةً لكون شبكات الخدمة الأولى ثقيلة إلى حد ما وصعبة التشغيل.

تشير قائمة الميزات الخاصة به إلى أنه معياري للغاية ؛ تتمثل الفكرة وراء Kuma في توجيهه نحو التكامل مع التطبيقات التي تعمل بالفعل على Kubernetes أو البنية التحتية الأخرى.

• في مجال إدارة حركة المرور ، تقدم Kuma ميزات شبكة خدمة مشتركة مثل حقن الأعطال وكسر الدائرة.
• بالإضافة إلى تشفير mTLS بين الخدمات ، يتم تأمين التبادلات بين مستوى البيانات وطائرة التحكم في Kuma عبر رمز وكيل لمستوى البيانات .
• يتم تعريف إمكانية المراقبة في Kuma عبر سياسات حركة المرور المختلفة حول المقاييس والتتبع والتسجيل.
• يتوفر اكتشاف الخدمة من خلال Kuma بفضل محلل DNS الخاص به الذي يعمل على المنفذ 5653 من مستوى التحكم.
• يركز Kuma بشدة على وظائف multimesh : يمكنك بسهولة دمج العديد من مجموعات Kubernetes أو بيئات VM في مجموعة Kuma الشائعة مع نوع النشر متعدد المناطق.
• يتكامل Kuma بسهولة مع Kong Gateway لمستخدمي Kong الحاليين.

يتطلب الإصدار العالمي (غير Kubernetes) من Kuma PostgreSQL كإحدى التبعيات ، وكان كبير مسؤولي التكنولوجيا في كونغ يعارض دعم SMI بشكل خاص. ولكن تم تطوير Kuma بفكرة عمليات النشر متعددة الأوساط السحابية والمتعددة من البداية ، وتعكس لوحة أجهزة القياس ذلك.

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

مراجعة Traefik Mesh السريعة

يُطلق على Traefik Mesh (من قبل Traefik Labs) اسم Maesh في الأصل ، وهو وافد جديد آخر في سباق أدوات شبكة الخدمة. تتمثل مهمة المشروع في إضفاء الطابع الديمقراطي على شبكة الخدمة من خلال تسهيل استخدامها وتكوينها ؛ تجربة المطورين مع Traefik Proxy المدروس جيدًا يضعهم في موقع رئيسي لتحقيق ذلك.

• تتضمن ميزات إدارة حركة المرور في Traefik Mesh كسر الدائرة وتحديد المعدل.
• من حيث إمكانية الملاحظة ، يتميز Traefik Mesh بدعم OpenTracing الأصلي ومقاييس خارج الصندوق (يتضمن التثبيت القياسي تلقائيًا Prometheus و Grafana) ، مما يوفر وقت الإعداد.
• للأمان - إلى جانب mTLS - المواصفات متوافقة مع SMI وتتيح شبكة Traefik ضبط أذونات المرور من خلال التحكم في الوصول.

تحتاج Traefik Mesh إلى تثبيت CoreDNS على الكتلة. (بينما يستخدم Azure CoreDNS افتراضيًا منذ 1.12 ، فإن GKE يتم تعيينه افتراضيًا إلى kube-dns اعتبارًا من كتابة هذه السطور ، مما يعني أن هناك خطوة إضافية مهمة في هذه الحالة.) كما أنه يفتقر إلى إمكانيات المجموعات المتعددة.

ومع ذلك ، فإن Traefik Mesh فريدة من نوعها في مقارنة شبكة الخدمة الخاصة بنا من حيث أنها لا تستخدم الحقن الجانبي. بدلاً من ذلك ، يتم نشره باعتباره DaemonSet على جميع العقد ليكون بمثابة وكيل بين الخدمات ، مما يجعله غير جائر. بشكل عام ، يعد Traefik Mesh سهل التثبيت والاستخدام.

مراجعة سريعة لـ AWS App Mesh

في عالم مزودي الخدمات السحابية ، تعد AWS أول من نفذ شبكة خدمة أصلية قابلة للتوصيل مع Kubernetes (أو EKS على وجه الخصوص) ولكن أيضًا بخدماتها الأخرى. تم إصدار AWS App Mesh في نوفمبر 2018 وما فتئت AWS تكرره منذ ذلك الحين. الميزة الرئيسية لـ AWS App Mesh هي النظام البيئي AWS الموجود مسبقًا ومكانته في السوق ؛ سيستمر المجتمع الكبير الذي يقف وراء AWS بشكل عام في زيادة استخدامه وسهولة استخدامه.

• تتضمن إدارة حركة المرور في AWS App Mesh فصل الدائرة فوق الميزات الشائعة.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

بنية تحتية

Traffic Management

الملاحظة

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

تعيين

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.