Kubernetes یک ابزار عالی برای اجرای کانتینرهای Docker در یک محیط تولید خوشه‌ای است. با این حال، مشکلاتی وجود دارد که Kubernetes نمی تواند آنها را حل کند. برای استقرار مکرر تولید، ما به یک استقرار کاملاً خودکار آبی/سبز برای جلوگیری از خرابی در فرآیند نیاز داریم، که همچنین نیاز به رسیدگی به درخواست‌های HTTP خارجی و انجام تخلیه SSL دارد. این نیاز به ادغام با یک متعادل کننده بار مانند ha-proxy دارد. چالش دیگر، مقیاس بندی نیمه خودکار خود خوشه Kubernetes هنگام اجرا در یک محیط ابری است، برای مثال کوچک کردن جزئی خوشه در شب.
اگرچه Kubernetes این ویژگی‌ها را ندارد، اما یک API ارائه می‌کند که می‌توانید برای حل مشکلات مشابه از آن استفاده کنید. ابزارهایی برای استقرار خودکار آبی/سبز و مقیاس بندی یک خوشه Kubernetes به عنوان بخشی از پروژه Cloud RTI، که بر اساس منبع باز ایجاد شده است، توسعه داده شد.
این مقاله، یک رونوشت ویدیویی، به شما نشان می‌دهد که چگونه Kubernetes را به همراه سایر اجزای منبع باز راه‌اندازی کنید تا یک محیط آماده برای تولید ایجاد کنید که کد را از یک git commit بدون توقف در تولید بپذیرد.
بنابراین، هنگامی که از دنیای خارج به برنامه های خود دسترسی پیدا کردید، می توانید شروع به راه اندازی کامل اتوماسیون کنید، یعنی آن را به مرحله ای برسانید که بتوانید یک git commit را انجام دهید و مطمئن شوید که این git commit به تولید ختم می شود. طبیعتاً هنگام اجرای این مراحل، هنگام اجرای استقرار، نمی خواهیم با خرابی مواجه شویم. بنابراین، هر اتوماسیون در Kubernetes با API شروع می شود.
Kubernetes ابزاری نیست که بتوان از جعبه آن به طور سازنده استفاده کرد. البته، شما می توانید این کار را انجام دهید، از kubectl و غیره استفاده کنید، اما همچنان API جالب ترین و مفیدترین چیز در مورد این پلتفرم است. با استفاده از API به عنوان مجموعه ای از توابع، می توانید تقریباً به هر کاری که می خواهید در Kubernetes انجام دهید دسترسی داشته باشید. خود kubectl نیز از REST API استفاده می کند.
این REST است، بنابراین می توانید از هر زبان یا ابزاری برای کار با این API استفاده کنید، اما زندگی شما با کتابخانه های سفارشی بسیار آسان تر خواهد شد. تیم من 2 کتابخانه از این قبیل نوشت: یکی برای Java/OSGi و دیگری برای Go. دومی اغلب استفاده نمی شود، اما در هر صورت شما این موارد مفید را در اختیار دارید. آنها یک پروژه متن باز با مجوز جزئی هستند. بسیاری از این کتابخانه ها برای زبان های مختلف وجود دارد، بنابراین شما می توانید آن هایی را انتخاب کنید که مناسب شما هستند.
بنابراین، قبل از شروع خودکارسازی استقرار خود، باید مطمئن شوید که این فرآیند در معرض هیچ گونه خرابی نخواهد بود. به عنوان مثال، تیم ما در اواسط روز، زمانی که مردم از برنامه‌ها بیشترین استفاده را می‌کنند، استقرار تولید را انجام می‌دهند، بنابراین مهم است که از تاخیر در این فرآیند جلوگیری شود. به منظور جلوگیری از خرابی، 2 روش استفاده می شود: استقرار آبی/سبز یا به روز رسانی چرخشی. در مورد دوم، اگر 5 نسخه از برنامه در حال اجرا دارید، آنها به طور متوالی یکی پس از دیگری به روز می شوند. این روش عالی کار می‌کند، اما اگر نسخه‌های مختلف برنامه به طور همزمان در طول فرآیند استقرار اجرا می‌شوند، مناسب نیست. در این حالت، می توانید رابط کاربری را در حالی که بک اند نسخه قدیمی را اجرا می کند، به روز کنید و برنامه از کار می افتد. بنابراین، از نقطه نظر برنامه نویسی، کار در چنین شرایطی بسیار دشوار است.
این یکی از دلایلی است که ما ترجیح می دهیم از استقرار آبی/سبز برای خودکارسازی استقرار برنامه هایمان استفاده کنیم. با این روش باید اطمینان حاصل کنید که در هر زمان تنها یک نسخه از برنامه فعال است.
مکانیسم استقرار آبی/سبز به این شکل است. ما ترافیک برنامه‌های خود را از طریق ha-proxy دریافت می‌کنیم، که آن را به نسخه‌های در حال اجرا برنامه همان نسخه ارسال می‌کند.
هنگامی که یک استقرار جدید ساخته می شود، از Deployer استفاده می کنیم که اجزای جدید به آن داده می شود و نسخه جدید را مستقر می کند. استقرار یک نسخه جدید از یک برنامه به این معنی است که مجموعه جدیدی از کپی‌ها «برآورده می‌شوند»، پس از آن این نسخه‌های کپی از نسخه جدید در یک پاد جداگانه و جدید راه‌اندازی می‌شوند. با این حال، ha-proxy چیزی در مورد آنها نمی داند و هنوز هیچ حجم کاری را به آنها منتقل نمی کند.
بنابراین، قبل از هر چیز، لازم است بررسی عملکرد نسخه های جدید بررسی سلامت انجام شود تا از آماده بودن ماکت ها برای سرویس بار اطمینان حاصل شود.
همه اجزای استقرار باید از نوعی بررسی سلامت پشتیبانی کنند. این می تواند یک بررسی تماس HTTP بسیار ساده باشد، زمانی که کدی با وضعیت 200 دریافت می کنید، یا یک بررسی عمیق تر، که در آن اتصال کپی ها را با پایگاه داده و سایر خدمات، پایداری اتصالات محیط پویا بررسی می کنید. و اینکه آیا همه چیز درست شروع و کار می کند یا خیر. این فرآیند می تواند بسیار پیچیده باشد.
پس از اینکه سیستم تأیید کرد که همه نسخه‌های به‌روزرسانی شده کار می‌کنند، Deployer پیکربندی را به‌روزرسانی می‌کند و confd صحیح را ارسال می‌کند، که ha-proxy را دوباره پیکربندی می‌کند.
فقط پس از این، ترافیک با کپی‌های نسخه جدید به پاد هدایت می‌شود و پاد قدیمی ناپدید می‌شود.
این مکانیسم از ویژگی های Kubernetes نیست. مفهوم استقرار آبی/سبز برای مدت طولانی وجود داشته است و همیشه از متعادل کننده بار استفاده می کرده است. ابتدا تمام ترافیک را به نسخه قدیمی اپلیکیشن هدایت می کنید و پس از آپدیت آن را به طور کامل به نسخه جدید منتقل می کنید. این اصل نه تنها در Kubernetes استفاده می شود.
اکنون شما را با یک جزء استقرار جدید آشنا می کنم - Deployer که بررسی های سلامتی را انجام می دهد، پراکسی ها را مجدداً پیکربندی می کند و غیره. این مفهومی است که برای دنیای خارج صدق نمی کند و در داخل Kubernetes وجود دارد. من به شما نشان خواهم داد که چگونه می توانید مفهوم Deployer خود را با استفاده از ابزارهای منبع باز ایجاد کنید.
بنابراین، اولین کاری که Deployer انجام می دهد این است که با استفاده از Kubernetes API یک کنترلر تکرار RC ایجاد می کند. این API پادها و سرویس هایی را برای استقرار بیشتر ایجاد می کند، یعنی یک کلاستر کاملاً جدید برای برنامه های ما ایجاد می کند. به محض اینکه RC متقاعد شد که نسخه‌ها شروع به کار کرده‌اند، بررسی سلامت عملکرد آنها را انجام می‌دهد. برای انجام این کار، Deployer از دستور GET /health استفاده می کند. اجزای اسکن مناسب را اجرا می کند و تمام عناصری را که از عملکرد خوشه پشتیبانی می کنند بررسی می کند.
پس از اینکه همه پادها سلامت خود را گزارش کردند، Deployer یک عنصر پیکربندی جدید ایجاد می‌کند - فضای ذخیره‌سازی توزیع‌شده etcd، که به صورت داخلی توسط Kubernetes استفاده می‌شود، از جمله ذخیره‌سازی پیکربندی متعادل‌کننده بار. ما داده ها را در etcd می نویسیم و یک ابزار کوچک به نام confd monitor etcd را برای داده های جدید.
اگر هر تغییری را در پیکربندی اولیه تشخیص دهد، یک فایل تنظیمات جدید ایجاد می کند و آن را به ha-proxy منتقل می کند. در این مورد، ha-proxy بدون از دست دادن هیچ گونه اتصالی راه‌اندازی مجدد می‌شود و بار را به سرویس‌های جدیدی هدایت می‌کند که نسخه جدید برنامه‌های ما را قادر به کار می‌کند.
همانطور که می بینید، با وجود فراوانی اجزا، هیچ چیز پیچیده ای در اینجا وجود ندارد. فقط باید به API و etcd توجه بیشتری داشته باشید. من می خواهم در مورد توسعه دهنده منبع باز که خود ما از آن استفاده می کنیم - Amdatu Kubernetes Deployer به شما بگویم.
این ابزاری برای هماهنگی استقرار Kubernetes است و دارای ویژگی های زیر است:
- استقرار آبی/سبز؛
- راه اندازی یک متعادل کننده بار خارجی؛
- مدیریت توصیفگر استقرار؛
- مدیریت استقرار واقعی؛
- بررسی عملکرد چک های سلامت در حین استقرار؛
- پیاده سازی متغیرهای محیطی در غلاف
این Deployer بر روی Kubernetes API ساخته شده است و یک REST API برای مدیریت دسته‌ها و استقرارها و همچنین یک Websocket API برای استریم گزارش‌ها در طول فرآیند استقرار ارائه می‌کند.
این داده‌های پیکربندی متعادل‌کننده بار را در etcd قرار می‌دهد، بنابراین شما مجبور نیستید از ha-proxy با پشتیبانی خارج از جعبه استفاده کنید، اما به راحتی از فایل پیکربندی load balancer خود استفاده کنید. Amdatu Deployer در Go نوشته شده است، مانند خود Kubernetes، و دارای مجوز Apache است.
قبل از اینکه شروع به استفاده از این نسخه از Deployer کنم، از Deployment Descriptor زیر استفاده کردم که پارامترهای مورد نیاز من را مشخص می کند.
یکی از پارامترهای مهم این کد، فعال کردن پرچم “useHealthCheck” است. باید مشخص کنیم که در طول فرآیند استقرار باید یک بررسی سلامت انجام شود. هنگامی که استقرار از کانتینرهای شخص ثالثی استفاده می کند که نیازی به تأیید ندارند، این تنظیم را می توان غیرفعال کرد. این توصیفگر همچنین تعداد Replica ها و URL frontend مورد نیاز ha-proxy را نشان می دهد. در پایان پرچم مشخصات pod "podspec" قرار دارد که Kubernetes را برای اطلاعات در مورد پیکربندی پورت، تصویر و غیره فراخوانی می کند. این یک توصیفگر JSON نسبتاً ساده است.
ابزار دیگری که بخشی از پروژه منبع باز Amdatu است Deploymentctl است. دارای یک رابط کاربری برای پیکربندی استقرارها، ذخیره تاریخچه استقرار، و حاوی وبک‌قلک‌هایی برای تماس‌های کاربران و توسعه‌دهندگان شخص ثالث است. ممکن است از UI استفاده نکنید زیرا Amdatu Deployer خود یک REST API است، اما این رابط می‌تواند بدون درگیر کردن هیچ API، استقرار را برای شما بسیار آسان‌تر کند. Deploymentctl در OSGi/Vertx با استفاده از Angular 2 نوشته شده است.
من اکنون موارد فوق را با استفاده از یک ضبط از پیش ضبط شده روی صفحه نمایش می دهم تا نیازی به صبر نداشته باشید. ما یک برنامه ساده Go را مستقر خواهیم کرد. اگر قبلاً Go را امتحان نکرده اید نگران نباشید، این یک برنامه بسیار ساده است، بنابراین باید بتوانید آن را کشف کنید.
در اینجا ما در حال ایجاد یک سرور HTTP هستیم که فقط به /health پاسخ می‌دهد، بنابراین این برنامه فقط بررسی سلامت را آزمایش می‌کند و نه چیز دیگری. اگر چک تایید شود، از ساختار JSON نشان داده شده در زیر استفاده می شود. این شامل نسخه برنامه است که توسط Deployer مستقر می شود، پیامی که در بالای فایل مشاهده می کنید و نوع داده بولین - اینکه آیا برنامه ما کار می کند یا خیر.
من با خط آخر کمی تقلب کردم، زیرا یک مقدار بولی ثابت در بالای فایل قرار دادم، که در آینده به من کمک می کند حتی یک برنامه "ناسالم" را اجرا کنم. بعدا به این موضوع می پردازیم.
پس بیایید شروع کنیم. ابتدا، وجود هر پاد در حال اجرا را با استفاده از دستور ~ kubectl get pods بررسی می‌کنیم و بر اساس عدم پاسخگویی از URL frontend، مطمئن می‌شویم که در حال حاضر هیچ استقراری انجام نشده است.
بعد در صفحه، رابط Deploymentctl را می بینید که ذکر کردم، که در آن پارامترهای استقرار تنظیم می شوند: فضای نام، نام برنامه، نسخه استقرار، تعداد نسخه های تکراری، URL جلویی، نام کانتینر، تصویر، محدودیت های منابع، شماره پورت برای بررسی سلامت، و غیره محدودیت منابع بسیار مهم است، زیرا به شما امکان می دهد از حداکثر مقدار ممکن از سخت افزار استفاده کنید. در اینجا می توانید گزارش استقرار را نیز مشاهده کنید.
اگر اکنون دستور ~ kubectl get pods را تکرار کنید، می‌بینید که سیستم به مدت 20 ثانیه "یخ می‌زند" و در طی آن ha-proxy دوباره پیکربندی می‌شود. پس از این، پاد شروع می شود و ماکت ما را می توان در گزارش استقرار مشاهده کرد.
من انتظار 20 ثانیه ای را از ویدیو قطع کردم و اکنون می توانید روی صفحه مشاهده کنید که نسخه اول برنامه مستقر شده است. همه این کارها فقط با استفاده از UI انجام شد.
حالا بیایید نسخه دوم را امتحان کنیم. برای انجام این کار، پیام برنامه را از "Hello, Kubernetes!" در "Hello, Deployer!"، سیستم این تصویر را ایجاد می کند و آن را در رجیستری Docker قرار می دهد، پس از آن به سادگی دوباره روی دکمه "Deploy" در پنجره Deploymentctl کلیک می کنیم. در این حالت، گزارش استقرار به طور خودکار به همان روشی که هنگام استقرار اولین نسخه برنامه اتفاق افتاد راه اندازی می شود.
دستور ~ kubectl get pods نشان می‌دهد که در حال حاضر 2 نسخه از برنامه در حال اجراست، اما قسمت ظاهری نشان می‌دهد که ما هنوز نسخه 1 را اجرا می‌کنیم.
متعادل کننده بار قبل از هدایت ترافیک به نسخه جدید منتظر می ماند تا بررسی سلامت کامل شود. بعد از 20 ثانیه به حالت curl می رویم و می بینیم که اکنون نسخه 2 برنامه را در اختیار داریم و اولین آن حذف شده است.
این استقرار یک برنامه "سالم" بود. بیایید ببینیم اگر برای یک نسخه جدید از برنامه، پارامتر Healthy را از true به false تغییر دهم، یعنی سعی کنم یک برنامه ناسالم را که در بررسی سلامت ناموفق بوده است، مستقر کنم، چه اتفاقی می افتد. این می تواند اتفاق بیفتد اگر برخی از خطاهای پیکربندی در برنامه در مرحله توسعه ایجاد شده باشد و به این شکل به تولید ارسال شود.
همانطور که می بینید، استقرار تمام مراحل بالا را طی می کند و ~kubectl get pods نشان می دهد که هر دو پاد در حال اجرا هستند. اما برخلاف استقرار قبلی، گزارش وضعیت وقفه را نشان می دهد. یعنی به دلیل عدم موفقیت بررسی سلامت، نسخه جدید برنامه قابل استقرار نیست. در نتیجه، مشاهده می کنید که سیستم به استفاده از نسخه قدیمی برنامه بازگشته است و نسخه جدید به سادگی حذف شده است.
خوبی این موضوع این است که حتی اگر تعداد زیادی درخواست همزمان به برنامه وارد شود، آنها حتی در هنگام اجرای رویه استقرار متوجه خرابی آن نمی شوند. اگر این برنامه را با استفاده از فریم ورک Gatling آزمایش کنید، که تا حد امکان درخواست ها را برای آن ارسال می کند، هیچ یک از این درخواست ها حذف نمی شوند. این بدان معناست که کاربران ما حتی به‌روزرسانی‌های نسخه را در زمان واقعی متوجه نمی‌شوند. در صورت عدم موفقیت، کار بر روی نسخه قدیمی ادامه می یابد؛ در صورت موفقیت آمیز بودن، کاربران به نسخه جدید سوئیچ می کنند.
تنها یک چیز وجود دارد که می تواند شکست بخورد - اگر بررسی سلامت موفقیت آمیز باشد، اما برنامه به محض اینکه بار کاری روی آن اعمال شود شکست می خورد، یعنی سقوط تنها پس از تکمیل استقرار رخ می دهد. در این صورت باید به صورت دستی به نسخه قبلی برگردید. بنابراین، نحوه استفاده از Kubernetes را با ابزارهای منبع باز طراحی شده برای آن بررسی کردیم. اگر این ابزارها را در خطوط لوله Build/Deploy خود بسازید، فرآیند استقرار بسیار آسان تر خواهد بود. در همان زمان، برای شروع استقرار، می توانید از رابط کاربری استفاده کنید یا با استفاده از مثلاً commit to master، این فرآیند را کاملاً خودکار کنید.
Build Server ما یک تصویر Docker ایجاد می کند، آن را به Docker Hub یا هر رجیستری که استفاده می کنید فشار می دهد. Docker Hub از webhook پشتیبانی می‌کند، بنابراین می‌توانیم راه‌اندازی از راه دور را از طریق Deployer به روشی که در بالا نشان داده شده است، راه‌اندازی کنیم. به این ترتیب می توانید به طور کامل استقرار برنامه خود را برای تولید بالقوه خودکار کنید.
بیایید به موضوع بعدی برویم - مقیاس بندی خوشه Kubernetes. توجه داشته باشید که دستور kubectl یک دستور مقیاس پذیر است. با کمک بیشتر، به راحتی می توانیم تعداد کپی ها را در خوشه موجود خود افزایش دهیم. با این حال، در عمل، ما معمولاً می خواهیم تعداد گره ها را به جای پادها افزایش دهیم.
در عین حال، در طول ساعات کاری ممکن است نیاز به افزایش داشته باشید و در شب، برای کاهش هزینه خدمات آمازون، ممکن است نیاز به کاهش تعداد نمونه برنامه های در حال اجرا داشته باشید. این به این معنی نیست که مقیاس کردن فقط تعداد پادها کافی است، زیرا حتی اگر یکی از گره ها بیکار باشد، باز هم باید برای آن به آمازون پول پرداخت کنید. یعنی در کنار جرم گیری غلاف ها، باید تعداد ماشین های مورد استفاده را نیز مقیاس بندی کنید.
این می تواند چالش برانگیز باشد زیرا چه از آمازون استفاده کنیم یا از سرویس ابری دیگری، Kubernetes چیزی در مورد تعداد ماشین های مورد استفاده نمی داند. فاقد ابزاری است که به شما امکان می دهد سیستم را در سطح گره مقیاس کنید.
بنابراین ما باید از هر دو گره و غلاف مراقبت کنیم. ما به راحتی می‌توانیم راه‌اندازی گره‌های جدید را با استفاده از ماشین‌های AWS API و Scaling مقیاس کنیم تا تعداد گره‌های کارگر Kubernetes را پیکربندی کنیم. همچنین می توانید از cloud-init یا یک اسکریپت مشابه برای ثبت گره ها در خوشه Kubernetes استفاده کنید.
ماشین جدید در گروه Scaling راه اندازی می شود، خود را به عنوان یک گره راه اندازی می کند، در رجیستری اصلی ثبت می شود و شروع به کار می کند. پس از این، می توانید تعداد کپی ها را برای استفاده در گره های حاصل افزایش دهید. کاهش مقیاس نیاز به تلاش بیشتری دارد، زیرا باید مطمئن شوید که چنین مرحله ای پس از خاموش کردن ماشین های "غیر ضروری" منجر به از بین رفتن برنامه های در حال اجرا نمی شود. برای جلوگیری از چنین سناریویی، باید گره ها را در وضعیت "غیرقابل برنامه ریزی" قرار دهید. این بدان معناست که زمانبندی پیش‌فرض این گره‌ها را هنگام برنامه‌ریزی پادهای DaemonSet نادیده می‌گیرد. زمان‌بند هیچ چیزی را از این سرورها حذف نمی‌کند، اما کانتینر جدیدی را نیز در آنجا راه‌اندازی نمی‌کند. مرحله بعدی خارج کردن گره تخلیه است، یعنی انتقال غلاف های در حال اجرا از آن به دستگاه دیگری یا گره های دیگری که ظرفیت کافی برای این کار دارند. هنگامی که مطمئن شدید که دیگر هیچ کانتینری در این گره ها وجود ندارد، می توانید آنها را از Kubernetes حذف کنید. پس از این، آنها به سادگی برای Kubernetes وجود ندارند. در مرحله بعد، باید از API AWS برای غیرفعال کردن گره ها یا ماشین های غیر ضروری استفاده کنید.
می توانید از Amdatu Scalerd، یکی دیگر از ابزارهای مقیاس باز منبع باز مشابه API AWS استفاده کنید. یک CLI برای افزودن یا حذف گره ها در یک خوشه فراهم می کند. ویژگی جالب آن امکان پیکربندی زمانبندی با استفاده از فایل json زیر است.
کد نشان داده شده ظرفیت خوشه را در طول شب به نصف کاهش می دهد. هم تعداد کپی های موجود و هم ظرفیت دلخواه خوشه آمازون را پیکربندی می کند. استفاده از این زمان‌بند به‌طور خودکار تعداد گره‌ها را در شب کاهش می‌دهد و آنها را در صبح افزایش می‌دهد و در هزینه استفاده از گره‌ها از سرویس ابری مانند آمازون صرفه‌جویی می‌کند. این ویژگی در Kubernetes تعبیه نشده است، اما استفاده از Scalerd به شما این امکان را می دهد که این پلتفرم را هر طور که می خواهید مقیاس کنید.
می‌خواهم به این نکته اشاره کنم که بسیاری از مردم به من می‌گویند: «این همه خوب است، اما در مورد پایگاه داده من که معمولاً ثابت است، چطور؟» چگونه می توانید چنین چیزی را در یک محیط پویا مانند Kubernetes اجرا کنید؟ به نظر من، شما نباید این کار را انجام دهید، شما نباید سعی کنید یک انبار داده را در Kubernetes اجرا کنید. این از نظر فنی امکان پذیر است و آموزش هایی در اینترنت در این زمینه وجود دارد، اما زندگی شما را به طور جدی پیچیده می کند.
بله، مفهوم فروشگاه‌های دائمی در Kubernetes وجود دارد، و شما می‌توانید سعی کنید فروشگاه‌های داده مانند Mongo یا MySQL را اجرا کنید، اما این یک کار کاملاً سخت است. این به دلیل این واقعیت است که انبارهای داده به طور کامل از تعامل با یک محیط پویا پشتیبانی نمی کنند. اکثر پایگاه های داده نیاز به پیکربندی قابل توجهی دارند، از جمله پیکربندی دستی خوشه، مقیاس خودکار و موارد مشابه دیگر را دوست ندارند.
بنابراین، شما نباید زندگی خود را با تلاش برای اجرای یک انبار داده در Kubernetes پیچیده کنید. کار خود را به روش سنتی با استفاده از خدمات آشنا سازماندهی کنید و به سادگی امکان استفاده از آنها را به کوبرنتس ارائه دهید.
برای پایان دادن به موضوع، می خواهم شما را با پلتفرم Cloud RTI مبتنی بر Kubernetes آشنا کنم که تیم من در حال کار بر روی آن است. ثبت متمرکز، نظارت بر برنامه ها و خوشه ها، و بسیاری از ویژگی های مفید دیگر را ارائه می دهد که مفید خواهند بود. از ابزارهای متن باز مختلفی مانند Grafana برای نمایش نظارت استفاده می کند.
یک سوال در مورد چرایی استفاده از متعادل کننده بار پراکسی ha با Kubernetes وجود داشت. سوال خوبی است زیرا در حال حاضر 2 سطح تعادل بار وجود دارد. سرویس های Kubernetes هنوز بر روی آدرس های IP مجازی قرار دارند. شما نمی توانید از آنها برای پورت ها در دستگاه های میزبان خارجی استفاده کنید زیرا اگر آمازون میزبان ابری خود را بیش از حد بارگذاری کند، آدرس تغییر می کند. به همین دلیل است که ha-proxy را در جلوی سرویس‌ها قرار می‌دهیم - برای ایجاد ساختار ثابت‌تری برای ترافیک تا ارتباط یکپارچه با Kubernetes.
سوال خوب دیگر این است که چگونه می توانید از تغییرات طرح پایگاه داده در هنگام استقرار آبی/سبز مراقبت کنید؟ واقعیت این است که صرف نظر از استفاده از Kubernetes، تغییر طرح پایگاه داده کار دشواری است. شما باید از سازگاری طرحواره قدیمی و جدید اطمینان حاصل کنید، پس از آن می توانید پایگاه داده را به روز کنید و سپس خود برنامه ها را به روز کنید. می‌توانید پایگاه داده را با هم عوض کنید و سپس برنامه‌ها را به‌روزرسانی کنید. من افرادی را می شناسم که یک کلاستر پایگاه داده کاملاً جدید را با یک طرح جدید راه اندازی کرده اند، اگر پایگاه داده بدون طرحی مانند Mongo دارید، این یک گزینه است، اما به هر حال کار آسانی نیست. اگر سوال دیگری ندارید، از توجه شما متشکرم!
چند تبلیغ 🙂
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).
Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید
منبع: www.habr.com