کوبرنتیز (Kubernetes) چیست و چه ویژگی‌هایی دارد؟

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

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

تاریخچه کوبرنتیز

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

گوگل در اوت ۲۰۱۴ اولین نسخه کوبرنتیز را منتشر کرد و این نسخه با استقبال زیادی از سوی توسعه‌دهندگان مواجه شد.

در سال‌های ۲۰۱۶ تا ۲۰۱۸، با پیشرفت و به‌روزرسانی‌های مداوم، کوبرنتیز به سرعت به یکی از محبوب‌ترین ابزارهای ارکستراسیون کانتینر تبدیل شد و شرکت های بزرگی مانند IBM، Microsoft و AWS شروع به ادغام آن در سرویس‌های خود کردند.

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

معماری کوبرنتیز

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

کلاستر (Cluster) چیست؟

یک کلاستر از چندین سرور یا گره (Node) تشکیل شده است که این نودها شامل دو نوع می شوند :

1. Control Plane: این صفحه شامل اجزای مرکزی کوبرنتیز است که کلاستر را مدیریت و کنترل می‌کنند. این بخش شامل Controller Manager یا سرور کنترل‌کننده، Scheduler یا سرور زمانبندی کوبرنتیز، API Server یا سرور اصلی کوبرنتیز و سرور بانک اطلاعاتی etcd می‌باشد.
2. Worker Node : هر کلاستر معمولاً دارای یک یا چند گره است. این گره‌ها سرورهای فیزیکی یا مجازی هستند که برنامه‌های کاربردی در قالب پادها (Pods) روی آن‌ها اجرا می‌شوند. پادها کوچک‌ترین واحد اجرایی در کوبرنتیز هستند که شامل یک یا چند کانتینر می‌شوند.

• در ادامه مفصل‌تر به توضیح هر جز می‌پردازیم:
• Controller Manager یا سرور کنترل‌کننده : Controller Manager از طریق سرور API وضعیت مورد نظر و وضعیت فعلی اشیایی که در کلاستر مدیریت می‌کند را مشاهده می‌کند و اگر وضعیت مورد نظر و فعلی آن‌ها مطابقت نداشته باشند، اقدامات اصلاحی را انجام می‌دهد تا وضعیت اشیاء را به سمت وضعیت مطلوب هدایت کند.
•  API Server یا سرور اصلی کوبرنتیز : API Server بخش ابتدایی در Control Plane کوبرنتیز است. این سرور از به روزرسانی‌ها، مقیاس‌بندی‌ها و دیگر عملیات‌های مربوط به مدیریت چرخه حیات منابع کلاستر مطلع است و نقش رابط ارتباطی تمام زیرسرویس‌ها را دارد. این بخش به عنوان دروازه عمل می‌کند و کلاینت‌ها می‌توانند از خارج کلاستر از طریق آن به منابع کلاستر دسترسی پیدا کنند و همچنین با کمک همین بخش برای دسترسی به منابع مورد نیاز در کلاستر احراز هویت می‌شوند. کلاینت‌ها از API Server به عنوان تونلی برای ارتباط با نودها، سرویس‌ها و پادها استفاده می‌کنند.
•  Scheduler یا سرور زمانبندی کوبرنتیز : این بخش وظیفه دارد تا میزان استفاده از منابع را برای هر گره محاسبه کند و تصمیم بگیرد که آیا پادهای جدید باید مستقر شوند یا خیر؟ و اگر نیاز به استقرار پاد جدید بود، کدام گره برای استقرار آن‌ها مناسب‌تر می‌باشد. به صورت کلی این بخش کمک می‌کند تا منابع به شکل بهینه مصرف شده و برنامه‌ها با کیفیت مطلوب اجرا شوند.
•  سرور بانک اطلاعاتی ETDC : ETCD یک پایگاه داده با کارایی بالا و مقیاس‌پذیر است. داده‌ها در این پایگاه داده به صورت key-value ذخیره می‌شوند. این داده‌ها مربوط به پیکربندی و اطلاعات مربوط به وضعیت کلاستر می‌باشد. این پایگاه داده در کوبرنتیز نقش حیاتی ایفا می‌کند زیرا تمامی اجزا و مولفه‌های کلاستر برای عملکرد صحیح و همگام‌سازی اطلاعات به داده‌های ذخیره شده در ETCD متکی هستند.
• Nodes :  یک کلاستر کوبرنتیز باید حداقل یک نود محاسباتی داشته باشد. پادها، هماهنگ و برنامه‌ریزی می‌شوند تا بر روی نودها اجرا شوند. نودها کارهای یک کلاستر کوبرنتیز مانند اتصال برنامه‌ها و شبکه، منابع محاسباتی و ذخیره‌سازی به یکدیگر را انجام می‌دهند. نودها می‌توانند ماشین‌های مجازی یا سرورهای فیزیکی باشند. 
• CRI : CRI یک واسط استاندارد است که به کوبرنتیز این امکان را می‌دهد تا با انواع مختلف runtime های کانتینر تعامل داشته باشد. این واسط به طور خاص برای جدا کردن اجزای مربوط به اجزای کانتینر از سایر بخش‌های کوبرنتیز طراحی شده است.
• Kubelet : هر نود محاسباتی شامل یک Kubelet است. Kubelet عاملی است که با control plane ارتباط برقرار می‌کند و بر اساس دستورات آن، پادها را اجرا و نظارت می‌کند تا اطمینان حاصل شود که در وضعیت مطلوب قرار دارند. 
• Kube-proxy : هر نود محاسباتی دارای یک Kube-proxy است که مسئول تسهیل خدمات شبکه در کوبرنتیز است. این پروکسی می‌تواند ترافیک را مستقیماً ارسال کند یا از قابلیت‌های لایه فیلتر سیستم‌عامل برای مدیریت ارتباطات شبکه در داخل و خارج کلاستر استفاده کند. این پروکسی بر روی هر نود اجرا می‌شود تا اطمینان حاصل شود که سرویس‌ها برای منابع خارجی در دسترس هستند و با زیرشبکه میزبان جداگانه در ارتباط است.
• Pods : پادها در کوبرنتیز اهمیت زیادی دارند زیرا ساختاری هستند که توسعه دهندگان مستقیم با آن‌ها تعامل دارند. پادها کوچک‌ترین و ساده‌ترین واحد قابل استقرار در کوبرنتیز هستند و نشان‌دهنده یک یا چند کانتینر می‌باشند که منابع‌ و شبکه‌ای مشترک دارند. پادها واحد اصلی مدیریت در اکوسیستم کوبرنتیز می‌باشند و به عنوان مرز منطقی برای کانتینرهایی عمل می‌کنند که منابع و زمینه را به اشتراک می‌گذارند. 

ویژگی‌های Kubernetes

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

• مقیاس پذیری خودکار (Auto-Scaling) : کوبرنتیز می‌تواند تعداد پادها را بر اساس نیاز‌های بار کاری افزایش یا کاهش دهد. این ویژگی تضمین می‌کند که اپلیکیشن‌ها همیشه با منابع کافی اجرا شوند.
• تعادل بار (Load Balancing) : کوبرنتیز ترافیک ورودی را بین پادهای مختلف توزیع می‌کند تا بار کاری به صورت یکنواخت بین آن‌ها پخش شود. 
• انعطاف پذیری و تحمل خطا (Self-healing) : کوبرنتیز به‌طور خودکار پادهایی که دچار خطا یا خرابی شده‌اند را بازسازی می‌کند و همچنین نودهایی که از دسترس خارج شده‌اند را از چرخه خارج می‌کند و بار را به نود‌های سالم منتقل می‌کند.
• Rollout : این ویژگی این امکان را می‌دهد تا به صورت تدریجی و کنترل شده، افراد بتوانند نسخه‌های جدید اپلیکیشن‌های خود را منتشر کنند و در صورت بروز مشکل، به سرعت به نسخه قبلی بازگردند.
• ذخیره‌سازی دائمی (Persistent Storage) : این ویژگی برای اپلیکیشن‌هایی که نیاز به نگهداری داده‌های طولانی مدت دارند، بسیار ضروری است و فضایی را برای ذخیره‌سازی داده‌ها فراهم می‌کند که پس از خاموش شدن یا جابه‌جایی پادها از بین نروند.
• Deployment : Deployment به‌صورت کلی برای مدیریت چرخه حیات اپلیکیشن‌ها استفاده می‌شود و یک شی در کوبرنتیز است که به افراد اجازه می‌دهد تا استقرار، به روزرسانی، مقیاس گذاری و مدیریت پادها را انجام دهند.
• پشتیبانی از Hybrid and Multi-cloud Support‌ : این ویژگی یکی از ویژگی‌های مهم کوبرنتیز است که به توسعه‌دهندگان این امکان را می‌دهد تا برنامه‌ها و سرویس‌های خود را در محیط‌های مختلف به صورت یکپارچه اجرا و مدیریت کنند.

داکر و کوبرنتیز چه تفاوتی دارند؟

داکر ابزاری به منظور ساخت imageهای برنامه‌‌های کاربردی و اجرای آنها به صورت container است. این ابزار در واقع یک Container Runtime است که برخی امکانات مانند ساخت image، مدیریت استقرار و ... را به صورت محدود دارد. این ابزار به صورت محدود امکان مدیریت استقرار containerها در یک کلاستر کوچک را با استفاده از ویژگی Docker Swarm  می‌دهد. اما در کلاستر‌های بزرگ کارایی چندانی ندارد. کوبرنتیز ابزاری است که با آن می‌توان در کلاستر‌های مقیاس کوچک تا بزرگ به منظور استقرار Containerها بهره‌برداری کرد. در واقع کوبرنتیز به منظور اجرای Containerها از یک Container Runtime مانند داکر یا Containerd استفاده می‌کند. کوبرنتیز دارای ویژگی‌هایی مانند service, Ingress, Secret,  load balancing و ... است و با امکاناتی مانند پادها، استقرار، مقیاس‌پذیری، توزیع پذیری و ... را برای بهره‌برداران به ارمغان می‌آورد.

مانیتورینگ Kubernetes

پلتفرم مانیتورینگ معین قابلیت مانیتورینگ سلامت کلاستر و گره‌­های تشکیل‌دهنده آن، پادها، Namespaceها و Deploymentها را در کوبرنتیز (Kubernetes) دارد. برای مشاهده لیست شاخص‌های قابل مانیتورینگ کوبرنتیز در پلتفرم معین اینجا کلیک کنید.