1. GİRİŞ

Kubernetes, modern bulut‑native uygulamaların dağıtımı, ölçeklenmesi ve yönetimi için endüstri standardı hâline gelmiştir. Konteyner teknolojilerinin (Docker vb.) yaygınlaşması, mikroservis mimarilerinin benimsenmesi ve çoklu ortamlarda (on‑prem, public cloud, hybrid) çalışma ihtiyacı Kubernetes'i çekirdek bir teknolojiye dönüştürdü. Bu makale Kubernetes mimarisinin teknik detaylarını, bileşenlerini, veri akışını ve uygulama senaryolarını mühendis bakış açısıyla ele alır.

Bu konu neden bugün önemli?

• Kubernetes, uygulamaları environment'lar arasında taşınabilir ve tekrar üretilebilir hale getirir.
• DevOps/Platform Engineering yaklaşımlarının merkezinde yer alır; GitOps ve CI/CD akışları ile sıkı entegrasyon sunar.
• Konteyner orkestrasyonu sayesinde kaynak verimliliği, otomatik recovery ve yatay ölçeklenebilirlik sağlanır.

Kimler için önemli?

• Platform mühendisleri, DevOps ve SRE ekipleri
• Mikroservis mimarileri ile çalışan backend mühendisleri
• Bulut mimarları ve teknik liderler — ölçeklenebilir altyapı tasarlayanlar

Hangi problemleri çözüyor?

• Manuel container yönetimi ve dağıtım karmaşası
• Servis discovery, load balancing ve rolling update gibi operasyonel zorluklar
• Yüksek erişilebilirlik, otomatik yeniden başlatma ve self‑healing ihtiyaçları

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• Pod: Kubernetes'teki dağıtım birimi; bir veya birkaç container'ı aynı network namespace ve storage ile birlikte çalıştırır.
• Node: Pod'ları çalıştıran fiziksel veya sanal makine.
• Cluster: Kontrol düzlemi (control plane) ve bir veya daha çok node'dan oluşan küme.
• Namespace: Cluster içinde kaynak izolasyonu sağlayan mantıksal bölüm.
• Deployment / StatefulSet / DaemonSet: Pod yaşam döngüsü ve dağıtım stratejilerini yöneten kontrolörler.
• Service: Pod'lara erişim ve servis discovery sağlayan soyutlama; ClusterIP, NodePort, LoadBalancer tipleri vardır.

2.2 Mimari genel görünüm

Kubernetes mimarisi iki ana katmandan oluşur: Kontrol düzlemi (control plane) ve çalışma düğümleri (worker nodes). Kontrol düzlemi cluster durumunu yönetir; scheduler, API server, controller manager ve etcd gibi bileşenleri barındırır. Worker node'lar pod'ları çalıştırır (kubelet, kube‑proxy). Bu ayrım, yönetişim ve operasyonel sorumlulukların ayrılmasını sağlar.

2.3 Terminoloji ve roller

• API Server: Cluster'in merkezi giriş noktası; tüm CRUD operasyonları buradan geçer.
• etcd: Cluster state'ini saklayan dağıtılmış key‑value datastore; yüksek erişilebilirlik ve yedekleme kritik.
• kube‑scheduler: Pod'ları uygun node'lara atayan mekanizma; resource requests/limits ve affinity kurallarını değerlendirir.
• kube‑controller‑manager: StatefulSet, ReplicaSet, Job gibi kontrol döngülerini yöneten bileşenleri barındırır.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi — bileşenler ve veri akışı

Yüksek seviyede veri akışı şu şekildedir: Kullanıcı veya CI sistemi kubectl/CI aracı ile API Server'a istek gönderir. API Server istekleri doğrular, admission controller'lar ile politika kontrolleri yapar ve etcd'ye yazılacak istekleri kabul eder. Controller manager ve scheduler, istenen durumu (desired state) gözlemler ve worker node'larda gerekli pod'ların ayağa kalkması için kubelet'lara talimat verir. Node'da container runtime (containerd, CRI‑O) pod'ları başlatır; kube‑proxy ağ kurallarıyla paket yönlendirmesini sağlar.

3.2 Control plane bileşenleri — detay

API Server

Cluster ile etkileşimin merkezidir. Tüm REST çağrıları API server üzerinden geçer; authentication, authorization ve admission kontrol noktaları burada uygulanır.

etcd

Cluster'in tek gerçek state deposudur. Küçük gecikmeler bile cluster stabilitesini etkileyebilir; bu nedenle etcd performansı, yedekleme ve restore süreçleri kritik önem taşır.

Scheduler

Yeni oluşturulan pod'ları node'lara atarken kaynak talepleri (requests), limit'ler, affinity/anti‑affinity ve taints/tolerations politikalarını göz önünde bulundurur.

Controller Manager

ReplicaSet, StatefulSet, DaemonSet gibi kontrol döngülerini çalıştırır; eksik pod'ları yeniden oluşturmak, scaling ve garbage collection görevleri bu katmanda yürür.

3.3 Worker node bileşenleri — detay

kubelet

Node agent'ı; API server ile konuşur, pod manifest'lerini alır ve container runtime'ı kullanarak container'ları başlatır, health check'leri çalıştırır.

kube‑proxy

Service IP'leri ve ağ trafiğinin hedef pod'lara yönlendirilmesini sağlar. IPVS veya iptables tabanlı çalışma modları mevcuttur.

Container runtime

containerd veya CRI‑O gibi runtime'lar container lifecycle yönetimini yapar; güvenlik profile'ları (seccomp, AppArmor) ve image management önemli noktalardır.

3.4 Ağ ve servis discovery

Kubernetes'te ağ modeli "her pod kendi IP'sine sahip" olacak şekilde tasarlanmıştır. Pod-to-pod iletişimi CNI (Container Network Interface) plugin'leri ile sağlanır (Calico, Flannel, Cilium). Servis discovery için DNS tabanlı çözüm (CoreDNS) kullanılır; Service kaynakları ise cluster‑internal yük dengeleme sağlar. Ingress kaynakları ve Ingress Controller'lar HTTP/HTTPS trafiğini cluster dışından içe yönlendirir.

3.5 Storage ve persistency

Kubernetes storage abstraksiyonları PersistentVolume (PV) ve PersistentVolumeClaim (PVC) yoluyla uygulanır. Dinamik provisioning, storage class'lar ve CSI (Container Storage Interface) sayesinde farklı storage sağlayıcılarına bağlanılabilir. Stateful uygulamalar için StatefulSet ve volumeClaimTemplates kullanılır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Büyük Ölçek ve Resilience

Netflix benzeri yüksek trafikli platformlar için Kubernetes, microservice yönetimini otomatikleştirir; ancak yüksek ölçekle beraber servis mesh (Istio, Linkerd) ve chaos engineering (Chaos Monkey) gibi ek katmanlar eklenir. Canary deploy ve otomatik rollback politikalarıyla risk yönetimi yapılır.

Uber — Edge ve Bölgesel Dağıtım

Uber gibi coğrafi olarak dağıtık trafiği olan uygulamalarda Kubernetes cluster'ları bölgesel olarak konumlandırılır; traffic shaping, regional failover ve lokal cache invalidation gibi özel operasyonlar uygulanır.

Amazon — Managed Kubernetes (EKS) ve Entegrasyon

Büyük sağlayıcılar managed Kubernetes hizmetleri (EKS, AKS, GKE) ile kontrol düzlemini yönetir; kullanıcılar worker node'lar ve uygulama seviyesine odaklanır. Managed hizmetler IAM, VPC entegrasyonu ve update yönetimi gibi operasyonel yükleri azaltır.

OpenAI — Model Serving ve GPU Yönetimi

ML/AI firmaları Kubernetes'i model serving, autoscaling GPU node pool yönetimi ve inference rollout'ları için kullanır. NVIDIA device plugin, node labeling ve resource scheduling kritik rollerdir.

Stripe — Güvenlik ve Compliance

Fintech şirketleri için Kubernetes üzerinde network policy, pod security policies (PSP/PodSecurity), audit logging ve immutable image politikaları sıkı bir şekilde uygulanır. Secrets yönetimi ve runtime policy enforcement (OPA/Gatekeeper) yaygındır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Taşınabilirlik: Container ve manifest'lerle uygulamalar farklı bulut/ortamlar arasında taşınabilir.
• Otomasyon ve self‑healing: Restart, reschedule ve auto‑recovery mekanizmaları yüksek erişilebilirlik sağlar.
• Ölçeklenebilirlik: Otomatik yatay pod ölçeklendirmesi (HPA), cluster autoscaler ile maliyet ve performans dengesi sağlanır.

Sınırlamalar

• Karmaşıklık: Kubernetes öğrenme eğrisi ve operasyonel karmaşıklık yüksek olabilir; platform mühendisliği yatırımı gerekir.
• Maliyet: Yanlış yapılandırma veya aşırı provision maliyetleri artırır; observability ve logging maliyetleri göz önünde olmalı.
• Stateful uygulamalar: Veri tutarlılığı, storage performansı ve migration senaryoları dikkatli planlanmalıdır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Control plane bileşenlerini HA (yüksek erişilebilirlik) olarak dağıtın; etcd cluster'ını çoklu bölgede çoğaltmayın (network latency sorunları) ama replicate ve backup planları kurun.
• Pod resource requests ve limits tanımlayın; scheduler'ın doğru karar vermesi için kaynak taleplerini belirtin.
• Namespace ve RBAC politika'ları ile takım izolasyonu sağlayın; least privilege erişim modelini uygulayın.

Performans optimizasyonu

• Node labeling ve taints/tolerations kullanarak workload'ları uygun donanımda çalıştırın (GPU, fast‑storage).
• Horizontal Pod Autoscaler (HPA) ve Vertical Pod Autoscaler (VPA) kombinasyonunu dikkatli kullanın; HPA için doğru metrik (CPU, memory, custom metric) seçin.
• Cluster Autoscaler ile node havuzlarını dinamik yönetin; spot instance/preemptible kullanımı maliyeti düşürür fakat preemption riskini yönetin.

Güvenlik

• NetworkPolicy ile pod‑level network segmentation uygulayın; service mesh ile mTLS trafiği sağlayın.
• Image provenance ve signed images kullanın (Notary/ Cosign) ve image vulnerability scanning pipeline'ları kurun.
• Admission controller ve policy as code (OPA/Gatekeeper) ile konfigürasyon değişikliklerini doğrulayın.

Ölçeklenebilirlik

• Multi‑AZ ve multi‑region tasarımlarında DNS‑based failover ve global load balancing stratejileri kullanın.
• Microservice boundary'lerini net tutun; veritabanı ve stateful servisler için doğru partitioning/replication stratejisini seçin.

8. SIK YAPILAN HATALAR

• Pod'lara resource limit tanımlamamak: Node üzerindeki noisy neighbor etkisi ve OOM kill riskleri artar.
• etcd backup ve restore stratejisi olmadan üretime geçirmek: state kaybı büyük felaketlere yol açar.
• Secrets'ı düz metin olarak config map içinde tutmak: güvenlik zafiyeti oluşturur.
• Monitoring ve alerting olmadan autoscaling politikaları uygulamak: yanlış ölçeklendirmeler servis kesintisine sebep olabilir.

9. GELECEK TRENDLER

1. GitOps ve declarative operasyonların yaygınlaşması: Kubernetes operasyonları Git tabanlı workflow'larla daha sıkı entegre edilecek (ArgoCD, Flux).
2. Service mesh ve observability'nin birleşimi: Dağıtık tracing, distributed context ve güvenlik kontrolleri service mesh tarafında daha da merkezi hale gelecek.
3. AI destekli operasyon: Anomali tespiti, otomatik remediation ve kapasite öngörüleri ML modelleri ile desteklenecek.
4. Edge Kubernetes: IoT ve edge uygulamaları için lightweight control plane ve federated cluster yaklaşımları gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Kubernetes neden Docker ile birlikte anılıyor?

   Docker konteyner formatı ve runtime popüler olduğu için Kubernetes'in ilk yaygın kullanım senaryosu Docker container'ları yönetmekti. Günümüzde Kubernetes, OCI compliant birbirden farklı container runtime'ları da destekler (containerd, CRI‑O).

2. Stateful uygulamalar Kubernetes'te nasıl yönetilmeli?

   StatefulSet, PersistentVolume ve Stateful volumeClaimTemplates kullanarak veri tutarlı bir dağıtım sağlanabilir. Database migration ve backup/restore stratejileri ayrı planlanmalıdır.

3. etcd neden kritik?

   etcd cluster, Kubernetes'in tek doğruluk kaynağıdır (source of truth). etcd'nin bozulması veya veri kaybı cluster bütünlüğünü etkiler; bu nedenle performans, yedekleme ve güvenlik önlemleri kritik.

4. Service mesh hangi problemleri çözer?

   Service mesh, servisler arası iletişimde güvenlik (mTLS), traffic yönetimi (traffic shifting, canary) ve telemetry (distributed tracing) gibi sorunları merkezi bir katman ile çözer.

5. Kubernetes'i kendi datacenter'ımda mı yoksa managed servisle mi çalıştırmalıyım?

   Managed servisler (EKS, AKS, GKE) kontrol düzlemi yönetimini kolaylaştırır ve operasyonel yükü azaltır. Kendi datacenter'ınızda ise tam kontrol ve özelleştirme avantajı vardır ancak operasyonel maliyet daha yüksektir.

6. Monitoring için hangi göstergeleri izlemeliyim?

   Pod/Node CPU, memory kullanımı, pod restart rate, scheduler latency, etcd latency/commit index, API server error rate, kubelet health ve application level metrics (latency, error rate) izlenmelidir.

7. Rolling update ile zero‑downtime nasıl sağlanır?

   Deployment stratejileri (maxUnavailable, maxSurge), readinessProbe ve livenessProbe ayarları ile mevcut servis kopyaları korunarak yeni sürüm kademeli olarak alınır. Canary veya blue/green stratejileri ekstra güvenlik sağlar.

8. Kubernetes güvenliğini nasıl başlatmalıyım?

   RBAC ile erişim kontrolü, NetworkPolicy ile ağ segmentasyonu, image scanning, signed images ve admission controller tabanlı policy enforcement ile süreç başlatılmalı.

Anahtar Kavramlar

Pod

Kubernetes'teki en küçük deploy edilebilir birim; bir veya daha fazla container içerir.

etcd

Cluster state'ini saklayan dağıtılmış key‑value store.

Service

Pod'lara erişimi soyutlayan nesne; load balancing ve discovery sağlar.

Ingress

Cluster dışından gelen HTTP/HTTPS trafiğini yönlendiren API; Ingress Controller ile uygulanır.

Service Mesh

Servisler arası iletişimi yöneten, güvenlik ve gözlemlenebilirlik sağlayan altyapı katmanı.

Öğrenme Yol Haritası

1. 0–1 ay: Docker ve konteyner kavramları, Kubernetes temel komutları (kubectl), Pod ve Service tanımları.
2. 1–3 ay: Deployments, ReplicaSets, ConfigMap, Secret, PersistentVolume ve StatefulSet kavramları, basit bir uygulamayı cluster'a deploy edin (minikube/kind).
3. 3–6 ay: CNI plugin'leri, storage class'lar, ingress controller, Helm chart'ları ve monitoring stack (Prometheus/Grafana) öğrenin ve uygulayın.
4. 6–12 ay: Service mesh (Istio/Linkerd), GitOps (ArgoCD/Flux), cluster autoscaler, pod autoscaler ve security hardening konularında deneyim kazanın.
5. 12+ ay: Multi‑cluster yönetimi, federated control plane, edge Kubernetes ve performans optimizasyonu konularında uzmanlaşın.