مجازی سازی و رایانش ابری

شرکت VMware در کنفرانس VMWorld 2019 تکنولوژی به نام Project Pacific را معرفی کرد. این تکنولوژی در واقع نسخه ای از vSphere است که مجددا طراحی شده و هدف از آن یکپارچه شدن با Control Plane محصول Kubernetes (به اختصار K8s) جهت مدیریت یکپارچه ماشین های مجازی و کانتینرها در بستر vSphere می باشد. توسعه دهندگان نرم افزار با استفاده از دستورات Kubernetes می توانند به راحتی ماشین های مجازی، دیسک و کارت های شبکه متصل به آنها را مدیریت کنند. این امر می تواند برای تیم هایی که از محیط های ناهمگون که درون آنها هم ماشین مجازی و هم کانتینر وجود دارند مفید واقع شود البته در صورتی که بستر مجازی آنها VMware vSphere باشد.

تکنولوژی Project Pacific اجزای بستر Kubernetes را در قالب ماشین های مجازی vSphere پیاده سازی می کند و ادمین بستر مجازی سازی شده می تواند از قابلیت های بستر vSphere مانند اختصاص منابع، رمزنگاری،High Availability (HA) ،  Distributed Resource Scheduler (DRS) و تهیه Snapshot برای Workload های Kubernetes استفاده کند.

در این تکنولوژی دو جزء اصلی بستر Kubernetes یعنی Agent و Container Runtime به صورت اجزاء سفارشی شده به vSphere اضافه شده اند. یک نوع خاصی از کلاستر Kubernetes به نام Supervisor بر روی محیط Project Pacific اجرا می شود. به عبارت دیگر Kubernetes از ESXi به جای سیستم عامل لینوکس برای پیاده سازی اجزای خود استفاده می کند و Agent مخصوص vSphere به نام Spherelet را بر روی هاست های ESXi نصب می کند. Spherelet براساس پروژه ای به نام Virtual Kubelet توسعه یافته که کابرد اصلی آن ایجاد ارتباط میان Kubernetes و سایر سرویس دهنده ها جهت ایجاد بستری برای اجرای Pod ها در آن است. لازم به ذکر است Virtual Kubelet یک ابزار متن باز و توسط مایکروسافت توسعه یافته است.

کانتینرها بر روی ESXi توسط یک Container Runtime به نام CRX)Container Runtime Executive) اجرا می شوند. CRX همانند یک ماشین مجازی می باشد که درون آن یک کرنل لینوکس به همراه یک Container Runtime حداقلی قرار دارد. اما از آنجا که این کرنل لینوکس با Hypervisor ادغام شده، ما می توانیم از طریق آن عملیات های بهینه سازی مربوط به ماشین های مجازی را بر روی کانتینر ها هم داشته باشیم. CRX از تکنیکی به نام Direct Boot برای آماده سازی اولیه ماشین مجازی استفاده می کند و در این روش نیازی به مراحل معمول بوت کرنل نمی باشد. در ادامه به بررسی هر کدام از این مفاهیم پرداخته خواهد شد.

علاوه تغییراتی که این تکنولوژی بر روی ESXi ایجاد می کند به  vCenter نیز مجموعه ای از اجزا را اضافه می کند. این اجزا عبارتند از:

• Workload Platform Service: این سرویس قابلیت ایجاد Namespace بر روی Cluster را فعال می کند و تعامل میان رابط های REST API و Namespace ها را برقرار می کند.
• K8s Client Bindings: ارتباط میان سرویس Workload Platform با K8s API Server برقرار می کند. ادمین بستر مجازی می تواند با استفاده از رابط کاربری HTML5 نرم‌افزار vCenter تنظیمات مربوط به Kubernetes را انجام دهد و تنظیمات انجام شده، به تنظیمات قابل استفاده در Kubernetes Namespace ترجمه می شوند.
• Token Exchange Service: این سرویس توکن های مربوط به vSphere SSO SAML را دریافت و آنها را به قالب JSON Web Tokens (JWT) جهت استفاده Kubernetes تبدیل می کند.
• Bundle of Images: مخزنی برای نگهداری Image های مربوط به Control Plane و Spherelet Bundle ایجاد می کند.

معماری Project Pacific

Supervisor Cluster

پس از فعالسازی Project Pacific بر روی vSphere Cluster آن کلاستر به  Supervisor Clusterتبدیل می شود و قابلیت های Kubernetes بر روی آن فعال خواهد شد. هنگامی که قابلیت های Kubernetes بر روی کلاستر فعال شود، مراحل زیر توسط vCenter اجرا خواهند شد:

تعداد 3 ماشین مجازی Kubernetes Control Plane با استفاده از Supervisor Control Plane Image درون کلاستر ایجاد می شود. اطلاعات مربوط به پایگاه داده بستر Kubernetes درون این ماشین های مجازی در قالب Key-Value ذخیره و نگهداری می شوند (مشابه K8s etcd). قاعده Anti-Affinity به این ماشین های مجازی اعمال می شود و بر روی 3 هاست مختلف پیاده سازی می شوند تا در صورت بروز مشکل برای هاست ها، خللی در Control Plane ایجاد نشود. در ماشین های مجازی Control Plane علاوه بر اینکه سرویس Kubernetes API server در حال اجرا می باشد، چندین افزونه مربوط به vSphere نیز وجود دارد. این افزونه ها عبارتند از:

NCP – NSX-T Container Plugin

این افزونه به صورت یک کانتینر اجرا می شود و ارتباط میان NSX Manager و Kubernetes Control Plane را برقرار می کند. مدیریت اجزای شبکه مانند Logical ports، Switch، Router و Security Groups با استفاده از فراخوانی NSX API ها بر عهده این افزونه می باشد.

(Cloud Native Storage (CNS

به ادمین بستر مجازی این اجازه را می دهد تا از vSphere Datastore (از هر نوعی VMFS، NFS یا vSAN) به عنوان Persistent Volume کانتینرهای ایجاد شده توسط Kubernetes استفاده کند.

Scheduling

هنگامی که ادمین قصد دارد یک Pod جدید ایجاد کند این سرویس با بهره گیری از قابلیت VMware DRS مشخص می کند که برای قرار گرفتن این Pod در کلاستر Supervisor کدام Node مناسب است.

Authentication

کاربران می توانند با استفاده از حساب های کاربری تعریف شده در SSO vSphere به Guest Cluster Kubernetes ها متصل شوند.

بسته نرم افزای Spherelet بر روی تمامی هاست های درون کلاستر نصب می شود و این امر سبب می شود که ESXi هاست ها بتوانند به عنوان Kubernetes Worker Node عمل کنند. در vCenter سرویس Workload Platform این Agent را بر روی تک تک هاست های درون کلاستر نصب می کند. همچنین Spherelet با استفاده از REST API Namepace ها را مدیریت می کند.

نصب Container Runtime Executive (CRX) بر روی هاست های ESXi. CRX از نظر سرویس Hostd و سرور vCenter مشابه یک ماشین مجازی به نظر می رسد اما CRX امکان اجرای کانتینر ها به صورت مستقیم بر روی VMKernel را فراهم می سازد. CRX یک ماشین مجازی است که شامل یک هسته لینوکس (سیستم عامل PhotonOS) و Container Runtime حداقلی است. همانند سایر ماشین های مجازی این ماشین مجازی نیز دارای یک (virtual machine executive)VMX فایل است اما برای اینکه ماشین مجازی بتواند بسیار سریع بوت (کمتر از یک ثانیه) شود بسیاری از پارامترهای درون آن حذف شده اند. علاوه بر VMXفایل بهینه شده  VMware تکنولوژی Direct Boot را طراحی کرده است که به واسطه آن بسیاری از عملیات های زمانبر فرآیند بوت سیستم عامل مانند شناسایی سخت افزار و یا پیکربندی ساختار حافظه حذف شده اند زیرا ساختار حافظه CRX از قبل ایجاد شده است و در زمان بوت نیازی به تعریف آن ندارد. Pod هایی که از طریق CRX در بستر vSphere ایجاد می شوند، Native Pod یا vSphere Pod نامیده می شوند.

Namespace

مفهوم Namespace تعریف شده برای Supervisor Cluster در بستر vSphere با مفهوم مشابه آن در Kubernetes متفاوت است. Namespace در Supervisor Cluster را می توان به عنوان یک Resource Pool جهت اختصاص دادن منابع سخت افزاری مانند CPU، حافظه در نظر گرفت. ادمین بستر vSphere همچنین می تواند دسترسی کاربران به Namespace را مشخص کند. علاوه بر این ادمین می تواند تعیین کند که کدام یک از سیاست های ذخیره سازی به Namespace اعمال شود و براساس آن مشخص می شود که Namespace می تواند به کدام Datastore دسترسی داشته باشد.

Guest Cluster

Kubelet استفاده شده در Supervisor Cluster با Kubelet مورد نیاز Kubernetes متفاوت است به همین دلیل با ساختار Kubernetes Cluster انطباق وجود ندارد و ممکن است در پیاده سازی برخی از کانتینرها با مشکل مواجه شویم. VMware برای رفع این مشکل Guest Cluster را طراحی و توسعه داده است. اساسا Guest Cluster دقیقا یک Kubernetes Cluster است که در درون Supervisor Cluster و به صورت ماشین های مجازی اجرا می شود. Guest Cluster کاملا با بستر Kubernetes بالادستی خود منطبق است و فقط به جای اینکه سرورهای Master و Node بر روی هاست ها پیاده سازی شوند بر روی ماشین های پیاده سازی شده اند.

نکته دیگری که در این زمینه باید به آن اشاره شود این است که رابطه میان Supervisor Cluster و vSphere Cluster یک رابطه یک به یک است. به عبارت دیگر در یک vSphere Cluster فقط می تواند یک Supervisor Cluster وجود داشته باشد. اما چنین رابطه ای میان Guest Cluster و Supervisor Cluster وجود ندارد و چندین Guest Cluster با Namespace های مختلف می تواند درون یک Supervisor Cluster وجود داشته باشند.

VMware vSphere with Tanzu

در اوایل سال 2020 میلادی و شش ماه پس از معرفی Project Pacific شرکت VMware از محصول جدیدی به نام VMware Cloud Foundation (VCF) with Tanzu را معرفی کرد که در آن از تکنولوژی Project Pacific استفاده شده بود. شرکت VMware پس از ارائه این محصول متوجه شد که علاوه بر کاربرانی که برای بستر Cloud و توسعه نرم افزارهای خود از VCF with Tanzu استفاده می کنند، کاربران بسیاری نیز وجود دارند که بر روی بستر فعلی vSphere از Kubernetes استفاده می کنند و خواهان استفاده از زیرساخت های شبکه و ذخیره ساز فعلی vSphere برای پیاده سازی Kubernetes هستند از همین روی شرکت Vware تصمیم گرفت در نسخه vSphere 7 Update 1  این قابلیت را به بستر vSphere نیز اضافه کند.

در مقاله های بعدی به معرفی تکنولوژی vSphere with Tanzu پرداخته خواهد شد.