معماری کلاستر

یک کلاستر کوبرنتیز از یک کنترل‌گر (control plane) به علاوه تعدادی ماشین کارگر که نود نامیده می‌شوند تشکیل شده است که اپلیکیشن های کانتینری شده را اجرا می‌کند. هر کلاستر حداقل به یک نود کارگر برای اجرای پادها نیاز دارد.

نود(های) کارگر پادها را میزبانی می‌کنند که اجزای بار کاری اپلیکیشن هستند. کنترل‌گر نودهای کارگر و پادهای داخل کلاستر را مدیریت می‌کند. در محیط‌های عملیاتی٬ کنترل پلین در چند کامپیوتر اجرا می‌شود و یک کلاستر تعداد زیادی نود را برای تحمل خطا و ایجاد دسترسی پذیری اجرا می‌کند.

این مستند اجزای مختلفی که برای یک کلاستر کامل و مشغول به کار نیاز دارید را تشریح می‌کند.

درباره این ساختار

دیاگرام داخل تصویر ۱٬ یک نمونه از کلاستر کوبرنتیز را نمایش می‌دهد. توزیع اصلی اجزا می‌تواند بر اساس تنظیمات مشخص شده و نیازمندی‌های کلاستر متفاوت باشد.

در دیاگرام٬ هر نود یک kube-proxy اجرا می‌کند. شما به یک پروکسی شبکه بر روی هر نود نیاز دارید تا مطمئن شوید API سرویس و رفتار های مرتبط در شبکه کلاستر شما در دسترس است. اگرچه٬ برخی پلاگین ها پروکسی شبکه شخص ثالث خودرا مستقر می‌کنند. وقتی از این نوع پلاگین های شبکه استفاده کنید٬ نیازی به اجرای kube-proxy نیست.

اجزای کنترل‌پلین (کنترل‌گر)

اجزای کنترل‌پلین٬ تصمیمات سراسری در مورد خوشه (مثلاً زمان‌بندی) و همچنین تشخیص و پاسخ به رویدادهای خوشه (مثلاً راه‌اندازی یک پاد جدید در زمانی که فیلد replica یک Deployment رضایت‌بخش نیست) می‌گیرند.

اجزای کنترل‌پلین٬ می‌تواند بر روی هر سیستمی در کلاستر اجرا شود. اگرچه٬ برای سهولت٬ اسکریپت‌های نصب به شکل عادی تمامی اجزای کنترل‌پلین را روی یک سیستم اجرا می‌کنند و کانتینرهای کاربر را روی این سیستم اجرا نمی‌کنند. برای مثال یک کنترل‌پلین نصب شده بین چندین سیستم٬ ساخت کلاسترهای دسترسی‌پذیر بالا با kubeadm را ببینید.

kube-apiserver

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

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

etcd

یک مخزن کلید-مقدارِ سازگار و با دسترسی بالا که به عنوان مخزن پشتیبان کوبرنتیز برای تمام داده‌های خوشه‌ای استفاده می‌شود.

اگر cluster کوبرنتیز شما از etcd به عنوان حافظه پشتیبان خود استفاده می‌کند، مطمئن شوید که یک طرح پشتیبان‌گیری (/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) برای داده‌ها دارید.

شما می‌توانید اطلاعات عمیق‌تری در مورد etcd را در مستندات رسمی بیابید.

kube-scheduler

جزء کنترل پلین که پادهای تازه‌ساخته‌شده‌ی بدون گره اختصاص شده را رصد می‌کند و یک گره را برای اجرای آن‌ها اتخاب می‌کند.

عواملی که در تصمیم‌های scheduling در نظر گرفته می‌شوند شامل این‌ها هستند: نیازهای منابع به‌صورت فردی و جمعی، محدودیت‌های سخت‌افزاری/نرم‌افزاری/سیاستی، مشخصات Affinity (وابستگی) و Anti-Affinity (ضدوابستگی)، محلی‌بودن داده، تداخل بین ورک‌لودها، و ضرب‌الاجل‌ها.

kube-controller-manager

جزء کنترل پلین که فرایندهای کنترلر را اجرا می‌کند.

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

انواع مختلفی از کنترلر وجود دارد. برخی مثال ها از قبیل:

• Node controller: مسئول اطلاع رسانی و پاسخگویی هنگامی که نود دان می‌شود (از دست می‌رود).
• Job controller: اشیاء Job را که نمایانگر وظایف یک‌باره هستند، زیر نظر می‌گیرد، سپس پادهایی ایجاد می‌کند تا آن وظایف را تا زمان تکمیل اجرا کند.
• EndpointSlice controller: اشیا EndpointSlice را پر می‌کند (برای ارتباط بین سرویس و پاد).
• ServiceAccount controller: یک ServiceAccounts پیش‌فرض برای namespace جدید می‌سازد.

لیست بالا از جامعیت برخوردار نیست.

cloud-controller-manager

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

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

همانند kube-controller-manager، cloud-controller-manager چندین حلقه کنترلی منطقاً مستقل را در یک فایل باینری واحد ترکیب می‌کند که شما آن را به عنوان یک فرآیند واحد اجرا می‌کنید. می‌توانید برای بهبود عملکرد یا کمک به تحمل خرابی‌ها، آن را به صورت افقی (بیش از یک کپی) مقیاس‌بندی کنید.

کنترلر های زیر می‌توانند پیش‌نیاز های ارایه دهنده ابری را داشته باشند:

• Node controller: برای بررسی ارائه دهنده ابر برای تعیین اینکه آیا یک گره پس از توقف پاسخگویی در ابر حذف شده است یا خیر
• Route controller: برای تنظیم مسیرها در زیربنای ساختار ابری
• Service controller: برای ساخت٬ بروزرسانی و حذف توزیع‌بارهای ارایه دهنده ابری

---

اجزای نود

روی هر نود اجرا می‌شود، پادهای در حال اجرا را حفظ می‌کند و محیط اجرایی کوبرنتیز را فراهم می‌کند.

kubelet

عاملی که روی هر گره در کلاستر اجرا می‌شود. این عامل اطمینان می‌دهد کانتینرها در یک پاد در حال اجرا باشند.

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

kube-proxy (اختیاری)

kube-proxy یک پروکسی شبکه است که روی هر گره (node) در کلاستر شما اجرا می‌شود و بخشی از مفهوم سرویس (Service) در کوبرنتیز را پیاده‌سازی می‌کند.

kube-proxy قوانین شبکه را روی گره‌ها نگه‌داری می‌کند. این قوانین شبکه به نشست‌های شبکه‌ی داخل یا خارج کلاستر اجازه می‌دهند با پادهای شما ارتباط شبکه‌ای برقرار کنند.

اگر لایه‌ی فیلترکردن بسته در سیستم‌عامل وجود داشته و در دسترس باشد، kube-proxy از آن استفاده می‌کند؛ در غیر این صورت، خود kube-proxy ترافیک را فوروارد می‌کند.

اگر از پلاگین شبکه‌ای استفاده می‌کنید که به خودی خود ارسال بسته را برای سرویس‌ها پیاده‌سازی می‌کند و رفتاری معادل kube-proxy ارائه می‌دهد، نیازی به اجرای kube-proxy روی نودهای کلاستر خود ندارید.

اگر از سرویسی استفاده می‌کنید که خودش ارسال بسته را برای سرویس‌ها پیاده‌سازی می‌کند و رفتاری معادل kube-proxy ارائه می‌دهد، نیازی به اجرای kube-proxy روی نودهای کلاستر خود ندارید.

Container runtime

یک جزء اساسی که کوبرنتیز را قادر می‌سازد تا کانتینرها را به طور مؤثر اجرا کند. این بخش مسئول مدیریت اجرا و چرخه حیات کانتینرها در محیط کوبرنتیز است.

کوبرنتیز از container runtimeهایی نظیر containerd٬ CRI-O٬ و دیگر Kubernetes CRI (Container Runtime Interface)ها پشتیبانی می‌کند.

افزونه‌ها

افزونه‌ها از منابع کوبرنتیز(DaemonSet, Deployment, و غیره) برای پیاده سازی ویژگی‌های کلاستر استفاده می‌کنند. از آنجا که اینها ویژگی‌های سطح کلاستر را ارائه می‌دهند، منابع namesapceی برای افزونه‌ها درnamespace kube-system قرار دارند.

افزونه‌های انتخاب شده در زیر توضبح داده شده اند. برای مشاهده لیست کامل‌تری از آن‌ها به صفحه افزونه‌ها مراجعه کنید.

DNS

درحالی که دیگر افزونه‌ها به طور قطعی مورد نیاز نیستند٬ تمامی کلاسترهای کوبرنتیز باید DNS کلاستر داشته باشند٬ چون خیلی مثال‌ها به آن وابسته است.

DNS کلاستر در کنار DNS سرور(های) دیگر محیط شما است که رکوردهای DNS را برای سرویس‌های کوبرنتیز ارائه می‌کند.

کانتینترهای اجرا شده توسط کوبرنتیز به شکل خودکار این DNS سرور را در جستجوی DNS خود قرار می‌دهند.

رابط کاربری وب (Dashboard)

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

Container resource monitoring

Container Resource Monitoring متریک‌های سری زمانی (time-series) عمومی در مورد کانتینرها را در یک دیتابیس مرکزی ثبت می‌کند و یک رابط کاربری برای مرور آن داده‌ها ارائه می‌دهد.

Cluster-level Logging

یک مکانیزم cluster-level logging مسئول ذخیره لاگ‌های کانتینر در یک ذخیره‌ساز مرکزی لاگ با رابط برای مرور و جستجو است.

پلاگین‌های شبکه

افزونه‌های شبکه٬ اجزای نرم‌افزاری هستند که مشخصات رابط شبکه کانتینر (CNI) را پیاده‌سازی می‌کنند. آن‌ها مسئول تخصیص آدرس‌های IP به پادها و فعال کردن آن‌ها برای برقراری ارتباط با یکدیگر در داخل خوشه هستند.

تفاوت‌های معماری

با وجود ثابت بودن اجزای اصلی کوبرنتیز٬ نحوه پیاده سازی و مدیریت می‌تواند متغیر باشد. دانستن این متغیرها برای طراحی و نگهداری کلاسترهای کوبرنتیزی که نیاز های عملیاتی را برآورده می‌کنند٬ حیاتی است.

گزینه های پیاده‌سازی کنترل‌پلین

اجزای کنترل‌پلین می‌توانند به چند روش پیاده‌سازی شوند:

پیاده‌سازی سنتی

اجزای کنترل‌پلین می‌توانند مستقیما بر روی سیستم مستقل یا ماشین مجازی اجرا شوند٬ عموما به عنوان سرویس systemd مدیریت می‌شوند.

پادهای ایستا

اجزای کنترل‌پلین پیاده‌سازی شده به عنوان پادهای ایستا٬ توسط Kubelet بر روی نودهای مشخص شده مدیریت می‌شوند. این یک راه مرسوم است که توسط ابزارهایی مثل kubeadm استفاده می‌شوند.

میزبانی شخصی

کنترل‌پلین به عنوان پاد در داخل کلاستر کوبرنتیز اجرا می‌شود و توسط Deployments و StatefulSet یا سایر اجزای اولیه کوبرنتیز مدیریت می‌شود.

سرویس کوبرنتیز مدیریت شده

ارائه‌دهندگان خدمات ابری اغلب کنترل‌پلین را حذف می‌کنند و اجزای آن را به عنوان بخشی از خدمات خود مدیریت می‌کنند.

ملاحظات مربوط به حجم کار در محل کار

قرارگیری بارهای کاری، از جمله اجزای کنترل‌پلین٬ می‌تواند بر اساس اندازه کلاستر الزامات عملکرد و سیاست‌های عملیاتی متفاوت باشد:

• در کلاسترهای کوچک‌تر یا توسعه‌دهندگی٬ اجزای کنترل‌پلین و حجم کار کاربر می‌تواند در یک نود قرار گیرد.
• محیط‌های عملیاتی بزرگ‌تر معمولا نود خاصی را به کنترل‌پلین اختصاص می‌دهند و آن را از حجم کار کاربر جدا می‌کنند.
• برخی سازمان‌ها افزونه‌های حیاتی و یا ابزارهای مانیتورینگ را بر روی نود کنترل‌پلین اجرا می‌کنند.

ابزار‌های مدیریت کلاستر

ابزارهایی مانند kubeadm٬ kops٬ و Kubespray راهکار های مختلفی را برای استقرار و مدیریت کلاستر را٬ با روش‌های خاص خود در چیدمان و مدیریت اجزا را ارائه می‌دهند.

انعطاف‌پذیری معماری کوبرنتیز به سازمان‌ها اجازه می‌دهد تا کلاسترهای خود را متناسب با نیازهای خاص تنظیم کنند و عواملی مانند پیچیدگی عملیاتی، عملکرد و سربار مدیریتی را متعادل سازند.

شخصی‌سازی و توسعه‌پذیری

معماری کوبرنتیز امکان شخصی‌سازی قابل توجهی را فراهم می‌کند:

• Schedulerهای شخصی می‌تواند در کنار scheduler پیش‌فرض کوبرنتیز و یا کاملا بجای آن مستقر شود.
• سرورهای API را می‌توان با CustomResourceDefinitions و API Aggregation گسترش داد.
• ارائه دهندگان ابر می‌توانند با استفاده از cloud-controller-manager عمیقاً با کوبرنتیز ادغام شوند.

انعطاف‌پذیری معماری کوبرنتیز به سازمان‌ها اجازه می‌دهد تا کلاسترهای خود را متناسب با نیازهای خاص تنظیم کنند و عواملی مانند پیچیدگی عملیاتی، عملکرد و سربار مدیریتی را متعادل سازند.

گام‌های بعدی

درباره این‌ها بیش‌تر یادبگیرید:

• نودها و ارتباط آن‌ها با کنترل‌پلین.
• کنترلرهای کوبرنتیز.
• kube-scheduler که Scheduler پیش‌فرض کوبرنتیز است.
• مستندات رسمی etcd.
• چند container runtime در کوبرنتیز.
• ادغام با ارائه‌دهندگان سرویس‌ابری با cloud-controller-manager.
• فرمان‌های kubectl.