🥇ماجراجویی Kubernetes Dailymotion: ایجاد زیرساخت در ابرها + در محل

توجه داشته باشید. ترجمه: Dailymotion یکی از بزرگترین سرویس های میزبانی ویدیو در جهان است و بنابراین یک کاربر قابل توجه Kubernetes است. در این مطلب، معمار سیستم دیوید دانچز، نتایج ایجاد پلتفرم تولید شرکت بر اساس K8s را به اشتراک می‌گذارد، که با نصب ابری در GKE آغاز شد و به عنوان یک راه‌حل ترکیبی پایان یافت، که امکان پاسخگویی بهتر و صرفه‌جویی در هزینه‌های زیرساخت را فراهم کرد.

تصمیم به بازسازی Core API Dailymotion بدون سه سال پیش، ما می‌خواستیم راه کارآمدتری برای میزبانی برنامه‌ها و تسهیل آن ایجاد کنیم فرآیندهای توسعه و تولید. برای این منظور تصمیم گرفتیم از پلتفرم ارکستراسیون کانتینر استفاده کنیم و طبیعتا Kubernetes را انتخاب کردیم.

چرا ارزش ساختن پلتفرم خود بر اساس Kubernetes را دارد؟

API سطح تولید در کمترین زمان با استفاده از Google Cloud

تابستان 2016

سه سال پیش، بلافاصله پس از خرید Dailymotion توسط ویویندی، تیم های مهندسی ما بر روی یک هدف جهانی متمرکز شده اند: ایجاد یک محصول کاملاً جدید Dailymotion.

بر اساس تجزیه و تحلیل ما از کانتینرها، راه حل های ارکستراسیون، و تجربه گذشته ما، ما متقاعد شده ایم که Kubernetes انتخاب درستی است. برخی از توسعه دهندگان قبلاً درک درستی از مفاهیم اولیه داشتند و می دانستند که چگونه از آن استفاده کنند، که یک مزیت بزرگ برای تحول زیرساخت بود.

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

چرا GKE را انتخاب کردید؟

ما این انتخاب را عمدتاً به دلایل فنی انجام دادیم. علاوه بر این، لازم بود به سرعت زیرساخت هایی فراهم شود که نیازهای تجاری شرکت را برآورده کند. ما برای برنامه های میزبانی نیازهایی داشتیم، مانند توزیع جغرافیایی، مقیاس پذیری و تحمل خطا.

خوشه های GKE در Dailymotion

از آنجایی که Dailymotion یک پلتفرم ویدیویی در سراسر جهان است، ما واقعاً می‌خواستیم کیفیت خدمات را با کاهش زمان انتظار بهبود ببخشیم. (تاخیر)... قبلا API ما فقط در پاریس موجود بود که کمتر از حد مطلوب بود. من می خواستم نه تنها در اروپا، بلکه در آسیا و ایالات متحده نیز میزبان برنامه ها باشم.

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

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

نظارت بر تعادل بار گوگل

پلتفرم ما همچنین به شدت از پردازنده‌های گرافیکی استفاده می‌کند. Google Cloud به شما این امکان را می دهد که به طور مستقیم از آنها در خوشه های Kubernetes استفاده کنید.

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

در نتیجه، تنها 6 ماه پس از شروع کار، توانستیم ترافیک تولیدی را در زیرساخت Google Cloud دریافت کنیم.

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

راه اندازی پلت فرم ارکستراسیون کانتینر محلی Dailymotion

پاییز 2016

در شرایطی که کل پشته آماده تولید بود و روی API کار کنید ادامه داد، زمان تمرکز بر روی خوشه های منطقه ای فرا رسیده بود.

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

زیرساخت Dailymotion از بیش از 2,5 هزار سرور در شش مرکز داده تشکیل شده است. همه آنها با استفاده از Saltstack پیکربندی شده اند. ما شروع به تهیه تمام دستور العمل های لازم برای ایجاد گره های استاد و کارگر و همچنین یک خوشه etcd کردیم.

بخش شبکه

شبکه ما کاملاً روت شده است. هر سرور IP خود را در شبکه با استفاده از Exabgp تبلیغ می کند. ما چندین پلاگین شبکه را مقایسه کردیم و تنها پلاگینی که تمام نیازها را برآورده کرد (به دلیل رویکرد L3 مورد استفاده) چلوار. کاملاً با مدل زیرساخت شبکه موجود مطابقت دارد.

از آنجایی که می‌خواستیم از تمام عناصر زیرساخت موجود استفاده کنیم، اولین کاری که باید انجام می‌دادیم این بود که ابزار شبکه خانگی خود را کشف کنیم (که در همه سرورها استفاده می‌شود): از آن برای تبلیغ محدوده آدرس IP در شبکه با گره‌های Kubernetes استفاده کنیم. ما به Calico اجازه دادیم تا آدرس‌های IP را به پادها اختصاص دهد، اما از آن برای جلسات BGP در تجهیزات شبکه استفاده نکرده و هنوز هم استفاده نمی‌کند. در واقع مسیریابی توسط Exabgp انجام می شود که زیرشبکه های مورد استفاده Calico را تبلیغ می کند. این به ما امکان می دهد از شبکه داخلی (و به ویژه از متعادل کننده بار) به هر غلاف دسترسی پیدا کنیم.

چگونه ترافیک ورودی را مدیریت می کنیم

برای تغییر مسیر درخواست های دریافتی به سرویس مورد نظر، تصمیم گرفته شد از Ingress Controller به دلیل ادغام با منابع ورودی Kubernetes استفاده شود.

سه سال پیش، nginx-ingress-controller بالغ‌ترین کنترل‌کننده بود: Nginx برای مدت طولانی وجود داشت و به دلیل پایداری و عملکردش شناخته شده بود.

در سیستم خود تصمیم گرفتیم که کنترلرها را روی سرورهای اختصاصی تیغه 10 گیگابیتی قرار دهیم. هر کنترل کننده به نقطه پایانی kube-apiserver خوشه مربوطه متصل شد. این سرورها همچنین از Exabgp برای تبلیغ آدرس های IP عمومی یا خصوصی استفاده می کردند. توپولوژی شبکه ما به ما این امکان را می دهد که از BGP از این کنترلرها استفاده کنیم تا بدون استفاده از سرویسی مانند NodePort، تمام ترافیک را مستقیماً به پادها هدایت کنیم. این رویکرد به جلوگیری از ترافیک افقی بین گره ها کمک می کند و کارایی را بهبود می بخشد.

حرکت ترافیک از اینترنت به پادها

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

انتقال ترافیک از Google Cloud به زیرساخت Dailymotion

پاییز 2018

پس از نزدیک به دو سال ساخت، آزمایش و تنظیم، بالاخره یک پشته کامل Kubernetes آماده پذیرش مقداری ترافیک داریم.

استراتژی مسیریابی فعلی بسیار ساده است، اما برای رفع نیازها کافی است. علاوه بر IP های عمومی (در Google Cloud و Dailymotion)، AWS Route 53 برای تنظیم خط مشی ها و هدایت کاربران به خوشه مورد نظر ما استفاده می شود.

نمونه سیاست مسیریابی با استفاده از مسیر 53

با Google Cloud این کار آسان است زیرا ما یک IP واحد را در همه خوشه ها به اشتراک می گذاریم و کاربر به نزدیک ترین خوشه GKE هدایت می شود. برای خوشه‌های ما، فناوری متفاوت است، زیرا IP آنها متفاوت است.

در طول مهاجرت، ما به دنبال هدایت درخواست‌های منطقه‌ای به خوشه‌های مناسب بودیم و مزایای این رویکرد را ارزیابی کردیم.

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

در حالت عادی، تمام ترافیک منطقه ای به خوشه محلی هدایت می شود و GKE در صورت بروز مشکل به عنوان یک ذخیره عمل می کند (بررسی سلامت توسط مسیر 53 انجام می شود).

...

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

PS از مترجم

همچنین ممکن است به یکی دیگر از پست های اخیر Dailymotion در مورد Kubernetes علاقه مند باشید. این به استقرار برنامه های کاربردی با Helm در بسیاری از خوشه های Kubernetes و منتشر شد حدود یک ماه پیش

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

منبع: www.habr.com

Kubernetes Adventure Dailymotion: ایجاد زیرساخت در ابرها + در محل