🥇نتیجه گیری ما از سال مهاجرت GitLab.com به Kubernetes

توجه داشته باشید. ترجمه: پذیرش Kubernetes در GitLab یکی از دو عامل اصلی در رشد شرکت در نظر گرفته می شود. با این حال، تا همین اواخر زیرساخت سرویس آنلاین GitLab.com بر روی ماشین های مجازی ساخته می شد و تنها حدود یک سال پیش مهاجرت آن به K8s آغاز شد که هنوز تکمیل نشده است. ما خوشحالیم که ترجمه مقاله اخیر یک مهندس GitLab SRE را در مورد چگونگی این اتفاق و نتیجه گیری مهندسان شرکت کننده در پروژه ارائه می دهیم.

حدود یک سال است که بخش زیرساخت ما تمام سرویس‌های در حال اجرا در GitLab.com را به Kubernetes منتقل کرده است. در طول این مدت، ما نه تنها با انتقال خدمات به Kubernetes، بلکه به مدیریت استقرار ترکیبی در طول انتقال نیز با چالش‌هایی مواجه شدیم. درس های ارزشمندی که آموختیم در این مقاله مورد بحث قرار خواهد گرفت.

از همان ابتدای GitLab.com، سرورهای آن در فضای ابری روی ماشین‌های مجازی کار می‌کردند. این ماشین های مجازی توسط Chef مدیریت می شوند و با استفاده از ما نصب می شوند بسته رسمی لینوکس. استراتژی استقرار در صورتی که برنامه نیاز به به روز رسانی داشته باشد، شامل به روز رسانی ناوگان سرور به شیوه ای هماهنگ و متوالی با استفاده از خط لوله CI است. این روش - البته آهسته و کمی حوصله سر بر - تضمین می کند که GitLab.com از روش های نصب و پیکربندی مشابه کاربران آفلاین استفاده می کند (خود مدیریتی) نصب GitLab با استفاده از بسته های لینوکس ما برای این کار.

ما از این روش استفاده می کنیم زیرا تجربه تمام غم ها و شادی هایی که اعضای عادی جامعه هنگام نصب و پیکربندی نسخه های GitLab خود تجربه می کنند بسیار مهم است. این رویکرد برای مدتی به خوبی جواب داد، اما زمانی که تعداد پروژه ها در GitLab از 10 میلیون گذشت، متوجه شدیم که دیگر پاسخگوی نیازهای ما برای مقیاس و استقرار نیست.

اولین قدم‌ها به سمت Kubernetes و GitLab بومی ابری

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

فشار به سمت ابر بومی و Kubernetes به مهندسان ما اجازه داد تا یک انتقال تدریجی را برنامه ریزی کنند، در طی آن ما برخی از وابستگی های برنامه به ذخیره سازی شبکه را کنار گذاشتیم و در عین حال به توسعه ویژگی های جدید ادامه دادیم. از زمانی که ما برنامه ریزی مهاجرت را در تابستان 2019 آغاز کردیم، بسیاری از این محدودیت ها برطرف شده اند و روند مهاجرت GitLab.com به Kubernetes اکنون به خوبی در حال انجام است!

ویژگی های GitLab.com در Kubernetes

برای GitLab.com، ما از یک کلاستر منطقه‌ای GKE استفاده می‌کنیم که تمام ترافیک برنامه‌ها را مدیریت می‌کند. برای به حداقل رساندن پیچیدگی مهاجرت (از قبل مشکل)، روی سرویس هایی تمرکز می کنیم که به ذخیره سازی محلی یا NFS متکی نیستند. GitLab.com از یک پایگاه کد Rails عمدتاً یکپارچه استفاده می‌کند، و ما ترافیک را بر اساس ویژگی‌های بار کاری به نقاط پایانی مختلفی هدایت می‌کنیم که در استخرهای گره خود ایزوله شده‌اند.

در مورد frontend، این انواع به درخواست های وب، API، Git SSH/HTTPS و Registry تقسیم می شوند. در مورد backend، ما مشاغل موجود در صف را بر اساس ویژگی های مختلف بسته به آن تقسیم می کنیم مرزهای منابع از پیش تعریف شده، که به ما امکان می دهد اهداف سطح سرویس (SLO) را برای بارهای کاری مختلف تنظیم کنیم.

همه این سرویس‌های GitLab.com با استفاده از یک نمودار اصلاح‌نشده GitLab Helm پیکربندی شده‌اند. پیکربندی در نمودارهای فرعی انجام می‌شود، که می‌توان با انتقال تدریجی سرویس‌ها به خوشه، آن‌ها را به صورت انتخابی فعال کرد. حتی با وجود اینکه تصمیم گرفتیم برخی از خدمات دولتی خود را مانند Redis، Postgres، GitLab Pages و Gitaly در مهاجرت وارد نکنیم، استفاده از Kubernetes به ما این امکان را می‌دهد که تعداد VMهایی را که Chef در حال حاضر مدیریت می‌کند، به شدت کاهش دهیم.

قابلیت مشاهده و مدیریت پیکربندی Kubernetes

تمام تنظیمات توسط خود GitLab مدیریت می شود. برای این کار از سه پروژه پیکربندی مبتنی بر Terraform و Helm استفاده شده است. ما سعی می کنیم تا حد امکان از خود GitLab برای اجرای GitLab استفاده کنیم، اما برای کارهای عملیاتی یک نصب جداگانه GitLab داریم. این برای اطمینان از عدم وابستگی شما به در دسترس بودن GitLab.com هنگام اجرای استقرار و به‌روزرسانی GitLab.com لازم است.

اگرچه خطوط لوله ما برای خوشه Kubernetes بر روی یک نصب جداگانه GitLab اجرا می شود، آینه هایی از مخازن کد وجود دارد که به صورت عمومی در آدرس های زیر در دسترس هستند:

k8s-workloads/gitlab-com - چارچوب پیکربندی GitLab.com برای نمودار GitLab Helm.
k8s-workloads/gitlab-helmfiles - شامل تنظیماتی برای سرویس هایی است که مستقیماً با برنامه GitLab مرتبط نیستند. اینها شامل پیکربندی‌هایی برای ورود به سیستم و نظارت خوشه‌ای و همچنین ابزارهای یکپارچه‌ای مانند PlantUML است.
زیرساخت Gitlab-com - پیکربندی Terraform برای Kubernetes و زیرساخت VM قدیمی. در اینجا شما تمام منابع لازم برای اجرای خوشه را پیکربندی می‌کنید، از جمله خود خوشه، گره‌ها، حساب‌های سرویس و رزرو آدرس IP.

وقتی تغییرات ایجاد می شود نمای عمومی نشان داده می شود. خلاصه کوتاه با پیوندی به تفاوت تفصیلی که SRE قبل از ایجاد تغییرات در خوشه تجزیه و تحلیل می کند.

برای SRE، پیوند منجر به یک تفاوت دقیق در نصب GitLab می شود که برای تولید استفاده می شود و دسترسی به آن محدود است. این به کارمندان و جامعه اجازه می دهد بدون دسترسی به پروژه عملیاتی (که فقط برای SRE ها باز است)، تغییرات پیکربندی پیشنهادی را مشاهده کنند. با ترکیب یک نمونه GitLab عمومی برای کد با یک نمونه خصوصی برای خطوط لوله CI، ما یک گردش کار واحد را حفظ می‌کنیم و در عین حال استقلال از GitLab.com را برای به‌روزرسانی‌های پیکربندی تضمین می‌کنیم.

آنچه در هجرت متوجه شدیم

در طول انتقال، تجربه ای به دست آمد که ما آن را برای مهاجرت ها و استقرارهای جدید در Kubernetes اعمال می کنیم.

1. افزایش هزینه ها به دلیل ترافیک بین مناطق در دسترس

آمار خروج روزانه (بایت در روز) برای ناوگان مخزن Git در GitLab.com

گوگل شبکه خود را به مناطق تقسیم می کند. آنها به نوبه خود به مناطق دسترسی (AZ) تقسیم می شوند. میزبانی گیت با مقادیر زیادی داده مرتبط است، بنابراین کنترل خروجی شبکه برای ما مهم است. برای ترافیک داخلی، خروج تنها در صورتی رایگان است که در همان منطقه در دسترس باقی بماند. از زمان نوشتن این مقاله، ما تقریباً 100 ترابایت داده را در یک روز کاری معمولی ارائه می کنیم (و این فقط برای مخازن Git است). سرویس‌هایی که در همان ماشین‌های مجازی در توپولوژی قدیمی مبتنی بر VM ما قرار داشتند، اکنون در پادهای مختلف Kubernetes اجرا می‌شوند. این به این معنی است که برخی از ترافیک‌هایی که قبلاً محلی برای VM بوده‌اند، می‌توانند به طور بالقوه به خارج از مناطق در دسترس سفر کنند.

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

2. محدودیت ها، درخواست های منابع و مقیاس بندی

تعداد ترافیک تولید پردازش ماکت در registry.gitlab.com. اوج ترافیک در ساعت 15:00 UTC است.

داستان مهاجرت ما در آگوست 2019 آغاز شد، زمانی که اولین سرویس خود، GitLab Container Registry، را به Kubernetes منتقل کردیم. این سرویس بسیار حیاتی و پرترافیک، انتخاب خوبی برای اولین مهاجرت بود، زیرا یک برنامه بدون تابعیت با وابستگی های خارجی کمی است. اولین مشکلی که با آن مواجه شدیم، تعداد زیاد غلاف های خارج شده به دلیل کمبود حافظه روی گره ها بود. به همین دلیل مجبور شدیم درخواست ها و محدودیت ها را تغییر دهیم.

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

3. معیارها و سیاهههای مربوط

بخش زیرساخت بر تأخیر، نرخ خطا و اشباع با نصب متمرکز است اهداف سطح خدمات (SLO) مرتبط به در دسترس بودن عمومی سیستم ما.

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

این مشکل تقریباً بلافاصله پس از انتقال برخی از بارهای کاری به خوشه کشف شد. زمانی که مجبور شدیم توابعی را بررسی کنیم که تعداد درخواست‌های آنها کم بود، اما وابستگی‌های پیکربندی بسیار خاصی داشتند، این امر به‌ویژه حادتر شد. یکی از درس‌های کلیدی از مهاجرت، نیاز به در نظر گرفتن نه تنها معیارها در هنگام نظارت، بلکه همچنین لاگ‌ها و "دم دراز" بود. (این در مورد چنین توزیع آنها در نمودار - تقریبا. ترجمه.) خطاها اکنون برای هر مهاجرت یک لیست دقیق از پرس و جوهای گزارش را درج می کنیم (پرس و جوهای ثبت نام) و رویه‌های برگشت روشنی را برنامه‌ریزی کنید که در صورت بروز مشکلات می‌توانند از یک شیفت به شیفت بعدی منتقل شوند.

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

4. تغییر ترافیک به یک خوشه جدید

برای GitLab.com، بخشی از سرورها به آن اختصاص داده شده است مرحله قناری. پارک قناری به پروژه های داخلی ما خدمات می دهد و همچنین می تواند توسط کاربران فعال شده است. اما در درجه اول برای آزمایش تغییرات ایجاد شده در زیرساخت و برنامه طراحی شده است. اولین سرویس انتقال یافته با پذیرش مقدار محدودی از ترافیک داخلی شروع شد و ما همچنان از این روش استفاده می کنیم تا مطمئن شویم SLO ها قبل از ارسال تمام ترافیک به خوشه برآورده می شوند.

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

5. ظرفیت های ذخیره غلاف و استفاده از آنها

تقریباً بلافاصله مشکل زیر شناسایی شد: پادها برای سرویس Registry به سرعت شروع به کار کردند، اما راه‌اندازی پادها برای Sidekiq طول کشید تا دو دقیقه. زمان طولانی راه اندازی برای پادهای Sidekiq زمانی به یک مشکل تبدیل شد که ما شروع به انتقال بار کاری به Kubernetes برای کارگرانی کردیم که نیاز به پردازش سریع مشاغل و مقیاس بندی سریع داشتند.

در این مورد، درس این بود که در حالی که مقیاس‌کننده خودکار غلاف افقی (HPA) کوبرنتس رشد ترافیک را به خوبی مدیریت می‌کند، مهم است که ویژگی‌های بار کاری را در نظر بگیریم و ظرفیت اضافی را به غلاف‌ها اختصاص دهیم (مخصوصاً زمانی که تقاضا به‌طور نابرابر توزیع شود). در مورد ما، یک افزایش ناگهانی در مشاغل وجود داشت که منجر به مقیاس‌بندی سریع شد، که منجر به اشباع منابع CPU قبل از اینکه زمان لازم برای مقیاس‌بندی گره‌پول را داشته باشیم، شد.

همیشه این وسوسه وجود دارد که تا جایی که ممکن است از یک خوشه بیرون بیایید، با این حال، با توجه به اینکه در ابتدا با مشکلات عملکردی مواجه شدیم، اکنون با بودجه سخاوتمندانه پاد شروع می کنیم و بعداً آن را کاهش می دهیم و SLO ها را زیر نظر داریم. راه اندازی غلاف برای سرویس Sidekiq سرعت قابل توجهی داشته است و اکنون به طور متوسط حدود 40 ثانیه طول می کشد. از کاهش زمان راه اندازی غلاف ها هم GitLab.com و هم کاربران نصب‌های خود مدیریتی را که با نمودار رسمی GitLab Helm کار می‌کنند، برد.

نتیجه

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

امیدوارم از داستان ماجراهای مهاجرت کوبرنتیس ما لذت برده باشید. ما به انتقال همه خدمات جدید به خوشه ادامه می دهیم. اطلاعات تکمیلی را می توان در نشریات زیر یافت:

PS از مترجم

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

منبع: www.habr.com

یافته های ما از یک سال مهاجرت GitLab.com به Kubernetes