🥇چگونه اولویت‌های غلاف در Kubernetes باعث خرابی در آزمایشگاه Grafana شد

توجه داشته باشید. ترجمه: جزئیات فنی در مورد دلایل قطعی اخیر سرویس ابری که توسط سازندگان Grafana نگهداری می شود را به شما ارائه می دهیم. این یک مثال کلاسیک از این است که چگونه یک ویژگی جدید و به ظاهر بسیار مفید طراحی شده برای بهبود کیفیت زیرساخت می تواند باعث آسیب شود، اگر تفاوت های ظریف متعدد کاربرد آن را در واقعیت های تولید فراهم نکنید. وقتی مطالبی مانند این ظاهر می شود که به شما امکان می دهد نه تنها از اشتباهات خود بیاموزید عالی است. جزئیات در ترجمه این متن از معاونت تولید آزمایشگاه گرافانا آمده است.

در روز جمعه، 19 جولای، سرویس میزبانی Prometheus در Grafana Cloud تقریباً 30 دقیقه از کار افتاد. من از همه مشتریانی که به دلیل قطعی آسیب دیده اند عذرخواهی می کنم. وظیفه ما فراهم کردن ابزارهای نظارتی مورد نیاز شما است و ما درک می کنیم که در دسترس نبودن آنها می تواند زندگی شما را دشوارتر کند. ما این حادثه را بسیار جدی می‌گیریم. این یادداشت توضیح می‌دهد که چه اتفاقی افتاده است، چگونه واکنش نشان داده‌ایم، و چه کاری انجام می‌دهیم تا اطمینان حاصل کنیم که دوباره تکرار نمی‌شود.

ماقبل تاریخ

Grafana Cloud Hosted Prometheus سرویس مبتنی بر قشر - پروژه CNCF برای ایجاد یک سرویس Prometheus با مقیاس پذیری افقی، بسیار در دسترس و چند مستاجر. معماری Cortex از مجموعه‌ای از میکروسرویس‌های مجزا تشکیل شده است که هر یک عملکرد خاص خود را انجام می‌دهند: تکرار، ذخیره‌سازی، پرس و جو و غیره. Cortex در حال توسعه فعال است و به طور مداوم در حال افزودن ویژگی های جدید و بهبود عملکرد است. ما مرتباً نسخه‌های جدید Cortex را در خوشه‌ها مستقر می‌کنیم تا مشتریان بتوانند از این ویژگی‌ها استفاده کنند - خوشبختانه، Cortex می‌تواند بدون توقف به‌روزرسانی شود.

برای به‌روزرسانی‌های یکپارچه، سرویس Ingester Cortex به یک نسخه اضافی Ingester در طول فرآیند به‌روزرسانی نیاز دارد. (توجه داشته باشید. ترجمه: مصرف کننده - جزء اصلی قشر. وظیفه آن جمع آوری یک جریان ثابت از نمونه ها، گروه بندی آنها در تکه های Prometheus و ذخیره آنها در پایگاه داده ای مانند DynamoDB، BigTable یا Cassandra است.) این به گیرندگان قدیمی اجازه می‌دهد تا داده‌های فعلی را به مصرف‌کنندگان جدید ارسال کنند. شایان ذکر است که مصرف کنندگان نیاز به منابع دارند. برای اینکه آنها کار کنند، باید 4 هسته و 15 گیگابایت حافظه در هر پاد داشته باشید، یعنی. 25 درصد از قدرت پردازش و حافظه دستگاه پایه در مورد خوشه های Kubernetes ما. به طور کلی، ما معمولاً منابع استفاده نشده بسیار بیشتری در خوشه نسبت به 4 هسته و 15 گیگابایت حافظه داریم، بنابراین می‌توانیم به راحتی این ورودی‌های اضافی را در حین ارتقاء بچرخانیم.

با این حال، اغلب اتفاق می افتد که در طول کار عادی هیچ یک از ماشین ها این 25٪ از منابع استفاده نشده را ندارند. بله، ما حتی تلاش نمی کنیم: CPU و حافظه همیشه برای سایر فرآیندها مفید خواهند بود. برای حل این مشکل تصمیم گرفتیم استفاده کنیم اولویت های Kubernetes Pod. ایده این است که به Ingesters اولویت بیشتری نسبت به سایر خدمات میکرو (بدون تابعیت) داده شود. هنگامی که ما نیاز به اجرای یک جذب کننده اضافی (N+1) داریم، به طور موقت سایر غلاف های کوچکتر را جابجا می کنیم. این غلاف ها به منابع رایگان در ماشین های دیگر منتقل می شوند و یک "سوراخ" به اندازه کافی بزرگ برای اجرای یک Ingester اضافی باقی می گذارند.

در روز پنجشنبه، 18 جولای، ما چهار سطح اولویت جدید را برای خوشه‌های خود ارائه کردیم: بحرانی, زیاد, متوسط и کم. آنها برای حدود یک هفته روی یک خوشه داخلی بدون ترافیک مشتری آزمایش شدند. به طور پیش‌فرض، غلاف‌های بدون اولویت مشخص دریافت می‌شوند متوسط اولویت، کلاس برای مصرف کنندگان با تنظیم شد بالا اولویت. بحرانی برای نظارت (Prometheus، Alertmanager، node-exporter، kube-state-metrics، و غیره) رزرو شده بود. پیکربندی ما باز است و می توانید روابط عمومی را مشاهده کنید اینجا.

سقوط

در روز جمعه، 19 جولای، یکی از مهندسان یک خوشه جدید Cortex اختصاصی را برای یک مشتری بزرگ راه اندازی کرد. پیکربندی این خوشه شامل اولویت‌های غلاف جدید نیست، بنابراین به همه پادهای جدید اولویت پیش‌فرض اختصاص داده شده است - متوسط.

خوشه Kubernetes منابع کافی برای خوشه Cortex جدید نداشت و خوشه Cortex تولیدی موجود به روز نشد (مصرف کنندگان بدون رها شدند. بالا اولویت). از آنجایی که Ingesters از خوشه جدید به طور پیش فرض داشته است متوسط اولویت، و غلاف‌های موجود در تولید اصلاً بدون اولویت کار می‌کردند، بلع‌کننده‌های خوشه جدید جایگزین خورنده‌های خوشه تولیدی Cortex موجود شدند.

ReplicaSet برای Ingester خارج شده در خوشه تولید، غلاف خارج شده را شناسایی کرد و یک مورد جدید برای حفظ تعداد مشخص شده کپی ایجاد کرد. پاد جدید به طور پیش فرض اختصاص داده شد متوسط اولویت، و یکی دیگر از اینگسترهای "قدیمی" در تولید منابع خود را از دست داد. نتیجه شد فرآیند بهمن، که منجر به جابجایی همه غلاف ها از Ingester برای خوشه های تولید Cortex شد.

مصرف کننده ها حالتی هستند و داده های 12 ساعت گذشته را ذخیره می کنند. این به ما امکان می دهد قبل از نوشتن آنها در ذخیره سازی طولانی مدت، آنها را به طور موثرتر فشرده کنیم. برای دستیابی به این هدف، Cortex داده‌ها را با استفاده از یک جدول هش توزیع شده (DHT) خرد می‌کند و با استفاده از قوام حد نصاب به سبک Dynamo، هر سری را در سه ورودی تکرار می‌کند. Cortex داده‌هایی را برای مصرف کنندگان غیرفعال نمی‌نویسد. بنابراین، هنگامی که تعداد زیادی از مصرف کنندگان DHT را ترک می کنند، Cortex نمی تواند تکرار کافی ورودی ها را فراهم کند و آنها از کار می افتند.

تشخیص و اصلاح

اعلان‌های جدید Prometheus بر اساس "بودجه خطا" (بر اساس بودجه خطا - جزئیات در مقاله آینده ظاهر خواهد شد) 4 دقیقه پس از شروع خاموش شدن، زنگ هشدار را به صدا در آورد. در حدود پنج دقیقه بعدی، برخی از تشخیص‌ها را انجام دادیم و خوشه Kubernetes زیربنایی را برای میزبانی خوشه‌های تولید جدید و موجود افزایش دادیم.

پس از پنج دقیقه دیگر، خورنده های قدیمی با موفقیت داده های خود را نوشتند، موارد جدید شروع به کار کردند و خوشه های Cortex دوباره در دسترس قرار گرفتند.

10 دقیقه دیگر صرف تشخیص و تصحیح خطاهای خارج از حافظه (OOM) از پراکسی های معکوس احراز هویت واقع در جلوی Cortex شد. خطاهای OOM به دلیل افزایش ده برابری QPS (به اعتقاد ما به دلیل درخواست های بیش از حد تهاجمی از سرورهای Prometheus مشتری) ایجاد شد.

عواقب بعدی

کل زمان توقف 26 دقیقه بود. هیچ داده ای گم نشد. جذب کننده ها با موفقیت تمام داده های درون حافظه را در ذخیره سازی طولانی مدت بارگیری کرده اند. در طول خاموش شدن، سرورهای Prometheus مشتری بافر حذف شدند (از راه دور) ضبط با استفاده از API جدید remote_write بر اساس WAL (نویسنده کالوم استیان از Grafana Labs) و نوشته های ناموفق پس از سقوط را تکرار کرد.

عملیات نوشتن خوشه تولید

یافته ها

درس گرفتن از این حادثه و انجام اقدامات لازم برای جلوگیری از تکرار آن مهم است.

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

ما یک سطح کنترل اضافی بر روی استقرار هر شیء اضافی که پیکربندی‌های آن سراسری است به خوشه اضافه می‌کنیم. از این پس چنین تغییراتی ارزیابی خواهد شد بоمردم بیشتری. علاوه بر این، اصلاحاتی که باعث خرابی شد برای یک سند پروژه جداگانه بسیار جزئی در نظر گرفته شد - فقط در یک شماره GitHub مورد بحث قرار گرفت. از این پس، تمام این تغییرات در تنظیمات با مستندات پروژه مناسب همراه خواهد بود.

در نهایت، ما اندازه پراکسی معکوس احراز هویت را برای جلوگیری از اضافه بار OOM که شاهد بودیم، خودکار می‌کنیم و تنظیمات پیش‌فرض Prometheus مربوط به بازگشت و مقیاس‌گذاری را بررسی می‌کنیم تا از مشکلات مشابه در آینده جلوگیری کنیم.

این شکست همچنین پیامدهای مثبتی داشت: با دریافت منابع لازم، Cortex به طور خودکار بدون مداخله اضافی بهبود یافت. ما همچنین تجربیات ارزشمندی را در کار با آنها به دست آوردیم گرافانا لوکی - سیستم جدید تجمیع گزارش ما - که به اطمینان از اینکه همه مصرف کنندگان در طول و بعد از شکست به درستی رفتار می کنند کمک کرد.

PS از مترجم

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

چگونه اولویت‌های غلاف در Kubernetes باعث خرابی در آزمایشگاه Grafana شد