---
title: "Kubernetes Mimarisi ve Evrimi Anlamak"
---
# Kubernetes Mimarisi ve Evrimi Anlamak
Konteyner orkestrasyonu, modern uygulamaların ölçekli bir şekilde inşa edilmesi, dağıtılması ve yönetilmesi şeklini kökten değiştirdi. 2010'ların başında ortaya çıkan birçok çözüm arasında **Kubernetes** – genellikle **K8s** olarak kısaltılır – konteynerleştirilmiş iş yüklerinin dağıtımını, ölçeklendirilmesini ve işletilmesini otomatikleştiren de‑facto standart haline geldi. Bu makale, Kubernetes’in ortaya çıkışına yol açan tarihsel faktörleri izler, katmanlı mimarisini ayrıntılı bir şekilde inceler ve hızlı değişen bulut ortamında hâlâ geçerli olmasını sağlayan tasarım kararlarını vurgular.
## Erken Küme Yöneticilerinden Birleştirilmiş Kontrol Düzlemine
Serüven, Google'da **Borg** ve açık kaynak projeleri olarak **Mesos** gibi özelleşmiş küme yöneticileriyle başladı. Bu sistemler, büyük ölçekli konteyner yönetiminin deklaratif bir model, merkezi zamanlama ve sağlam hata toleransı gerektirdiğini gösterdi. Google, 2014'te açık kaynak **Kubernetes** projesini duyurduğunda, Borg’dan edinilen dersleri modüler, API‑odaklı bir platforma döktü. İmparatorluk‑temelli betiklerden **API‑öncelikli** felsefeye geçiş, her işlemin (pod oluşturma, dağıtım ölçeklendirme, servis güncelleme vb.) bir deklaratif kaynak olarak ifade edilip kontrol düzlemi tarafından işlenebilmesini sağladı.
## Kubernetes Kontrol Düzleminin Temel Bileşenleri
K8s’in kalbinde, birlikte kontrol düzlemini oluşturan gevşek bağlı hizmetler kümesi bulunur. Her bileşen bir süreç olarak çalışır ve genellikle **master node** üzerinde statik podlar olarak dağıtılır. Bu hizmetler ile **etcd** anahtar‑değer deposu arasındaki etkileşim, sistemin tek gerçek kaynağını (source of truth) oluşturur.
### etcd – Dağıtık Konfigürasyon Deposu
`etcd`, düğüm bilgileri, iş yükü tanımları ve konfigürasyon nesneleri dahil olmak üzere tüm küme durumunu saklar. Raft uzlaşı algoritmasını kullanarak bir küme düğümünden çoğunluğu arasında tutarlılığı garanti eder ve kısmi arızalara karşı dayanıklılık sağlar. Tüm diğer kontrol düzlemi bileşenleri `etcd`’den okur ve ona yazar; böylece tek bir gerçek kaynağı korunmuş olur.
### kube‑apiserver – Ön Kapı
**kube‑apiserver**, kullanıcılar, kontrolörler ve iç bileşenlerden gelen RESTful API isteklerini doğrular ve işler. Tek bir HTTP / JSON uç noktası sunarak, altındaki depolama mekaniğini soyutlar; geliştiriciler **kubectl**, istemci kütüphaneleri veya özel kontrolörler aracılığıyla küme ile etkileşime girebilir. Kimlik doğrulama ve yetkilendirme eklentileri bu geçidi korur, RBAC politikaları ve kabul kontrollerini (admission controls) uygular.
### scheduler – Karar Motoru
Yeni bir pod manifestosu `etcd`’ye kaydedildiğinde, **scheduler** kümenin kaynak topolojisini inceler, öngörüler (ör. düğüm özdeşliği, taint’ler) ve öncelikler (ör. pod özdeşliği, yük dengeleme) uygular ve en uygun düğümü seçer. Genişletilebilir çerçevesi sayesinde yöneticiler, GPU‑ağır AI eğitimi veya düşük gecikmeli uç işleme gibi özel iş yükleri için özel zamanlama mantığını takabilir.
### controller‑manager – Durum Uzlaştırıcı
**controller‑manager**, API’de tanımlanan istenen durumu, kümede gözlemlenen gerçek durumla sürekli uzlaştıran bir dizi kontrolörü barındırır. Kontrolörler arasında **replication controller**, **deployment controller**, **statefulset controller** ve **service controller** bulunur. Her biri basit bir döngü izler: değişiklikleri izleme → farkı hesaplama → pod oluşturma veya uç noktaları güncelleme gibi düzeltici eylemler gerçekleştirme.
### cloud‑controller‑manager – Bulut‑Özel Adaptör
Halka açık bulutlarda çalışan kümeler için **cloud‑controller‑manager**, sağlayıcı‑özel API’leri (ör. yük dengeleyiciler, kalıcı depolama) ortak bir arayüzün ardına gizler. Bu ayrım, Kubernetes’in bulut‑agnostik kalmasını sağlarken AWS ELB veya GCP Persistent Disk gibi yerel hizmetlerden yararlanmasına olanak tanır.
## Düğüm Mimarisi: Runtime, Kubelet ve Proxy
İşçi düğümler, uygulamaları çalıştıran konteynerleri yürütür. Her düğüm üç ana ajan çalıştırır:
* **container runtime** – görüntüleri (image) çeken ve konteynerleri çalıştıran yazılım (Docker, containerd, CRI‑O). Modern K8s sürümleri, **Container Runtime Interface (CRI)** adlı gRPC‑tabanlı sözleşme aracılığıyla çalışma ortamlarıyla etkileşir; bu sayede takas‑edilebilir (plug‑able) runtime’lar kullanılabilir.
* **kubelet** – düğümü API sunucusuna kaydeden, pod tanımlarını alan ve konteynerlerin istenen duruma uymasını sağlayan ajan. Sağlık durumunu izler, durum raporları gönderir ve CPU‑memory için **cgroup** limitlerini uygular.
* **kube‑proxy** – iptables veya IPVS kurallarını tutarak hizmetleri küme genelinde ortaya çıkaran ağ proxy’si; yük dengeleme ve oturum bağlılığını (session affinity) yönetir.
## Mermaid ile Görsel Özet
```mermaid
graph TD
subgraph ControlPlane["Control Plane"]
APIServer["\"kube-apiserver\""]
Scheduler["\"scheduler\""]
ControllerMgr["\"controller-manager\""]
CloudCM["\"cloud-controller-manager\""]
ETCD["\"etcd\""]
end
subgraph Nodes["Worker Nodes"]
Node1["\"Node 1\""]
Node2["\"Node 2\""]
Node3["\"Node 3\""]
end
APIServer --> ETCD
Scheduler --> APIServer
ControllerMgr --> APIServer
CloudCM --> APIServer
APIServer --> Node1
APIServer --> Node2
APIServer --> Node3
Node1 -->|runs| Kubelet1["\"kubelet\""]
Node2 -->|runs| Kubelet2["\"kubelet\""]
Node3 -->|runs| Kubelet3["\"kubelet\""]
Node1 -->|runs| Proxy1["\"kube-proxy\""]
Node2 -->|runs| Proxy2["\"kube-proxy\""]
Node3 -->|runs| Proxy3["\"kube-proxy\""]
```
Şema, kontrol düzlemi ile her işçi düğüm arasındaki çift yönlü iletişimi gösterir. Tüm durum değişiklikleri `etcd` üzerinden akar; zamanlayıcı ve kontrolörler ise bağımsız karar vericiler olarak hareket eder.
## Ölçekleme Stratejileri ve Yüksek Erişilebilirlik
Kubernetes, hem dikey (bir düğüme kaynak ekleme) hem de yatay (daha fazla düğüm ekleme) ölçekleme yapabilir. **Horizontal Pod Autoscaler (HPA)**, gözlemlenen CPU kullanımı ya da özel metriklere dayalı olarak replica sayısını otomatik ayarlar. Kontrol düzlemi için HA, bir yük dengeleyicinin arkasında birden çok API sunucusu çalıştırılarak ve `etcd`’nin tek sayıdaki üye ile bir küme dağıtımı olarak yapılandırılmasıyla elde edilir. Zamanlayıcı ve controller‑manager’daki **lider seçim** (leader election) mekanizması, kritik eylemleri aynı anda sadece bir örnek üzerinde gerçekleştirirken, yedek kopyalar devralmaya hazır olur.
## Güvenlik Temelleri
K8s güvenliği çok katmanlı bir yaklaşımla ele alınır:
* **Kimlik Doğrulama** – API istemcilerinin kimliğini sertifikalar, token’lar veya harici kimlik sağlayıcılarıyla doğrular.
* **Yetkilendirme** – Role‑Based Access Control (RBAC) veya Attribute‑Based Access Control (ABAC) aracılığıyla politika kararlarını uygular.
* **Kabul Kontrolü (Admission Control)** – nesne kalıcı hale gelmeden önce pod güvenlik politikaları, görüntü kökeni (image provenance) veya kaynak kotaları gibi eklentileri çalıştırır.
* **Ağ Politikaları** – etiket seçicileriyle podlar arasındaki izin verilen trafik akışlarını tanımlar.
* **Pod Güvenlik Standartları** – ayrıcalıklı, temel ve kısıtlı olmak üzere önceden tanımlı politikalar sunarak güvenli pod yapılandırmalarını yönlendirir.
## Özelleştirilebilir Kaynaklarla Genişletilebilirlik
K8s’in en güçlü özelliklerinden biri **Custom Resource Definition (CRD)**’dir; geliştiricilerin çekirdek kodu değiştirmeden yeni API nesneleri oluşturmasına izin verir. **Operator**’lar ise bir kontrolör içinde alan‑özel mantığı kapsüller; CRD’ler sayesinde veri tabanları, mesajlaşma sistemleri gibi karmaşık durumlu uygulamaların otomasyonu, yerleşik kaynakları besleyen uzlaştırma döngüsüyle aynı çerçevede gerçekleşir.
## Gözlemlenebilirlik ve Sorun Giderme
Etkili gözlemlenebilirlik üç temel üzerine kuruludur:
1. **Metrikler** – **Metrics Server** aracılığıyla sunulur, Prometheus tarafından toplanır; düğüm ve pod kaynak tüketimini gösterir.
2. **Kayıt (Logging)** – fluentd veya Loki gibi araçlarla merkezi hâle getirilir; konteyner stdout/stderr akışlarını adli analiz için bir araya toplar.
3. **İzleme (Tracing)** – Jaeger gibi dağıtık izleme çerçeveleri, mikro hizmetler arasındaki istek akışını yakalar; gecikme darboğazlarını ortaya çıkarır.
Bu sinyaller Grafana gibi panellerde görselleştirilerek gerçek‑zamanlı sağlık kontrolleri ve performans ayarlamaları yapılabilir.
## Gelecek Yol Haritası: Ortaya Çıkan Trendler
Kubernetes, kenar (edge) bilişim, sunucusuz (serverless) iş yükleri ve yapay zeka‑merkezli boru hatları (pipeline) gereksinimlerini karşılamak için sürekli evrimleşiyor. Dikkat çeken bazı girişimler:
* **KubeEdge** – temel API’leri genişleterek cihaz ve iş yüklerini ağ kenarında yönetir; kesintili bağlanabilirlik ve düşük enerji kısıtlamalarını ön planda tutar.
* **Knative** – K8s üzerine inşa edilerek fonksiyonlar ve olay yönetimi gibi sunucusuz primitifler sunar; altyapı detaylarını soyutlar.
* **Cluster API** – Kubernetes kümelerinin kendisinin deklaratif olarak provision edilmesini standartlaştırır; bulutlar arasında tutarlı yaşam döngüsü yönetimini kolaylaştırır.
Bu projeler, tüm küme durumunun (altyapı dahil) versiyon kontrolüne alındığı ve otomatik olarak uzlaştırıldığı **GitOps** akımının genişlemesini yansıtır.
## Sonuç
Kubernetes mimarisi, modüler ve API‑odaklı tasarımın bir başyapıtıdır. Durum (etcd), niyet (API sunucusu), konumlandırma (scheduler) ve uzlaştırma (controller) gibi bileşenleri birbirinden net bir şekilde ayırarak, K8s dayanıklı, genişletilebilir ve çeşitli iş yüklerine uyum sağlayabilen bir platform sunar. Kontrol düzleminin uzlaşı mekanizmalarından düğüm‑seviyesindeki çalışma zaman etkileşimlerine kadar her katmanı kavramak, mühendislerin birkaç düğümden küresel çok‑bölge kümelere kadar güvenli, yüksek performanslı dağıtımlar tasarlamasına olanak tanır.
## See Also
-
-
-
-
-