Kubernetes mimarisini tanımlayın: control plane ile worker node'lar ve bileşenleri.

Question

IT Interview Practice · Accepted Answer

Bir Kubernetes cluster'ı iki tür makineye sahiptir: **control plane** (kararları veren ve durumu saklayan "beyin") ve **worker node'lar** (Pod'larınızın gerçekten çalıştığı yer). Her birinin küçük, iyi tanımlanmış bir bileşen kümesi vardır.

## Büyük resim

```text
┌──────────────── CONTROL PLANE (beyin) ────────────────────┐
│                                                            │
│   kube-apiserver ── ön kapı; TÜM iletişim buradan geçer    │
│        │                                                   │
│   etcd ───────── key-value store: cluster'ın DOĞRULUK      │
│                  KAYNAĞI (tüm nesneler & arzu edilen durum)│
│   kube-scheduler ── yeni bir Pod'un HANGİ node'da çalışacağına karar verir │
│   controller-manager ── kontrol döngülerini (reconciler) çalıştırır │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pod'lar (app'ler)│ │  └ Pod'lar (app'ler)│
└─────────────────────┘ └─────────────────────┘
```

## Control plane bileşenleri

```text
kube-apiserver        Tek giriş noktası. REST API'yi sunar; nesneleri doğrular &
                      etcd'ye kalıcılaştırır. kubectl, controller'lar ve kubelet'ler
                      YALNIZCA apiserver ile konuşur.
etcd                  Dağıtık, tutarlı key-value store. TÜM cluster durumunu tutar
                      (arzu edilen + mevcut). etcd'yi kaybet = cluster'ı kaybet.
kube-scheduler        Node atanmamış Pod'ları izler ve en iyi node'u seçer
                      (kaynak istekleri, affinity, taint'ler vb. temelinde).
kube-controller-      Kontrol döngülerini çalıştırır: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints vb. Her döngü gerçeği → arzu edilene sürükler.
cloud-controller-     (Cloud'da) sağlayıcıyla entegre olur: load balancer'lar, route'lar,
manager               node yaşam döngüsü.
```

## Worker node bileşenleri

```text
kubelet          Node ajanı. apiserver ile konuşur, runtime aracılığıyla container'ları
                 başlatır/durdurur ve Pod & node durumunu raporlar. Node'un gerçekliğini
                 kendisine atanan Pod'lara uydurur.
kube-proxy       Node'un ağ oluşturmasını (iptables/IPVS) programlar; böylece Service sanal
                 IP'leri doğru Pod endpoint'lerine load balance edilir.
container runtime Container'ları gerçekten çalıştıran yazılım (containerd, CRI-O).
```

## Bir "kubectl apply" sistemden nasıl akar

```text
1. kubectl → kube-apiserver: "3 replica'lı bir Deployment istiyorum"
2. apiserver nesneyi doğrular & etcd'ye yazar
3. controller-manager (deployment→replicaset controller) bunu görür, 3 Pod nesnesi oluşturur
4. scheduler 3 atanmamış Pod'u görür, her birini bir node'a atar (apiserver üzerinden geri yazar)
5. her node'un kubelet'i Pod'larını görür, runtime'a image çekip container başlatmasını söyler
6. kube-proxy Service ağını bağlar, böylece trafik yeni Pod'lara ulaşır
Her şey apiserver aracılığıyla yürütülen bir WATCH + RECONCILE döngüsüdür.
```

```bash
kubectl get nodes                 # node'ları listele (control-plane + worker'lar)
kubectl get pods -n kube-system   # control-plane / sistem bileşenlerini gör
kubectl get componentstatuses     # çekirdek control-plane parçalarının sağlığı
```

## Neden önemli

Control plane ile worker node'lar arasındaki ayrımı — ve her bileşenin rolünü — anlamak, Kubernetes'i kara kutudan, üzerinde akıl yürütüp işletebileceğiniz bir sisteme dönüştüren şeydir; bu yüzden orta ve üzeri seviye herhangi bir mühendis için çekirdek bilgidir. **Control plane** karar veren beyindir: **kube-apiserver**, her bileşenin ve kullanıcının üzerinden iletişim kurduğu tek ön kapıdır; **etcd**, tüm cluster durumunu tutan tutarlı key-value store'dur ve doğruluk kaynağıdır (onu kaybetmek cluster'ı kaybetmek demektir); **scheduler** her yeni Pod'un hangi node'a ineceğine karar verir; ve **controller-manager**, gerçek durumu arzu edilen duruma sürekli sürükleyen uzlaştırma döngülerini çalıştırır. Her **worker node**'da, **kubelet**, node'un container'larını kendisine atanan Pod'lara uyduran ajandır, **kube-proxy** Service sanal IP'lerinin doğru Pod'lara yönlenmesini sağlayan ağı programlar ve bir **container runtime** (containerd, CRI-O) container'ları gerçekten çalıştırır. Tek bir `kubectl apply`'ın bu sistemden nasıl aktığını görmek — apiserver'dan etcd'ye, controller'ların nesne oluşturması, scheduler'ın Pod yerleştirmesi, kubelet'lerin container başlatması, kube-proxy'nin ağı bağlaması, hepsi izle-ve-uzlaştır döngüleri olarak — platformun ardındaki zarif, tutarlı tasarımı ortaya koyar. Bu zihinsel model, bir Pod'un neden Pending kaldığını (scheduler), cluster'ın neden yanıt vermediğini (apiserver/etcd) veya bir Service'in neden yönlendirmediğini (kube-proxy) hata ayıklamak için ihtiyaç duyacağınız tam olarak şeydir; bu da onu gerçek cluster'ları işletmek ve sorun gidermek için vazgeçilmez kılar.

Büyük resim

Control plane bileşenleri

Worker node bileşenleri

Bir "kubectl apply" sistemden nasıl akar

Neden önemli

İlgili sorular