Merhaba arkadaşlar, bu seri yazısında sizlere Kubernetes mimarisinden bahsedeceğim. Kubernetes aşağıdaki ana bileşenlere sahiptir ve bunlardan oluşur diyebiliriz.

• Master ve worker node’lar
• Controller’lar
• Servisler
• Container Pod’ları
• Namespaces
• Ağ ve politikalar
• Storage

Bir kubernetes cluster, bir master node’dan ve bir dizi worker node’dan oluşur. Cluster, API çağrıları yoluyla hem iç hemde dış trafiği controller’lara yönlendirir. Bundan sonraki bileşenlere daha yakından bakalım.

Master Node

Master node, cluster içerisindeki çeşitli sunucu ve yönetici işlemlerini yürütür. Master node’un bileşenleri arasında kube-apiserver, kube-scheduler ve etcd veritabanı bulunmaktadır. Kubernetes olgunlaştıkça cloud-controller-manager gibi özel ihtiyaçları karşılamak için bileşenler oluşturuldu.

DNS servisleri gibi gerekli olan birçok eklenti vardır. Kubernetes henüz cluster düzeyinde log kaydı ve monitoring gibi yerel bileşenler geliştirmediği için bu çözümleri üçüncü parti yazılımlar ile sağlayabilmekteyiz.

kupe-apiserver

kube-apiserver, kubernetes cluster mekanizmasının ortasında yer almaktadır. Hem içerideki hemde dışarıdaki tüm istekler bu araç üzerinden gerçekleştirilir. Tüm istekler bu ajan tarafından kabul edilir ve doğrulanır, ayrıca etcd veritabanına yapılan tek bağlantı bu ajanla yapılır. Sonuç olarak cluster içerisindeki ana işlem yeridir diyebiliriz.

kube-scheduler

kube-scheduler, hangi node’un bir pod’a ev sahipliği yapacağını belirlemek için bir algoritma çalıştırır. Scheduler, mevcut kaynakları görüntüler ardından kullanılabirlilik ve başarıya göre pod’u konuşlandırmayı dener ve yeniden dener. Sonunda bir pod bir yere konuşlandırılana kadar bu işlem devam eder.

Algoritmayı etkilemenin birkaç yolu vardır ve bunun için özel bir scheduler kullanılabilir. Dilerseniz pod’u belirlediğiniz bir node’a konuşlandırabilirsiniz ancak diğer ayarlar nedeniyle bekleme durumuna düşebilir.

Başvurulan ilk ayarlardan bir tanesi pod’un geçerli kota kısıtlamaları dahilinde dağıtılıp, dağıtılmayacağıdır. O halde uygun yerleşimi belirlemek için node’ların taint ve toleration’larını ayrıca pod’ların label’ları kullanır.

etcd Veritabanı

Cluster’ın durumu, ağ iletişimi ve diğer kalıcı bilgiler etcd veritabanında veya b+ ağaçlarında key-value olarak depolar. Bir ekleme noktası bulmak ve değiştirmek yerine veriler daima sonuna eklenir. Verilerin önceki kopyaları daha sonra bir sıkıştırma işlemi ile çıkartılmak üzere işaretlenir. HTTP kütüphaneleri ve cURL ile birlikte çalışır.

Bir değerin değiştirilmesi işlemi, eş zamanlı olarak yapılan talepler kube-apiserver üzerinden yapılır ve istek boyunca seri halde etcd veritabanına eklenir.

Worker Node

Tüm worker node’lar kubelet ve kube-proxy’i ve container engine’i (Docker veya rkt) çalıştırır. kubelet, tüm node’lara yüklenen temel Docker Engine’i ile etkileşime girer ve çalışması gereken container’ların gerçekten çalıştığına emin olur. kube-proxy, container’ların ağ bağlantısını yönetmekle sorumludur. Bu işlemi iptables üzerinden yapar.

Kubernetes’de henüz cluster tabanlı bir log kaydı tutucusu yok. Bu işlemi Fluentd adında bir CNCF projesi kullanılıyor. Uygulandığınde cluster için iletileri filtreleyen, arabelleğe alan ve yönlendiren birleştirilmiş bir log katmanı sağlar.

kubelet

kubelet ajanı worker node’lar için değişiklik ve yapılandırma sağlayan bir araçtır. Pod öznitelikleri için API çağrılarını alır. (Bir pod’un öznitelikleri YAML veya JSON dosyasıdır.)

Bir pod’un storage’a, secrets’a veya configMaps’e erişim sağlaması gerekiyorsa, kubelet bu erişimi oluşturmayı sağlayacaktır.

Pod

Kubernetes’in tüm amacı bir container’ın yaşam döngüsünü düzenlemektir. Belirli container’lar ile etkileşime geçmiyoruz bunun yerine çalışabileceğimiz en küçük birimler pod’lardır. Paylaşılan kaynaklar nedeniyle, bir pod’un tasarımı tipik olarak container başına bir işlem mimarisi izler.

Bir pod içindeki container’lar paralel olarak başlatılır. Sonuç olarak, bir pod içinde ilk önce hangi container’ın kullanabileceğini belirlemenin bir yolu yoktur.

Pod başına sadece bir IP adresi vardır. Birden fazla container varsa IP’yi paylaşmaları gerekir. Birbiriyle iletişim kurmak için IPC veya paylaşılan bir dosya sistemi kullanabilirler. Genelde bir pod’da iki tane container barındırma sebebi birisinin diğer container içerisinde olanların log kaydını tutma ihtiyacıdır.

Container

Kubernetes orchestration’u container seviyesinde doğrudan manipülasyona izin vermezken, container’ların tüketmesine izin verilen kaynakları yönetebiliriz.

PodSpec’in resources bölümünde kaynak yönetimi yapabilirsiniz.

resources:
  limits:
    cpu: "2"
    memory: "7Gi"
  requests:
    cpu: "1"
    memory: "512Mi"

Kaynak kullanımını yönetmenin başka bir yolu bir namespace’deki sınırlamaların ayarlanmasına izin veren bir ResourceQuota nesnesi oluşturmaktadır.

Service

Dağıtılmış her nesnenin, kaynakları birbirine bağlayan ve bir şeyin yıkılması ve yerine yenisi konulması durumunda yeniden bağlanacak olan esnek ve ölçeklenebilir bir nesneye ihtiyacı vardır. Her servis, gelen istekleri birçok pod arasında dağıtmak için tek bir NodePort veya LoadBalancer gibi belirli bir trafiği işleyen bir mikroservistir.

Servis, gelen talepler için erişim politikalarını da yönetir. kaynak kontrolü ve güvenlik için faydalıdır.

Controller

Orchestration için önemli bir kavram controller kullanımıdır. Çeşitli contoller’lar Kubernetes ile birlikte gelir ve dilerseniz sizde oluşturabilirsiniz. Controller, belirli bir nesne durumu için kube-apiserver’ı sorgulayarak, bildirilen durum geçerli durumla eşleşene kadar nesneyi değiştirir.

Ağ Kurulumu

Önceki tüm bileşenlerin çalışmasını sağlamak, yapılandırma ve yönetimine alışkın olmamız lazım. Ancak tamamen işlevsel bir Kubernetes cluster elde etmek için, ağında uygun şekilde kurulması gerekecektir.

IaaS çözümlerine dayalı VM’ler dağıtma konusunda deneyiminiz varsa, bu tanıdık gelecektir. Bir pod, aynı IP adresini paylaşan ortak yetleştirilmiş container grubudur. Ağ perspektifinden bakıldığında, bir pod fizilsek ana bilgisayarın sanal makinesi olarak görülebilir. Ağın, podlara IP adresleri ataması ve herhangi bir node’daki tüm podlar arasında trafik yolları sağlaması gerekir.

Bir container orchestration sisteminde çözülmesi gereken üç ana ağ oluşturma sorunu vardır.

• Eşleştirilen container’dan container’a iletişimi (Pod sistemi ile çözülmüştür.)
• Pod’dan pod’a iletişim
• Pod’dan dışarıya iletişim (Servis konsepti ile çözülmüştür)

Kubernetes pod’dan pod’a iletişim kurabiliyor olmasını sağlamak için ağ yapılandırması yapmasını bekler, bunu sizin için ne yazıkki yapmaz.

Bu noktada Kubernetes Mimarisi yazımın sonuna gelmiş bulunmakdayız. Bir sonraki yazımda teoriyi daha iyi anlamamız adına laboratuvar yapmayı planlıyorum. Laboratuvar yazımıza buradan geçebilirsiniz, görüşmek üzere !

Umarım bu yazı sizin için bilgilendirici olmuştur. Yazıyla ilgili bir sorunuz, görüşünüz veya isteğiniz varsa alt kısımda bulunan yorumlardan veya mail adresimden iletişime geçebilirsiniz. Bu yazının başkaları içinde bilgilendirici olduğunu düşünüyorsanız sosyal olun ve sosyal medyada paylaşın! Okuduğunuz için teşekkürler !!!!