مقدمه

کوبان – پلتفرم جریان داده در زمان واقعی گرب – در حدود دو سال است کهKafkaonKuberneteswithStrimziرا در
تولید استفاده می کند. در مقاله قبلی (صفر اعتماد با کافکا) توضیح داده شده است که چگونه ما از Strimzi برای ارتقای امنیت پیشنهادی جریان داده استفاده کردیم.

در این مقاله، قصد داریم توضیح دهیم چگونه ما قابلیت تحمل خطا در طراحی اولیه خود را بهبود داده ایم به طوری که دیگر نیاز به دخالتی نداریم اگر بروکر کافکا به طور غیر منتظرهیک پایان یابد.

بیانیه مسئله

ما کافکا را در ابر AWS اجرا می کنیم. برای طراحی Kafka on Kubernetes که در این مقاله توصیف می شود، ما بر روی سرویس Kubernetes Elastic Kubernetes Service (EKS) از Amazon در AWS وابستگی داریم، با استفاده از کارگره های مستقل که به عنوان های نود های مدیریت خود در Cloud Elastic Compute Cloud (EC2) در AWS استقرار می یابند.

برای آسان تر کردن عملیات خود و محدود کردن حوزه اثر هر حادثه ، ما دقیقاً یک خوشه کافکا برای هر خوشه EKS مستقر می کنیم. همچنین به هر بروکر کافکا یک کارگره کامل اختصاص می دهیم. از نظر ذخیره سازی ، در ابتدا بر روی نمونه های EC2 با حجم فروش ناگسست نصب شدیم برای عملکرد I / O حداکثر. همچنین، هر خوشه کافکا از طریق خودVirtual پرایویت کلود (VPC) در دسترس است از VPC Endpoint Service خود.

شکل 1 نمایش منطقی طرح اولیه خوشه 3 نود Kafka on Kubernetes ما است، همانطور که به طور معمول توسط Coban اجرا می شود. اجزای Zookeeper و Cruise-Control برای وضوح نشان داده نمی شوند.

چهار سرویس کوبرنتیز وجود دارد (1): یکی برای اتصال اولیه – به عنوان ‘bootstrap’ شناخته می شود – که ترافیک ورودی را به هر پاد Kafka تغییر مسیر می دهد ، همچنین یکی برای هر پاد Kafka برای مشتریان برای هدف گیری هر بروکر Kafka به صورت جداگانه (نیاز به تولید یا مصرف از / به یک پارتیشن که در هر بروکر Kafka خاصی قرار دارد). چهار گوشگیر مختلف روی Load Balancer شبکه (NLB) که بر روی چهار پورت TCP مختلف متمرکز هستند ، به مشتریان Kafka امکان می دهند هدف خود را به سمت سرویس bootstrap یا هر بروکر Kafka خاصی که نیاز دارند، هدف قرار دهند. این بسیار شبیه به آنچه قبلاً در مورد ارائه خوشه Kafka از طریق VPC Endpoint Service توضیح داده شده است.

هر یک از نود های کارگر را یک پاد Kafka تهیه می کند (2). حجم ذخیره فروش ناگسست برای ایجاد یک حجم دائمی Kubernetes (PV) استفاده می شود که از طریق درخواست حجم دائمی سازی Kubernetes (PVC) به یک پاد متصل می شود.

سرانجام ، نود های کارگر متعلق به گروه های خودکار اسکیلینگ (ASG) است (3) به تعداد یک (Availability Zone (AZ. Strimzi نسبت به توزیع متساوی بروکرها در AZ ها افزودن تمایل کرده است. در این طراحی اولیه ، گروه های خودکار اسکیلینگ برای اتوماسینگ استفاده نمی شوند، زیرا ما می خواهیم اندازه خوشه را تحت کنترل نگه داشته و فقط از گروه های خودکار اسکیلینگ – با اندازه ثابت – برای تسهیل عملیات مقیاس بندی دستی و جایگزینی خودکار نودهای کارگر استفاده کنیم.

با این طراحی اولیه ، بیایید ببینیم در صورت پایان یک چنین نود کارگری چه اتفاقی می افتد.

شکل 2 نشان می دهد که نود کارگر C همراه با حجم ذخیره فروش ناگسست C خودش را متوقف می کند و جایگزین (توسط ASG) توسط یک نود کارگر جدید D و حجم دائمی ناگسست خالی D می شود. در هنگام راه اندازی ، نود کارگر D به طور خودکار به خوشه Kubernetes ملحق می شود. پاد بروکر 3 کافکا که روی نود کارگر C نادرست اجرا می شد ، بر روی نود کارگر D برنامه ریزی می شود تا روی نود کارگر جدید D مجدداً شروع شود.

اینکه حجم ذخیره فروش ناگسست C همراه با نود کارگر C خاتمه می یابد ، هیچ از دست دادن داده ای نیست زیرا همه موضوعات کافکا ما با حداقل سه کپی تنظیم شده اند. داده ها از بروکرهای کافکا بازمانده 1 و 2 به بروکر کافکا 3 به صورتی که بروکر کافکا 3 به طور موثر بر روی نود کارگر D شروع می شود.

با این طراحی اولیه سه مشکل اساسی وجود دارد:

مشتریان Kafka که در حال تولید یا مصرف به / از رهبران پارتیشن بروکر Kafka 3 هستند ، به طور ناگهانی با خطاهای اتصال مواجه می شوند ، زیرا که قبل از اینکه بروکر به طور مودبانه در دست برگیرد پایین نیامده است.گروه هدف های NLB برای هم اتصال bootstrap و بروکر Kafka 3 هنوز به نود کارگر C اشاره می کنند. بنابراین ، ارتباط شبکه از NLB به بروکر Kafka 3 قطع می شود. نیاز به تنظیم مجدد دستی گروه هدف وجود دارد.PVC مرتبط با پاد بروکر Kafka 3 به PV حجم فروش ناگسست جدید نود کارگر D قادر به تعویض خودکار نمی شود. به راستی ، تأمین استاتیک ویژگی جوانه برداری استوارهای محلی Kubernetes است. PVC هنوز در حالت متصل بودن است ، بنابراین Kubernetes هیچ اقدامی نمی کند. با این حال ، ذخیره واقعی زیر PV دیگر وجود ندارد. بدون هیچ ذخیره سازی ، پاد بروکر Kafka 3 قادر به راه اندازی نمی شود.

در این مرحله ، خوشه Kafka با تنها دو بروکر از سه بروکر در حال اجرا است ، تا زمانی که یک مهندس Coban برای تنظیم مجدد گروه هدف های NLB و حذف PVC زامبی (که در نتیجه باعث ایجاد مجدد توسط Strimzi می شود ، این بار با استفاده از PV حجم فروش ناگسست جدید) دخالت کند.

در بخش بعدی، خواهیم دید که چگونه ما موفق شده ایم به سه مشکل مذکور در بالا در طراحی خود برای مقابله با خطا پایداری ببخشیم.

راه حل

خاموشی مودبانه کافکا

برای کاهش اختلال برای مشتریان Kafka ، ما ازAWS Node Termination Handler(NTH) بهره بردیم. این مؤلفه که توسط AWS برای محیط های Kubernetes فراهم می شود ، قادر به انتقال و تخلیه یک نود کارگر است که قرار است خاتمه یابد. این تخلیه ، به نوبه خود ، با ارسال سیگنالSIGTERMمودبانه به تمام پادها در حال اجرا روی نود کارگری که در حال خروج است (بجای حذف بدون رحمانهSIGKILL چگونه یک خاتمه عادی) ، توقف مودبانه فرآیند Kafka را فعال می کند.

رویدادهای خاتمه مورد نظر که توسط NTH گرفته می شوند:

عملیات کوچک در ASG.حذف دستی یک نمونه.رویدادهای نگهداری AWS ، به طور معمول نمونه های EC2 برنامه ریزی شده برای بازنشستگی پیش رو.

این برای بیشتر اختلالاتی است که خوشه های ما در زمان های عادی و عملیات نگهداری معمولی ما می توانند با آن روبرو شوند ، مانند خاتمه یک نود کارگر برای تازه کردن آن. تنها شکست های سخت افزاری ناگهانی (رویدادهای AWS) به طور مستقیم به پهنه خطاهای سمت مشتریان Kafka منجر خواهد شد.

NTH دارای دو حالت است: سرویس متادیتای نمونه (IMDS) و Queue Processor. ما تصمیم گرفتیم به حالت دوم برویم زیرا قادر است نقطه ی پایان گسترده ای از رویدادها را که در پهنه خطا افزایش می یابد ، گرفته شود.

عملیات کوچک در ASG

شکل 3 نشان می دهد که NTH با صف پردازنده در حال عمل است و چگونه در پاسخ به یک عملیات کوچک کردن (به طور معمول در هنگام انجام یک عملیات نگهداری) واکنش نشان می دهد:

همزمان ، یک رویداد Auto Scaling lifecycle hook به یک صف Amazon Simple Queue Service (SQS) صادر می شود. در شکل 3 ، ما رویدادهای EC2 را نشان داده ایم (به عنوان مثال خاتمه عادی یک نمونه ، رویدادهای نگهداری AWS و غیره) که از طریق Amazon EventBridge عبور کرده و در نهایت در همان صف SQS انتها می کنند. ما در دو بخش بعدی به رویدادهای EC2 خواهیم پرداخت. NTH که یک پاد در همان خوشه Kubernetes است ، به طور مداوم این صف SQS را نظارت می کند.زمانی که یک رویداد کوچک کردن مرتبط با یک نود کارگر خوشه Kubernetes از صف SQS خوانده شود ، NTH دستورات کوبرنتیز API را به واحد کارگر تحت تأثیر می فرستد.در حین تخلیه ، Kubernetes یک