Merhaba,

Bugün Kubernetes’in tarihçesini çok merak ettim. Bu konuda bir araştırma yaptım. Ama devamını hangi konulara bağladım, okuyun bakalım faydalı bulacak mısınız?

Kubernetes’in bulut yapılarında mikro servisleri çalıştırmak için standart haline gelen konteyner orkestrasyon platformu olduğunu ve bize aynı zamanda üzerinde çalıştırdığımız servislerin taşınabilir, genişletilebilir olmasını sağlayan bir altyapı sağladığını biliyoruz. Şu anda görünen bulut sağlayıcılarının pek çoğunun, Kubernetes kümelerini oluşturarak dağıtık altyapılarının temelinde Kubernetes’i benimsedikleridir.

Kubernetes, Google’da dahili bir konteyner orkestrasyon çözümüyken, bugün pek çok kurumsal tarafından kullanılan bir yapı haline nasıl geldi?

Kubernetes’in original olarak Google tarafından geliştirilmiş olduğunu söylemiş oldum. Elbette açık kaynaktır ve katkıda bulunan büyük bir topluluk tarafından da yönetilmektedir.

Yazılım dağıtım süreçlerinin otomatikleştirilmesi, güncellemelerin kolay yapılması sayesinde, uygulamalarımızı ve hizmetlerimizi sıfır kesinti süresiyle yönetmemizi sağladığı için geliştirme sürecimizi son derece hızlandırmaktadır.

Google, 2003-2004 yılları arasında, Borg sistemi tanıttı. Borg sistem ne yapıyordu? Her biri on binlerce makineden oluşan kümeler içinde binlerce farklı uygulamanın yüz binlerce işini yürüten büyük ölçekli dahili küme yönetim sistemiydi. Ufak bir not, “cluster” yerine küme ifadesini kullanıyorum.

Google, 2013 yılında, Borg’un ardından, büyük işleme kümeleri için esnek, ölçeklenebilir zamanlayıcı (scheduler) olan Omega küme yönetim sistemini tanıttı.

2014 yılının ortasında, Google, Kubernetes’i Borg’un açık kaynaklı bir sürümü olarak sektöre tanıttı

7 Haziran 2014 günü, Kubernetes’in ilk “github commit”i gerçekleşti. 10 Temmuz 2014 günü, Microsoft, RedHat, IBM, Docker Kubernetes topluluğuna katıldı.

Artık her yerde ismini gördüğümüz,  CNCF’i (Cloud Native Computing Foundation) kurmak için Google, Linux Foundation ile 21 Temmuz 2015’de ortaklık yaptı.

23 Şubat 2016’da Kubernetes’in paket yöneticisi Helm’in ilk sürümü yayınlandı.

13 Eylül 2017’de Oracle, Cloud Native Computing Foundation’a platin üye olarak katıldı. Oracle, Oracle Bulut Altyapısı için açık kaynaklı bir Kubernetes yükleyicisi sağladı ve Kubernetes’i Oracle Linux üzerinde yayınladı.

2017 Ekim’de, Docker, Kubernetes’i tamamen Kucakladı. Geliştiriciler ve operatörler, Docker ile uygulamalar oluşturabilir ve bunları hem Docker Swarm hem de Kubernetes kullanarak sorunsuz bir şekilde test edip dağıtabilir hale geldi.

24 Ekim 2017’de, Microsoft, AKS’nin önizlemesini sundu. AKS, Azure tarafından barındırılan bir kontrol düzlemi, otomatik yükseltmeler, kendi kendini iyileştirme, kolay ölçeklendirme ve geliştiriciler ve küme operatörleri için basit bir kullanıcı deneyimi sunar.

17 Kasım 2017’de Amazon, Kubernetes için “Elastic Container Service”i duyurdu. AWS’de Kubernetes kullanarak konteyner uygulamaları dağıtabilir, yönetebilir ve ölçeklendirebilirsiniz.

21 Mayıs 2018’de, Google Kubernetes Engine 1.10 genel kullanılabilir oldu. Kurumsal firmalar için pek çok özelliğiyle kararlı bir yapı haline geldi.

5 Haziran 2018’de Amazon EKS genel kullanıma Sunuldu. Amazon, EKS ile, Kubernetes kümeleri oluşturma, güvenlik altına alma, çalıştırma ve bakımını yapma sürecini basitleştirmeyi ve sıfırdan bir Kubernetes kümesi kurmak yerine uygulama oluşturmaya odaklanmak isteyen kuruluşlara konteyner tabanlı bilgi işlemin avantajlarını sunmayı vaad ediyor.

13 Haziran 2018’de, Azure Kubernetes Hizmeti (AKS) genel kullanıma sunuldu. Azure mühendislerinin müşterilerin tam olarak yönetilen Kubernetes kümeleri için sürekli izleme, operasyon ve destek sağladığından emin olarak üretim Kubernetes uygulamalarımızı dağıtabilir ve yönetebiliriz.

Evet, Kubernetes’in hızla ilerleyen güzel bir yolculuğu var.

No alt text provided for this image

Şekil 1. Kubernetes 2018 OSCON ödülü.

Kubernetes, 2018 “O’Reilly Open Source Conference”da, ödül de aldı.

Mikro servis dünyasının bu denli gelişmesinde tartışmasız büyük bir payı olan Docker’dan bahsetmeden olmaz. Docker konusunda yazdığım yazılarıma aşağıda olan linklerden ulaşabilirsiniz.

https://asiyeyigit.com/docker-bolum-7/

https://asiyeyigit.com/docker-bolum-6/

https://asiyeyigit.com/docker-bolum-5/

https://asiyeyigit.com/docker-bolum-4/

https://asiyeyigit.com/docker-bolum-3/

https://www.linkedin.com/pulse/docker-b%C3%B6l%C3%BCm-2-asiye-yigit/

https://www.linkedin.com/pulse/docker-asiye-yigit/

Ama en başa dönelim. Monolitik Mimari… Nedir Monolitik Mimari, neyi farklı yapmaya başlar oldukta, işlerimiz daha kolaylaştı?

2000’lerin başında, yazılım geliştirmek için popüler bir tasarım paradigması olan Servis Odaklı Mimarinin (SOA) yükselişine o yıllarda sektörde olan hepimiz tanık olduk. Basit bir ifadeyle, SOA, farklı platformlar ve diller üzerinden yapılan birden çok hizmeti ortak bir iletişim mekanizması aracılığıyla entegre etmemizi gerektiren büyük ölçekli kurumsal uygulamalar oluşturmamıza izin veren bir yazılım mimarisi modelidir.

No alt text provided for this image

Şekil 2. SOA Mimarisi

Kurumsal uygulamalar gibi büyük ölçekli yazılım çözümleri için SOA tercih edilir. SOA, uygulamayı modülerleştirmeye odaklanmak yerine birden çok hizmeti tek bir uygulamada entegre etmeye odaklanır. Bir SOA’daki çeşitli servisler arasındaki etkileşim için kullanılan ortak iletişim mekanizması, Kurumsal Servis Veri Yolu (ESB: Enterprise Service Bus) olarak adlandırılır.

SOA tabanlı uygulamalar doğası gereği monolitik olmaya daha eğilimlidirler. Bu, kullanıcı arayüzünüzün veya sunum katmanınızın, iş mantığınızın veya uygulama katmanınızın ve veri tabanı katmanınızın tek bir platforma entegre edilmiş olduğu anlamına gelmektedir.

Bir örnek ile daha anlaşılır yapmaya çalışayım. Bir e-ticaret mağazası düşünelim. Bir e-ticaret sitesine birden fazla cihaz ile erişilmesi gerekir. Yani, mobile için, dizüstü bilgisayarlar için ayrı kullanıcı arabirimleri olması gerekir. E-ticaret uygulamalarınızın düzenli çalışmasını sağlamak için birden fazla işlemin veya servisin birbiriyle etkileşimli çalışması gerektiğini de biliyoruz. Bu servisler, hesap oluşturma, ürün kataloğu görüntüleme, alışveriş sepetini oluşturma ve doğrulama, sipariş onayı, ödeme mekanizması oluşturma gibi sıralanabilir.

Monolitik bir uygulamada, tüm bu servisler tek bir uygulama katmanı altında çalışır, yani bir e-ticaret yazılımı mimarisi aşağıdaki gibi görünür.

No alt text provided for this image

Şekil 3. Monolitik uygulama mimarisi.

Sunulan servislerin sayısı arttıkça uygulamanın boyutunun büyüyeceği açıktır. Bu durum, geliştiricilerin uygulama kod tabanını oluşturması ve sürdürmesi için bunaltıcı, hataya açık ve yorucu olabilir. Mevcut yığınınızı güncellemek sadece zor değil, aynı zamanda o yığındaki bir şeyi değiştirmek de bir kabus haline gelebilmektedir. Her değişiklik, geliştiricilerin,  uygulamanın tamamını yeniden oluşturmasını gerektirir. Elbette müşteri sayısındaki artışla birlikte, daha fazla işlem talebimiz olacak ve daha fazla kaynak gerekecektir. Bu nedenle, ölçeklenebilir çözümler oluşturmak çok önemlidir. Monolitik uygulamalarla, yalnızca bir yönde, yani dikey olarak ölçeklendirme yapabiliriz, maalesef yatay olarak ölçeklendirme yapamayız. Bu zorunluluk, bellek ve hesaplama gücü gibi daha fazla donanım kaynağı ekleyerek uygulamayı tek bir makine üzerinde ölçeklendirebileceğimiz anlamına gelmektedir. Yani, birden çok makineye yayılan yatay ölçeklendirmeyi sağlayamayacağız.

Ve işte hayatımızı kurtaran bir mimari hayatımıza girdi… Mikro servisler… Mikro servis mimarisi, SOA’nın özelleştirilmiş ve monolitik bir mimarinin dezavantajlarının üstesinden gelen alternatif bir model olarak düşünülebilir.

Bu mimaride, uygulamayı, diğer mevcut servislerden veya bir bütün olarak uygulamanın kendisinden bağımsız olarak oluşturulabilen, dağıtılabilen, ölçeklenebilen ve hatta bakımı yapılabilen daha küçük bağımsız servislere bölerek modülerleştirmeye odaklanıyoruz. Bu bağımsız servislere, mikro servisler, dolayısıyla Mikro Servis Mimarisi adı verilir.

No alt text provided for this image

Şekil 4. Mikro Servis Mimarisi.

Bakın işimiz hangi açılardan daha kolay hale geliyor?

Geliştiricilerin her biri bir veya daha fazla servis oluşturan/sürdüren küçük ekiplere ayrılması sağlanarak karmaşıklık azaltılır.

Her değişiklik için tüm uygulamayı yeniden oluşturmak yerine küçük parçalarda değişiklik yapılmasını sağlayarak riski azaltır

Zaman içinde tek bir noktadan, tüm uygulama yerine bir veya daha fazla servis için teknoloji yığınını aşamalı olarak güncelleme/yükseltme esnekliği sağlayarak bakım işlemlerini kolaylaştırır.

Size herhangi bir dilde servis oluşturma esnekliği sağlamanın yanı sıra, verilen servislerin her birinin ayrı veri modellerini korumanıza da olanak tanır.

Bireysel servis dağıtımlarını, servis yönetimini ve uygulamanın otomatik ölçeklenmesini sağlamak için tam otomatik bir dağıtım mekanizması oluşturabilirsiniz.

Yazılım mimari modellerinin evriminin yanında, yazılım altyapılarının desteklenmesi ve ölçeklenebilir çözüm ve servislerin verimli yönetiminin sağlanması için Docker ve Kubernetes gibi teknolojilerin ortaya çıkması da aslında kaçınılmaz değil miydi? Hep bildik bir anlatım var ama gerçekten de en doğru şekilde bu şekilde ifade edebiliriz, dönüşümün resmini. Yani aşağıdaki şekil ile bu dönüşümü ifade etmek mümkün.

No alt text provided for this image

Şekil 5. Yazılım altyapı evrimi.

İlk görsel fiziksel bir makineyi veya bir donanım sunucusunu göstermektedir. Tipik olarak, uygulamalar oluşturduğumuzda, ana bilgisayar işletim sistemimiz tarafından sağlanan kaynakları kullanırız. Peki ya uygulamayı ölçeklendirmek isterseniz? Bu noktada, başka bir donanım sunucusu isteyebilirsiniz ve/veya mevcut sunucuya büyüyebildiği kadar kaynak eklersiniz, ama unutmayın kaynak ekledikçe, performans doğrusal artmayacaktır, donanım şasesinin bize verdiği maksimum verimliliği geçemeyiz. Sayı arttıkça, maliyetiniz artar. Diğer taraftan, uygulamanızı çalıştırmak için donanımınızın tüm kaynaklarına aynı anda ihtiyacınız olup olmadığını düşünebilirsiniz. Pek değil, öyleyse neden bu kadar büyük bir altyapı kullanalım?

Bu ihtiyaçlar, zorluklar, bugün Sanal Makineler (VM’ler) olarak adlandırdığımız yapılar aracılığıyla BT altyapı kurulumlarını optimize etmek için donanım sanallaştırmasının gelişmesine yol açmıştır. İkinci görselde gördüğünüz gibi, tek bir fiziksel makine veya ana bilgisayar işletim sistemi üzerinden çalıştırılan konuk (guest) işletim sistemleri vardır. Bu, çok sayıda fiziksel makine kurmaya gerek kalmadan birden çok uygulamayı çalıştırmamızı sağlar. Ana işletim sistemi, üzerinde çalışan farklı VM’ler arasında sistematik kaynak dağıtımı ve yük dengelemesi olmasını sağlar.

VM’ler, bakım için yazılımı daha erişilebilir hale getirse ve maliyetleri önemli ölçüde azaltsa da, daha fazla optimizasyon hala mümkündür, her zaman, iyinin iyisi vardır. İnsan aklı nelere kadir?

Bu sorunlar, ihtiyaçlar bir sonraki yeniliğe yol açtı: konteynerleştirme. Daha işletim sistemine özel olan sanal makinelerin aksine, konteynerler uygulamaya özeldir ve onları çok daha hafif hale getirir. Ayrıca, VM’ler birden çok işlemi çalıştırabilirken bir konteyner genelde tek bir işlem olarak çalışır. Bu bizi iki şeye götürür:

Fiziksel bir makinede birden çok konteyner çalıştırabilir veya onu tek bir sanal makinede çalıştırmayı bile düşünebilirsiniz (test ve öğrenme amaçlı).

Konteynerleştirme, sanallaştırma ile rekabet halinde değildir, daha ziyade BT yazılım altyapınızı daha da optimize etmek için tamamlayıcı bir teknolojidir.

Bu dönüşümü gördükten sonra, işte Docker, bu dönüşümü mümkün kılan teknolojilerden birisi. Mikro servis mimarisi ve konteynerleştirme gibi teknolojileri başarabilmemiz için elimizde sağlam araçların olması gerekir.

Docker, dünyanın önde gelen yazılım konteynerleştirme platformudur. Mikro servisinizi, daha sonra bağımsız olarak korunabilen ve dağıtılabilen Docker konteyner olarak adlandırdığımız şeye kapsüller. Bu konteynerlerin her biri, belirli bir iş işlevinden sorumlu olacaktır. Amacımızda buydu zaten, uygulamamızı biribirnden bağımsız ufak parçalara bölebilmek.

Daha önce konuştuğumuz, e-ticaret web sitesi örneğini ele alalım. Hesap oluşturma, ürün kataloğu görüntüleme, alışveriş sepeti oluşturma ve doğrulama, bu mimaride birbirinden ayrı mikro servisler olacaktır. Yani, her biri, konteynerler içinde kapsüllenebilir. Docker konteynerleri, sadece uygulamanın çalışması için gerekli bileşenleri içereceğinden, yani işletim sisteminin hepsini içermeyecek, kernel ve gerekli kütüphaneleri, uygulamanın bağımlı olduğu bileşenleri içermesi yeterli olacağından, daha hafif ve kolay dağıtılabilirdirler.

Biraz Docker Swarm’dan bahsedeyim. Docker’ın, yazılımın paketlenme biçiminde yaptığı değişiklik bence devrim niteliğindedir. Diğer taraftan, böyle pek çok konteyner’i yönetmek kolay bir şey değil. İşte bu konteynerlerin orkestrasyonu noktasında Docker Swarm devreye giriyor.

Swarm, bir Docker ana bilgisayar havuzunu sanal, tek bir ana bilgisayara dönüştürür. Swarm, özellikle ortamını basit bir şekilde yönetmek için orkestrasyona ihtiyaç duyan, birden fazla ortamda çalışan kişiler için kolaylıklar sağlamaktadır.

Kubernetes ve Docker Swarm, ikisi de elbette açık kaynaklı konteyner orkestrasyon araçları olmakla birlikte aralarında temel farklılıklar mevcut.

Benim sektörden gözlemlediğim, Kubernetes, daha fazla karmaşıklıkla daha yüksek talepleri desteklerken Docker Swarm, başlaması hızlı olan temel bir çözüm sunmaktadır. Docker Swarm, hızlı dağıtımları ve basitliği tercih eden geliştiriciler arasında oldukça popülerdir. Diğer taraftan, eşzamanlı olarak, Kubernetes, popüler hizmetleri çalıştıran çeşitli yüksek profilli internet firmaları tarafından üretim ortamlarında yoğun olarak kullanılmaktadır.

https://www.youtube.com/watch?v=9_s3h_GVzZc benim favorim Nana’nın hazırladığı kısa video çok güzel Docker, Docker Swarm ve Kubernetes arasındaki farklılıkları anlatıyor.

No alt text provided for this image

Şekil 6. Docker ve Kubernets (K8s).

No alt text provided for this image

Şekil 7. Kubernetes

No alt text provided for this image

Şekil 8. Docker Swarm

No alt text provided for this image

Şekil 9. Kubernetes ve Docker Swarm

Docker olmadan Kubernetes çalışır mı, evet. Kubernetes olmadan Docker çalışır mı, evet.

Docker’ın rakiplerine bakalım, ilk olarak podman’i söyleyebilirim.

Red Hat OpenShift 4 ve RHEL8’de artık Docker Daemon desteklenmiyor. Elbette, Docker imajlarını kullanabilirsiniz. Yani Red Hat artık, konteyner motoru olarak Docker’ı kullanmıyor. Neden olarakta, Docker motoru, “daemon” modeline bağlı olduğu için artık yeni kullanım durumlarında yeterince hızlı olamadığı ifade ediliyor. Ek olarak, Docker motorunun, Kubernetes’in gelişim hızına ayak uyduramadığı da nedenler arasında sayılıyor.

Scott Mccarty, https://www.linkedin.com/pulse/part-i-docker-supported-openshift-4-rhel-8-scott-mccarty/ bu makalesinde,  ilerisi için, Docker daemon’ın ve API’sinin teknolojiye yön veremeyeceğinin ve Kubernetes API’nin çok daha önemli olacağının altını çiziyor. Yine bu yazısında, OpenShift 4’ün CRI-O “Container Runtime Interface – OpenShift” ile ve RHEL 8’in de podman ile çalışacağını belirtiyor.

Hazır podman’den söz açılmışken, biraz daha detay aktarayım.

Malum, mikro servis dünyasında, konteynerler, imajlar ve imaj kayıtları birbirleriyle etkileşime girebilmelidir. Yani, imajlar oluşturabilmeli, bu imajları depolarınıza alabilmelisiniz. Yine, imaj deposundan imaj alabilmeli ve bu imajlardan konteyner oluşturabilmeniz gerekir.

Podman, konteynerleri ve konteyner imajlarını yönetmek ve imaj kayıtları ile etkileşim kurmak için kullanılan açık kaynaklı bir araçtır. Aşağıdaki temel özellikleri sunar:

Open Container Initiative (OCI) tarafından belirtilen imaj biçimini kullanır. Bu özellikler standart, topluluk tarafından yönlendirilen, tescilli olmayan bir imaj formatı tanımlar.

Podman, yerel imajları yerel dosya sisteminde saklar. Bu sayede, gereksiz istemci/sunucu mimarisini veya yerel makinede çalışan arka plan programlarına sahip olmayı önlemiş olur.

Podman, Docker CLI ile aynı komut modellerini takip eder, bu nedenle yeni bir araç seti öğrenmeye gerek yoktur.

Podman, Kubernetes ile uyumludur. Kubernetes, konteynerleri yönetmek için Podman’i kullanabilir.

Aslında buraya kadar kademe kademe, konteyner, ama sonra niye Kubernetes veya Docker Swarm’a ihtiyaç duyulduğunu aktarmış olsamda, genel bir özet olarak konteynerlerin limitasyonlarını ifade etme gereği hissediyorum.

Konteynerler, servisleri paketlemek ve çalıştırmak için kolay bir yol sağlar. Bir kuruluş tarafından yönetilen konteynerlerin sayısı arttıkça, bunları manuel olarak başlatma işi, dış taleplere hızla yanıt verme ihtiyacıyla birlikte katlanarak artar.

Bir üretim ortamında konteynerleri kullanırken, firmalar genellikle şunlara ihtiyaç duyar:

Çok sayıda servis arasında kolay iletişim.

Konteyner sayısından bağımsız olarak uygulamalardaki kaynak sınırlarının yönetilmesi.

Uygulama kullanım artışlarına yanıt vermek için çalışan konteynerleri artırmak veya azaltmak.

Servisin bozulmasına tepki verebilmek.

Yeni sürümün kademeli olarak bir dizi kullanıcıya sunulması.

Konteyner çalışma zamanları (Podman gibi) yukarıdaki gereksinimleri yeterince karşılamadığından, kuruluşlar/firmalar genellikle bir kapsayıcı orkestrasyon teknolojisine ihtiyaç duyar.

Yazımın başından beri ifade ettiğim sonuca burda da ulaştık J, yani Kubernetes, konteyner uygulamalarının dağıtımını, yönetimini ve ölçeklendirilmesini basitleştiren bir orkestrasyon hizmeti sunar.

Kubernetes’in bize sağladıklarını aşağıdaki gibi özetleyebiliriz.

Hizmet Keşfi ve Yük Dengeleme:

Kubernetes, her bir konteyner grubuna tek bir DNS girişi atayarak servisler arası iletişimi sağlar. Bu şekilde, istekte bulunan servisin yalnızca hedefin DNS adını bilmesi yeterlidir. Bu da kümenin konteynerin konumunu ve IP adresini değiştirmesine izin vererek servisin etkilenmemesini sağlar. Bu, servisi sağlayan konteyner havuzu boyunca talebin yük dengelemesine izin verir. Örneğin, Kubernetes, pod’ların kullanılabilirliğini dikkate alarak bir MySQL servisine gelen istekleri eşit olarak bölebilir.

Yatay Ölçekleme:

Uygulamalar, Kubernetes komut satırı arabirimi veya web kullanıcı arabirimi ile bir yapılandırma kümesiyle manuel olarak veya otomatik olarak yukarı ve aşağı ölçeklenebilir.

Kendi kendini İyileştirme:

Kubernetes, konteynerleri izlemek için kullanıcı tanımlı durum denetimlerini kullanabilir ve arıza durumunda bunları yeniden zamanlayabilir.

Otomatik Kullanıma Sunma:

Kubernetes, güncellemeleri kademeli olarak uygulama konteynerlerine dağıtabilir. Yeni güncellemeleri kullanıma sunma sırasında bir şeyler ters giderse Kubernetes, dağıtımın önceki yinelemesine geri dönebilir.

“Secrets” ve Konfigürasyon Yönetimi:

Uygulama sırları (secrets), kullanıcı adları, parolalar ve servis uç noktaları (service endpoints) veya gizli tutulması gereken herhangi bir yapılandırma ayarı olabilir. Konteynerleri yeniden oluşturmadan uygulamalarınızın yapılandırma ayarlarını ve gizli anahtarlarını yönetebilirsiniz.

Operatörler:

Operatörler, uygulamanın yaşam döngüsü bilgisini de Kubernetes kümesine getiren paketlenmiş Kubernetes uygulamalarıdır. Operatörler, uygulama durumundaki değişikliklere tepki veren kümenin durumunu güncellemek için Kubernetes API’sini kullanır.

Evet şimdi gelelim, bize tam da ihtiyacımız olan kurumsal özellikleri sunan Red Hat OpenShift Container Platform’a (RHOCP).

Dikkat ederseniz, hep taş üstüne taş ekleyerek ilerliyoruz ve artık en tepede ne var, RHOCP.

Red Hat OpenShift Konteyner Platformu (RHOCP), bir Kubernetes konteyner altyapısı üzerine inşa edilmiş bir dizi modüler bileşen ve servisler içerir. RHOCP, PaaS platformu sağlamak için, uzaktan yönetim, çoklu kiralama, artırılmış güvenlik, izleme ve denetleme, uygulama yaşam döngüsü yönetimi ve geliştiriciler için self servis arabirimleri gibi gerekli olan her şeyi içerir.

Red Hat OpenShift v4’ten başlayarak, bir OpenShift kümesindeki ana bilgisayarların tümü, temel işletim sistemi olarak Red Hat Enterprise Linux CoreOS’u kullanır.

OpenShift, bir Kubernetes kümesine aşağıdaki özellikleri ekler:

Entegre Geliştirici İş Akışı:

RHOCP, yerleşik bir konteyner kayıt defterini, CI/CD ardışık düzenlerini ve kaynak depolardan konteyner imajlarına kadar “artifacts” oluşturmak için kullanılan S2I’yi entegre eder.

“Routes”:

Servisleri dış dünyaya açmak için “routes” yapısını kullanmanıza olanak sağlar.

Metrikler ve Günlük Kaydı:

Yerleşik ve kendi kendini analiz eden ölçüm servisini ve toplu günlük kaydını platforma dahil eder.

Birleşik Kullanıcı Arayüzü (Unified UI):

OpenShift, tüm farklı yetenekleri yönetmek için birleştirilmiş araçlar ve kullanıcı arayüzü sağlar.

Yazımı tamamlama zamanı geldi. Kubernetes’den başladım, SOA, mikro servis yapılar derken, Docker’dan bahsetmeden olmaz dedim, niye Docker Swarm, Kubernetes ihtiyacı var ki diye sorguladım, ardından PaaS için Kubernetes üzerine inşa edilen OpenShift’e değindim.

Özet olarak,

Konteynerler, çok az ek yük ile oluşturulan yalıtılmış uygulama çalışma zamanlarıdır.

Bir konteyner imajı, bir uygulamayı tüm bağımlılıklarıyla birlikte paketleyerek uygulamayı farklı ortamlarda çalıştırmayı kolaylaştırır.

Podman, Docker gibi uygulamalar, standart Linux çekirdeğinin özelliklerini kullanarak konteynerler oluştururlar.

Konteyner imaj kayıtları, konteyner imajlarını birden çok kullanıcıya ve ana bilgisayara dağıtmak için tercih edilen bir mekanizmadır.

OpenShift, Kubernetes kullanarak birden çok konteynerden oluşan uygulamaların orkestrasyonunu yapar.

Kubernetes, konteyner uygulamaları için yük dengeleme, yüksek kullanılabilirlik ve kalıcı depolamayı yönetir.

OpenShift, Kubernetes’e çoklu kiralama, güvenlik, kullanım kolaylığı ve sürekli entegrasyon ve sürekli geliştirme özellikleri ekler.

OpenShift route’ları, konteyner uygulamalarına yönetilebilir bir şekilde harici erişim sağlar.

Sarav Asiye Yiğit – 3 Nisan 2022

Kaynakça:

https://kubernetes.io/blog/2018/07/20/the-history-of-kubernetes-the-community-behind-it/

https://www.dynatrace.com/news/blog/kubernetes-vs-docker/

https://timber.io/blog/docker-and-the-rise-of-microservices/

https://thenewstack.io/kubernetes-vs-docker-swarm-whats-the-difference/#:~:text=As%20a%20platform%2C%20Docker%20has,run%20equally%20well%20in%20Swarm.

http://crunchtools.com/why-no-docker/

https://www.linkedin.com/pulse/part-i-docker-supported-openshift-4-rhel-8-scott-mccarty/

https://learn.redhat.com/t5/Containers-DevOps-OpenShift/podman-vs-CRI-O-vs-RunC/td-p/9639