کنترل‌پلین در کوبرنتیز چیست و چگونه کلاستر را مدیریت می‌کند؟

مدیریت یک کلاستر در کوبرنتیز فقط به اجرای کانتینرها محدود نمی‌شود. این سامانه باید وضعیت مطلوبی را که کاربر برای منابع مختلف تعریف می‌کند دریافت کند، وضعیت فعلی کلاستر را به‌طور مداوم بسنجد و برای نزدیک‌کردن این دو وضعیت تصمیم بگیرد. برای مثال، زمانی که یک دیپلویمنت (Deployment) جدید ایجاد می‌شود یا تعداد رپلیکاها (Replica) تغییر می‌کند، کوبرنتیز باید تشخیص دهد چه اقداماتی لازم است تا کلاستر به وضعیت مورد انتظار برسد. همین موضوع باعث می‌شود هنگام آشنایی با معماری کوبرنتیز، این پرسش مطرح شود که کنترل‌پلین در کوبرنتیز چیست و چه نقشی در مدیریت کلاستر ایفا می‌کند.

کنترل‌پلین (Control Plane) مجموعه‌ای از اجزای اصلی کوبرنتیز است که اغلب به‌عنوان مغز کلاستر شناخته می‌شود و وضعیت کلی آن را مدیریت می‌کند. سرور API کوبرنتیز (Kubernetes API) را در دسترس قرار می‌دهد، Scheduler پادهای بدون نود را به نود مناسب اختصاص می‌دهد و مدیر کنترلر، کنترلرهای موردنیاز برای اجرای رفتارهای API کوبرنتیز را اجرا می‌کند. به همین دلیل، می‌توان کنترل‌پلین را لایه مدیریتی کلاستر دانست؛ بخشی که وظیفه اصلی آن مدیریت وضعیت و هماهنگی فرایندهای کلاستر است، نه اجرای بارهای کاری کاربران.

همچنین تفاوت کنترل‌پلین و نود ورکر (Worker Node) را نقش آن‌ها در معماری کلاستر مشخص می‌کند؛ بارهای کاری کاربران روی نودهای ورکر اجرا می‌شوند، درحالی‌که کنترل‌پلین مسئول مدیریت وضعیت کلاستر، تصمیم‌گیری و هدایت فرایندهای کنترلی است. در ادامه، معماری کنترل‌پلین کوبرنتیز، اجزای اصلی آن و نحوه کار کنترل‌پلین کوبرنتیز را بررسی می‌کنیم.

کنترل‌پلین چه نقشی در معماری کوبرنتیز دارد؟

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

مسئولیت اصلی کنترل‌پلین اجرای بارهای کاری کاربران نیست و در معماری معمول، این بارهای کاری روی نود ورکرها اجرا می‌شوند. برای مثال، Scheduler فقط نود مناسب را برای اجرای یک پاد انتخاب می‌کند، اما اجرای واقعی پاد روی نود بر عهده kubelet و محیط اجرای کانتینر است. به همین دلیل، کنترل‌پلین مسئول تصمیم‌گیری و هماهنگ‌سازی است؛ در حالی که اجرای بارهای کاری روی نودهای ورکر انجام می‌شود.

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

اجزای اصلی کنترل‌پلین کوبرنتیز کدام‌اند؟

کنترل‌پلین کوبرنتیز از چند جزء اصلی تشکیل شده است که هرکدام مسئولیت مشخصی در مدیریت کلاستر بر عهده دارند. این اجزا در کنار یکدیگر درخواست‌های مربوط به API کوبرنتیز را پردازش می‌کنند، وضعیت کلاستر را پایش می‌کنند و شرایط لازم را برای نزدیک‌کردن وضعیت فعلی به وضعیت مطلوب فراهم می‌سازند.

سرور API یا kube-apiserver

سرور API یا kube-apiserver یکی از اجزای اصلی کنترل‌پلین است که API کوبرنتیز را در دسترس قرار می‌دهد. ابزارهایی مانند kubectl و سایر سرویس‌گیرنده‌های API، از طریق این رابط با کلاستر تعامل می‌کنند. درخواست‌های دریافتی در این بخش اعتبارسنجی شده و مراحل احراز هویت، مجوزدهی و کنترل پذیرش (Admission Control به معنی بررسی، پذیرش، رد یا اصلاح درخواست پیش از ثبت آن) روی آن‌ها انجام می‌شود. همچنین سرور API برای ثبت و بازیابی وضعیت منابع و اطلاعات پیکربندی کلاستر با etcd تعامل می‌کند.

سرور API مسئول اجرای مستقیم کانتینرها نیست. اجرای پادها و کانتینرهای مربوط به بارهای کاری روی نودهای ورکر و به‌وسیله kubelet و محیط اجرای کانتینر انجام می‌شود.

پایگاه داده etcd

پایگاه داده etcd یک مخزن کلید-مقدار (Key-Value Store) سازگار و توزیع‌شده است که داده‌های API کوبرنتیز، از جمله اطلاعات منابع و پیکربندی کلاستر، را نگهداری می‌کند. ازآنجایی‌که تمام داده‌های سرور API در آن ذخیره می‌شوند، ازدست‌رفتن داده‌های etcd می‌تواند بازیابی کلاستر را دشوار یا غیرممکن کند. به همین دلیل، پشتیبان‌گیری، امنیت و دسترس‌پذیری آن برای پایداری کنترل‌پلین حیاتی است. در معماری کوبرنتیز، تمام اجزای کنترل‌پلین مستقیما به etcd متصل نمی‌شوند، بلکه تعامل آن‌ها با وضعیت کلاستر از طریق سرور API انجام می‌گیرد.

زمان‌بند یا kube-scheduler

Scheduler پادهایی را پیدا می‌کند که هنوز به نودی اختصاص داده نشده‌اند و هر پاد را به یک نود مناسب اختصاص می‌دهد. Scheduler فقط نود مناسب را برای هر پاد انتخاب می‌کند. پس از آن، kubelet روی نود ورکر از اجرای کانتینرهای پاد اطمینان حاصل می‌کند و محیط اجرای کانتینر مسئول اجرای کانتینرها است.

مدیر کنترلر یا kube-controller-manager

مدیر کنترلر یا kube-controller-manager کنترلرهایی را اجرا می‌کند که مبتنی بر مفهوم «حلقه کنترل» (Control Loop) کار می‌کنند. این کنترلرها وضعیت منابع را از طریق API مشاهده کرده و تلاش می‌کنند وضعیت فعلی را با وضعیت مطلوب تطبیق دهند. برای مثال، اگر تعداد پادهای در حال اجرا کمتر از تعداد تعریف‌شده باشد، کنترلر مربوط این اختلاف را تشخیص می‌دهد و برای ایجاد منابع لازم اقدام می‌کند. از نمونه‌های مهم این کنترلرها می‌توان به Node Controller (برای نظارت بر وضعیت نودها) و Job Controller اشاره کرد.

مدیر کنترلر ابری یا cloud-controller-manager

مدیر کنترلر ابری یا cloud-controller-manager یک جزء اختیاری کنترل‌پلین است که کوبرنتیز را با ارائه‌دهندگان زیرساخت ابری یکپارچه می‌کند. بنابراین، وجود این جزء به محیط استقرار کلاستر وابسته است و همه کلاسترها الزاما از آن استفاده نمی‌کنند.

یک درخواست چگونه در کنترل‌پلین پردازش می‌شود؟

برای درک کلی نحوه کار کنترل‌پلین کوبرنتیز، فرض کنید کاربری قصد دارد یک دیپلویمنت کوبرنتیز جدید ایجاد کند.

۱. کاربر مشخصات دیپلویمنت را از طریق kubectl ارسال می‌کند.

۲. درخواست به سرور API می‌رسد و مراحل احراز هویت، مجوزدهی، کنترل پذیرش و اعتبارسنجی لازم را طی می‌کند.

۳. وضعیت مطلوب از طریق سرور API در etcd ثبت می‌شود.

۴. کنترلر دیپلویمنت ایجاد این منبع را مشاهده می‌کند و ReplicaSet لازم را می‌سازد؛ سپس کنترلر ReplicaSet، پادهای موردنیاز را ایجاد می‌کند.

۵. Scheduler برای پادهای بدون نود، نود مناسب انتخاب می‌کند.

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

۷. وضعیت جدید دوباره از طریق سرور API ثبت می‌شود و کنترلرها به نظارت خود ادامه می‌دهند.

نکته مهم این است که معمولا اجزای کنترل‌پلین به‌صورت زنجیره‌ای و با ارسال فرمان مستقیم به یکدیگر عمل نمی‌کنند. هماهنگی میان آن‌ها بیشتر بر اساس مشاهده و به‌روزرسانی وضعیت منابع از طریق API کوبرنتیز انجام می‌شود؛ به همین دلیل هر جزء، بر اساس تغییرات وضعیت کلاستر، وظیفه خود را انجام می‌دهد.

در صورت خرابی کنترل‌پلین چه اتفاقی می‌افتد؟

پیامد خرابی کنترل‌پلین به نوع خرابی و میزان افزونگی معماری بستگی دارد. خرابی یک فرایند یا یک نود کنترل‌پلین در معماری دسترس‌پذیر لزوماً کل کنترل‌پلین را از دسترس خارج نمی‌کند؛ زیرا Instanceهای سالم می‌توانند ارائه سرویس را ادامه دهند. در مقابل، ازدسترس‌خارج‌شدن کامل کنترل‌پلین، فعالیت‌های مدیریتی کلاستر را مختل می‌کند. پیامدهای از دسترس خارج شدن کامل کنترل‌پلین عبارت‌اند از:

• پردازش نشدن درخواست‌های جدید API
• اختلال در ایجاد، تغییر یا حذف منابع از طریق API
• زمان‌بندی‌نشدن پادهای جدید
• توقف فرایند تطبیق وضعیت فعلی با وضعیت مطلوب
• مختل‌شدن مشاهده وضعیت کلاستر با ابزارهایی مانند kubectl

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

خرابی یک عضو etcd لزوماً کل کلاستر etcd را از دسترس خارج نمی‌کند. تا زمانی که بیش از نیمی از اعضا فعال و در دسترس باشند، حد نصاب حفظ می‌شود و کلاستر می‌تواند به فعالیت عادی خود ادامه دهد. اما اگر تعداد اعضای در دسترس از حد نصاب کمتر شود، کلاستر etcd دیگر نمی‌تواند عملیات عادی خود را انجام دهد. همچنین ازدست‌رفتن داده‌های etcd در نبود نسخه پشتیبان معتبر، بازیابی کلاستر کوبرنتیز را با مشکل جدی مواجه می‌کند.

کنترل‌پلین با دسترس‌پذیری بالا چگونه طراحی می‌شود؟

در معماری دارای دسترس‌پذیری بالا، اجزای کنترل‌پلین روی بیش از یک نود اجرا می‌شوند و در محیط‌های ابری، این نودها پشت یک لود بالانسر مبتنی بر TCP قرار می‌گیرند. لود بالانسر ترافیک ورودی API کوبرنتیز را میان instanceهای سالم kube-apiserver توزیع می‌کند و باید بتواند از طریق پورت سرور API با همه نودهای کنترل‌پلین ارتباط برقرار کند. برای افزایش دسترس‌پذیری کنترل‌پلین، معمولا از اصول زیر در طراحی معماری استفاده می‌شود:

• استفاده از چند نود کنترل‌پلین
• توزیع نودهای کنترل‌پلین و اعضای etcd میان دامنه‌های خرابی مستقل، در صورت امکان
• قراردادن instanceهای kube-apiserver پشت یک لود بالانسر
• اطمینان از ارتباط لود بالانسر با instanceهای kube-apiserver و هدایت ترافیک به instanceهای سالم
• انتخاب یکی از دو توپولوژی stacked etcd یا external etcd
• استفاده از تعداد فرد اعضای etcd برای حفظ حد نصاب و تداوم فعالیت کلاستر در صورت خرابی برخی از اعضا
• پایش سلامت اجزای کنترل‌پلین
• تهیه نسخه پشتیبان منظم از etcd و آزمایش فرایند بازیابی آن
• حفاظت از گواهی‌ها و اطلاعات حساس کنترل‌پلین

مستندات رسمی کوبرنتیز دو توپولوژی اصلی را برای استقرار کنترل‌پلین با دسترس‌پذیری بالا معرفی می‌کنند:

تفاوت اصلی این دو رویکرد در هم‌مکان بودن یا جدا بودن اعضای etcd و نودهای کنترل‌پلین است. روش stacked etcd به زیرساخت کمتری نیاز دارد، درحالی‌که روش external etcd با جدا کردن این دو بخش، ماشین‌های بیشتری را برای اعضای etcd در نظر می‌گیرد.

دسترسی به کنترل‌پلین چگونه ایمن می‌شود؟

ازآنجایی‌که سرور API نقطه اصلی ورود مدیریتی به کلاستر است، نحوه دسترسی شبکه‌ای به آن بر سطح حمله کنترل‌پلین اثر مستقیم دارد. این دسترسی می‌تواند از طریق Endpoint عمومی یا خصوصی فراهم شود. در صورت استفاده از Endpoint عمومی، دسترسی باید تا حد امکان به آدرس‌ها یا شبکه‌های مجاز محدود شود. Endpoint خصوصی هم برای محیط‌هایی مناسب است که دسترسی عمومی به سرور API در آن‌ها ضروری نیست. برای افزایش امنیت کنترل‌پلین، رعایت موارد زیر ضروری است:

• استفاده از ارتباط رمزنگاری‌شده مبتنی بر TLS
• اعمال احراز هویت و مجوزدهی مبتنی بر کمترین سطح دسترسی
• حفاظت از فایل‌های kubeconfig، گواهی‌ها و کلیدهای کنترل‌پلین
• ثبت و بررسی رویدادهای Audit
• محافظت از دسترسی شبکه‌ای و داده‌های etcd

مدیریت کنترل‌پلین در کوبرنتیز خودمدیریت‌شده و مدیریت‌شده چه تفاوتی دارد؟

در یک کلاستر کوبرنتیز خودمدیریت‌شده (Self-managed Kubernetes) مبتنی بر kubeadm، تیم بهره‌بردار باید نودهای کنترل‌پلین، لود بالانسر مربوط به kube-apiserver و توپولوژی etcd را راه‌اندازی و مدیریت کند. همچنین این تیم باید اجزای لازم را روی نودهای کنترل‌پلین مستقر کند و در مدل external etcd، کلاستر جداگانه etcd را پیش از راه‌اندازی کنترل‌پلین آماده سازد.

در کوبرنتیز مدیریت‌شده (Managed Kubernetes)، ارائه‌دهنده، سرویس کنترل‌پلین را مدیریت می‌کند و اجزای اصلی آن، مانند kube-apiserver، etcd ،kube-scheduler و kube-controller-manager، در محدوده کنترل‌پلین مدیریت‌شده قرار می‌گیرند. در مقابل، نودهای ورکر، زیرساختی هستند که برنامه‌های کاربران را اجرا می‌کنند.

تفاوت اصلی این دو مدل در مسئولیت راه‌اندازی و مدیریت کنترل‌پلین است. در مدل خودمدیریت‌شده، این مسئولیت بر عهده تیم بهره‌بردار قرار دارد؛ اما در مدل مدیریت‌شده، ارائه‌دهنده سرویس کنترل‌پلین و اجزای اصلی آن را مدیریت می‌کند.

جمع‌بندی

درپاسخ به این پرسش که کنترل‌پلین در کوبرنتیز چیست، می‌توان گفت کنترل‌پلین لایه تصمیم‌گیری و مدیریت وضعیت کلاستر است. اجزایی مانند kube-apiserver ،etcd ،kube-scheduler و kube-controller-manager مسئولیت مشخصی در مدیریت وضعیت کلاستر بر عهده دارند و در کنار یکدیگر امکان تصمیم‌گیری و هماهنگی فرایندهای کنترلی را فراهم می‌کنند. در سمت مقابل، اجرای مستقیم بارهای کاری بر عهده نودهای ورکر است، نه کنترل‌پلین.

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