Kubernetes’in Kalbini Anlamak: Bileşenler, Mimari ve kubectl apply Komutunun Arkasındaki Sihir
- emirhanaydin
- 1 gün önce
- 3 dakikada okunur
Modern yazılım artık tek bir sunucuda çalışan küçük uygulamalardan çok daha fazlası. Mikroservisler, yatay ölçeklenebilirlik, self-healing yani kendini onarma ve otomatik dağıtım gibi şeyler artık standart hale geldi. İşte tam da bu yüzden güçlü bir orkestrasyon platformuna ihtiyaç var ve Kubernetes tam burada devreye giriyor.
Bu dokümanda, Kubernetes’in temel bileşenlerini ve bunların nasıl birlikte çalıştığını adım adım anlatacağım. Amacım, konuyu derinlemesine ama anlaşılır şekilde aktarmak.
1. Kubernetes Mimarisi
Kubernetes aslında iki ana katmandan oluşuyor: Control Plane ve Worker Nodes.
Control Plane
Burası cluster’ın beyni. Tüm yönetim ve karar mekanizmaları burada çalışıyor.
API Server – Cluster ile tüm iletişimin merkezi
etcd – Cluster state’in tutulduğu dağıtık veritabanı
Scheduler – Pod’ları uygun node’lara yerleştiren akıllı motor
Controller Manager – Otomasyon ve self-healing işlemlerini yönetir
Cloud Controller Manager (opsiyonel) – Eğer bulut kullanıyorsan, bulut sağlayıcı entegrasyonu için
Worker Nodes
Burası uygulamaların çalıştığı makineler.
kubelet – Node’u yöneten ajan
Container Runtime – Container’ları çalıştıran motor (containerd veya CRI-O)
kube-proxy – Ağ trafiğini Pod’lara yönlendiren sistem
Bu bileşenler nasıl konuşur? Önemli kural: Hiçbir component birbirine direkt konuşmaz.Hepsi API Server üzerinden konuşur.
Scheduler → API ServerController Manager → API ServerKubelet → API Serverkubectl → API Server
API Server bir "trafik kontrol kulesi"dir.
2. Control Plane Bileşenleri
2.1 API Server (kube-apiserver)
API Server cluster’ın kapısı diyebiliriz. Buraya gelen her istek (kubectl, dashboard, controller’lar…) önce API Server üzerinden geçiyor.
Ne yapıyor?
Authentication: Kullanıcı kimliğini doğrular
Authorization: Yetkilerini kontrol eder
Admission Controllers: Gerekirse isteği değiştirir veya reddeder
Controller’lara watch event yollar
Etcd ile veri alışverişi yapar
Diğer bileşenlerle REST API üzerinden iletişim kurar
Scheduler ile Pod scheduling akışını yönetir
API Server’ın Request Pipeline’ı
Tasarım notu: API Server stateless, yani cluster state’i kendisi tutmuyor, bunu etcd yapıyor. Ayrıca, istersen birden fazla API Server çalıştırabilirsin (horizontal scaling) ve tüm iletişim HTTP/JSON veya Protobuf üzerinden oluyor.
2.2 etcd – Cluster’ın Hafızası
Etcd, Kubernetes’in tüm cluster bilgisini saklayan dağıtık bir key-value store. Burada cluster’daki her şeyin kaydı tutuluyor.Etcd çok hassastır; IOPS ve latency çok kritiktir.
Neden etcd?
Strong consistency: Cluster state her zaman tutarlı
Watch/Notify: Değişiklikleri anında görebiliyorsun
Quorum bazlı yazma: N/2+1 node olmadan veri yazılamıyor, böylece split-brain olmuyor
Hafif ve performanslı
Raft algoritması kullanılıyor; leader seçiliyor, log replikasyonu yapılıyor ve consensus sağlanıyor.
Ne saklanıyor?
Pod ve Deployment bilgileri
Node bilgileri
ConfigMap ve Secret’lar
Replica sayıları
Service ve Cluster IP’leri
Özetle etcd, Kubernetes’in tek doğru bilgi kaynağı. Bozulursa cluster çalışmaz.
2.3 Scheduler – Pod’ları Node’lara Atayan Motor
Scheduler’ın 3 aşamalı algoritması vardır:
Filter CPU yeterli mi? Memory yeterli mi? Taints/tolerations uygun mu? Node affinity sağlanıyor mu?
Score Hangi node daha mantıklı?
Bind Pod’u seçilen node’a bağlar."Bunu şurada çalıştır" diye API Server’a yazar.
Scheduler asla pod yaratmaz.Sadece kime gideceğini seçer.
2.4 Controller Manager – Self-Healing ve Otomasyon
Her controller bir loop çalıştırır:
desired state → actual state karşılaştırması → farkı düzelt Deployment ControllerNode ControllerJob ControllerEndpoint ControllerNamespace Controller
Hepsi API Server’ı izler (watch).Bir değişiklik fark ederse aksiyon alır.
3. Worker Node Bileşenleri
3.1 kubelet
Görevleri:
PodSpec’i API Server’dan alır
Container runtime’a iletir
Health check yapar (Liveness, Readiness, Startup)
Volume mount eder
CNI ile network kurmasını sağlar
Node health bilgisini API Server’a gönderir
Kubelet çalışmazsa node pod çalıştıramaz.
3.2 Container Runtime
Kubernetes artık Docker’ı runtime olarak kullanmıyor, bunun yerine containerd veya CRI-O var.
Container image çekiyor (pull)
Container başlatıyor/durduruyor
Network ve filesystem izolasyonu sağlıyor
Process ve lifecycle yönetimi yapıyor
3.3 kube-proxy
Service trafiğini doğru Pod’lara yönlendiriyor
iptables veya ipvs kullanıyor
Load balancing ve Cluster IP yönlendirmesi sağlıyor
3.4 — CNI Plugin (Pod network’ü kurar)
Pod doğduğunda CNI şu işleri yapar:
Pod için network namespace yaratır
Pod’a IP verir
Routing kurar
Network policy uygular
Calico → en yaygın
Cilium → eBPF ile modern ve hızlı
Flannel → basit overlay
4. POD NASIL YARATILIR?
Bir örnek üzerinden anlatayım, kubectl apply -f nginx.yml dediğinde arka planda neler oluyor:
1. Adım — kubectl apply
Kubectl → API Server’a POST gönderir.
2. Adım — API Server Pipeline
Auth
RBAC
Mutating Admission (örn: Istio sidecar ekler)
Validating Admission
Etcd’ye kayıt
ALTIN KURAL:Pod henüz hiçbir node’da değil.Sadece etcd’ye yazıldı.
3. Adım — Scheduler devreye girer
Scheduler API Server’ı izler.
Bir pod Pending ve nodeName boş → “Schedule edilmesi gerek”.
Scheduler:
Filtreler node’ları
Skorlar
Seçer
Binding işlemini API Server’a yazar
Pod artık bir node’a atanmıştır ama hala çalışmıyor.
4. Adım — Kubelet devreye girer
Node’daki kubelet API Server’ı izler:
“Bu Pod bana atanmış.”
Sonra:
PodSandbox (pause) yaratır
Network oluşturması için CNI plugin’i çağırır
Containerları başlatır
Health check’leri çalıştırır
Pod ilk defa Running olur.
5. Adım — Service / Kube-proxy / Network binding
Pod çalışınca:
Endpoints nesnesine eklenir
Kube-proxy iptables/ipvs entry’lerini günceller
Network policy uygulanır
Artık Pod cluster içinden erişilebilir.
POD ÖLÜMÜ & RECONCILE LOOP
Pod ölürse:
Kubelet “pod öldü” event’i yollar
Controller Manager bunu fark eder
Yeni pod yaratır
Scheduler tekrar atama yapar
Kubernetes’in sihri işte burada:Kimseye haber vermiyorsun.Sistem kendini hep düzeltiyor.
Yorumlar