در طول سال ها، 300 میلیون کاربر Pinterest بیش از 200 میلیارد پین در بیش از 4 میلیارد برد ایجاد کرده اند. برای خدمت به این ارتش از کاربران و پایگاه محتوای گسترده، این پورتال هزاران سرویس را توسعه داده است، از ریزسرویس هایی که می توانند توسط چند CPU مدیریت شوند، تا یکپارچه های غول پیکر که بر روی یک ناوگان کامل از ماشین های مجازی اجرا می شوند. و سپس لحظه ای فرا رسید که چشمان شرکت به k8s افتاد. چرا «مکعب» در پینترست خوب به نظر می‌رسد؟ شما در این مورد از ترجمه مقاله اخیر ما یاد خواهید گرفت .
بنابراین، صدها میلیون کاربر و صدها میلیارد پین. برای خدمت به این ارتش از کاربران و پایگاه عظیم محتوایی، ما هزاران سرویس را توسعه داده‌ایم، از ریزسرویس‌هایی که می‌توانند توسط چند CPU مدیریت شوند، تا یکپارچه‌های غول‌پیکر که روی کل ناوگان ماشین‌های مجازی اجرا می‌شوند. علاوه بر این، ما چارچوب‌های مختلفی داریم که ممکن است به CPU، حافظه یا دسترسی I/O نیز نیاز داشته باشند.
در نگهداری از این باغ وحش ابزار، تیم توسعه با تعدادی چالش مواجه است:
- هیچ راه یکسانی برای مهندسان برای اجرای یک محیط تولید وجود ندارد. خدمات بدون تابعیت، خدمات دولتی و پروژه های در حال توسعه فعال بر اساس پشته های فناوری کاملاً متفاوتی هستند. این منجر به ایجاد یک دوره آموزشی کامل برای مهندسان شد و همچنین کار تیم زیرساخت ما را به طور جدی پیچیده کرد.
- توسعه دهندگان با ناوگان ماشین های مجازی خود بار زیادی را بر دوش مدیران داخلی ایجاد می کنند. در نتیجه، عملیات ساده ای مانند به روز رسانی سیستم عامل یا AMI هفته ها و ماه ها طول می کشد. این منجر به افزایش حجم کار در موقعیت های به ظاهر کاملاً روزمره می شود.
- مشکلات در ایجاد ابزارهای مدیریت زیرساخت جهانی در کنار راه حل های موجود. با این واقعیت که یافتن صاحبان ماشین های مجازی آسان نیست، وضعیت پیچیده تر می شود. یعنی ما نمی دانیم که آیا می توان این ظرفیت را با خیال راحت استخراج کرد تا در سایر بخش های زیرساخت ما فعالیت کند یا خیر.
سیستم های ارکستراسیون کانتینری راهی برای یکسان سازی مدیریت حجم کار هستند. آنها در را برای افزایش سرعت توسعه باز می کنند و مدیریت زیرساخت را ساده می کنند، زیرا تمام منابع درگیر در پروژه توسط یک سیستم متمرکز مدیریت می شوند.
شکل 1: اولویت های زیرساخت (قابلیت اطمینان، بهره وری توسعه دهنده، و کارایی).
تیم پلتفرم مدیریت ابر در Pinterest K8s را در سال 2017 کشف کردند. تا نیمه اول سال 2017، ما بیشتر قابلیت‌های تولیدی خود، از جمله API و همه سرورهای وب خود را ثبت کرده بودیم. پس از آن، ما یک ارزیابی کامل از سیستم‌های مختلف برای هماهنگی راه‌حل‌های کانتینری، ساختن خوشه‌ها و کار با آنها انجام دادیم. در اواخر سال 2017 تصمیم گرفتیم از Kubernetes استفاده کنیم. کاملاً انعطاف پذیر بود و به طور گسترده در جامعه توسعه دهندگان پشتیبانی می شد.
تا به امروز، ما ابزارهای بوت کلاستر خود را بر اساس Kops ساخته‌ایم و اجزای زیرساخت موجود مانند شبکه، امنیت، معیارها، ورود به سیستم، مدیریت هویت و ترافیک را به Kubernetes منتقل کرده‌ایم. ما همچنین یک سیستم مدل‌سازی حجم کار را برای منبع خود پیاده‌سازی کردیم که پیچیدگی آن از دید توسعه‌دهندگان پنهان است. اکنون ما بر روی اطمینان از ثبات خوشه، مقیاس بندی آن و اتصال مشتریان جدید متمرکز شده ایم.
Kubernetes: The Pinterest Way
شروع کار با Kubernetes در مقیاس Pinterest به عنوان پلتفرمی که مهندسان ما دوست دارند با چالش‌های زیادی همراه بود.
به عنوان یک شرکت بزرگ، سرمایه گذاری زیادی در ابزارهای زیرساختی انجام داده ایم. به عنوان مثال می‌توان به ابزارهای امنیتی اشاره کرد که پردازش گواهی و توزیع کلید، اجزای کنترل ترافیک، سیستم‌های کشف سرویس، اجزای دید، و اجزای ارسال گزارش و معیارها را مدیریت می‌کنند. همه اینها به یک دلیل جمع آوری شد: ما مسیر عادی آزمون و خطا را طی کردیم، و بنابراین می خواستیم به جای اختراع مجدد چرخ قدیمی در یک پلت فرم جدید، همه این تجهیزات را در زیرساخت جدید Kubernetes ادغام کنیم. این رویکرد به طور کلی مهاجرت را ساده کرد، زیرا تمام پشتیبانی برنامه از قبل وجود دارد و نیازی به ایجاد از ابتدا نیست.
از طرف دیگر، مدل‌های پیش‌بینی بار در خود Kubernetes (مانند استقرار، کار و مجموعه‌های Daemon) برای پروژه ما کافی نیستند. این مسائل قابلیت استفاده موانع بزرگی برای حرکت به Kubernetes هستند. به عنوان مثال، ما شنیده‌ایم که توسعه‌دهندگان سرویس از گم شدن یا نادرست بودن تنظیمات ورود شکایت می‌کنند. ما همچنین با استفاده نادرست از موتورهای قالب مواجه شدیم، زمانی که صدها نسخه با مشخصات و کار مشابه ایجاد شد، که منجر به مشکلات اشکال زدایی کابوس شد.
همچنین نگهداری نسخه های مختلف در یک خوشه بسیار دشوار بود. پیچیدگی پشتیبانی مشتری را تصور کنید اگر نیاز به کار همزمان در چندین نسخه از یک محیط زمان اجرا دارید، با تمام مشکلات، باگ ها و به روز رسانی های آنها.
ویژگی ها و کنترلرهای کاربر Pinterest
برای آسان‌تر کردن پیاده‌سازی Kubernetes برای مهندسان ما، و ساده‌سازی و سرعت بخشیدن به زیرساخت‌هایمان، ما تعاریف منابع سفارشی (CRD) خود را توسعه داده‌ایم.
CRD ها عملکرد زیر را ارائه می دهند:
- ترکیب منابع بومی مختلف Kubernetes به طوری که آنها به عنوان یک حجم کاری واحد کار کنند. به عنوان مثال، منبع PinterestService شامل یک استقرار، یک سرویس ورود و یک نقشه پیکربندی است. این به توسعه دهندگان اجازه می دهد تا نگران راه اندازی DNS نباشند.
- اجرای پشتیبانی برنامه های ضروری کاربر باید تنها بر روی مشخصات کانتینر مطابق با منطق تجاری خود تمرکز کند، در حالی که کنترلر CRD تمام کانتینرهای اولیه، متغیرهای محیطی و مشخصات pod را پیاده سازی می کند. این یک سطح اساسی متفاوت از راحتی را برای توسعه دهندگان فراهم می کند.
- کنترل‌کننده‌های CRD همچنین چرخه حیات منابع بومی را مدیریت می‌کنند و در دسترس بودن اشکال‌زدایی را بهبود می‌بخشند. این شامل تطبیق مشخصات دلخواه و واقعی، به‌روزرسانی وضعیت CRD و نگهداری گزارش‌های رویداد و موارد دیگر است. بدون CRD، توسعه‌دهندگان مجبور به مدیریت منابع متعدد خواهند بود که تنها احتمال خطا را افزایش می‌دهد.
در اینجا یک نمونه از PinterestService و یک منبع داخلی است که توسط کنترلر ما مدیریت می شود:
همانطور که در بالا می بینید، برای پشتیبانی از یک کانتینر سفارشی، باید یک کانتینر اولیه و چندین افزونه را برای تامین امنیت، دید و ترافیک شبکه یکپارچه کنیم. علاوه بر این، ما قالب‌های نقشه پیکربندی را ایجاد کردیم و از قالب‌های PVC برای کارهای دسته‌ای، و همچنین ردیابی متغیرهای محیطی متعدد برای ردیابی هویت، مصرف منابع و جمع‌آوری زباله، پشتیبانی کردیم.
تصور اینکه توسعه‌دهندگان بخواهند این فایل‌های پیکربندی را بدون پشتیبانی از CRD بنویسند، سخت است، چه رسد به حفظ و رفع اشکال پیکربندی‌ها.
گردش کار استقرار برنامه
تصویر بالا نحوه استقرار یک منبع سفارشی Pinterest را در یک خوشه Kubernetes نشان می دهد:
- توسعه دهندگان از طریق CLI و رابط کاربری با خوشه Kubernetes ما تعامل دارند.
- ابزارهای CLI/UI فایل‌های YAML پیکربندی گردش کار و سایر ویژگی‌های ساخت (همان شناسه نسخه) را از Artifactory بازیابی می‌کنند و سپس آنها را به سرویس ارسال شغل ارسال می‌کنند. این مرحله تضمین می کند که فقط نسخه های تولیدی به خوشه تحویل داده می شوند.
- JSS یک دروازه برای پلتفرم های مختلف از جمله Kubernetes است. در اینجا کاربر احراز هویت می شود، سهمیه ها صادر می شود و پیکربندی CRD ما تا حدی بررسی می شود.
- پس از بررسی CRD در سمت JSS، اطلاعات به API پلتفرم k8s ارسال می شود.
- کنترلر CRD ما رویدادها را در تمام منابع کاربر نظارت می کند. CRها را به منابع k8s تبدیل می‌کند، ماژول‌های لازم را اضافه می‌کند، متغیرهای محیطی مناسب را تنظیم می‌کند، و سایر کارهای پشتیبانی را انجام می‌دهد تا اطمینان حاصل شود که برنامه‌های کاربر کانتینری از پشتیبانی زیرساختی کافی برخوردار هستند.
- سپس کنترل‌کننده CRD داده‌های دریافتی را به API Kubernetes ارسال می‌کند تا بتوان آنها را توسط زمان‌بند پردازش کرده و در مرحله تولید قرار داد.
یادداشت: این جریان کاری پیش از انتشار از استقرار برای اولین کاربران پلت فرم جدید k8s ایجاد شده است. ما در حال حاضر در حال اصلاح این فرآیند برای ادغام کامل با CI/CD جدید خود هستیم. این بدان معنی است که ما نمی توانیم همه چیز مربوط به Kubernetes را به شما بگوییم. ما مشتاقانه منتظر به اشتراک گذاشتن تجربیات خود و پیشرفت تیم در این جهت در پست بعدی وبلاگ خود، "ساخت پلت فرم CI/CD برای Pinterest هستیم."
انواع منابع خاص
بر اساس نیازهای خاص Pinterest، ما CRD های زیر را متناسب با جریان های کاری مختلف توسعه داده ایم:
- PinterestService سرویس هایی بدون تابعیت هستند که برای مدت طولانی در حال اجرا هستند. بسیاری از سیستم های اصلی ما مبتنی بر مجموعه ای از چنین خدماتی هستند.
- PinterestJobSet کارهای دسته ای کامل را مدل می کند. یک سناریوی رایج در Pinterest این است که چندین کار بدون توجه به سایر فرآیندهای مشابه، کانتینرهای مشابهی را به صورت موازی اجرا می کنند.
- PinterestCronJob به طور گسترده در ارتباط با بارهای دوره ای کوچک استفاده می شود. این یک بسته بندی برای کار cron بومی با مکانیسم های پشتیبانی Pinterest است که مسئول امنیت، ترافیک، گزارش ها و معیارها هستند.
- PinterestDaemon شامل دیمون های زیرساختی است. این خانواده همچنان به رشد خود ادامه می دهد زیرا ما حمایت بیشتری را به خوشه های خود اضافه می کنیم.
- PinterestTrainingJob به فرآیندهای Tensorflow و Pytorch گسترش می یابد و همان سطح پشتیبانی از زمان اجرا را مانند سایر CRD ها ارائه می دهد. از آنجایی که Pinterest به طور فعال از Tensorflow و سایر سیستم‌های یادگیری ماشین استفاده می‌کند، دلیلی داشتیم که یک CRD جداگانه در اطراف آنها بسازیم.
ما همچنین در حال کار بر روی PinterestStatefulSet هستیم که به زودی برای انبارهای داده و سایر سیستم‌های دارای وضعیت تطبیق داده می‌شود.
پشتیبانی از زمان اجرا
هنگامی که یک برنامه کاربردی در Kubernetes اجرا می شود، به طور خودکار یک گواهی برای شناسایی خود دریافت می کند. این گواهی برای دسترسی به فضای ذخیره سازی مخفی یا برقراری ارتباط با سرویس های دیگر از طریق mTLS استفاده می شود. در همین حال، Container Init Configurator و Daemon تمام وابستگی های لازم را قبل از اجرای برنامه کانتینری دانلود می کنند. وقتی همه چیز آماده شد، سایدکار ترافیک و دیمون آدرس IP ماژول را در Zookeeper ما ثبت می کنند تا مشتریان بتوانند آن را کشف کنند. همه اینها کار خواهند کرد زیرا ماژول شبکه قبل از راه اندازی برنامه پیکربندی شده است.
موارد فوق نمونه های معمولی از پشتیبانی زمان اجرا برای بارهای کاری هستند. سایر انواع بارهای کاری ممکن است به پشتیبانی کمی متفاوت نیاز داشته باشند، اما همه آنها به شکل سایدکارهای سطح پاد، دیمون های سطح گره یا ماشین مجازی هستند. ما اطمینان می‌دهیم که همه اینها در زیرساخت مدیریت مستقر شده و در بین برنامه‌ها سازگار است، که در نهایت به طور قابل‌توجهی بار از نظر کار فنی و پشتیبانی مشتری را کاهش می‌دهد.
تست و QA
ما یک خط لوله آزمایشی سرتاسر در بالای زیرساخت آزمایش Kubernetes موجود ساختیم. این تست ها برای همه خوشه های ما اعمال می شود. خط لوله ما قبل از اینکه بخشی از خوشه محصول شود، اصلاحات زیادی را پشت سر گذاشت.
علاوه بر سیستم‌های آزمایش، ما سیستم‌های نظارت و هشدار را داریم که به طور مداوم وضعیت اجزای سیستم، مصرف منابع و سایر شاخص‌های مهم را رصد می‌کنند و تنها در مواقع ضروری به ما اطلاع می‌دهند.
جایگزین، گزینه ها
ما به برخی از جایگزین‌های منابع سفارشی، مانند کنترل‌کننده‌های دسترسی جهش و سیستم‌های الگو نگاه کردیم. با این حال، همه آنها با چالش های عملیاتی قابل توجهی همراه هستند، بنابراین ما مسیر CRD را انتخاب کردیم.
یک کنترل کننده پذیرش جهشی برای معرفی کارگاه های جانبی، متغیرهای محیطی و سایر پشتیبانی های زمان اجرا استفاده شد. با این حال، با مشکلات مختلفی مانند اتصال منابع و مدیریت چرخه حیات مواجه بود که در CRD چنین مشکلاتی وجود ندارد.
توجه: سیستم های قالب مانند نمودار Helm نیز به طور گسترده ای برای اجرای برنامه های کاربردی با پیکربندی های مشابه استفاده می شوند. با این حال، برنامه های کاری ما بسیار متنوع هستند که نمی توان با استفاده از الگوها مدیریت کرد. همچنین در هنگام استقرار مداوم خطاهای زیادی هنگام استفاده از قالب ها وجود خواهد داشت.
کار آینده
ما در حال حاضر با یک بار مختلط در تمام خوشه های خود سروکار داریم. برای پشتیبانی از چنین فرآیندهایی در انواع و اندازه های مختلف، ما در زمینه های زیر کار می کنیم:
- مجموعه‌ای از خوشه‌ها، برنامه‌های کاربردی بزرگی را در میان خوشه‌های مختلف برای مقیاس‌پذیری و پایداری توزیع می‌کنند.
- اطمینان از ثبات خوشه، مقیاس پذیری و دید برای ایجاد اتصال برنامه و SLA.
- مدیریت منابع و سهمیه ها به گونه ای که برنامه ها با یکدیگر تضاد نداشته باشند و مقیاس خوشه از طرف ما کنترل شود.
- یک پلت فرم جدید CI/CD برای پشتیبانی و استقرار برنامه های کاربردی در Kubernetes.
منبع: www.habr.com