Kubernetes Cluster Mimarisi
Table of Contents
Bu yazımda yazılım sistemlerinin en önemli araçlarından birisi olan Kubernetes'in mimarisi , üzerinde bulunan component'ların birbirleriyle olan ilişkisi ve bu component'ların hangi amaçla kullanıldığı hakkında yazacağım.
Kubernetes container yaşam döngüsünü otomatik olarak düzenlemeye yarayan, container'ları sunucularda veya bulutta dağıtmak ve yönetmek için kullanılan bir araçtır.
Kubernetes cluster iki ana yapıdan oluşur.
- Control Plane / Master
- Worker Node
Control Plane / Master
Control Plane dört ana yapıdan oluşur. Bunlar Api-Server, Etcd, Scheduler ve Controller Manager yapılarıdır.
1. Api-Server
Api Server kullanıcıların Kubernetes Cluster'a komut göndermek için ilk gittikleri yerdir. Kullanıcı kubectl komutu ile Api Server ile iletişim kurar.
Kubernetes içerisindeki bütün component'lar birbirleriyle iletişim kurmak için Api Server'ı kullanır. İçeriden ve dışarıdan gelen bütün istekler bu yapı aracılığıyla iletilir.
2. Etcd
Etcd ise bir distributed key value veri deposudur. Kubernetes konfigürasyonunu ve durumunu saklar. Kubernetes'de bulunan bütün kaynakların bilgisi Etcd'de bulunmaktadır. Bu bilgiyi ise diğer component'lar Api Server ile sağlarlar.
Örneğin, bir user Kubernetes'de bir podun bilgisini isterse öncelikle Api Server'a gider ve Api Server, Etcd'den bu bilgiyi alır ve kullanıcıya'a iletir.
3. Scheduler
Scheduler, Kubernetes cluster'ındaki pod'ların hangi node'lar ile çalışacağına karar verir. Buna karar verirken pod gereksinimlerine, Cpu-Ram gereksinimlerine bakarak aynı zamanda node üzerinde kullanulan Cpu-Ram ve trafik miktarini baz alır.
Örnek vermek gerekirse, bir Worker Node'unda çok fazla Cpu-Ram tüketimi var ise bu pod'u daha az Cpu-Ram kullanan pod'a aktarır. Aynı şekilde Auto-scaling konfigürasyonu yapıldığı zaman Scheduler Cpu-Ram miktarina göre node ve pod sayısını yönetilmesini sağlar.
4. Controller Manager
Controller Manager, Kubernetes üzerindeki en önemli component'lardan bir tanesidir. Kubernetes cluster'ı sürekli izler ve herhangi bir sorunda düzeltilmesi için ilk adımı atar.
Controller Manager controller'ların bir araya gelmesinden oluşur. Bunlardan önemli olanlardan bazıları ise Node controller, Replication Controller ve Deployment Controller olarak örnek verilebilir.
Kubernetes'e bir application ve 5 pod şeklinde çalıştırılması gerektiği declarative bir şekilde tanımlandığı bir durumu bir senaryo olarak ele alalım. Bu şekilde tanımlanmasına Desire State denir. Control Manager ise bu durumu takip etmekten sorumludur. Örneğin, 1 pod bir şekilde sorun yaşayıp çalışmadığı durumda Control Manager tekrardan bir pod ayağa kaldırır. Sonuç olarak, Desire State olarak tanımlanan yapıyı sağlamakla yükümlüdür.
Worker Node
Worker Node ise container yapılarının çalıştığı bölümdür. Kubelet, kube-proxy ve container runtime bileşenlerinden oluşur.
1. Kubelet
Kubelet, container'ların çalışmasından sorumlu bir yapıdır. Desire State kullanıcı tarafından Control Plane'de tanımlandığında Control Plane kubelet'e Api-Server aracılığı ile Desire State'i bildirir. Kubelet ise worker node'da bulunan container runtime ile container'ı ayağa kaldırır.
2. kube-proxy
Kube-proxy, Worker Node'da bulunan network yapısıdır. Kube-proxy sayesinde podlar birbiri arasındaki network trafiğini yönlendirebilir. Ayrıca, Kube-proxy birden fazla pod bulunduğunda bir servis aracılığıyla bu pod'lara network trafiğini load-balancing ile yönlendirilmesinden sorumludur.
İşleyiş Mekanizması
Kubernetes Cluster mimarisinde bulunan component'ların görevlerini açıkladıktan sonra Kubernetes Cluster'ına bir deployment yapıldığında hangi aşamalardan geçtiğini örnek bir senaryo ile adım adım işleyelim:
- Kubernetes'e bir deployment yapmak istediğimizde öncelikle yaml formatında dosyayı kubectl ile birlikte Api Server'a iletiliriz.
- Kullanıcı, Api Server'dan gerekli authentication ve authorization adımlarını geçtikten sonra Etcd veritabanına yaml dosyamızı kaydeder. Bu bilgilerin içerisinde resources, limit, cpu, memory, image adı ve label'lar key value olarak Etcd'de tutulur.
- Etcd'ye yaml yazıldıktan sonra tekrardan Api Server aracılığı ile Schedular'a ulaşılır. Scheduler ise Worker Node'ların resources kullanımına, Cpu-Ram kullanımına ve healthy durumuna bakarak gerekli bir Worker Node seçer.
- Api Server hangi Worker Node schedule edilecekse orada bulunan kubelet ile iletişime geçer.
- Kubelet ise üzerinde bulunan container runtime ile iletişime geçer ve bir container ayağa kaldırır. Container runtime ayağa kalkarken etcd bulunan image'ı Api-Server aracılığıyla bularak container'ı başlatır.
- Bu adımlar tamamlandıktan sonra bütün sorumluluğu Controller Manager devralır.
- Pod'da bir sorun yaşandığı zaman Controller Manager yeni bir pod ayağa kaldırır. Eğer ki Desire State güncellenirse Controller Manager tekrardan gerekli güncellemeleri yapar.
Leave a comment 💬
All Comments
No comments yet.