پلتفرم Kubernetes چیست و چه مزایایی دارد؟ – قسمت دوم (پایانی)

 در قسمت اول مقاله در مورد پلتفرم Kubernetes به عنوان یک پلتفرم پرتابل، توسعه‌پذیر و متن‌باز برای مدیریت بارهای کاری و خدمات Containerizeشده است صحبت کردیم و عنوان کردیم که این پلتفرم هم خودکارسازی و هم پیکربندی Declarative را می تواند تسهیل نماید. این پلتفرم یک اکوسیستم بزرگ و در حال رشد سریع دارد. خدمات، پشتیبانی و ابزار Kubernetes به‌طور گسترده‌ای قابل‌دسترسی هستند.

وقتی Kubernetes پیاده‌سازی می‌شود، یک کلاستر دریافت می‌گردد. یک کلاستر Kubernetes شامل مجموعه‌ای از ماشین‌ به نام Nodeها است که برنامه‌های کاربردی Containerizeشده را اجرا می‌کنند. هر کلاستری حداقل یک Node کارگر دارد.

این Nodeها Podهایی را که اجزای بار کاری برنامه کاربردی هستند، Host می‌کنند. Nodeها و Podهای داخل کلاستر، توسط Control Plane مدیریت می‌شوند. در محیط‌های تولیدی، Control Plane معمولاً روی چندین رایانه اجرا می‌شود و یک کلاستر معمولاً چندین Node را اجرا می‌کند و بدین‌صورت تحمل خطا و دسترس‌پذیری بالایی فراهم می‌گردد.

اجزای یک کلاستر Kubernetes

اجزای Control Plane

اجزای Control Plane تصمیماتی سراسری مانند برنامه‌ریزی را در مورد کلاستر می‌گیرند و همچنین رخدادهای کلاستر را شناسایی کرده و به آن‌ها پاسخ می‌دهند، به عنوان مثال شروع به کار یک Pod جدید وقتی که Field مربوط به Replicaهای یک پیاده‌سازی کامل نشده باشد.

اجزای Control Plane را می‌توان روی هر ماشینی در کلاستر اجرا کرد. اما برای سادگی، اسکریپت‌های تنظیم یا همان Set Up، معمولاً تمام اجزای Control Plane را روی ماشین یکسانی آغاز می‌کنند و Containerهای کاربر را روی این ماشین اجرا نمی‌کنند.

kube-apiserver

API Server یکی از اجزای Kubernetes Control Plane است که Kubernetes API را افشا می‌کند. API Server برای Kubernetes Control Plane یک Front End محسوب می‌شود.

kube-apiserver پیاده‌سازی اصلی یک Kubernetes API Server می باشد که برای این طراحی شده است که به‌صورت افقی توسعه پیدا کند، یعنی با پیاده‌سازی Instanceهای بیشتر توسعه می‌یابد. می‌توان چندین Instance از kube-apiserver را اجرا کرد و ترافیک را بین آن Instanceها متعادل نمود.

etcd

یک Key Value Store باثبات و دارای دسترس‌پذیری بالا که به‌عنوان Store پشتیبان کلاستر Kubernetes برای تمام داده‌های کلاستر مورد استفاده قرار می‌گیرد. اگر کلاستر Kubernetes از etcd به‌عنوان Store پشتیبان استفاده کند، باید اطمینان حاصل کرد که یک برنامه‌ی پشتیبان‌گیری برای آن داده‌ها وجود داشته باشد.

kube-scheduler

یکی از اجزای Control Plane که منتظر Podهایی می‌ماند که به‌تازگی ایجاد شده‌ باشند و Node اختصاصی نداشته باشند و یک Node را انتخاب می‌کند تا روی آن اجرا شوند. عواملی که برای تصمیمات برنامه‌ریزی باید مدنظر قرار گیرند، شامل موارد زیر هستند: الزامات منابع فردی و جمعی، محدودیت‌های سخت‌افزار/نرم‌افزار/پالیسی، مشخصات affinity و anti-affinity، محل داده‌ها، تداخل بین بارهای کاری و ضرب‌الاجل‌ها.

kube-controller-manager

یکی از اجزای Control Plane که فرایندهای Controller را اجرا می‌کند. از نظر منطقی هر Controller یک فرایند جداگانه است، اما برای کاهش پیچیدگی، همگی در یک باینری واحد گرد‌آوری می‌شوند و در یک فرایند واحد اجرا می‌گردند.

بیشتر بخوانید: معرفی و نحوه عملکرد Kubernetes در vSphere به همراه بررسی مزایای این تکنولوژی

برای از انواع این Controller‌ها عبارت‌اند از:

• Node Controller: مسئول توجه و پاسخ در زمانی که Nodeها خاموش می‌شوند.
• Job Controller: منتظر Objectهای Hob می‌ماند که نشان‌دهنده‌ی Taskهای یک باری هستند، سپس Podهایی را ایجاد می‌کند تا آن Taskها را به‌طور کامل اجرا کنند.
• Endpoints Controller: استقرار داده را در Objectهای Endpoint انجام می‌دهد (یعنی Serviceها و Podها را ترکیب می‌کند).
• Controllerهای Service Account & Token: اکانت‌های پیش‌فرض و Tokenهای دسترسی API را برای Namespaceهای جدید می‌سازد.

cloud-controller-manager

یک جزء Kubernetes Control Plane که منطق کنترلی مختص به Cloud را کارگذاری می‌کند. Cloud  Controller Manager به افراد این امکان را می‌دهد که کلاستر خود به API ارائه‌دهنده‌ی Cloud خود مرتبط کنند و اجزایی که با آن پلتفرم Cloud تعامل می‌کنند را از اجزایی که فقط با کلاستر تعامل می‌کنند، جداسازی می‌کند.

cloud-controller-manager فقط Controllerهایی را اجرا می‌کند که مخصوص ارائه‌دهنده‌ی Cloud باشد. اگر کلاستر Kubernetes روی Premise خود فرد یا در یک محیط یادگیری درون PC او اجرا شود، کلاستر یک Cloud Controller Manager ندارد.

cloud-controller-manager نیز مثل kube-controller-manager چندین حلقه‌ی کنترلی که از لحاظ منطقی از هم مجزا هستند را درون یک باینری واحد ادغام می‌کند که به‌عنوان یک فرایند واحد اجرا گردد. می‌توان توسعه را به‌صورت افقی انجام داد، تا عملکرد بهبود پیدا کند یا خرابی‌ها تحمل گردد.

Controllerهای زیر می‌توانند وابستگی‌هایی به ارائه‌دهنده‌ی Cloud داشته باشند:

• Node Controller: برای چک کردن ارائه‌دهنده‌ی Cloud با هدف مشخص کردن اینکه آیا یک Node، پس‌ازاینکه دیگر پاسخ نداده است، در Cloud حذف شده است یا خیر
• Route Controller: برای تنظیم مسیرها در زیرساخت Cloud اساسی
• Service Controller: برای ایجاد، بروزرسانی و حذف کردن تعدیل‌‌کنندگان بار ارائه‌دهنده‌ی Cloud

اجزای Node

اجزای Node روی هر Node اجرا می‌شوند، Podهای در حال اجرا را حفظ می‌کنند و محیط اجرای Kubernetes را فراهم می‌کنند.

kubelet

یک Agent که روی هر Node در کلاستر اجرا می‌گردد. اطمینان حاصل می‌کند که Container در یک Pod اجرا شوند. kubelet مجموعه‌ای از PodSpecs را که از طریق مکانیسم‌های مختلفی ارائه می‌شوند برمی‌دارد و اطمینان حاصل می‌کند که Containerهایی که در آن PodSpecs توصیف شده‌اند در حال اجرا و سالم باشند. Kubelet  قرار نیست Containerهایی را که توسط Kubernetes ساخته نشده‌اند مدیریت کند.

kube-proxy

kube-proxy یک پراکسی شبکه است که روی هر Node در کلاستر اجرا می‌شود و بخشی از مفهوم سرویس Kubernetes را پیاده‌سازی می‌کند. kube-proxy قواعد شبکه را روی Nodeها حفظ می‌کند. این قواعد شبکه امکان ارتباط شبکه به Podها را از Sessionهای شبکه داخل یا خارج از کلاستر فراهم می‌کند.

kube-proxy از لایه Packet Filtering سیستم‌عامل استفاده می‌کند، البته درصورتی‌که موجود و قابل‌دسترس باشد. در غیر این صورت، kube-proxy خودِ ترافیک را Forward می‌نماید.

Container Runtime

Container Runtime نرم‌افزاری است که مسئول اجرای Containerها می‌باشد. Kubernetes از Container Runtimeهایی مثل Containerd، CRI-O و هر پیاده‌سازی از Kubernetes CRI (Container Runtime Interface) پشتیبانی می‌کند.

Addonها

Addonها از منابع Kubernetes یعنی DaemonSet، Deployment و غیره استفاده می‌کنند تا ویژگی‌های کلاستر را پیاده‌سازی کنند. ازآنجایی‌که این Addonها ویژگی‌هایی را در سطح کلاستر فراهم می‌کنند، منابع Namespaced برای Addonها به  kube-system Namespace تعلق دارد.

DNS

درحالی‌که Addonهای دیگر مؤکدا لازم نیستند، تمام کلاسترهای Kubernetes باید Cluster DNS داشته باشند، زیرا مثال‌های زیادی به آن بستگی دارد. Cluster DNS  یک DNS Server علاوه بر DNS Serverهای دیگر در محیط است که آمار DNS را برای خدمات Kubernetes ارائه می‌دهد. Containerهایی که به‌طور خودکار توسط Kubernetes شروع به کار می‌کنند شامل این DNS Server در جستجوهای DNS خود هستند.

Web UI (Dashboard)

Dashboard یک رابط کاربری مبتنی بر وب همه‌منظوره برای کلاسترهای Kubernetes است. این رابط کاربری به کاربران این امکان را می‌دهد که برنامه‌های کاربردی در حال اجرا در کلاستر و همچنین خود کلاستر را مدیریت و عیب‌یابی کنند.

Container Resource Monitoring

Container Resource Monitoring معیارهای سنجش سری زمانی کلی در مورد Containerها را در یک دیتابیس مرکزی ضبط می‌کند و یک رابط کاربری را برای مرور آن داده‌ها فراهم می‌نماید.

Logging در سطح کلاستر

یک مکانیسم Logging در سطح کلاستر مسئول ذخیره‌ی Logهای Container به یک Log Store مرکزی با رابط کاربری جستجو/مرورگر است.

مقاله های مرتبط: