مفهوم‌ها

• 1: نمای کلی
• 1.1: اجزای کوبرنتیز
• 2: معماری کلاستر
• 3: Configuration

1 - نمای کلی

این صفحه یک نمای کلی از کوبرنتیز است.

نام کوبرنتیز از ریشه یونانی٬ به معنی خلبان یا ناخدا است. K8s به عنوان مخفف حاصل شمارش ۸ حرف بین "K" و "s" ابتدا و انتهای Kubernetes است. گوگل پروژه کوبرنتیز را در سال ۲۰۱۴ متن باز کرد. کوبرنتیز حاصل بیش از ۱۵ سال تجربه گوگل در اجرای بارکاری محصولات در مقیاس بالا با ایده‌ها و عملکردهای بهترین-در-نوع-خود در جامعه است.

چرا به کوبرنتیز نیاز دارید و چه‌کاری انجام می‌دهد؟

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

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

کوبرنتیز موارد زیر را برای شما فراهم می کند:

• پایش سرویس و توزیع بار کوبرنتیز می‌تواند یک کانتینر را با استفاده از نام DNS یا استفاده از آدرس IP خودش نمایان کند. اگر ترافیک یک کانتیر زیاد است٬ کوبرنتیز قادر است ترافیک را توزیع و متعادل کند تا استقرار پایدار باشد.
• ارکستراسیون فضای ذخیره سازی کوبرنتیز به شما امکان می‌دهد تا به صورت خودکار فضای ذخیره سازی دلخواه٬ از جمله فضای داخلی٬ سرویس‌دهنده ابری و ... را متصل کنید.
• رونمایی و عقبگرد خودکار شما می‌توانید با استفاده از Kubernetes وضعیت مطلوب را برای کانتینرهای مستقر شده خود توصیف کنید و Kubernetes می‌تواند وضعیت واقعی را با سرعت کنترل شده به وضعیت مطلوب تغییر دهد. برای مثال٬ می‌توانید کوبرنتیز را خودکار کنید تا کانتینر های جدیدی برای استقرار شما ایجاد کند٬ کانتینر های موجود را حذف کند و تمام منابع آن‌ها را به کانتینر های جدید اختصاص دهد.
• bin packing خودکار شما به کوبرنتیز٬ کلاستری از نود ها را می‌دهید که می‌تواند برای انجام وظایف کانتینری شده از آن استفاده کند. شما میتوانید به کوبرنتیز بگویید چه میزان رم و CPU برای هر کانتینر نیاز است. کوبرنتیز می‌تواند کانتینر ها را برای بهترین مصرف منابع در نود های شما سامان‌دهی کند.
• خود درمانی کوبرنتیز کانتینر های خطا خورده را ری-استارت می کند٬ کانتینر ها را جایگزین می کند٬ کانتینر هایی که به بررسی سلامت تعریف شده توسط کاربر پاسخ نمی‌دهند از بین می‌برد٬ و آن‌ها را تا زمانی که آماده خدمات‌دهی نباشند٬ ارایه نمی‌کند.
• مدیریت Secret و پیکربندی کوبرنتیز به شما امکان می دهد اطلاعات حساس مانند رمزعبور٬ توکن های احراز هویت و کلید های SSH را ذخیره سازی و مدیریت کنید. شما می‌توانید Secret ها و پیکربندی برنامه را بدون بازسازی image آن و بدون افشای Secret در بسته های پیکربندی٬ مستقر و بروزرسانی کنید.
• اجرای دسته‌ای علاوه بر سرویس٬ کوبرنتیز قادر است تا در صورت تمایل بارکاری دسته‌ای و CI شما را مدیریت و کانتینرهای خطا دار را جایگزین کند.
• مقیاس بندی افقی مقیاس برنامه خودرا با یک دستور ساده٬ از طریق رابط کاربری٬ یا به صورت خودکار بر اساس مصرف CPU بالا و پایین ببرید.
• IPv4/IPv6 dual-stack اختصاص دادن آدرس IPv4 و IPv6 به پاد ها و سرویس ها.
• طراحی شده برای توسعه‌پذیری بدون نیاز به تغییر کد منبع٬ قابلیت های دلخواه خودرا به کلاستر کوبرنتیز اضافه کنید.

کوبرنتیز چی نیست

کوبرنتیز یک سیستم PaaS (Platform as a Service) سنتی شامل-همه-چیز نیست. از آن‌جایی که کوبرنتیز در سطح کانتینر و نه در سطح سخت‌افزار کار می کند٬ برخی ویژگی های عمومی و رایج در ارائه دهندگان PaaS مانند استقرار٬ مقیاس‌بندی٬ توزیع بار ارائه می‌دهد و کابران را قادر می‌سازد تا ثبت وقایع٬ مانیتورینگ و راهکار های هشداردهی را ادغام کنند. با این‌حال٬ کوبرنتیز یکپارچه نیست و این راه‌کار های پیش‌فرض اختیاری و قابل اتصال هستند. کوبرنتیز بلوک های سازنده برای ساخت پلتفرم های توسعه‌دهندگان را فراهم می کند٬ اما در مواردی که مهم است٬ انتخاب و راحتی کاربر را حفظ می کند.

کوبرنتیز:

• انواع اپلیکیشن های پشتیبانی شده را محدود نمی‌کند. کوبرنتیز قصد دار تا از انواع بسیار متنوعی از بارهای کاری٬ از جمله باوضعیت (statefull)٬ بدون وضعیت(stateless)٬ و پردازش داده٬ پشتیبانی کند. اگر برنامه ای روی کانتینر اجرا شده٬ باید به خوبی روی کوبرنتیز اجرا شود.
• کد های منبع را مستقر نمی‌کند و برنامه شما را نمی‌سازد. فرآیند ادغام٬ همرسانی و استقرار مستمر (continous Itegration, Delivery, Deployment) توسط فرهنگ و ترجیحات سازمانی و همچنین نیازمندی های فنی تعیین می‌شود.
• خدمات سطح اپلیکیشن از جمله میان-افزار (برای مثال٬ گذرگاه پیام)٬ فریم ورک پردازش داده(برای مثال٬ Spark)٬ پایگاه داده (برای مثال٬ MySQL)٬ کش ها و نه حتی فضای ذخیره سازی کلاستری (برای مثال٬ Ceph) را به عنوان سرویس درونی ندارد. چنین اجزایی می‌توانند روی کوبرنتیز اجرا شوند٬ و/یا می توانند توسط برنامه های اجرا شده روی کوبرنتیز از طریق مکانیزم های قابل حمل مانند Open Service Broker مورد استفاده باشند.
• راهکارهای ثبت وقایع٬ مانیتورینگ و هشدار را اجبار نمی‌کند. برخی یکپارچه سازی ها را برای نمایش مفهوم٬ و مکانیزم های دریافت متریک را ارایه می کند.
• ه یک زبان یا سیستم پیکربندی (مانند Jsonnet) ارائه می‌دهد و نه استفاده از آن را الزامی می‌کند. در عوض، یک API اعلامی (Declarative API) فراهم می‌کند که می‌تواند توسط هر نوع مشخصات اعلامی مورد استفاده قرار گیرد.
• هیچ سیستم پیکربندی٬ نگهداری٬ مدیریت یا خوددرسمانی را ارائه یا اتخاذ نمی‌کند.
• به علاوه٬ کوبرنتیز تنها یک سیستم ارکستراسیون نیست. در واقع٬ نیاز به ارکستراسیون را از بین می‌برد. تعریف فنی ارکستراسیون٬ اجرای یک جریان کاری تعریف شده است: اول الف را انجام بده٬ آنگاه ب آنگاه ث. در مقابل٬ کوبرنتیز شامل تعدادی . In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn't matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.

گذشته تاریخی کوبرنتیز

بیایید نگاهی به گذشته بندازیم تا ببینیم چرا کوبرنتیز مفید است.

دوره توسعه سنتی:

در اوایل٬ سازمان ها برنامه ها را روی سرور های فیزیکی اجرا می کردند. هیچ‌راهی برای تعریف مرز های منابع برنامه ها روی سرور فیریکی وجود نداشت و این موضوع٬ باعث مشکلاتی در تخصیص منابع می‌شد. برای مثال، اگر چندین برنامه روی یک سرور فیزیکی اجرا شوند، ممکن است مواردی وجود داشته باشد که یک برنامه بیشتر منابع را اشغال کند و در نتیجه، برنامه‌های دیگر عملکرد ضعیفی داشته باشند. یک راه حل٬ اجرای هر برنامه روی یک سرور فیزیکی مجزا است. اما این امر به دلیل کم‌بود منابع مقیاس‌پذیر نبود و برای سازمان ها نگهداری سرور های فیزیکی متعدد پرهزینه است.

دوره توسعه مجازی سازی شده:

به عنوان یک راهکار٬ مجازی سازی معرفی شد. مجازی سازی به شما امکان می‌دهد چندین ماشین مجازی (VM) را روی CPU یک سرور فیزیکی اجرا کنید. مجازی‌سازی امکان جداسازی برنامه‌ها بین ماشین‌های مجازی را فراهم می‌کند و سطحی از امنیت را فراهم می‌کند، زیرا اطلاعات یک برنامه نمی‌تواند آزادانه توسط برنامه دیگری قابل دسترسی باشد.

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

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

دوره توسعه کانتینری:

کانتینرها مشابه ماشین‌های مجازی هستند، اما ویژگی‌های ایزوله‌سازی ساده‌تری دارند تا بتوانند سیستم عامل (OS) را بین برنامه‌ها به اشتراک بگذارند. بدین‌ترتیب٬ کانتینر ها سبک تلقی می‌شوند. مشابه یک ماشین مجازی، یک کانتینر سیستم فایل، سهم CPU، حافظه، فضای پردازش و موارد دیگر مخصوص به خود را دارد. از آنجایی که آنها از زیرساخت اصلی جدا شده‌اند، می‌توانند در میان ابرها و توزیع‌های سیستم عامل قابل حمل باشند.

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

• ایجاد و استقرار چابک برنامه‌ها: افزایش سهولت و کارایی ایجاد ایمیج کانتینر در مقایسه با استفاده از تصویر ماشین مجازی.
• توسعه، ادغام و استقرار مداوم: امکان ساخت و استقرار مداوم و قابل اعتماد ایمیج کانتینر را با بازگشت‌های سریع و کارآمد (به دلیل تغییرناپذیری تصویر) فراهم می‌کند.
• جداسازی دغدغه‌های توسعه و عملیات: ایجاد ایمیج کانتینر برنامه در زمان ساخت/انتشار به جای زمان استقرار، و در نتیجه جداسازی برنامه‌ها از زیرساخت.
• قابلیت مشاهده: نه تنها اطلاعات و معیارهای سطح سیستم عامل را نشان می‌دهد، بلکه سلامت برنامه و سایر سیگنال‌ها را نیز پوشش می‌دهد.
• سازگاری محیطی در طول توسعه، آزمایش و تولید: همانطور که در فضای ابری اجرا می‌شود، روی لپ‌تاپ نیز به همان شکل اجرا می‌شود.
• قابلیت حمل توزیع ابری و سیستم عامل: روی اوبونتو، RHEL، CoreOS، در محل، روی ابرهای عمومی بزرگ و هر جای دیگر اجرا می‌شود.
• مدیریت برنامه محور: سطح دیدگاه را از اجرای یک سیستم عامل روی سخت افزار مجازی به اجرای یک برنامه روی یک سیستم عامل با استفاده از منابع منطقی ارتقا می‌دهد.
• میکروسرویس‌های آزاد، توزیع‌شده، الاستیک و با اتصال سست: برنامه‌ها به قطعات کوچک‌تر و مستقل تقسیم می‌شوند و می‌توانند به صورت پویا مستقر و مدیریت شوند - نه یک پشته یکپارچه که روی یک ماشین بزرگ تک منظوره اجرا می‌شود.
• جداسازی منابع: عملکرد قابل پیش‌بینی برنامه.
• استفاده از منابع: راندمان و تراکم بالا.

• نگاهی بر اجزای کوبرنتیز
• نگاهی بر API کوبرنتیز
• نگاهی بر ساختار کلاستر
• آماده شروع؟

1.1 - اجزای کوبرنتیز

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

اجزای اصلی

یک کلاستر کوبرنتیز از یک کنترل‌گر (control plane) و یک یا چند نود کارگر (worker node) تشکیل شده است. نمای کلی مختصری از اجزای اصلی:

اجزای Control Plane

مدیریت وضعیت کلی کلاستر:

kube-apiserver

جز اصلی سرور که API HTTP کوبرنتیز را در معرض نمایش قرار می‌دهد.

etcd

ذخیره‌ساز کلید-مقدار سازگار و با دسترسی بالا برای تمام داده‌های سرور API.

kube-scheduler

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

kube-controller-manager

controllers را برای اجرای رفتار های API کوبرنتیز اجرا می‌کند.

cloud-controller-manager (اختیاری)

با ارائه‌دهنده(های) ابریِ زیربنایی ادغام می‌شود.

اجزای Node

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

kubelet

مطمئن می‌شود پاد ها و کانتینرهای آن‌ها اجرا می‌شوند.

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

قوانین شبکه را روی نودها برای پیاده‌سازی . سرویس‌ها حفظ می‌کند.

Container runtime

نرم افزار مسئول اجرای کانتینر. برای اطلاعات بیش‌تر٬ Container Runtimes را بخوانید.

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

افزونه ها

افزونه‌ها عملکرد کوبرنتیز را بهبود می‌دهند. چند نمونه مهم شامل:

DNS

برای تبدیل‌های DNS در سطح کلاستر.

Web UI (Dashboard)

برای مدیریت کلاستر با رابط کاربری وب.

Container Resource Monitoring

برای دریافت و ذخیره متریک های کانتینر.

Cluster-level Logging

برای ذخیره لاگ‌های کانتینر در یک ذخیره ساز مرکزی.

انعطاف در معماری

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

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

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

یک کلاستر کوبرنتیز از یک کنترل‌گر (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.

3 - Configuration