مدیریت سیستم های توزیع شده ممکن است دشوار باشد زیرا آنها دارای عناصر متحرک و متغیر زیادی هستند که همه باید برای عملکرد سیستم به درستی کار کنند. اگر یکی از عناصر از کار بیفتد، سیستم باید آن را شناسایی کند، آن را دور بزند و آن را تعمیر کند و همه اینها باید به طور خودکار انجام شود. در این مجموعه بهترین تمرین‌های Kubernetes، نحوه تنظیم تست‌های آمادگی و سرزندگی را برای آزمایش سلامت یک خوشه Kubernetes خواهیم آموخت.
Health Check یک راه ساده است که به سیستم اطلاع می دهد که آیا نمونه برنامه شما در حال اجرا است یا خیر. اگر نمونه برنامه شما خراب است، دیگر سرویس ها نباید به آن دسترسی داشته باشند یا درخواستی برای آن ارسال کنند. در عوض، درخواست باید به نمونه دیگری از برنامه ارسال شود که قبلاً در حال اجرا است یا بعداً راه اندازی خواهد شد. علاوه بر این، سیستم باید عملکرد از دست رفته برنامه شما را بازیابی کند.
به‌طور پیش‌فرض، Kubernetes زمانی که همه کانتینرهای درون پادها در حال اجرا هستند، شروع به ارسال ترافیک به یک پاد می‌کند و زمانی که کانتینرها خراب می‌شوند، کانتینرها را راه‌اندازی مجدد می‌کند. این رفتار پیش‌فرض سیستم ممکن است برای شروع به اندازه کافی خوب باشد، اما می‌توانید قابلیت اطمینان استقرار محصول خود را با استفاده از بررسی‌های سلامت عقلی سفارشی بهبود بخشید.
خوشبختانه، Kubernetes انجام این کار را بسیار آسان می کند، بنابراین هیچ بهانه ای برای نادیده گرفتن این بررسی ها وجود ندارد. Kubernetes دو نوع بررسی سلامت را ارائه می دهد، و درک تفاوت در نحوه استفاده از هر کدام مهم است.
تست آمادگی برای این طراحی شده است که به Kubernetes بگوید که برنامه شما برای مدیریت ترافیک آماده است. قبل از اجازه دادن به سرویس برای ارسال ترافیک به یک پاد، Kubernetes باید تأیید کند که بررسی آمادگی موفقیت آمیز است. اگر تست آمادگی ناموفق باشد، Kubernetes ارسال ترافیک به پاد را تا زمانی که آزمون قبول شود متوقف می‌کند.
تست Liveness به Kubernetes می گوید که آیا برنامه شما زنده است یا مرده. در مورد اول، Kubernetes آن را به حال خود رها می کند، در مورد دوم، غلاف مرده را حذف می کند و آن را با یک مورد جدید جایگزین می کند.
بیایید سناریویی را تصور کنیم که در آن برنامه شما 1 دقیقه طول می کشد تا گرم شود و راه اندازی شود. سرویس شما تا زمانی که برنامه به طور کامل بارگیری و اجرا نشود شروع به کار نخواهد کرد، اگرچه گردش کار قبلاً شروع شده است. همچنین اگر بخواهید این استقرار را به چند نسخه افزایش دهید، مشکل خواهید داشت، زیرا این کپی ها تا زمانی که کاملا آماده نشده باشند، نباید ترافیک دریافت کنند. با این حال، به طور پیش فرض، Kubernetes به محض شروع فرآیندهای داخل کانتینر، ارسال ترافیک را آغاز می کند.
هنگام استفاده از تست آمادگی، Kubernetes منتظر می ماند تا برنامه به طور کامل اجرا شود و به سرویس اجازه می دهد تا ترافیک را به نسخه جدید ارسال کند.
بیایید سناریوی دیگری را تصور کنیم که در آن برنامه برای مدت طولانی متوقف می شود و درخواست های سرویس را متوقف می کند. با ادامه روند اجرا، Kubernetes به طور پیش‌فرض فرض می‌کند که همه چیز خوب است و به ارسال درخواست‌ها به غلاف غیرفعال ادامه می‌دهد. اما هنگام استفاده از Liveness، Kubernetes تشخیص می‌دهد که برنامه دیگر درخواست‌ها را ارائه نمی‌دهد و به طور پیش‌فرض غلاف مرده را مجددا راه‌اندازی می‌کند.
بیایید ببینیم که چگونه آمادگی و دوام آزمایش می شود. سه روش تست وجود دارد - HTTP، Command و TCP. برای بررسی می توانید از هر یک از آنها استفاده کنید. رایج ترین راه برای آزمایش یک کاربر، پروب HTTP است.
حتی اگر برنامه شما یک سرور HTTP نیست، همچنان می توانید یک سرور HTTP سبک وزن در داخل برنامه خود ایجاد کنید تا با تست Liveness تعامل داشته باشد. پس از این، Kubernetes شروع به پینگ کردن پاد می کند و اگر پاسخ HTTP در محدوده 200 یا 300 ms باشد، نشان دهنده سالم بودن پاد است. در غیر این صورت، ماژول به عنوان "ناسالم" علامت گذاری می شود.
برای تست های Command، Kubernetes دستور را در داخل کانتینر شما اجرا می کند. اگر دستور با کد خروجی صفر برگردد، کانتینر سالم علامت گذاری می شود، در غیر این صورت، با دریافت شماره وضعیت خروج از 1 تا 255، ظرف به عنوان "بیمار" علامت گذاری می شود. اگر نمی‌توانید یا نمی‌خواهید سرور HTTP را اجرا کنید، اما قادر به اجرای دستوری هستید که سلامت برنامه شما را بررسی می‌کند، این روش تست مفید است.
مکانیسم تایید نهایی تست TCP است. Kubernetes سعی می کند یک اتصال TCP را در پورت مشخص شده برقرار کند. اگر بتوان این کار را انجام داد، ظرف سالم و در غیر این صورت غیر قابل دوام تلقی می شود. اگر از سناریویی استفاده می کنید که در آن آزمایش با درخواست HTTP یا اجرای دستور خیلی خوب کار نمی کند، این روش می تواند مفید باشد. به عنوان مثال، خدمات اصلی برای تأیید با استفاده از TCP، gRPC یا FTP خواهد بود.
تست ها را می توان به روش های مختلفی با پارامترهای مختلف پیکربندی کرد. شما می توانید مشخص کنید که چند بار باید اجرا شوند، آستانه موفقیت و شکست چقدر است و چه مدت منتظر پاسخ ها باشید. برای اطلاعات بیشتر، مستندات مربوط به تست های آمادگی و سرزندگی را ببینید. با این حال، یک نکته بسیار مهم در راه اندازی تست Liveness وجود دارد - تنظیم اولیه تاخیر در تست initialDelaySeconds. همانطور که اشاره کردم، شکست این تست منجر به راه اندازی مجدد ماژول می شود. بنابراین باید مطمئن شوید که تا زمانی که برنامه آماده کار نشده باشد، آزمایش شروع نمی‌شود، در غیر این صورت از راه‌اندازی مجدد شروع می‌شود. من توصیه می کنم از زمان راه اندازی P99 یا متوسط زمان راه اندازی برنامه از بافر استفاده کنید. به خاطر داشته باشید که این مقدار را تنظیم کنید زیرا زمان راه اندازی برنامه شما سریعتر یا کندتر می شود.
اکثر کارشناسان تأیید می کنند که بررسی سلامت یک بررسی اجباری برای هر سیستم توزیع شده است و 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