سفر چند خوشه ای K8S

هی هابر!

ما نماینده تیم پلتفرم Exness هستیم. قبلاً همکاران ما قبلاً مقاله ای در مورد آن نوشته بودند تصاویر آماده تولید برای k8s. امروز می خواهیم تجربه خود را از مهاجرت خدمات به Kubernetes به اشتراک بگذاریم.

برای شروع، ما تعدادی اعداد را برای درک بهتر آنچه در مورد آن بحث خواهد شد به شما پیشنهاد می کنیم:

• بخش توسعه ما متشکل از 100+ نفر، شامل بیش از 10 تیم مختلف با فرآیندهای QA، DevOps و Scrum خودکفا است. پشته توسعه - Python، PHP، C++، Java و Golang. 
• اندازه محیط های آزمایش و تولید هر کدام حدود 2000 کانتینر می باشد. آنها Rancher v1.6 را روی مجازی سازی خودشان و تحت VMware اجرا می کنند. 

انگیزه

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

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

ما می خواستیم استانداردهای IaC را دنبال کنیم و در صورت لزوم، ظرفیت را در هر موقعیت جغرافیایی و بدون قفل فروشنده به سرعت بدست آوریم و همچنین بتوانیم به سرعت آن را رها کنیم.

گام های نخست

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

بعد، سوال انتخاب ابزاری برای ایجاد خوشه مطرح شد. ما محبوب ترین راه حل ها را مقایسه کردیم: kops، kubespray، kubeadm.

برای شروع، kubeadm به نظر ما مسیری بسیار پیچیده بود، بیشتر شبیه به نوعی مخترع یک ​​«دوچرخه» بود، و کپس از انعطاف کافی برخوردار نبود.

و برنده این شد:

ما شروع به آزمایش با مجازی‌سازی و AWS خود کردیم و سعی کردیم چیزی تقریباً شبیه به الگوی مدیریت منابع قبلی‌مان را بازسازی کنیم، جایی که همه یک "خوشه" مشترک داشتند. و اکنون ما اولین خوشه خود را از 10 ماشین مجازی کوچک داریم که چند تای آنها در AWS قرار دارند. ما شروع به تلاش برای مهاجرت تیم ها به آنجا کردیم، به نظر می رسید همه چیز "خوب" است و داستان می تواند تمام شود، اما ...

مشکلات اول

Ansible چیزی است که Kubespray بر روی آن ساخته شده است، این ابزاری نیست که به شما امکان می دهد IaC را دنبال کنید: هنگام راه اندازی/از کار انداختن گره ها، مشکلی به طور مداوم پیش می رفت و به نوعی مداخله نیاز بود، و هنگام استفاده از سیستم عامل های مختلف، کتاب بازی به طور متفاوتی رفتار می کرد. . با افزایش تعداد تیم‌ها و گره‌ها در خوشه، متوجه شدیم که کتاب بازی بیشتر و بیشتر طول می‌کشد تا تکمیل شود و در نتیجه رکورد ما 3,5 ساعت بود، در مورد شما چطور؟ 🙂

و به نظر می رسد که Kubespray فقط Ansible است، و همه چیز در نگاه اول واضح است، اما:

در ابتدای سفر، وظیفه راه اندازی ظرفیت ها فقط در AWS و مجازی سازی بود، اما پس از آن، همانطور که اغلب اتفاق می افتد، نیازها تغییر کردند.
 


با توجه به این موضوع، مشخص شد که الگوی قدیمی ما از ترکیب منابع در یک سیستم ارکستراسیون مناسب نیست - در موردی که خوشه ها بسیار دور هستند و توسط ارائه دهندگان مختلف مدیریت می شوند. 

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

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

چه کاری انجام دهید؟

با در نظر گرفتن موارد فوق و تمایل تیم ها به استقلال بیشتر، ما به یک نتیجه گیری ساده رسیدیم: یک تیم - یک خوشه. 

بنابراین ما مورد دوم را دریافت کردیم:

و سپس خوشه سوم: 

بعد شروع کردیم به فکر کردن: فرض کنید در یک سال تیم های ما بیش از یک خوشه خواهند داشت؟ مثلاً در مناطق جغرافیایی مختلف یا تحت کنترل ارائه دهندگان مختلف؟ و برخی از آنها می خواهند بتوانند به سرعت یک خوشه موقت را برای برخی آزمایشات مستقر کنند. 

Kubernetes کامل می آمد! به نظر می رسد این نوعی MultiKubernetes است. 

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

مدتی از آغاز سفر ما در دنیای Kubernetes می گذرد و تصمیم گرفتیم راه حل های موجود را دوباره بررسی کنیم. معلوم شد که در حال حاضر در بازار وجود دارد - Rancher 2.2.

در مرحله اول تحقیقات ما، Rancher Labs قبلاً اولین نسخه نسخه 2 را منتشر کرده بود، اما اگرچه می‌توان آن را با راه‌اندازی یک کانتینر بدون وابستگی خارجی با چند پارامتر یا با استفاده از نمودار رسمی HELM خیلی سریع افزایش داد، اما خام به نظر می‌رسید. برای ما، و ما نمی‌دانستیم که آیا می‌توانیم به این تصمیم اعتماد کنیم که آیا توسعه می‌یابد یا به سرعت کنار گذاشته می‌شود. پارادایم خوشه = کلیک در خود رابط کاربری نیز برای ما مناسب نبود، و ما نمی‌خواستیم به RKE وابسته شویم، زیرا ابزاری با تمرکز نسبتاً محدود است. 

نسخه Rancher 2.2 قبلاً ظاهری کاربردی تری داشت و همراه با نسخه های قبلی دارای یکسری ویژگی های جالب بود، مانند ادغام با بسیاری از ارائه دهندگان خارجی، یک نقطه توزیع حقوق و فایل های kubeconfig، راه اندازی یک kubectl. تصویر با حقوق شما در UI، فضاهای نام تودرتو که پروژه‌ها نامیده می‌شوند. 

همچنین یک انجمن از قبل در اطراف Rancher 2 تشکیل شده بود، و ارائه دهنده ای به نام HashiCorp Terraform برای مدیریت آن ایجاد شد که به ما کمک کرد همه چیز را کنار هم بگذاریم.

چی شد

در نتیجه، ما به یک خوشه کوچک در حال اجرا Rancher رسیدیم که برای همه خوشه‌های دیگر قابل دسترسی است، و همچنین بسیاری از خوشه‌های متصل به آن، دسترسی به هر یک از آنها را می‌توان به سادگی اضافه کردن یک کاربر به فهرست ldap، بدون توجه به در کجا قرار دارد و از منابع کدام ارائه دهنده استفاده می کند.

با استفاده از gitlab-ci و Terraform، سیستمی ایجاد شد که به شما این امکان را می‌دهد تا خوشه‌ای از هر پیکربندی را در ارائه‌دهندگان ابری یا زیرساخت‌های خودمان ایجاد کنید و آنها را به Rancher متصل کنید. همه اینها در سبک IaC انجام می شود، جایی که هر خوشه توسط یک مخزن توصیف می شود و وضعیت آن نسخه می شود. در همان زمان، اکثر ماژول ها از مخازن خارجی متصل می شوند، به طوری که تنها چیزی که باقی می ماند انتقال متغیرها یا توصیف پیکربندی سفارشی شما برای نمونه است، که به کاهش درصد تکرار کد کمک می کند.

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

این مقاله توسط A. Antipov، A. Ganush، مهندسین پلتفرم نوشته شده است. 

منبع: www.habr.com