Konteyner orkestrasyonu sağlayan 2015 yılında opensource olan bir projedir. Önceki yazımda da bahsettiğim gibi node üzerine kurulan serverlardan siz istediğinizi control plane ilişkisi adı altında tanımalayabiliyorsunuz. Bu componentler de tanımladığınızda kuruluyor.
Componentleri tanıtmadan önce sizlere konteyner orkestrasyonu nedir bunu anlatmak istiyorum.
Şimdi DevOps ta biz sistemi otomatikleştiriyoruz ve bu sistemin dağıtım süreci olsun yönetimi olsun konteynerlar,yazılım uygulamaları gibi şeyleri paketlemenin en verimli yolu konteynerlardır.
Konteyner orkestrasyonu dağıtılmış bir sistemde birden fazla Konteynerin dağıtımını yöneten ve otomatikleştirme sürecidir. Yani bir otomasyon biçimidir.
Açık kaynaklı 4 tane popüler konteyner orkestrasyon çözümü vardır bunlar işte Kubernetes, Docker Swarm, Apache Marathon ve Nomad dır.
Ayrıca ticari olarakta Mesosphere DC/OS ve Amazon ECS gibi çeşitli ticari Konteynerlarda mevcuttur.
Yukarıdaki görsele göre aşağıda bu componentleri açıklayacağım.
kubelet = sizin kodunuzun yaşayıp yaşamadığını gösterir. (kubectl get nodes komutuyla bunu tespit edebiliriz)
k-proxy = networkteki işlemleri yapıyor
c-m (control manager) = bu bizim işte joblarımız çalışıyor mu ya da işte nodelarımız aktif mi bunları kontrol ve takip ediyor.
c-c-m (cloud controller manager) = bu da cloud provider apiları ile haberleşiyor mu onu sağlıyor.
api = tüm işlemlerin birbirleriyle haberleşmesini sağlıyor.
etcd = tüm key-value veri çiftleri burada saklanıyor.
sched = hangi pod müsait onu gösteriyor.
Bir komut yazdığımızda süreç nasıl ilerliyor yukarıdan görebiliriz.
Önce api serverlarımıza diyoruz ki biz bir pod oluşturacağız sonra işte key-value değerlerimiz oluşuyor bunu tekrar api serverlarımıza bildiriyor sonra biz tekrar scheduler a soruyoruz boş yer var mı apimiz buna cevap veriyor sonra kubelete gidiyor diyor sen burada pod çalıştır pod çalıştıktan sonra api servera gidiyor ve yine her adımda oluştuğu gibi etcd key-value değerleri atanıyor.
Şimdi en küçük deploy edilebilir birimimiz olan podlardan bahsedelim biraz.
Pod
Podlar en küçük deploy edileibilir birimimizdir. Aynı namespace ve storage i paylaşırlar yani aslında containerların sarıldığı bi sağlayıcıdır.
Sidecar Pattern
Podlar içindeki konteynerlar aynı ip ve volume alanını paylaşırlar. Bu sayede main uygulamamız yanında ona yardımcı olan (log toplama ve proxy yapma gibi) ikinci bir Konteyner çalıştırabiliriz. Buna sidecar pattern denir.
Podlar Öldüğünde Ne Olur
Bir pod çöktüğünde veya node kapandığında o podun içindeki veriler kaybolur eğer harici bir storageiniz yoksa. İşte bu noktada devreye deployment objesi girer.
Deployment : Siz bana her zaman 3 tane pod çalıştır dersiniz. Eğer pod çökerse kubernetes’in o meşhur controller manager bileşeni bunu fark eder ve hemen yeni bir pod oluşturur buna self-healing denir.
Services
Podların ip adresleri değişkendir. Bir pod silinip yenisi geldiğinde ip adresi değişir. İşte bu noktada serviceler kullanırız.
ClusterIP = Sadece cluster içindeki podları birbirine ulaşmasını sağlar.
NodePort = Uygulamayı tunelling ile belirli bir port üzerinden dışarı açar.
LoadBalancer = Cloud providerlar üzerinden dış ip almamızı sağlar (AWS, Google Cloud vb.)
Sonuç olarak 2015 yılında google kendi iç projesi olarak Borg’dan esinlerek açık kaynaklı hale getirdiği bu devasa ekosistem, bugün modern yazılım dünyasının işletim sistemidir. Docker ile beraber bir sürü projeyi ayağa kaldırıp yaptığımız işlemler kubernetesin beyni ile birleştiğinde daha yönetilebilir sistem haline gelmiştir.
