🏗️ Kubernetes Mimarisi

Kubernetes Mimarisi: Kubernetes cluster'ını bir şirket gibi düşün: Control Plane yönetim katıdır — CEO (API Server), hafıza/İK (etcd), planlayıcı (görev atar), yöneticiler (contr

Kubernetes cluster'ını bir şirket gibi düşün: Control Plane yönetim katıdır — CEO (API Server), hafıza/İK (etcd), planlayıcı (görev atar), yöneticiler (controller'lar) — Worker Node'lar ise işin gerçekten yapıldığı ofislerdir, her birinde sorumlu (kubelet), posta odası (kube-proxy) ve çalışanlar (pod'lardaki container'lar) vardır. Peki "neyin olması gerektiğine karar verme" (Control Plane) ile "işi gerçekten yapma" (Worker Node'lar) neden tek bir bileşene değil de ayrı bileşenlere bölünüyor? Çünkü hem karar veren hem de uygulayan tek bir nokta, uygulamayla meşgulken karar vermeye devam edemez — rolleri ayırınca şirket, tek tek ofisler tamir altındayken bile karar vermeye (çökmüş bir pod'u yeniden zamanlamaya) devam eder. Bu, iyi tasarlanmış bir Java servisinin her şeyi tek bir thread'de yapmak yerine orkestrasyon katmanını (bir scheduler/coordinator) worker thread'lerinden ayırmasıyla aynı mantıktır. Production'da bu ayrım, tek bir Worker Node'un çökmesinin tüm cluster'ın karar verme mekanizmasını da düşürmemesinin tam olarak sebebidir — Control Plane etkilenen pod'ları başka yere yeniden zamanlar.

Kubernetes Cluster Mimarisi

Control Plane Bileşenleri

kube-controller-manager

Worker Node Bileşenleri

Pratik: Cluster mimarisini kubectl ile oku

TODO alanlarını cluster bilgisi, node listesi, kube-system pod'ları ve node detaylarıyla tamamla.

Bir Pod İsteği Cluster İçinde Nasıl Yürür

kubectl istek yollar

Manifest veya komut API Server'a HTTPS isteği olarak gider.

API Server doğrulanmış hedef durumu etcd içine yazar.

Scheduler node seçer

Kaynak istekleri, taint ve affinity kurallarına göre uygun node seçilir.

Seçilen node üzerindeki kubelet container runtime'a pod'u başlatmasını söyler.