یک نکته مهم در عملکرد سیستم های توزیع شده مدیریت خرابی است. Kubernetes با استفاده از کنترل‌کننده‌هایی که سلامت سیستم شما را نظارت می‌کنند و سرویس‌هایی که از کار افتاده‌اند راه‌اندازی مجدد می‌کنند، به این امر کمک می‌کند. با این حال، Kubernetes می تواند به اجبار برنامه های شما را متوقف کند تا از سلامت کلی سیستم اطمینان حاصل کند. در این مجموعه به بررسی این موضوع خواهیم پرداخت که چگونه می توانید به کوبرنتیس کمک کنید تا کار خود را به نحو احسن انجام دهد و زمان خرابی برنامه را کاهش دهد.
قبل از کانتینرها، اکثر برنامه ها روی ماشین های مجازی یا فیزیکی اجرا می شدند. اگر برنامه از کار افتاد یا مسدود شد، لغو کار در حال انجام و بارگیری مجدد برنامه زمان زیادی طول کشید. در بدترین حالت، شخصی مجبور بود این مشکل را در شب و در نامناسب ترین ساعت به صورت دستی حل کند. اگر فقط 1-2 ماشین کار یک کار مهم را انجام می دادند، چنین اختلالی کاملا غیرقابل قبول بود.
بنابراین، به جای راه اندازی مجدد دستی، آنها شروع به استفاده از نظارت در سطح فرآیند کردند تا در صورت خاتمه غیرعادی برنامه به طور خودکار راه اندازی مجدد شود. اگر برنامه از کار بیفتد، فرآیند نظارت کد خروج را می گیرد و سرور را راه اندازی مجدد می کند. با ظهور سیستم هایی مانند Kubernetes، این نوع پاسخ به خرابی های سیستم به سادگی در زیرساخت ادغام شد.
Kubernetes از یک حلقه رویداد مشاهده-تفاوت- اقدام-عمل استفاده می کند تا اطمینان حاصل کند که منابع در حین حرکت از کانتینرها به گره ها سالم می مانند.
این بدان معناست که دیگر نیازی به اجرای دستی نظارت بر فرآیند ندارید. اگر منبعی در بررسی سلامت ناموفق باشد، Kubernetes به سادگی آن را به طور خودکار جایگزینی را ارائه می کند. با این حال، Kubernetes بسیار بیشتر از نظارت بر برنامه شما برای خرابی ها انجام می دهد. می‌تواند نسخه‌های بیشتری از برنامه ایجاد کند تا روی چندین ماشین اجرا شود، برنامه به‌روزرسانی شود یا چندین نسخه از برنامه شما به طور همزمان اجرا شود.
بنابراین، دلایل زیادی وجود دارد که Kubernetes می تواند یک ظرف کاملا سالم را خاتمه دهد. به عنوان مثال، اگر استقرار خود را ارتقا دهید، Kubernetes به آرامی پادهای قدیمی را متوقف می کند و در عین حال موارد جدید را شروع می کند. اگر یک گره را ببندید، Kubernetes اجرای تمام پادها را در آن گره متوقف خواهد کرد. در نهایت، اگر منابع یک گره تمام شود، Kubernetes تمام پادها را خاموش می کند تا آن منابع را آزاد کند.
بنابراین، بسیار مهم است که برنامه شما با کمترین تأثیر برای کاربر نهایی و حداقل زمان بازیابی پایان یابد. این بدان معناست که قبل از خاموش شدن، باید تمام داده‌هایی را که باید ذخیره شوند ذخیره کند، تمام اتصالات شبکه را ببندد، کارهای باقی مانده را کامل کند و سایر کارهای فوری را مدیریت کند.
در عمل، این بدان معنی است که برنامه شما باید بتواند پیام SIGTERM را مدیریت کند، سیگنال پایان فرآیند که سیگنال پیش‌فرض ابزار kill در سیستم‌عامل‌های یونیکس است. با دریافت این پیام، برنامه باید خاموش شود.
هنگامی که Kubernetes تصمیم می گیرد یک پاد را خاتمه دهد، تعدادی رویداد رخ می دهد. بیایید به هر مرحله ای که Kubernetes هنگام خاموش کردن یک ظرف یا غلاف برمی دارد نگاه کنیم.
فرض کنید می خواهیم یکی از غلاف ها را خاتمه دهیم. در این مرحله، دریافت ترافیک جدید متوقف می شود - کانتینرهای در حال اجرا در غلاف تحت تأثیر قرار نمی گیرند، اما تمام ترافیک جدید مسدود می شود.
بیایید به قلاب preStop نگاه کنیم، که یک دستور خاص یا درخواست HTTP است که به کانتینرها در یک pod ارسال می شود. اگر برنامه شما در هنگام دریافت SIGTERM به درستی خاموش نمی شود، می توانید از preStop برای خاموش شدن صحیح استفاده کنید.
اکثر برنامه‌ها با دریافت سیگنال SIGTERM به‌خوبی از آن خارج می‌شوند، اما اگر از کد شخص ثالث یا سیستمی استفاده می‌کنید که به طور کامل کنترل نمی‌کنید، قلاب preStop یک راه عالی برای خاموش کردن برازنده بدون تغییر برنامه است.
پس از اجرای این قلاب، Kubernetes یک سیگنال SIGTERM را به کانتینرهای موجود در غلاف ارسال می کند و به آنها اطلاع می دهد که به زودی قطع خواهند شد. با دریافت این سیگنال، کد شما به فرآیند خاموش شدن ادامه خواهد داد. این فرآیند ممکن است شامل توقف هر گونه اتصال طولانی مدت مانند اتصال پایگاه داده یا جریان WebSocket، ذخیره وضعیت فعلی و موارد مشابه باشد.
حتی اگر از یک قلاب preStop استفاده می‌کنید، بسیار مهم است که بررسی کنید هنگام ارسال سیگنال SIGTERM دقیقاً چه اتفاقی برای برنامه شما می‌افتد و چگونه رفتار می‌کند، به طوری که رویدادها یا تغییرات در عملکرد سیستم ناشی از خاموش شدن پاد به‌عنوان اتفاق نیفتد. یک سورپرایز برای شما
در این مرحله، Kubernetes برای مدت زمان مشخصی به نام terminationGracePeriodSecond یا دوره زمانی که سیگنال SIGTERM را دریافت می‌کند، منتظر می‌ماند.
به طور پیش فرض این مدت 30 ثانیه است. مهم است که توجه داشته باشید که به موازات قلاب preStop و سیگنال SIGTERM اجرا می شود. Kubernetes منتظر پایان hook preStop و SIGTERM نخواهد بود—اگر برنامه شما قبل از پایان TerminationGracePeriod خارج شود، Kubernetes بلافاصله به مرحله بعدی می‌رود. بنابراین، بررسی کنید که مقدار این دوره در ثانیه از زمان لازم برای خاموش کردن صحیح پادک کمتر نباشد و اگر از 30 ثانیه بیشتر شد، دوره را به مقدار مورد نظر در YAML افزایش دهید. در مثال ارائه شده، 60s است.
و در نهایت، آخرین مرحله این است که اگر کانتینرها پس از اتمام GracePeriod همچنان در حال اجرا هستند، یک سیگنال SIGKILL ارسال می کنند و به زور حذف می شوند. در این مرحله، Kubernetes تمام اشیاء غلاف دیگر را نیز پاک می کند.
Kubernetes به دلایل زیادی پادها را خاتمه می دهد، بنابراین مطمئن شوید که برنامه شما در هر صورت به خوبی خاتمه می یابد تا از یک سرویس پایدار اطمینان حاصل کنید.
چند تبلیغ 🙂
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با 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