هل كافكا على Kubernetes جيد؟

اهلا بك يا هبر!

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

مقدمة

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

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

يبدو للبعض أنه إذا قمت بتحويل Kubernetes إلى عبء عمل ذي حالة جيدة ، فإنه يتحول إلى قاعدة بيانات مُدارة بالكامل يمكنها التنافس مع RDS. هذا خطأ. ربما إذا كنت تعمل بجد بما فيه الكفاية ، وقمت بربط مكونات إضافية واشركت فريقًا من مهندسي SRE ، فستتمكن من تجهيز RDS أعلى Kubernetes.

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

لذا ، هل يجب عليك تشغيل كافكا على Kubernetes؟ السؤال المضاد: هل سيعمل كافكا بشكل أفضل بدون Kubernetes؟ لهذا السبب أريد أن أوضح في هذا المقال كيف يكمل كافكا وكوبرنيتيس بعضهما البعض ، وما هي المزالق التي يمكن أن تصادف عندما يتم الجمع بينهما.

وقت الانتهاء

دعنا نتحدث عن الشيء الأساسي - بيئة وقت التشغيل على هذا النحو

عملية

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

ذاكرة

وسطاء كافكا يلتهمون الذاكرة. عادة ما يكون من المألوف قصر حجم كومة JVM على 4-5 جيجا بايت ، لكنك ستحتاج أيضًا إلى الكثير من ذاكرة النظام ، نظرًا لأن كافكا يستخدم ذاكرة التخزين المؤقت للصفحة بشكل كبير جدًا. في Kubernetes ، عيّن حدود الحاوية على الموارد والطلبات بشكل مناسب.

مخزن البيانات

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

لهذا السبب يجب عليك استخدام التخزين الدائم للبيانات. فليكن تخزين طويل الأجل غير محلي مع نظام ملفات XFS أو بشكل أكثر دقة ext4. لا تستخدم NFS. حذرت. لن تعمل إصدارات NFS v3 أو v4. باختصار ، سينتهي وسيط Kafka إذا لم يتمكن من إزالة دليل البيانات بسبب مشكلة "إعادة التسمية الغبية" التي يعاني منها NFS. إذا لم أقنعك بعد ، بحذر شديد اقرأ هذه المقالة. يجب أن يكون مخزن البيانات غير محلي حتى يتمكن Kubernetes من تحديد عقدة جديدة بمرونة أكبر بعد إعادة التشغيل أو إعادة التوطين.

Сеть

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

ترتيب

البيانات العادية

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

• تحت: pod هي أصغر وحدة قابلة للنشر في Kubernetes. يحتوي Pod على عبء العمل الخاص بك ، ويتوافق Pod مع عملية في المجموعة الخاصة بك. تحتوي الحجرة على حاوية واحدة أو أكثر. سيتم تشغيل كل خادم ZooKeeper في المجموعة وكل وسيط في كتلة كافكا في حجرة منفصلة.
• جليل: StatefulSet هو كائن Kubernetes يعمل مع أحمال عمل متعددة ذات حالة ، وتتطلب أعباء العمل هذه التنسيق. توفر StatefulSets ضمانات فيما يتعلق بترتيب البودات وتفردها.
• خدمات مقطوعة الرأس: تتيح لك الخدمات فصل البودات عن العملاء باستخدام اسم منطقي. Kubernetes في هذه الحالة هي المسؤولة عن موازنة التحميل. ومع ذلك ، عند التعامل مع أعباء العمل ذات الحالة ، كما هو الحال مع ZooKeeper و Kafka ، يحتاج العملاء إلى التواصل مع حالة معينة. هذا هو المكان الذي تكون فيه الخدمات بدون رأس مفيدة: في هذه الحالة ، سيظل للعميل اسم منطقي ، لكن لا يمكنك الوصول إلى الكبسولة مباشرة.
• حجم للتخزين طويل الأجل: هذه الكميات مطلوبة لتكوين التخزين الدائم للكتلة غير المحلية المذكورة أعلاه.

في يولين يوفر مجموعة شاملة من البيانات لمساعدتك في البدء مع كافكا على Kubernetes.

مخططات خوذة

Helm هو مدير حزم لـ Kubernetes يمكن مقارنته بمديري حزم أنظمة التشغيل مثل yum أو apt أو Homebrew أو Chocolatey. باستخدامه ، يكون من الملائم تثبيت حزم البرامج المحددة مسبقًا ، الموضحة في مخططات Helm. يجعل مخطط Helm الذي تم اختياره جيدًا المهمة الصعبة المتمثلة في كيفية تكوين جميع المعلمات بشكل صحيح لاستخدام كافكا على Kubernetes أسهل. هناك العديد من مخططات كافكا: الرسم الرسمي هو في الحضانة، هناك واحد من تقاطع، واحد آخر من [اضغط على مواصلة.

مشغلي

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

В списке مشغلين رائعين تم ذكر عاملين لكافكا. واحد منهم - ستريمزي. بمساعدة ستريمزي ، ليس من الصعب رفع كتلة كافكا في غضون دقائق. لا يلزم أي تكوين تقريبًا ، بالإضافة إلى ذلك ، يوفر المشغل نفسه بعض الميزات الرائعة ، على سبيل المثال ، تشفير TLS من نقطة إلى نقطة داخل المجموعة. يوفر Confluent أيضًا المشغل الخاص.

أداء

من المهم جدًا اختبار الأداء من خلال توفير نقاط فحص لمثال كافكا الخاص بك. ستساعدك هذه الاختبارات في العثور على الاختناقات المحتملة قبل أن تبدأ المشاكل. لحسن الحظ ، يوفر كافكا بالفعل أداتين لاختبار الأداء: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. استخدمها بنشاط. كمرجع ، يمكنك الرجوع إلى النتائج الموضحة في هذا المشنور جاي كريبس ، أو التركيز على هذا الاستعراض أمازون MSK بواسطة ستيفان ماريك.

العمليات

رصد

الشفافية في النظام مهمة للغاية - وإلا فلن تفهم ما يحدث فيه. يوجد اليوم مجموعة أدوات قوية توفر المراقبة بناءً على مقاييس نمط السحابة الأصلية. هناك أداتان شائعتان لهذا الغرض هما بروميثيوس وجرافانا. يمكن لـ Prometheus جمع المقاييس من جميع عمليات Java (Kafka و Zookeeper و Kafka Connect) باستخدام مصدر JMX بأبسط طريقة. إذا أضفت مقاييس cAdvisor ، فيمكنك فهم كيفية استخدام الموارد في Kubernetes بشكل كامل.

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

المصدر: streamzi.io/docs/master/#kafka_dashboard

سيكون من الجيد استكمال كل هذا بمراقبة العملاء (المقاييس من قبل المستهلكين والمنتجين) ، بالإضافة إلى مراقبة زمن الوصول (هناك نقب) والمراقبة الشاملة - لهذا الغرض ، استخدم كافكا مونيتور.

تسجيل

التسجيل هو مهمة أخرى مهمة. تأكد من تسجيل جميع الحاويات في تثبيت كافكا الخاص بك stdout и stderr، وتأكد من أن مجموعة Kubernetes الخاصة بك تجمع كل السجلات في بنية أساسية مركزية للتسجيل ، مثل Elasticsearch.

اختبار وظيفي

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

طرح التحديثات

تدعم StatefulSets التحديثات التلقائية: عند اختيار إستراتيجية RollingUpdate ، سيتم تحديث كل قرص كافكا بدوره. بهذه الطريقة ، يمكن تقليل وقت التوقف إلى الصفر.

تدريج

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

إدارة

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

النسخ الاحتياطي والاسترداد

الآن سيعتمد توفر كافكا أيضًا على توفر Kubernetes. إذا تعطلت مجموعة Kubernetes الخاصة بك ، ففي أسوأ الحالات ، ستنخفض كتلة كافكا أيضًا. وفقًا لقانون مورفي ، سيحدث هذا بالتأكيد ، وستفقد البيانات. للتخفيف من هذا النوع من المخاطر ، يجب أن يكون لديك فهم جيد لمفهوم النسخ الاحتياطي. يمكنك استخدام MirrorMaker ، وهناك خيار آخر وهو استخدام S3 لهذا الغرض ، كما هو موضح في هذا بعد بواسطة Zalando.

اختتام

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

المصدر: www.habr.com