OpenShift Kurulum Yöntemleri Nelerdir, Hangisini Seçmeliyim?
Kurumsal kubernetes diyince akla ilk gelen teknolojilerden olan Red Hat OpenShift Container Platform ürününün kurulumunda hangi yöntem kullanılacağı ile ilgili bazen kafa karışıklıkları olabiliyor. Desteklediği platformların sayısı ve farklı kurulum yöntemlerinin bu platformlara olan uygunluğu gibi konulardan ötürü ufak bir yazı ile bu karmaşanın önüne geçmeye çalışacağız.
Başlamadan önce bazı kavramları netleştirelim. Red Hat dokümanlarda ya da hibrit konsolda bu terimleri birbiriyle yer değiştirerek kullanabiliyor.
Bazı yöntemlerde internet erişimi ihtiyacı zorunlu iken, bazı yöntemlerde bunu yerel image registry ile çözebiliyorsunuz.
IPI
"IPI" yani "Installer Provisioned Infrastructure" bazen "Full Stack Automation" olarak da geçiyor. İsminden de anlaşılabileceği üzere kurulumla ilgili tüm gereksinimleri "installer" gerçekleştiriyor.
Bu yöntemin avantajı tüm kurulumu tek bir click ile yapıyor olmanız. Ortamınıza uygun bir konfigurasyon dosyası üretip tek yapmanız gereken arkanıza yaslanmak oluyor.
Dezavantaj olarak kurulum yöntemleri arasında en az esnek olan "IPI" kurulum diyebiliyiriz. Değiştirebileceğiz parametreler sınırlı olabiliyor, ya da ileri seviye hibrit kümelerin kurulması gibi mimarileri desteklemiyor.
Avantajı yoğun kullanımda ortaya çıkıyor. Örneğin yüzlerde node barındıran fiziksel bir OpenShift kurulumun saatler içerisinde bu yöntemle kolaylıkla gerçekleştirebilirsiniz.
Aşağıdaki dokümanda farklı platfromlarda nasıl kullanılabileceği ile ilgili detay bilgi mevcut.
[https://docs.openshift.com/container-platform/4.15/installing/installing-preparing.html#supported-installation-methods-for-different-platforms]
UPI
"UPI" yani "User Provizioned Infrastructure" bazen "pre-existing infrastructure" olarak da geçiyor. Bu yöntemde kullanıcılar tüm alyapı bileşenlerini hazırlamakla mükellefler. Bunlara sunucular, dns kayıtları, harici load balancer kurulumları da dahil.
Bu yöntem kullanıcılara daha fazla özelleştirme yapma imkanı sunarken, otomasyon sürecinini de kullanıcının yapmasını bekliyor. Burada tercih size kalmış, manuel yöntemlerle de kurulumlar yapılabilmekte.
Detay bilgi ve hangi provider desteği bulunuyor aşağıdaki linkten edinebilirsiniz.
[https://docs.openshift.com/container-platform/4.15/installing/installing-preparing.html#supported-installation-methods-for-different-platforms]
Assisted Installer
Bu kurulum yöntemi Red Hat'in Hibrit konsolu üzerinde sağlanan GUI üzerinden sağlanıyor. Tamamen SAAS yaklaşım ile servis veriyor. Sizden birtakım bilgileri arayüzden sağlamanızı bekliyor. Sonrasında arkanıza yaslanıyor ve kümenizin hazır olmasını bekliyorsunuz.
Kurulum öncesinde otomatik olarak yaptığı validasyon testleriyle de sizi ön hazırlıklar konusunda destekliyor.
Bu kurulumun en önemli gereksinimi tüm nodeların internet erişimi olması. Tamamen "connected" bir şekilde kurulum yapıyor. Internet erişimi kısıtlı olan ortamlarda alternatifi olarak "Agent Based Installer" kullanılabiliyor.
Daha detaylı bilgiye aşağıdaki link üzerinden erişebilirsiniz.
[https://docs.openshift.com/container-platform/4.15/installing/installing_on_prem_assisted/installing-on-prem-assisted.html]
Agent Based Installer
Offline ya da air-gapped ortamlarda "Assisted Installer" tecrübesi yaşamanıza olanak sağlayan bu kurulum yöntemi size sunucularınızda kullanabileceğiniz bir ISO sağlayarak tüm kurulumu yapmanıza olanak sağlıyor. Kurulum için tüm gereken bilgileri bu ISO içerisine koyarak dışarıdan bilgi göndermeye gerek kalmadan kurulumları gerçekleştirebiliyorsunuz.
Bu yöntemin avantajlarından bir tanesi de bootstrap dediğimiz dedike bir node ihtiyacı olmaması. Bu sayede genellikle fiziksel ortamlarda tercih edilen bu yöntem sayesinde fiziksel kaynaklarınızı daha optimize yönetebiliyorsunuz.
Dezantaj olarak bu yazının yazıldığı tarih (Haziran 2024) itibari ile day2 operasyonla resmi bir çözümle yeni node eklemeniz mümkün değil. https://access.redhat.com/solutions/7056068
Bu yöntem daha çok edge senaryolarda kullanılmaya uygun olarak düşünebilirsiniz.
[https://docs.openshift.com/container-platform/4.15/installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.html]
Single Node (SNO)
Bazı durumlarda tek node olarak konumlanmış bir OpenShift ihtiyacınız olabiliyor.
Bu kurulum kendi içinde epey limitasyonla geliyor ve daha çok spesifik ihtiyaçları karşılamaya yönelik geliştirilmiş.
Edge tarafta compute ihtiyacı, taşınabilir cloud , 5G radio access network(RAN) gibi ihtiyaçlar için kullanılması öneriliyor.
Tek node olması sebebi ile yüksek erişilebilirlilik desteği sağlamıyor.
[https://docs.openshift.com/container-platform/4.15/installing/installing_sno/install-sno-preparing-to-install-sno.html]
Advanced Cluster Management for Kubernetes Üzerinden (Hive)
Advanced Cluster Management for Kubernetes bundan sonra ACM olarak kısaltacağım ürün ile çoklu küme yönetiminde işinizi epey kolaylaştıracak aksiyonlar alabiliyorsunuz. Bunlardan birisi de küme yönetimi ve yeni küme kurulumu.
ACM üzerinden "Hive" API objeleri kullanarak desteklenen providerlar üzerinde yeni küme kurulumu gerçekleştirebiliyorsnuz. Yöntem olarak "IPI" kullanılıyor. ACM size öncesinde ve sonrasında kullanmak üzere Ansible Playbooklarınızı kullanabileceğiniz entegrasyonu da sağlıyor. Bu sayede IPI ile otomatize edilemeyen konuları Ansible ile gerçekleştirebiliyorsunuz.
Bu sayede OpenShift küme kurulumlarını API tabanlı hale getirebiliyor, isterseniz Gitops mantığı ile yeni küme kurulumlarını kolaylıkla tetikleyebiliyorsunuz.
[https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html-single/clusters/index#create-intro]
Hosted Control Planes(HCP)
Hosted Control Plane en kaba tabirle etcd,api gibi ana kubernetes servislerin pod ya da OpenShift sanallaştırma üzerinde sanal makine olarak bir kümede ayağa kaldırılması olarak düşünebilirsiniz. Bu sayede hem control plane kaynak ihtiyacını azaltmış hemde yeni küme kurulumunda en çok vakit alan control plane kurulumunu aradan çıkararak çok hızlı bir şekilde küme kurulumu gerçekleştirebiliyorsunuz. HCP arkada HyperShift kullanarak bu işlemi yapıyor. Şu an için OpenShift sanallaştırma ve Bare Metal ortamlarda HCP kullanılabiliyor.
Detay bilgiyi aşağıdaki dokümanlardan edinebilirsiniz.
[https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html-single/clusters/index#hosted-control-planes-intro]
[https://docs.openshift.com/container-platform/4.15/hosted_control_planes/index.html]
Bulut Servisleri
AWS , Azure gibi bulut sağlayıcıların sunduğu yönetilen hizmet olarak alınabilecek yapılar da mümkün. Bu tarz kullanım biraz daha maliyetli olsa da tüm operasyon yükünü sağlayıcıya verdiği için operasyonel maliyetleri düşürmede faydalı.
Platform Agnostic
Bir kurulum yöntemi olmasa da diğer tüm maddelerin yeterli olmadığı senaryolarda "son çözüm" olarak platform bağımsız kurulum da yapılabiliyor. Bu yapı bazı mimarileri kurgularken uygun olabiliyor, örneğin sanal control plane ortamlarına fiziksel worker node bağlamak gibi. İlk kurulum biraz zor olsa da kurulumdan sonra herhangi bir OpenShift kümesi yönetmekten farkı olmuyor. "UPI" kuruluma çok benziyor, sadece tüm gerekli altyapıyı sizin planlamanız ve kurmanız gerekiyor.
Gantek olarak müşterilerin ihtiyaçlarını doğru analiz edip en uygun mimariyi çıkarma konusunda hassasiyetle çalışıyoruz. Bu tarz yapıların özellikle analizinin doğru yapılması, beklentinin doğru bir şekilde karşılanması için kritiklik arz ediyor. Aksi taktirde farklı sebeplerden dolayı küme kurulumlarının yenilenmesi ya da projelerde durma noktasına gelebilecek durumlar oluşması olası.
Erdem Keçe- Red Hat Certified Architect in Infrastructure Level II