استفاده از کنترل‌کننده‌های پذیرش جهش‌دهنده برای تسهیل مهاجرت‌های Kubernetes

محیط صحنه‌سازی قدیمی سفیر تنها مجموعه‌ای از فضاهای نام در همان خوشه محیط تولید ما بود. استفاده از فضاهای نام برای جداسازی محیط ها ایده آل نیست زیرا تغییرات در مرحله بندی می تواند بر تولید تأثیر بگذارد. استفاده از فضاهای نام برای جداسازی محیط ها ایده آل نیست زیرا تغییرات در مرحله بندی می تواند بر تولید تأثیر بگذارد.

برای مثال، به‌روزرسانی منابع خوشه‌ای مانند Edge Stack CRD می‌تواند بر کل خوشه تأثیر بگذارد. همچنین ما را مجبور کرد به‌دلیل خطر شکست تولید و از دست دادن مزایای کلیدی GitOps، به‌جای استفاده از رویکرد تحویل مداوم به سبک GitOps، برخی تغییرات مرحله‌بندی را به صورت دستی اعمال کنیم. مهاجرت برنامه ها به یک محیط جدید به دلیل تفاوت بین وابستگی های خارجی، محدودیت های سخت افزاری و غیره می تواند چالش برانگیز باشد.

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

رویکرد ما به GitOps

قبل از اینکه توضیح دهم چگونه با مهاجرت مقابله کردیم، بیایید در مورد نحوه انجام GitOps صحبت کنیم.

در Ambassador، همه مانیفست‌های مستقر در یک خوشه Kubernetes در یک مخزن Git ذخیره می‌شوند. این مخزن توسط ArgoCD نظارت می شود و زمانی که نسخه جدیدی از مانیفست وجود داشته باشد، ArgoCD آن را مستقر می کند.

معمولاً دو نوع برنامه در کلاستر ما وجود دارد:

برنامه‌هایی مانند Grafana و Prometheus که از آنها استفاده می‌کنیم، اما مالک آن‌ها نیستیم. مانیفست های این برنامه ها در مخزن مانیفست نگهداری می شوند.

برنامه های متعلق به ما، مانند Edge Stack، Telepresence و Blackbird. کد منبع و مانیفست های این برنامه ها در مخزن خودشان نگهداری می شوند. هنگامی که یک تغییر ایجاد می شود، یک کار آخرین نسخه مانیفست خود را به مخزن ArgoCD منتقل می کند.
ArgoCD

کنترل کننده های پذیرش Kubernetes برای نجات!

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

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

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

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

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

با کاربران همدلی کنید
آخرین نیاز یک الزام فنی نیست بلکه “مردم” است. هدف ما همیشه همدلی با کاربران است، بنابراین راه حلی می خواستیم که نه تنها اهداف فنی را برآورده کند، بلکه مشکل را با دلسوزی برای توسعه دهندگان ما حل کند.

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

این به ما مزایای زیر را داد:

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

اگر محیط جدید مشکلاتی داشت، امکان بازگشت به محیط قبلی با کمترین تلاش وجود داشت

چگونه کار می کند؟

Kubernetes دارای یک کنترل‌کننده پذیرش MutatingAdmissionWebhook است که مکانیزمی برای پیکربندی وبک‌هوک‌ها فراهم می‌کند که می‌تواند درخواست‌های سرور API Kubernetes را تغییر دهد (ووب هوک‌ها را تغییر دهد) یا رد کند (اعتبار‌سنجی وب‌قلاب‌ها). به طور معمول، این وبکهک ها برای اجرای اقدامات امنیتی، حصول اطمینان از پیروی منابع از سیاست های خاص، یا مدیریت پیکربندی (مثلاً پیکربندی محدودیت های منابع) استفاده می شوند.

ما یک وب هوک جهش یافته به نام patcher ایجاد کردیم که هر درخواستی را برای ایجاد یا تغییر منابع خاص (مانند ConfigMaps و Deployments) رهگیری می کند و در صورت لزوم مانیفست را تغییر می دهد. در اینجا برخی از به روز رسانی هایی است که پچر مدیریت می کند:

راه اندازی اعتبارنامه های رجیستری Docker: وصله کننده آن را تنظیم می کند

imagePullSecret

فیلد موجود در ServiceAccount که توسط یک پاد استفاده می‌شود، به پاد امکان می‌دهد تصاویر را از یک رجیستری Docker خصوصی دریافت کند.

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

برای انجام این کار، پچر درخواست Webhook را بررسی می کند. اگر حاوی یک شی است که باید اصلاح شود، یک پاسخ با یک وصله JSON نشان دهنده تغییرات برای اعمال می شود.

مسدود کردن ایجاد اشیایی که در محیط جدید منسوخ شده یا ناخواسته هستند: این کار با تنظیم کلید مجاز پاسخ webhook روی false انجام می شود.

اکنون که نحوه عملکرد پچر را توضیح دادم، بیایید به روند راه اندازی یک خوشه جدید نگاه کنیم:

پچر را نصب کنید و آن را طوری پیکربندی کنید که برنامه های فقط تولید را مسدود کند.

ArgoCD را برای خوشه جدید پیکربندی کنید و همه برنامه ها را به گونه ای اجرا کنید که در حالت “غیرفعال” شروع شوند. به عنوان مثال، اسرار برای اتصال به یک DB وجود ندارد.

برای هر برنامه:

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

ملاحظات دیگری را مطرح کردیم!

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

در دسترس بودن خوشه

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

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

محدوده اشیاء اصلاح شده توسط webhook را محدود کنید. در حالی که می‌توانید یک وب‌هوک را برای پذیرش درخواست‌ها برای همه اشیاء پیکربندی کنید، این کار توصیه نمی‌شود زیرا هر گونه مشکلی در وب‌هوک می‌تواند به شدت بر خوشه تأثیر بگذارد. یک رویکرد بهتر محدود کردن اشیایی است که وب‌هوک اصلاح می‌کند.

پایدار در مقابل حالت زنده

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

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