VMware Project Pacific nedir?

Merhabalar,

Son yıllarda teknoloji firmaları, tabiri caizse teknoloji atağına kalkmış durumdalar ve özellikle cloud teknolojileri tarafında heyecan verici gelişmeleri görmekteyiz. VMware de sektörün lideri olarak bu çalışmalarına hız vermiş durumda. Bu makalede, VMware’in Pacific Projesi adını verdiği teknolojinin ne olduğunu, temel-üst düzey temel kavramlarını ve terminolojilerini ayrıntılı bir şekilde açıklamaya çalışacağım.

Vmware  Pasific Projesi nedir?

VMware Pacific Projesi, günümüz cloud ve hybrid cloud dünyasında, modern uygulamaları oluşturma, devreye alma ve yönetme yöntemlerimizi, BT Operasyonlarını ve bunların geliştirilmesini önemli ölçüde basitleştiren, daha yüksek bir soyutlama seviyesine izin vermek için Kubernetes’i kontrol paneli olarak entegre eden, VMware vSphere’in yeniden yapılandırılması ile geliştirilen bir projedir.

Pacific Projesi, Custom Resource Definitions (CRD’ler) arasında modern uygulamaları düzenlemek için Kubernetes kontrol panelinden yararlanır. Dolayısıyla, her türlü kaynak ve uygulamanın, Kubernetes altında tanımlı bir yerel lokasyonda dağıtılabileceği ve kontrol edilebileceği anlamına gelir.

Bir geliştirici için Pacific Projesi, sanal makineler, diskler ve ağlar gibi bulut kaynaklarını yönetmek için Kubernetes bildirim sözdizimini kullanabildikleri bir Kubernetes kümesi gibi görünüyor. BT yöneticisine göre ise Pacific Projesi, uygulamayı yönetme yeteneği ile vSphere’e oldukça benziyor.

Pacific Projesi, kuruluşların VMware vSphere üzerindeki modern uygulamaların geliştirilmesini ve çalışmasını hızlandırmayı sağlarken, var olan teknoloji yatırımlarını yani mevcut donanım altyapısını kullanarak mevcut yatırımlardan yararlanmaya devam edecek. Kubernetes’i vSphere’in kontrol paneli olarak kullanarak, geliştiricilerin ve BT operatörlerinin Container’lar ve / veya sanal makinelerden oluşan uygulamalar oluşturmasına ve yönetmesine olanak tanıyacak. Böylece işletmelerin, mevcut olan ve yeni yapılandırılacak olan modern uygulamaları yan yana çalıştırmak için tek bir platformdan yararlanmasına olanak tanıyacaktır.

Geleneksel Uygulamalar vs Modern Uygulamalar

Geleneksel uygulamaların, genellikle bulut modeline geçmeden önce oluşturulan, az sayıda sanal makine üzerinde dağıtılarak çalıştırılan uygulamalardan oluştuğunu söyleyebiliriz. Uygulama geliştirmeye yönelik Private Cloud ve hybrid cloud yaklaşımlarının ön plana çıkması ve modern zamanlarda hızlanan teknoloji atılımları ile, bu model artık güncelliğini yitirmekte ve günümüzdeki uygulama standartlarına uygulanamayacak kadar da yetersiz kalmakta.

Aşağıda, modern bir uygulama ile geleneksel bileşenlerin kombinasyonuna bir örnek verilmiştir. Kubernetes Cluster’ları, sanal sunucular üzerindeki geleneksel uygulamalar, dağıtık olmayan database’ler ve daha birçok kaynak bu örnekte  gösterilmemiştir.

Modern uygulamalar, geliştiriciler için genellikle sorun yaratır. Böyle bir uygulamayı nasıl dağıtır ve çalıştırırsınız? Kubernetes’i kullanamazsınız çünkü uygulamanın büyük bölümleri Kubernetes üzerine kurulmamıştır. Böyle bir uygulamayı dağıttıktan sonra, uygulamayı nasıl koruyup güncellersiniz? Dağıtımı değiştirmek, izlemek, teşhis etmek ve hatalarını ayıklamak için ne tür araçlar kullanabilirsiniz?

Peki operasyon ekipleri, erişilebilirlik, güvenlik, hizmet kalitesi ve depolama politikasını nasıl yönetecekler? Böyle bir uygulamayı destekleyen altyapı maliyetleri nasıl kontrol edilecek?

Modern uygulamalar ayrıca altyapı ekiplerine de sorun çıkaracak gibi görünüyor. Bazı kuruluşlar, mevcut vSphere altyapılarının yanında yeni, Container / Cloud odaklı bir yapı oluşturmaya karar verecek olsalar, risklerle dolu bir yola girmiş olacaklar. Uygulamalarınız yukarıdaki gibi görünüyorsa, hem vSphere altyapısına hem de Container tabanlı platformlara yayılacaktır. En iyi ihtimalle, yönetişim ve politika uygulama karmaşıklığı, bunu tek bir platformda yapmaktan iki kat daha zordur. Her şey altyapı silolarına ayrılmıştır ve bu başarılı bir yapı kurmanıza sınırlayıcı bir etkisi olmaktadır.

İşte tüm bu konular, Pacific Projesi’nin ele alacağı konular olacaktır.

Modern Uygulamalara Kubernetes Cephesinden Yaklaşım

Bu tür farklı konfigürasyonlarda inşa edilen modern uygulamalarla, bir dağıtımın tanımlanması, uygulamanın her bileşeni için birçok farklı arayüzle çok karmaşık hale gelir. Project Pacific, bulut yerel ve geleneksel yaklaşımlardaki tüm uygulamaların bir Kubernetes yerel yolunda tanımlanmasına ve dağıtılmasına izin vererek bu sorunu giderir. Yukarıdaki şemada gösterildiği gibi, kullanıcılar birleşik bir dağıtım yapılandırması oluşturmak için bir YAML yapılandırması kullanarak Kubernetes Kümeleri, geleneksel uygulamalar, sunucusuz işlevler ve veritabanlarını tanımlayabilir. Bu şekilde tanımlanan uygulamalar, Project Pacific’in Kubernetes’i vSphere ile entegrasyonu sayesinde tek bir birim olarak da kullanılabilir. Bu, modern uygulamalarla çalışma sürecini önemli ölçüde basitleştirir!

Kubernetes as a platform platform

VMware’de sahip olduğumuz temel fikir, Kubernetes’in bir Container platformundan çok daha fazlası olabileceği, TÜM iş yükleri için platform olabileceğidir. Kubernetes’in ortak yaratıcısı Joe Beda, Kubernetes hakkında konuştuğunda, bunu bir platform platformu olarak tanımlıyor; “yeni platformlar oluşturmak için bir platformdur” diyor. Evet, Kubernetes bir konteyner düzenleme platformudur, ancak özünde Kubernetes her şeyi düzenleyebilir!

Vmware vSphere’i yeniden keşfetmek için, Kubernetes’in bu “platform platformu” yönünü kullanırsak ne olur? Ya Geliştiriciler sanal bir makine veya bir container veya bir kubernetes cluster oluşturmak istediklerinde, sadece bir kubernetes YAML dosyası yazsalar ve kubectl ile diğer Kubernetes nesnelerinde olduğu gibi dağıtsalar?

İşte bu teknoloji, geliştiricilerin sadece private cloud uygulamaları için değil, TÜM uygulamaları için Kubernetes’in avantajlarından yararlanabileceği anlamına gelir. Birden fazla teknoloji yığınına yayılan modern uygulamaları dağıtmalarını ve yönetmelerini kolaylaştırır öyle değil mi?

Geliştiriciler için Workload-level Management

Dağıtım yapılandırmaları basitleştirildiğinde, geliştiriciler artık uygulamaları dağıtabilir, çalıştırabilir ve altyapı kaynaklarını modüler olarak değil iş yükü düzeyinde tanımlayabilir. Bu, Pacific Projesi’nin geliştiricilere sunduğu gerçekten basit ama güçlü bir avantajdır. Ayrıca geliştiricilere, dağıtımlarında herhangi bir kaynak tanımlama ve oluşturma yeteneği vererek, artık bu hizmet isteklerini işlemler yoluyla yapmak için uzun ve zahmetli bir süreçten geçmek zorunda kalmazlar.

Operasyonlar için Namespace-level Management

Pacific Projesi’nin operasyon avantajlarını anlamak için önce anlamamız gereken birkaç kavram var.

Kubernetes Namespace: Namespace, bir Kubernetes cluster içindeki tek bir Kubernetes cluster’ının ve bu cluster kaynaklarının birden çok kullanıcı arasında bölünmesini sağlayan sanal bir kaynak sınırıdır. Yani aslında, kaynak nesnelerinin (container, VM’ler, diskler, vb.) bir koleksiyonudur.

Ya modern uygulamaları ve tüm parçalarını modellemek için Kubernetes Namespace kullandıysak ve daha sonra VM’lerde yapabileceğimiz benzer tüm işlemleri namespace’de yaparsak ne olur? Tek tek sanal makinelerle uğraşmak yerine, bir kerede nesnelerin Namespace’lerine kaynak ayırma, vMotion, Şifreleme, HA ve anlık görüntüler gibi şeyler yapabilseydiniz ne olurdu?

Bunun sanal altyapı yöneticileri üzerinde gerçekten dönüştürücü iki etkisi var.

İlk olarak, bunun sanal altyapı yöneticilerine büyük bir verimlilik artışı sağladığını söyleyebiliriz. Geçmişte, vCenter envanterinizde uğraşmanız gereken binlerce VM’ye sahip olabilirdiniz. Ancak bu VM’leri mantıksal uygulamalarında gruplandırdığınızda, yalnızca düzinelerce Namespace ile uğraşmanız gerekebilir. Geçmişte bir uygulamayı şifrelemek istiyorsanız, önce uygulamanın bir parçası olan tüm VM’leri bulmanız ve ardından her birinde şifrelemeyi açmanız gerekirdi. Şimdi vCenter’daki Namespace bir düğmeyi tıklatabilirsiniz ve hepsini sizin için sistem otomatik olarak yapar. Büyük bir üretkenlik artışı elde edersiniz çünkü bireysel VM’ler yerine, gruplanmış malzemelerle ilgilenebilirsiniz.

İkinci olarak, Namespace geliştirici self servisi için bize daha iyi bir model vereceğini söyleyebiliriz. Birçok BT kuruluşunun ticket sistemlerine büyük ölçüde güvenmesinin nedenlerinden biri, geliştirici uygulamaları üzerinde yönetişim sağlamanın tek yolu olmasıdır. Geliştiricileriniz düzenlenmiş bir uygulama kullanıyorlarsa, VM’lerin doğru şekilde kurulduğundan emin olmak için oluşturulurken orada olmanız gerekir. Ancak Namespaces ile Namespace’de bir kez bir ilke ayarlayabilir ve ardından geliştiricinin gün boyu bu Namespace’e kendi kendine hizmet kaynaklarını bırakmasını sağlayabilirsiniz. Namespace’deki her nesne, ayarladığınız ilkeleri devralır. BT, kurumsal politikaların uygulanmasını sağlarken, geliştiriciler altyapıya hızlı ve self servis erişimlerini sağlamış olurlar.

Pacific Projesinin Mimarisi

Pacific Projesi, Vmware vSphere’i, bir kubernetes yerel platformuna dönüştürüyor. Bir Kubernetes kontrol panelini doğrudan ESXi ve vCenter’a entegre eder ve böylece ESXi için kontrol paneli haline gelerek, vCenter aracılığıyla uygulama odaklı yönetim gibi yetenekleri ortaya çıkarılmış olur.

vSphere with Native Kubernetes

vSphere, VMware’in bulut bilişim sanallaştırma platformudur ve iki temel bileşenden oluşur.

vCenter Server : Sanal sunucular, ESXi sunucular ve cluster’lar, Network ve Storage gibi kaynakların yönetimini sağladığımız merkezi yönetim sunucusudur. Operasyonlar, sanal makineleri ve Software-Defined Datacenter (SDDC) kaynaklarını oluşturabilir, yönetebilir ve izleyebilir.

ESXi Clusters: ESXi sunucular, sanal sunucuların dağıtımını yapıp barındırıldığı bare-metal hypervisor’lerdir. ESXi cluster’lar ise, vCenter tarafından yönetilerek, birden fazla ESXi sunucuyu içerirler ve üzerilerindeki kaynakları bir havuz mantığıyla sanal sunuculara kullandırırlar.

Supervisor clusters

Supervisor, üzerinde çalışmaya ihtiyaç duyduğu Linux sunucu yerine ESXi sunucuyu kullanan özel bir Kubernetes cluster’dır. Bu, bir Kubelet’in (uygulamamız Spherelet olarak adlandırılır) doğrudan ESXi sunucuya entegre edilmesiyle sağlanır. Spherelet bir VM’de çalışmaz, doğrudan ESXi üzerinde çalışır. Aşağıdaki iki şekil de mantıksal olarak aynıdır. Daha rahat anlaşılabilmesi için farklı şemları paylaşmak istedim.

Şimdi bu kavramları biraz açıklayalım.

Kubernetes Control Plane VMs: ESXi cluster içinde dağıtılan ve cluster için bir Kubernetes kontrol paneli oluşturmak üzere birlikte çalışan, birden çok VM anlamına gelmektedir. Bu Kubernetes kontrol paneli, Spherelet ile birlikte, geliştiricilerin Kubernetes API’sını kullanarak, Supervisor Kubernetes cluster’a çevrilmiş ortam için arayüz oluşturmasına izin verir.

Spherelet: ESXi ana bilgisayarını işlevsel olarak bir Kubernetes cluster’a dönüştürmek için Kubernetes kontrol paneli VM’leriyle bir arayüz oluşturur.

ESXi Native Pods: Pod’lar da dahil olmak üzere, Supervisor’e dağıtılan iş yükleri, her biri hipervisor üzerinde kendi izole sanal makinelerinde çalışır. Bunu sağlamak için ESXi sunuculara CRX adı verilen yeni bir konteyner runtime eklenmiştir. CRX, guest içinde bir Linux çekirdeği ve minimum container runtime içeren sanal bir makine gibidir. Ancak bu Linux çekirdeği hipervisor’le birleştiğinden, container’ı etkili şekilde paravirtualized yapabilmek için birtakım düzenlemeler yapılabilmektedir.

  • Bir Native Pod, bir VM ile aynı güvenlik izolasyonuna sahiptir.
  • Çünkü CRX, hipervisor’da guest olarak çalıştığı için, Native Pod’un kendi kaynak tahsisi ve diğer Pod’lardan izolasyonu vardır. Bir Pod’un performansındaki herhangi bir değişim, diğer iş yüklerine etki etmez.
  • VMware’de yapılan dahili testler, CPU yalıtımı nedeniyle Native Pod’lar üzerinde çalışan container’ların, geleneksel vSphere VM’lere göre % 30, bare-metal üzerindekine göre de % 8 daha hızlı çalışma potansiyeli olduğunu göstermektedir.

Yukarıda, VM’leri, Cluster API’leri (Kubernetes), Guest Kubernetes Cluster Controller’ı barındıran Supervisor Cluster soyutlama katmanı ve ek hizmetleri barındırmak için oluşturulmuş bir Supervisor Cluster katmanının mantıksal yapısı görülmektedir. Bu yapıda geliştirici ekipler için user namespace’ler oluşturulabilir ve geliştiriciler, uygulamaları kendilerine atanmış namespace’ler altında dağıtabilir. Kısaca nasıl çalıştıklarını da görelim madem 🙂

1. Operations: Supervisor Cluster üzerinde namespace oluşturma

Project Pacific, bir ESXi Kümesinde etkinleştirildiğinde ve bir Supervisor Kubernetes Cluster’a dönüştürüldüğünde, bu Supervisor Cluster vCenter aracılığıyla yönetilebilir. Operasyonlar, Supervisor Cluster içinde User Namespace’ler oluşturabilir, SDDC kaynaklarını yönetebilir ve her bir Namespace’e politika atayabilir. Vcenter üzerinden, tüm operasyonlar izlenebilir ve yönetilebilir durumdadır.

2. Developers: Uygulama dağıtımı ve yönetimi

Bir namespace oluşturulduktan ve tek bir geliştiriciye ya da bir geliştirici ekibine atandıktan sonra, bu geliştiriciler uygulamaları kendi kendilerine dağıtabilir ve çalıştırabilir, kendi namespace’lerindeki altyapı kaynaklarını yönetebilir ve sadece Kubernetes API’sı aracılığıyla destek hizmetlerini oluşturabilirler. Pacific Projesi’nin çok güzel özelliklerinden biri de budur.

Guest Kubernetes Cluster: Supervisor Kubernetes Cluster, upstream Kubernetes ile tam olarak uyumlu olmayan, Kubernetes for vSphere’in özel bir uygulamasıdır. Bu nedenle Project Pacific, geliştiricilerin Kubernetes CLI’yi kullanarak herkesin oluşturabileceği ve dağıtabileceği, tamamen uyumlu bir upstaream Kubernetes Cluster hizmeti olan Guest Kubernetes Cluster’ı sunar.

3. App Services yapılandırma

Bağımsız yazılım satıcıları (ISV) ve geliştiricilerin işbirliği ile, Kubernetes operatörlerini kullanan uygulama hizmetleri, vSphere ve Project Pacific üzerine kurulabilir. Kullanıcılar bu hizmetleri doğrudan vSphere ortamına kurabilir, çalıştırabilir ve bu hizmetleri kullanan uygulamalar oluşturabilir.

4. Supervisor Cluster monitor etme

vCenter’dan, VM’ler, Kubernetes Cluster’lar ve ESXi Native Pod’ların etkinliği izlenebilir. Geliştiriciler, istedikleri hizmetleri kendileri dağıtma ve çalıştırma, namespacel’ler ve SDDC oluşturma ve yönetme konusunda özgür olurlar. Genişletilebilirlik, Multi-tenancy, üst düzey yönetim…

Bu Project Pacific’in gücü olacaktır!

Gördüğünüz gibi oldukça komplike ama bir o kadar da kolay ve esnek bir gelecek bizleri beklemekte. Şimdiden konu hakkında bilgi sahibi olabilmeniz açısından da kaynakları olabildiğince anlaşılır şekilde tercüme etmeye çalıştım.

Yararlı olması dileğiyle.

Yusuf İşleyen

Kaynaklar :
https://blogs.vmware.com/vsphere/2019/08/project-pacific-technical-overview.html
https://medium.com/@lnmei/project-pacific-technical-overview-for-new-users-b7b32a8c2e35