طی سخنرانی اصلی در روز اول کنفرانس VMworld 2019، شرکت VMware از Project Pacific پرده‌برداری کرد. به‌طور خلاصه، Project Pacific، vSphere را به پلتفرم یکپارچه برنامه‌ی کاربردی تبدیل می‌کند. با یکپارچه‌سازی عمیق Kubernetes با پلتفرم vSphere توسعه‌دهندگان می‌توانند از طریق یک Control Plane شناخته شده برنامههای خود را نصب و مدیریت کنند. علاوه‌براین، اکنون Containerها که بسیار حائز اهمیت هستند، از همه عملیات‌هایی که عموما در ماشینهای مجازی در دسترس هستند، بهره می‌برند.
VMware نزدیک به سه سال است که با وجود خرید Heptio و Pivotal، بر روی Project Pacific مشغول به کار است. Jared Rosoff بنیانگذار پروژه و مدیر تولید اظهار داشته است که بالغ بر 200 مهندس در این پروژه دخیل می‌باشند که درگیر هر جز از پلتفرم vSphere هستند.
یک Control Plane واحد
با یکپارچه‌سازی Kubernetes با پلتفرم vSphere، اکنون Kubernetes Control Plane به توسعه‌دهندگان و تیم‌های عملیاتی اجازه‌ی تعامل می‌دهد. به جای تحمل دردسرهای نصب و پیکربندی و نگهداری کلاسترهای Kubernetes، هر میزبان ESXi مانند یک Kubernetes Worker Node عمل می‌کند. هر کلاستر یک Kubernetes Control Plane را اجرا می‌کند که چرخه‌ی عمرش توسط vCenter مدیریت می‌شود. این کلاستر Kubernetes، کلاستر Supervisor نام دارد و به‌صورت Native، درون کلاستر راه‌اندازی می‌شود. این بدین معناست که قابلیت Kubernetes، درست شبیه به DRS و HA فقط با فشار یک کلید فعال‌سازی می‌گردد.
پلتفرم یکپارچه
اکنون تیم‌های مختلفی می‌توانند با Containerها تعامل کنند. قابلیت اجرا به‌صورت Native بروی vSphere، این امکان را فراهم آورده است تا اطلاعات آنها بروی ساختار مانیتورینگ، Log analyticها و همینطور عملیات‌های مدیریتی؛ قابل رویت باشد. این امر به تیم‌های IT اجازه می‌دهد تا از محیط‌های Dual-Stack دور شوند. در چند سال گذشته بسیاری از تیم‌های IT که روی Kubernetes سرمایه‌گذاری کرده بودند در کنار ایجاد Stack برای مدیریت و کنترل محیط مجازی‌سازی، شروع به ایجاد Stack عملیاتی نمودند. اجرای Stackهای مستقل و جداگانه در کنار هم به‌خودی‌خود یک چالش است.
بااین‌حال چشم‌انداز‌های برنامه‌ی کاربردی مدرن در هیج یک از این Stackها محدود نشده است. آنها ترکیبی از Containerها، ماشینهای مجازی و حتی گاهی یکسری توابع هستند. داشتن نماهای یکسان درمیان چندین Stack عملیاتی، تقریبا غیرممکن است. Project Pacific پلتفرم یکپارچه‌ای را ارائه می‌دهد که در آن توسعه‌دهندگان و اپراتورها مفاهیم یکسانی را با هم به اشتراک می‌گذارند. هر تیم امکان دیدن همه Objectها را در رایانش، ذخیره‌سازی و لایه‌های شبکه دیتاسنتر مجازی دارد. این پلتفرم در حالی پیشنهاد دید یکپارچه از چشم‌انداز کامل برنامههای کاربردی را دارد که این دید سراسری را با نامگذاری و روش‌های سازمانی مشترک ارائه می دهد.
سهولت در مدیریت
از منظر مدیریتی، vSphere از همان ابتدا با در نظر گرفتن گروه مدیران به عنوان تنها اپراتور، طراحی شده است. با به نمایش در آمدن Kubernetes API، توسعه‌دهندگان حالا می‌توانند مستقیما برنامههای کاربردی خود را نصب و مدیریت کنند. همانگونه که قبلا ذکر شد، برنامههای کاربردی مدرن مجموعه‌ای از Containerها و VMها هستند و بنابراین vSphere Kubernetes API برای حمایت از ماشینهای مجازی گسترش یافته است که به توسعه‌دهندگان برای نصب و مدیریت Container و ماشینهای مجازی کمک می کند.
برای هدایت پیاده‌سازی برنامههای کاربردی توسط توسعه‌دهندگان، Project Pacific از Namespsceها استفاده می‌کند. در Kubernetes، Namespaceها برای تخصیص منبع و محدودیت‌ها و گروه‌بندی Objectها مانند Container و دیسک‌ها ضروری می‌باشد. در Project Pacific موضوع فراتر ازاین است. علاوه بر این، این Namespaceها به تیم عملیاتی IT توانایی اجرای Policyها را هم می‌دهند. برای مثال، در ترکیب با Cloud-Native Storage یا به اختصار CNS، Policy ذخیره‌سازی ممکن است وابسته به Namespace باشد، البته مشروط بر اینکه مجهز به ظرفیت دائمی و سطح سرویس مناسب باشند.
علاوه بر منافع موجود برای توسعه دهندگان، همچنانکه که کلاستر Supervisor بهNamespace ها تقسیم می‌شود، آنها نیز تبدیل به واحدهای Tenancy و ایزوله می‌شوند. در اصل، آنها واحدی از مدیریت در vCenter می‌شوند، که به تیم عملیات IT توانایی تخصیص منبع، مدیریت Policy، تشخیص و رفع عیب در Namespace و سطح بارکاری را می‌دهد. از آنجا که Namespace حالا جزئی Native در vCenter است، هدفش گروه‌بندی تمام بارهای کاری، کلاسترهای Guest، VMها و همچنین Containerها است و به اپراتورها توانایی مدیریت همه آنها را به صورت کامل می‌دهد.
کلاسترهای Guest
انتظار بر این است که Supervisor Cluster، با ادغام با Claud-Native Storage و Networking، vSphere را تقویت کند. کلاسترهای Guest از کلاستر Kubernetes Upstream API برای مدیریت چرخه عمر (Lifecycle) استفاده می‌کنند. این یک سیستم کاملا باز است که با کل اکوسیستم Kubernetes کار می‌کند.
ایجاد کانتینر با ماشین های مجازی ایزوله
همانطور که قبلا این باور غلط، مبنی بر اینکه ESXi یک Linux Os است را رد کردیم، اکنون نیز می‌گوییم که Containerها بسیار مهم هستند. از آنجایی که کاربر برای کنترل Containerها نیاز به اجرای لینوکس دارد، آیا ESXi می‌تواند یک Linux Os باشد؟ خیر، ESXi هنوز Linux نیست. برای راه‌اندازی Containerها، Project Pacific از یک Container Runtime جدید استفاده می‌کند که CRX نام دارد.
به زبان ساده‌تر، vSphere Native Pod یک ماشین مجازی است. همه اجزای غیر ضروری حذف و یک Linux Kernel سبک‌وزن و یک (Container Runtime (CRX کوچک عرضه شده است. با بهره‌گیری از سال‌ها تجربه‌ی Para-Virtualization، این CRX طوری بهینه‌سازی شده است که عملکرد بهتری از Containerهایی داشته باشد که در پلتفرم‌های قدیمی اجرا می‌شوند. این CRX، 30% سریعتر از Linux VM سنتی و 8% سریعتر از Bare-Metal Linuxها است.
حسن استفاده از ساختار VM این است که این vSphere Native Podها در لایه‌ی Hypervisor جدا هستند. برخلاف آن دسته Podها که در همان لینوکسی که هسته و سخت‌افزار مجازی یکسانی دارند، اجرا می‌شوند، vSphere Native Podها هسته‌ی Linux و سخت‌افزارهای مجازی کاملا جداگانه‌ای دارند. بنابراین از منظر امنیت و مصرف منابع بسیار قدرتمندتر عمل کرده است. در نتیجه تسهیل امنیت و تضمین مدلهای جدایی مناسب برای Multi-Tenancy فراهم می‌گردد.
