آیا کافکا روی Kubernetes خوب است؟

درود، حبر!

زمانی ما اولین نفری بودیم که موضوع را به بازار روسیه معرفی کردیم کافکا و ادامه دهید مسیر برای توسعه آن به ویژه، ما موضوع تعامل بین کافکا و کوبرنیتس. قابل مشاهده (و کاملاً دقیق) مقاله این موضوع در اکتبر سال گذشته در وبلاگ Confluent به نویسندگی گوئن شاپیرا منتشر شد. امروز می‌خواهیم توجه شما را به مقاله‌ای جدیدتر از ماه آوریل توسط یوهان گیگر جلب کنیم که اگرچه بدون علامت سوال در عنوان نیست، اما موضوع را به شکلی اساسی‌تر بررسی می‌کند و متن را با پیوندهای جالبی همراه می‌کند. اگر می توانید ترجمه رایگان "میمون آشوب" را برای ما ببخشید!

معرفی

Kubernetes برای مدیریت بارهای کاری بدون وضعیت طراحی شده است. به طور معمول، چنین حجم کاری در قالب یک معماری میکروسرویس ارائه می شود، آنها سبک وزن هستند، به خوبی مقیاس افقی هستند، از اصول برنامه های کاربردی 12 عاملی پیروی می کنند و می توانند با قطع کننده های مدار و میمون های آشوب کار کنند.

کافکا، از سوی دیگر، اساساً به عنوان یک پایگاه داده توزیع شده عمل می کند. بنابراین، هنگام کار، شما باید با حالت سروکار داشته باشید، و این بسیار سنگین تر از یک میکروسرویس است. Kubernetes از بارهای حالتی پشتیبانی می کند، اما همانطور که کلسی هایتاور در دو توییت اشاره می کند، باید با احتیاط رفتار کرد:

برخی از مردم احساس می کنند که اگر Kubernetes را در یک حجم کاری حالتی قرار دهید، به یک پایگاه داده کاملاً مدیریت شده تبدیل می شود که رقیب RDS است. این اشتباه است. شاید، اگر به اندازه کافی سخت کار کنید، اجزای اضافی اضافه کنید و تیمی از مهندسان SRE را جذب کنید، بتوانید RDS را در بالای Kubernetes بسازید.

من همیشه توصیه می کنم که همه هنگام اجرای بارهای کاری حالتی در Kubernetes بسیار احتیاط کنند. اکثر افرادی که می پرسند "آیا می توانم بارهای کاری حالتی را در Kubernetes اجرا کنم" تجربه کافی با Kubernetes و اغلب با حجم کاری که در مورد آن می پرسند ندارند.

بنابراین، آیا باید کافکا را در Kubernetes اجرا کنید؟ سوال متقابل: آیا کافکا بدون کوبرنتس بهتر کار خواهد کرد؟ به همین دلیل است که می‌خواهم در این مقاله به این نکته اشاره کنم که چگونه کافکا و کوبرنتس مکمل یکدیگر هستند و ترکیب آن‌ها چه مشکلاتی می‌تواند داشته باشد.

زمان تکمیل

بیایید در مورد چیز اساسی صحبت کنیم - خود محیط زمان اجرا

روند

کارگزاران کافکا CPU پسند هستند. TLS ممکن است مقداری سربار معرفی کند. با این حال، مشتریان کافکا ممکن است در صورت استفاده از رمزگذاری، CPU بیشتری داشته باشند، اما این بر کارگزاران تأثیر نمی گذارد.

حافظه

دلالان کافکا خاطره را می خورند. اندازه Heap JVM معمولاً به 4-5 گیگابایت محدود می شود، اما شما همچنین به حافظه سیستم زیادی نیاز خواهید داشت زیرا کافکا به شدت از کش صفحه استفاده می کند. در Kubernetes، منابع کانتینر را تنظیم کنید و محدودیت‌هایی را درخواست کنید.

ذخیره اطلاعات

ذخیره سازی داده ها در کانتینرها زودگذر است - داده ها هنگام راه اندازی مجدد از بین می روند. برای داده های کافکا می توانید از یک حجم استفاده کنید emptyDir، و اثر مشابه خواهد بود: داده های کارگزار شما پس از تکمیل از بین می رود. پیام‌های شما همچنان می‌توانند در سایر کارگزاران به عنوان کپی ذخیره شوند. بنابراین، پس از راه اندازی مجدد، کارگزار شکست خورده ابتدا باید تمام داده ها را تکرار کند و این فرآیند می تواند زمان زیادی را ببرد.

به همین دلیل است که باید از ذخیره سازی طولانی مدت داده استفاده کنید. اجازه دهید ذخیره سازی طولانی مدت غیر محلی با سیستم فایل XFS یا به طور دقیق تر، ext4 باشد. از NFS استفاده نکنید من به شما هشدار دادم نسخه های NFS v3 یا v4 کار نمی کنند. به طور خلاصه، اگر کارگزار کافکا نتواند دایرکتوری داده را به دلیل مشکل "تغییر نام احمقانه" در NFS حذف کند، از کار می افتد. اگر هنوز شما را متقاعد نکرده ام، بسیار با احتیاط این مقاله را بخوانید. ذخیره‌گاه داده باید غیرمحلی باشد تا Kubernetes بتواند با انعطاف‌پذیری بیشتری گره جدیدی را پس از راه‌اندازی مجدد یا جابجایی انتخاب کند.

شبکه

مانند اکثر سیستم های توزیع شده، عملکرد کافکا به شدت به حفظ تأخیر شبکه در حداقل و پهنای باند در حداکثر وابسته است. سعی نکنید همه بروکرها را در یک گره میزبانی کنید، زیرا این کار باعث کاهش دسترسی می شود. اگر یک گره Kubernetes از کار بیفتد، کل خوشه کافکا از کار خواهد افتاد. همچنین، خوشه کافکا را در کل مراکز داده پراکنده نکنید. همین امر در مورد خوشه Kubernetes نیز صدق می کند. یک مصالحه خوب در این مورد، انتخاب مناطق مختلف در دسترس است.

پیکربندی

اعلامیه های منظم

وب سایت Kubernetes دارای راهنمای بسیار خوبی در مورد نحوه پیکربندی ZooKeeper با استفاده از مانیفست. از آنجایی که ZooKeeper بخشی از کافکا است، اینجا مکان خوبی برای آشنایی با مفاهیم Kubernetes در اینجا است. وقتی این را فهمیدید، می توانید از همان مفاهیم با خوشه کافکا استفاده کنید.

• تحت: یک pod کوچکترین واحد قابل استقرار در Kubernetes است. یک پاد شامل حجم کاری شما است و خود پاد مربوط به فرآیندی در خوشه شما است. یک غلاف حاوی یک یا چند ظرف است. هر سرور ZooKeeper در مجموعه و هر کارگزار در خوشه کافکا در یک پاد جداگانه اجرا می شود.
• StatefulSet: StatefulSet یک شی Kubernetes است که بارهای کاری چندگانه stateful را مدیریت می کند و چنین بارهای کاری نیاز به هماهنگی دارند. StatefulSets ضمانت هایی را در مورد ترتیب غلاف ها و منحصر به فرد بودن آنها ارائه می دهد.
• خدمات بدون سر: سرویس ها به شما امکان می دهند با استفاده از یک نام منطقی، پادها را از مشتریان جدا کنید. Kubernetes در این مورد مسئول تعادل بار است. با این حال، هنگام اجرای بارهای کاری حالت دار، مانند ZooKeeper و Kafka، مشتریان باید با یک نمونه خاص ارتباط برقرار کنند. اینجاست که سرویس‌های هدلس به کار می‌آیند: در این مورد، مشتری همچنان یک نام منطقی خواهد داشت، اما نیازی نیست مستقیماً با پاد تماس بگیرید.
• حجم ذخیره سازی طولانی مدت: این حجم ها برای پیکربندی ذخیره سازی دائمی بلوک غیر محلی که در بالا ذکر شد مورد نیاز است.

بر یولین مجموعه ای جامع از مانیفست ها را برای کمک به شما در شروع کار با کافکا در Kubernetes ارائه می دهد.

نمودارهای هلم

Helm یک مدیر بسته برای Kubernetes است که می تواند با مدیران بسته سیستم عامل مانند yum، apt، Homebrew یا Chocolatey مقایسه شود. نصب بسته های نرم افزاری از پیش تعریف شده شرح داده شده در نمودار Helm را آسان می کند. یک نمودار Helm که به خوبی انتخاب شده است، کار دشوار نحوه پیکربندی صحیح همه پارامترها برای استفاده از کافکا در Kubernetes را آسان می کند. چندین نمودار کافکا وجود دارد: نمودار رسمی واقع شده است در شرایط جوجه کشی، یکی از وجود دارد اتصال، یکی دیگر - از بیتنی.

اپراتورها

از آنجا که Helm کاستی های خاصی دارد، ابزار دیگری محبوبیت قابل توجهی پیدا می کند: اپراتورهای Kubernetes. این اپراتور نه تنها نرم افزار را برای Kubernetes بسته بندی می کند، بلکه به شما امکان می دهد چنین نرم افزاری را مستقر کرده و آن را مدیریت کنید.

در لیست اپراتورهای شگفت انگیز دو عملگر برای کافکا ذکر شده است. یکی از آنها - استریمزی. با Strimzi، به راحتی می توانید خوشه کافکا خود را در عرض چند دقیقه راه اندازی کنید. عملاً هیچ پیکربندی مورد نیاز نیست، علاوه بر این، خود اپراتور برخی از ویژگی های خوب را فراهم می کند، به عنوان مثال، رمزگذاری نقطه به نقطه TLS در کلاستر. Confluent نیز فراهم می کند اپراتور خود.

کارایی

مهم است که عملکرد را با محک زدن نمونه کافکا خود آزمایش کنید. چنین آزمایشاتی به شما کمک می کند تا قبل از بروز مشکلات، گلوگاه های احتمالی را پیدا کنید. خوشبختانه، کافکا در حال حاضر دو ابزار تست عملکرد ارائه کرده است: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. از آنها استفاده فعال داشته باشید. برای مرجع، می توانید به نتایج شرح داده شده در این پست جی کرپس، یا روی این بررسی آمازون MSK توسط استفان مارک.

عملیات

نظارت

شفافیت در سیستم بسیار مهم است - در غیر این صورت شما متوجه نمی شوید که در آن چه اتفاقی می افتد. امروزه یک جعبه ابزار محکم وجود دارد که نظارت مبتنی بر معیارها را به سبک بومی ابری ارائه می‌کند. دو ابزار محبوب برای این منظور Prometheus و Grafana هستند. Prometheus می‌تواند معیارها را از تمام فرآیندهای جاوا (Kafka، Zookeeper، Kafka Connect) با استفاده از صادرکننده JMX - به ساده‌ترین روش، جمع‌آوری کند. اگر معیارهای cAdvisor را اضافه کنید، می‌توانید نحوه استفاده از منابع در Kubernetes را کاملاً درک کنید.

Strimzi یک نمونه بسیار مناسب از داشبورد Grafana برای کافکا دارد. معیارهای کلیدی را به تصویر می کشد، به عنوان مثال، در مورد بخش هایی که کمتر تکرار شده اند یا آنهایی که آفلاین هستند. آنجا همه چیز خیلی واضح است. این معیارها با استفاده از منابع و اطلاعات عملکرد و همچنین شاخص های ثبات تکمیل می شوند. بنابراین شما بدون هیچ هزینه ای از نظارت اولیه خوشه کافکا برخوردار می شوید!

منبع: streamzi.io/docs/master/#kafka_dashboard

خوب است که همه اینها را با نظارت مشتری (معیارهای مصرف کنندگان و تولیدکنندگان) و همچنین نظارت بر تأخیر تکمیل کنیم (برای این کار وجود دارد سوراخ) و نظارت سرتاسر - برای این استفاده مانیتور کافکا.

ورود به سیستم

ورود به سیستم یکی دیگر از وظایف حیاتی است. مطمئن شوید که همه کانتینرهای نصب کافکا شما وارد شده اند stdout и stderrو همچنین اطمینان حاصل کنید که خوشه Kubernetes شما همه گزارش ها را در یک زیرساخت ثبت مرکزی جمع می کند، به عنوان مثال. ارزیابی جستجو.

بررسی عملکردی

Kubernetes از کاوشگرهای زنده و آمادگی برای بررسی اینکه آیا غلاف شما به طور معمول کار می کند یا خیر استفاده می کند. اگر بررسی زنده بودن ناموفق باشد، Kubernetes آن ظرف را متوقف می‌کند و اگر خط‌مشی راه‌اندازی مجدد مطابق با آن تنظیم شود، به‌طور خودکار آن را مجدداً راه‌اندازی می‌کند. اگر بررسی آمادگی ناموفق باشد، Kubernetes پاد را از درخواست‌های سرویس جدا می‌کند. بنابراین، در چنین مواردی، دیگر نیازی به مداخله دستی نیست، که یک مزیت بزرگ است.

انتشار به روز رسانی ها

StatefulSets از به‌روزرسانی‌های خودکار پشتیبانی می‌کند: اگر استراتژی RollingUpdate را انتخاب کنید، هر کدام تحت کافکا به نوبه خود به‌روزرسانی می‌شوند. به این ترتیب می توان زمان خاموشی را به صفر رساند.

مقیاس بندی

مقیاس بندی یک خوشه کافکا کار آسانی نیست. با این حال، Kubernetes مقیاس کردن پادها را به تعداد معینی از کپی‌ها بسیار آسان می‌کند، به این معنی که می‌توانید به‌صورت اعلامی به تعداد دلخواه کافکا تعریف کنید. سخت ترین کار در این مورد، تخصیص مجدد بخش ها پس از افزایش مقیاس یا قبل از کاهش مقیاس است. باز هم Kubernetes به شما در انجام این کار کمک می کند.

اداره

وظایف مربوط به مدیریت خوشه کافکا، مانند ایجاد موضوعات و تخصیص مجدد بخش‌ها، می‌تواند با استفاده از اسکریپت‌های پوسته موجود با باز کردن رابط خط فرمان در پادهای خود انجام شود. با این حال، این راه حل چندان زیبا نیست. Strimzi از مدیریت موضوعات با استفاده از یک اپراتور متفاوت پشتیبانی می کند. اینجا مقداری جا برای پیشرفت وجود دارد.

کپی رنو و کوشش و مقاومت

اکنون در دسترس بودن کافکا به در دسترس بودن Kubernetes نیز بستگی دارد. اگر خوشه Kubernetes شما شکست بخورد، در بدترین حالت، خوشه کافکا شما نیز شکست خواهد خورد. طبق قانون مورفی قطعا این اتفاق خواهد افتاد و شما اطلاعات را از دست خواهید داد. برای کاهش این نوع ریسک، یک مفهوم پشتیبان خوب داشته باشید. می توانید از MirrorMaker استفاده کنید، گزینه دیگر استفاده از S3 برای این کار است، همانطور که در این توضیح داده شده است پست از زالاندو

نتیجه

هنگام کار با خوشه های کوچک تا متوسط ​​کافکا، قطعاً ارزش استفاده از Kubernetes را دارد زیرا انعطاف پذیری بیشتری را ارائه می دهد و تجربه اپراتور را ساده می کند. اگر نیازهای تأخیر و/یا توان عملیاتی بسیار قابل توجهی دارید، ممکن است بهتر باشد گزینه دیگری را در نظر بگیرید.

منبع: www.habr.com