وقتی بحث از مجازی‌سازی می‌کنیم، می‌دانیم که سخت‌افزار اصلی آن شامل Storage محاسباتی و شبکه‌سازی میباشد. این همان فرآیندی است که در فضای Public Cloud و حتی بارهای کاری مبتنی بر SaaS مانند Microsoft 365 مشاهده می‌کنیم. Kubernetes هم تفاوتی ندارد، چراکه می‌توانیم کلاسترهای Kubernetes را به شکل‌های بسیار مختلفی اجرا کنیم. Bare Metal، استفاده از ماشین‌های مجازی یا VMها یا بهره‌وری از یک سرویس مدیریت‌شده Kubernetes مثل Amazon AKS از نمونه‌های آن است.
تنظیم کانتینر با Kubernetes
اگر به Kubernetes به‌عنوان موتور تنظیم Container نگاه کنیم میتوان گفت Kubernetes تنها موتور موجود تنظیم Container نیست و موتورهای دیگری همچون Docker Swarm و Hashicorp Nomad نیز هستند. با این حال، وقتی صحبت از تنظیم Container می‌شود، Kubernetes در صدر لیست قرار می‌گیرد.
مقایسه Kubernetes و vSphere در VM Orchestration
وقتی به مجازی‌سازی و خصوصاً به vSphere نگاه می‌کنیم، مرکز مجازی‌ای را می‌بینیم که میتوان آن را به تنظیم‌کننده VM تشبیه کرد. این کار کمک می‌کند ماشین‌های مجازی‌مان را در تمام Hostهای مجازی‌سازی ESXi خود هم‌تراز کنیم، زیرا اگر یکی از این Hostها از کار بیفتد یا خراب شود، ماشین‌های مجازی‌ای که روی آن قرار دارند بدون آن که برای خودشان یا برنامه کاربردی‌ای که بر آن‌ها اجرا می‌شود، Downtime ایجاد شود، به Host دیگری منتقل می‌شوند.
از ماشین‌های مجازی تا کانتینرهای Kubernetes: تغییر در تنظیم
این فرآیند در Kubernetes نیز بسیار شبیه فرآیند ذکرشده است، با این تفاوت که در Kubernetes، ماشین‌های مجازی تنظیم نمی‌شوند، بلکه Containerها و سرویس‌های وابسته هماهنگ می‌شوند. به‌جای آن که کانتینرهای Kubernetes بین Hostها جابه‌جا شوند، صرفاً Containerهای جدیدی راه‌اندازی می‌شوند تا برنامه کاربردی در حالت موردنظر اجرا شود.
بیشتر بخوانید: معرفی VMware vSphere با 101 Kubernetes، بررسی اهداف و قابلیت های آن
نکته دیگری که در اینجا باید به آن توجه کرد این است که در دنیای مجازی‌سازی، می‌توانیم یک ESXi Host واحد راه‌اندازی کنیم و ماشین‌های مجازی را درون آن اجرا کنیم. در این صورت بزرگترین مشکل فقدان دسترس‌پذیری بالا برای این VMها در صورت خرابی Host است، در خصوص کانتینرهای Kubernetes نیز میتوان اقدام مشابهی انجام داد. میتوان ماشین مجازی‌ای را اجرا کرد که یک Docker اجرا می‌کند و در این صورت برنامه کاربردی در Container اجرا خواهد شد. اگر این ماشین مجازی از کار بیفتد، برنامه نیز از کار خواهد افتاد، به همین علت به موتورهای تنظیم نیاز است تا دسترس‌پذیری بالا و مقاومت هنگام خرابی را فراهم کنند.
واحدهای سازنده Kubernetes
در ماشین مجازی، ممکن است یک یا چند برنامه کاربردی وجود داشته باشد که همه روی یک ماشین مجازی نصب شده باشند. با این امکان جدید در داخل یک برنامه کاربردی احتمالاً چندین سرویس وجود خواهد داشت که این برنامه را قادر می‌سازد برای یک کاربر یا کاربر نهایی کار کند.
برای مشاوره رایگان و یا راه‌اندازی مجازی‌سازی دسکتاپ VDI با کارشناسان شرکت APK تماس بگیرید. |
مزایای Containerization و مقیاس‌بندی
برنامه کاربردی ما در محیط Containerشده قطعاً به چندین Container Image مختلف تقسیم می‌شود که همچون سرویس‌هایی هستند که برنامه کاربردی ما را شکل می‌دهند. یکی از مزایای کلیدی Containerization این است که می‌توانیم حجم و گستره عملکرد هر یک از سرویس‌های Containerها را بسته به نیاز و شرایط خود مثلاً در برخورد با تقاضای بیشتر در زمان های شلوغ افزایش یا کاهش دهیم.
درک Podها در Kubernetes
وقتی نام این سرویس‌ها به گوشمان می‌خورد، می‌توانیم آن‌ها را بیان ساده‌تری از رابط وب مدیریت Front End در نظر بگیریم که چندین سرویس Back End مانند احراز هویت، کاتالوگ و سهام دارد. این سرویس‌ها سپس این داده‌ها را در سرویس داده ذخیره می‌کنند؛ در این سرویس داده، با پایگاه داده‌ای مشابه آنچه قبلاً دیده‌ایم مانند MySQL یا Postgres روبه‌رو خواهیم شد. در ماشین‌های مجازی، همه این سرویس‌ها احتمالاً بر یک ماشین مجازی یکسان مستقر خواهند بود. اما در محیط Kubernetes، این بخش‌های برنامه کاربردی به‌صورت Container Image هستند و Pod نامیده می‌شوند.
Podها کوچکترین واحدهای محاسباتی قابل پیاده‌سازی هستند که میتوان در Kubernetes ایجاد و مدیریت کرد. Podها مجموعه‌ای از یک یا چند Container با منابع Storage و شبکه و مشخصات نحوه اجرای Containerها هستند. در برنامه کاربردی به‌خصوص، سرویس‌های ذکر شده احتمالاً هریک حداقل یک Pod دارند.
میتوان این Podها را بسته‌بندی کرد و قابلیت‌هایی چون پیاده‌سازی‌ها، همسان‌سازی‌ها، Statefulsetها و Daemonsetها را به منابع بارهای کاری اضافه کرد. هرکدام از این‌ها وضعیت مطلوبی ارائه می‌کنند که برنامه کاربردی می‌تواند در آن اجرا شود.
بیشتر بخوانید: استفاده از پلتفرم Kubernetes در VMware vSphere چه مزایایی دارد – قسمت اول
بررسی معماری کلاستر Kubernetes
همان طور که پیش‌تر گفته شد، با بررسی و تحلیل همه جوانب متوجه می‌شویم که تنظیم Container بسیار شبیه تنظیم ماشین مجازی است، چراکه هردو پلتفرم متشکل از پردازش، Storage و شبکه هستند.
تفاوت در نام‌گذاری: مجازی‌سازی در برابر ; کانتینرهای Kubernetes
در دنیای Kubernetes، برخی از معماری‌های مشابهی را که در مجازی‌سازی هم می‌بینیم، متفاوت نام‌گذاری می‌کنیم. در مجازی‌سازی از عبارت Host استفاده می‌کنیم. ماشین‌های مجازی بر این Hostها اجرا می‌شوند. ممکن است Hostهای زیادی داشته باشیم و کلاستر خودمان را تشکیل دهیم و بر اساس آن‌ها اندازه محیط خود را تعیین کنیم. در دنیای Kubernetes با مفاهیم یا سطوح کنترل و Worker Node یا Node در حال سرویس‌دهی سروکار داریم موارد دیگری هم هستند اما برای اطلاعات و مفاهیم اولیه با همین اصطلاحات شروع می‌کنیم. سپس Podها برای اجرا بر این Nodeهای در حال سرویس‌دهی پیاده‌سازی می‌شوند تا بتوان به تعداد Node در حال عملیات موردنیاز ایجاد کلاستر دست یافت باز هم محدودیت‌هایی وجود خواهد داشت، اما فعلاً از این مفهوم مقیاس‌پذیری بی‌نهایت استفاده می‌کنیم.
از منظر مدیریت یا زمان‌بندی و برنامه‌ریزی در مجازی‌سازی و مخصوصاً در VMware vSphere، ما یک مرکز مجازی داریم. این مرکز مجازی بر Hostهای ما نظارت می‌کند و اطمینان حاصل می‌کند که ماشین‌های مجازی به‌طور مؤثر در سراسر کلاستر ما پخش شده باشند. به علاوه، در صورت خرابی، این مرکز مجازی است که فرآیند انتقال به Host دیگر را راه‌اندازی می‌کند. مرکز مجازی که از بهترین شیوه‌ها پیروی می‌کند، در یک کلاستر ساکن نخواهد بود.
در Kubernetes از Node دیگری استفاده می‌کنیم که هیچ‌یک از بارهای کاری Pod ما را اجرا نمی‌کند؛ بلکه عنوان بخشی از کلاستر را دارد که مطمئن می‌شود همه‌چیز سالم است و Containerها یا Podهای ما را برنامه‌ریزی می‌کند تا بر کارآمدترین Node درون کلاستر اجرا شوند. صفحه کنترل می‌تواند مانند مرکز مجازی عمل کند و همراه چندین Instance دسترس‌پذیری بالایی داشته باشد.
در این مطلب به تعداد کمی از شباهت‌های بین مجازی‌سازی و Kubernetes پرداختیم، اما بزرگترین نتیجه‌ای که از این مطلب می‌گیریم، این است که Kubernetes فقط یک پلتفرم دیگر است. مجازی‌سازی نیز، زمانی که برای اولین بار در کنار سرورهای فیزیکی ظاهر شد و زمانی که Hyperscalerهای بزرگ Cloud را عرضه کردند، همین طور بود.
