اهلا يا هبر
في وقت من الأوقات ، كنا أول من
طرح موضوع
كافكا في السوق الروسية ومواصلة
مراقبة تطوره. على وجه الخصوص ، بدا موضوع التفاعل بين كافكا و
Kubernet مثيرة للاهتمام بالنسبة لنا. تم نشر
مقال (وحذر إلى حد ما) حول هذا الموضوع على مدونة شركة كونفلوينت في أكتوبر الماضي ، من تأليف جوين شابيرا. نود أن نلفت انتباهكم اليوم إلى مقال نشر في أبريل الماضي بقلم يوهان جيغر ، الذي ، رغم أنه لا يخلو من علامة استفهام في العنوان ، ينظر في الموضوع بطريقة أكثر موضوعية ، ويرافق النص مع روابط مثيرة للاهتمام. يرجى مسامحتنا للترجمة المجانية لـ "chaos monkey" إذا استطعت!
مقدمة
تم تصميم Kubernetes للتعامل مع الأحمال عديمي الجنسية. وكقاعدة عامة ، يتم تقديم أعباء العمل هذه في شكل هندسة الخدمات المصغرة ، فهي خفيفة الوزن ومناسبة تمامًا للقياس الأفقي ، وتطيع مبادئ التطبيقات المكونة من 12 عاملًا ، وتسمح بالعمل مع قواطع الدوائر والقردة الفوضى.
كافكا ، من ناحية أخرى ، تعمل بشكل أساسي كقاعدة بيانات موزعة. وبالتالي ، عند العمل ، يجب عليك التعامل مع الحالة ، وهي أثقل بكثير من الخدمة الصغيرة. يدعم Kubernetes الكميات الكبيرة ، ولكن كما يشير Kelsey Hightower في اثنين من تغريداته ، يجب التعامل معها بحذر:
يبدو للبعض أنه إذا قمت بلف Kubernetes إلى تحميل ذي حالة ، فإنه يتحول إلى قاعدة بيانات مُدارة بالكامل يمكنها منافسة RDS. هذا ليس كذلك. ربما إذا كنت تعمل بجد وتثبّت مكونات إضافية وتجتذب فريقًا من مهندسي SRE ، فيمكنك تثبيت RDS أعلى Kubernetes.
أوصي دائمًا أن يتوخى الجميع الحذر الشديد عند إطلاق الأحمال المحافظة على الحالة على Kubernetes. لا يتمتع معظم المهتمين بـ "هل يمكنني تشغيل كميات كبيرة على Kubernetes" بخبرة كافية في العمل مع Kubernetes ، وغالبًا مع الحمل الذي يسألون عنه.
لذلك ، يجب أن أركض كافكا على Kubernetes؟ سؤال مضاد: هل ستعمل كافكا بشكل أفضل بدون Kubernetes؟ لهذا السبب أود أن أؤكد في هذا المقال كيف يكمل كافكا وكوبرنيتيس بعضهما البعض ، وما هي المخاطر التي يمكن أن تصادفها عند الجمع.
مهلة
دعونا نتحدث عن الشيء الأساسي - بيئة وقت التشغيل نفسها
هذه العمليةالسماسرة كافكا مريحة عند العمل مع وحدة المعالجة المركزية. TLS قد تحمل بعض النفقات العامة. في الوقت نفسه ، يمكن لعملاء Kafka تحميل وحدة المعالجة المركزية بشكل أكبر إذا استخدموا التشفير ، لكن هذا لا يؤثر على الوسطاء.
الذاكرةسماسرة كافكا يلتهمون الذاكرة. عادة ما يكون حجم كومة الذاكرة المؤقتة لـ JVM من المألوف للحد من 4 إلى 5 غيغابايت ، لكنك ستحتاج أيضًا إلى الكثير من ذاكرة النظام ، حيث يستخدم Kafka ذاكرة التخزين المؤقت للصفحة بشكل نشط للغاية. في Kubernetes ، قم بتعيين حدود الحاوية للموارد والطلبات بشكل مناسب.
مستودع البياناتتخزين البيانات في الحاويات سريع الزوال - يتم فقد البيانات عند إعادة التشغيل. يمكنك استخدام وحدة التخزين
emptyDir لبيانات Kafka ، وسيكون التأثير مماثلاً: ستفقد بيانات وسيطك بعد الانتهاء. لا يزال من الممكن حفظ رسائلك على الوسطاء الآخرين كنسخ متماثلة. لذلك ، بعد إعادة التشغيل ، يجب على السمسار الفاشل أولاً نسخ جميع البيانات ، وقد تستغرق هذه العملية الكثير من الوقت.
هذا هو السبب في أنه ينبغي استخدام تخزين البيانات على المدى الطويل. فليكن تخزينًا طويل الأجل غير محلي باستخدام نظام ملفات XFS أو بدقة أكثر ext4. لا تستخدم NFS. لقد حذرت. لن تعمل إصدارات NFS v3 أو v4. باختصار ، سينتهي وسيط Kafka إذا لم يتمكن من حذف دليل البيانات بسبب مشكلة "إعادة التسمية الغبية" ذات الصلة بـ NFS. إذا كنت ما زلت غير مقتنع ،
اقرأ هذا المقال بعناية فائقة. يجب أن يكون مستودع البيانات غير محلي حتى تتمكن Kubernetes من تحديد عقدة جديدة بمرونة أكبر بعد إعادة التشغيل أو النقل.
شبكةكما هو الحال مع معظم الأنظمة الموزعة ، يعتمد أداء كافكا إلى حد كبير على زمن الوصول إلى الشبكة في الحد الأدنى وعرض النطاق الترددي الأقصى. لا تحاول وضع جميع الوسطاء على نفس العقدة ، لأن هذا سوف يقلل من التوافر. في حالة فشل عقدة Kubernetes ، تفشل أيضًا كتلة Kafka بأكملها. أيضا ، لا تفريق الكتلة كافكا عبر مراكز البيانات بأكملها. الشيء نفسه ينطبق على الكتلة Kubernetes. حل وسط جيد في هذه الحالة هو اختيار مناطق وصول مختلفة.
ترتيب
البيانات المشتركةيحتوي موقع Kubernetes على
دليل جيد للغاية حول كيفية تكوين ZooKeeper باستخدام البيانات. نظرًا لأن ZooKeeper جزء من كافكا ، فمن المناسب أن تبدأ في التعرف على ماهية مفاهيم Kubernetes المطبقة هنا. بمجرد معرفة ذلك ، يمكنك استخدام نفس المفاهيم مع مجموعة كافكا.
- Sub : sub هي أصغر وحدة قابلة للنشر في Kubernetes. تحتوي الحافظة على عبء العمل الخاص بك ، والجراب نفسه يتوافق مع العملية في الكتلة الخاصة بك. الموقد يحتوي على حاوية واحدة أو أكثر. سيعمل كل خادم على ZooKeeper في المجموعة وكل وسيط في مجموعة Kafka بطريقة منفصلة.
- StatefulSet : StatefulSet هو كائن Kubernetes الذي يعمل مع أعباء العمل متعددة الحالة ، والتي تتطلب التنسيق. يوفر StatefulSet ضمانات بشأن ترتيب الموقد وتفردها.
- الخدمات مقطوعة الرأس : تتيح لك الخدمات فصل القرون عن العملاء باستخدام اسم منطقي. Kubernetes في هذه الحالة هي المسؤولة عن موازنة التحميل. ومع ذلك ، عند الحفاظ على أعباء العمل ذات الحالة ، كما في حالة ZooKeeper و Kafka ، يحتاج العملاء إلى تبادل المعلومات مع مثيل معين. هذا هو المكان الذي تكون فيه الخدمات مقطوعة الرأس في متناول يدي: في هذه الحالة ، سيظل للعميل اسم منطقي ، ولكن لن يتعين عليك الانتقال مباشرة إلى الأسفل.
- وحدة التخزين للتخزين طويل الأجل : هذه الأحجام مطلوبة لتكوين وحدة التخزين طويلة الأجل غير المحلية ، والتي تم ذكرها أعلاه.
يوفر
Yolean مجموعة شاملة من العروض التي تجعل من السهل البدء مع Kafka على Kubernetes.
مخططات هيلمHelm هو مدير الحزم في Kubernetes ، والتي يمكن مقارنتها بمديري الحزم لنظام التشغيل ، مثل yum أو apt أو Homebrew أو Chocolatey. استخدامه مناسب لتثبيت حزم البرامج المحددة مسبقًا الموضحة في مخططات Helm. يسهل مخطط Helm الذي تم اختياره جيدًا المهمة الصعبة: كيفية تكوين جميع المعلمات بشكل صحيح لاستخدام Kafka على Kubernetes. هناك العديد من مخططات Kafka:
الرسم الرسمي
في حالة حاضنة ، وهناك
رسم من
Confluent ، وآخر من
Bitnami .
مشغلينظرًا لأن لدى Helm عيوب معينة ، تكتسب أداة أخرى شعبية كبيرة: مشغلي Kubernetes. لا يقوم المشغل فقط بحزم البرنامج الخاص بـ Kubernetes ، ولكنه يسمح لك أيضًا بنشر مثل هذا البرنامج وإدارته أيضًا.
قائمة
المشغلين رهيبة يذكر اثنين من المشغلين لكافكا. واحد منهم هو
Strimzi . بمساعدة Strimzi ، من السهل رفع مجموعة كافكا في دقائق. لا يلزم عمليا أي تكوين ، بالإضافة إلى ذلك ، يوفر المشغل نفسه بعض الميزات الرائعة ، على سبيل المثال ، تشفير TLS من النوع "من نقطة إلى نقطة" داخل الكتلة. كما يوفر Confluent
مشغلها الخاص .
إنتاجيةمن المهم للغاية اختبار الأداء من خلال تزويد مثيل كافكا المثبت بنقاط التحكم. ستساعدك هذه الاختبارات في تحديد الاختناقات المحتملة قبل أن تبدأ المشاكل. لحسن الحظ ، توفر Kafka بالفعل أداتين لاختبار الأداء:
kafka-producer-perf-test.sh و
kafka-consumer-perf-test.sh . استخدامها بنشاط. كمرجع ، يمكنك الرجوع إلى النتائج الموضحة في
هذا المنشور
بواسطة Jay Kreps ، أو استخدام مراجعة Stéphane Maarek Amazon MSK.
العمليات
مراقبةالشفافية في النظام مهمة للغاية - وإلا فلن تفهم ما يحدث فيها. يوجد اليوم مجموعة أدوات صلبة توفر المراقبة استنادًا إلى المقاييس بأسلوب السحاب الأصلي. أداتان شائعتان لهذا الغرض هما بروميثيوس وغرافانا. يمكن لـ Prometheus جمع المقاييس من جميع عمليات Java (Kafka و Zookeeper و Kafka Connect) باستخدام مصدر JMX - بأبسط الطرق. إذا قمت بإضافة مقاييس cAdvisor ، فيمكنك فهم كيفية استخدام الموارد في Kubernetes بشكل أفضل.
Strimzi لديه مثال لوحة القيادة Grafana مريحة للغاية ل Kafka. يتصور المقاييس الأساسية ، على سبيل المثال ، حول القطاعات غير المكتملة أو تلك غير المتصلة بالإنترنت. كل شيء واضح جدا هناك. وتستكمل هذه المقاييس بمعلومات حول استخدام الموارد والأداء ، وكذلك مؤشرات الاستقرار. وبالتالي ، يمكنك الحصول على المراقبة الأساسية للمجموعة كافكا دون سبب!
المصدر:
strimzi.io/docs/master/#kafka_dashboardسيكون من الجيد استكمال كل هذا بمراقبة العملاء (مقاييس للمستهلكين والمنتجين) ، وكذلك مراقبة التأخر (لهذا يوجد
Burrow ) ومراقبة شاملة - لذلك ، استخدم
Kafka Monitor .
تسجيلتسجيل هو مهمة أخرى حاسمة. تأكد من تسجيل جميع الحاويات الموجودة في تثبيت كافكا في
stdout و
stderr ، وتأكد من أن مجموعة Kubernetes الخاصة بك تجمع كل السجلات في بنية أساسية
للتسجيل المركزي ، مثل
Elasticsearch .
فحص الصحةتستخدم Kubernetes تحقيقات الفعالية والاستعداد للتحقق مما إذا كانت السنفات تعمل بشكل صحيح. إذا فشل الاختبار المباشر ، فستقوم Kubernetes بإيقاف هذه الحاوية ، ثم إعادة تشغيلها تلقائيًا إذا تم تعيين سياسة إعادة التشغيل وفقًا لذلك. إذا فشل فحص التوفر ، فعندئذ تقوم Kubernetes بعزل هذا تحت خدمة الطلب. وبالتالي ، في مثل هذه الحالات ، لم يعد التدخل اليدوي مطلوبًا على الإطلاق ، وهذه ميزة كبيرة.
طرح التحديثاتيدعم StatefulSet التحديثات التلقائية: عند اختيار استراتيجية RollingUpdate ، سيتم تحديث كل منها تحت Kafka بدوره. بهذه الطريقة ، يمكن تقليل وقت التوقف إلى الصفر.
تدريجتوسيع نطاق كافكا ليست مهمة سهلة. ومع ذلك ، في Kubernetes ، من السهل جدًا توسيع نطاق القرون لعدد معين من النسخ المتماثلة ، مما يعني أنه يمكنك تحديد العديد من وسطاء كافكا على النحو الذي تريده. الأصعب في هذه الحالة هو إعادة تعيين القطاعات بعد التوسع أو قبل التوسع. مرة أخرى ، سوف Kubernetes مساعدتك في هذه المهمة.
إدارةيمكن القيام بالمهام المتعلقة بإدارة مجموعة Kafka الخاصة بك ، على وجه الخصوص ، إنشاء الموضوعات وإعادة تعيين القطاعات ، باستخدام البرامج النصية الموجودة في shell ، وفتح واجهة سطر الأوامر في ملفاتك. ومع ذلك ، هذا الحل ليس جميلا جدا. يدعم Strimzi إدارة الموضوعات باستخدام مشغل آخر. هناك شيء لتعديله هنا.
النسخ الاحتياطي واستعادةيعتمد توافر كافكا الآن على توافر Kubernetes. إذا سقطت مجموعة Kubernetes الخاصة بك ، في أسوأ الأحوال ، تقع كتلة كافكا أيضًا. بموجب قانون مورفي ، سيحدث هذا وستفقد البيانات. لتقليل هذا النوع من المخاطر ، يكون لديك مفهوم نسخ احتياطي جيد. يمكنك استخدام MirrorMaker ، هناك خيار آخر هو استخدام S3 لهذا ، كما هو موضح في هذا المنشور من Zalando.
استنتاج
عند العمل مع مجموعات كافكا الصغيرة أو المتوسطة الحجم ، من المستحسن بالتأكيد استخدام Kubernetes ، حيث توفر مرونة إضافية وتبسط العمل مع المشغلين. إذا كانت لديك متطلبات خطيرة غير وظيفية فيما يتعلق بالاختفاء و / أو الإنتاجية ، فقد يكون من الأفضل التفكير في خيار نشر آخر.