1. GİRİŞ

Kubernetes, container orkestrasyonunun endüstri standardı haline gelmesiyle birlikte modern altyapı ve platform mühendisliğinin çekirdeğini oluşturur. Mikroservislerin, CI/CD akışlarının ve bulut‑native yaklaşımların yaygınlaşması Kubernetes'i kritik bir teknoloji haline getirdi. Bu makalede Kubernetes'in temel ve ileri düzey bileşenlerini ayrıntılı olarak inceliyor; her bir bileşenin rolünü, etkileşimlerini, operasyona etkilerini ve dikkat edilmesi gereken noktaları mühendis perspektifiyle açıklıyoruz.

Bu konu neden bugün önemli?

• Konteyner tabanlı uygulamaların üretime güvenli, ölçeklenebilir ve sürdürülür şekilde taşınması gereklidir.
• Organizasyonlar, platform mühendisliği ve GitOps yaklaşımlarıyla operasyonel karmaşıklığı azaltmak istiyor.
• Kubernetes bileşenlerini tanımak, doğru tasarım ve güvenlik kararları almak için zorunludur.

Kimler için önemli?

• Platform/SRE mühendisleri ve altyapı ekipleri
• Backend geliştiriciler (kendi servislerini productiona koyanlar)
• DevOps, güvenlik mühendisleri ve teknik yöneticiler

Hangi problemleri çözüyor?

• Kapsayıcı uygulamalarının dağıtımı, ölçeklenmesi ve yaşam döngüsü yönetimi
• Servis discovery, yük dengeleme, sürüm geçişleri ve fault tolerance
• Ölçeklenebilir gözlemlenebilirlik, politika bazlı güvenlik ve otomasyon

2. KAVRAMSAL TEMELLER

2.1 Kubernetes'in iki ana katmanı

Kubernetes mimarisi genel olarak iki ana bölüme ayrılır: control plane (kontrol düzlemi) ve worker node'lar (çalışma düğümleri). Control plane cluster'ın istenen durumunu yönetir; worker node'lar ise uygulama yüklerini çalıştırır. Bu soyutlama, operasyon ve güvenlik ayrımı sağlar.

2.2 Temel terminoloji

• Pod: Bir veya birkaç container'ı barındıran en küçük çalışma birimi.
• Node: Pod'ları barındıran fiziksel veya sanal makine.
• Service: Pod gruplarına tutarlı ağ erişimi sağlayan soyutlama.
• Deployment/StatefulSet/DaemonSet: Çeşitli çalışma yükü modellerini yöneten kontrolörler.
• etcd: Cluster state'inin tutulduğu dağıtılmış anahtar‑değer deposu.
• API Server: Cluster'in tüm denetim noktası ve REST API yüzeyi.

2.3 Bileşen kategorileri

1. Control plane bileşenleri (API Server, etcd, Scheduler, Controller Manager)
2. Node tarafı bileşenler (kubelet, kube‑proxy, container runtime)
3. Networking (CNI plugin'leri, Service, Ingress)
4. Storage (PV/PVC, CSI)
5. Güvenlik (RBAC, PSP/PodSecurity, NetworkPolicy)
6. Observability (metrics‑server, Prometheus, tracing)
7. Extensibility (CRD, Operator pattern, admission controllers)

3. NASIL ÇALIŞIR? — CONTROL PLANE BİLEŞENLERİ

3.1 API Server

API Server (kube‑apiserver), cluster ile etkileşimin merkezidir. Tüm CRUD operasyonları burada gerçekleşir; authentication, authorization (RBAC), admission controller'lar ve audit logging noktaları API Server tarafından yönetilir. API Server yatay olarak ölçeklendirilebilir ancak arkasındaki etcd ile uyum gözlenmelidir.

3.2 etcd

etcd, Kubernetes'in source of truth'udur. Cluster state, config ve metadata burada saklanır. etcd performansı, quorum ve latency faktörleri cluster stabilitesini doğrudan etkiler. Production kurulumlarda etcd cluster'ı HA (yüksek erişilebilirlik) ile kurulur ve düzenli yedekleme/restore prosedürleri zorunludur.

3.3 kube‑scheduler

Scheduler, yeni oluşturulan pod'ları uygun node'a atar. Karar verirken resource requests/limits, node affinity/anti‑affinity, taints/tolerations, topology constraints ve custom scheduler extender'ları dikkate alır. Performans kritik uygulamalarda scheduler'ın davranışını izlemek ve gerektiğinde extender/priority configuration yapmak gerekir.

3.4 kube‑controller‑manager

Controller manager, cluster içindeki kontrol döngülerini (replication, endpoint, namespace controller vb.) çalıştırır. Her kontrolör istenen durumu (desired state) gözlemler ve gerekli düzeltmeleri uygular. Örneğin ReplicaSet eksik pod gördüğünde yeni pod oluşturur.

3.5 Admission Controllers

Admission controllers, API Server'a gelen isteklere müdahale eden pluggable bileşenlerdir. Mutating admission controllers request'i değiştirebilir, validating admission controllers ise isteği reddedebilir. Policy enforcement (Gatekeeper/OPA), image policy, resource limit enforcement bu katmanda gerçekleşir.

4. NASIL ÇALIŞIR? — NODE TARAFI VE RUNTIME BİLEŞENLERİ

4.1 kubelet

Kubelet node üzerinde çalışan agent'tır. API Server ile konuşur, pod manifest'lerini alır ve container runtime (containerd/CRI‑O) vasıtasıyla container'ları başlatır. Kubelet ayrıca sağlık kontrollerini uygular, pod lifecycle event'larını raporlar ve volume mount işlemlerini yönetir.

4.2 kube‑proxy

kube‑proxy, Service IP'lerine gelen trafiği arka plandaki pod'lara yönlendirir. IPVS veya iptables tabanlı modlarda çalışır. Büyük ölçekli cluster'larda IPVS performans avantajı sunar.

4.3 Container runtime

Kubernetes, CRI (Container Runtime Interface) sayesinde farklı runtime'ları destekler: containerd, CRI‑O gibi. Runtime, container lifecycle yönetimini, image çekme ve güvenlik izolasyonunu sağlar. Runtime konfigürasyonu (image pull policy, imagePullSecrets, runtimeClass) production için önemlidir.

4.4 Node level security

Node'ları sertleştirmek (hardening) önemlidir: OS güncellemeleri, kernel parametreleri, runtime seccomp/AppArmor, read‑only root filesystem tercihleri ve hostPath kullanımı minimize edilmelidir. Ayrıca kubelet authentication/authorization ve TLS konfigürasyonu düzgün yapılmalıdır.

5. AĞ, SERVİS VE İLETİŞİM BİLEŞENLERİ

5.1 CNI (Container Network Interface)

CNI plugin'leri (Calico, Flannel, Cilium, Weave) pod'lara IP ataması, routing ve network policy enforcement sağlar. Seçilecek CNI, performans, network policy desteği ve observability ihtiyaçlarına göre belirlenmelidir. Örneğin Cilium eBPF tabanlı olduğu için yüksek performans ve gelişmiş network visibility sunar.

5.2 Service ve DNS (CoreDNS)

Service objesi, pod gruplarına sabit bir erişim noktası sağlar. CoreDNS cluster içi DNS çözümünü sağlar ve service discovery'yi mümkün kılar. DNS scaling ve performansı uygulama discovery sürelerini etkiler; CoreDNS etkin konfigürasyon ve kaynak limitleriyle optimize edilmelidir.

5.3 Ingress ve Ingress Controller

Ingress kaynakları HTTP/HTTPS trafiğini cluster dışından pod'lara yönlendirir. Ingress Controller'lar (NGINX, Traefik, HAProxy, Contour) Ingress tanımını uygulayan bileşenlerdir. TLS termination, path‑based routing, rate limiting ve WAF entegrasyonları ingress katmanında uygulanır.

5.4 Service Mesh

Service mesh (Istio, Linkerd, Consul) servisler arası iletişimi proxy tabanlı olarak yönlendirir, mTLS ile güvenliği sağlar, trafikte gözlemlenebilirlik ve traffic shaping özellikleri sunar. Service mesh, özellikle büyük mikroservis ortamlarında observability ve güvenlik için kritik olabilir ancak operational yükü artırır.

6. STORAGE VE STATEFUL BİLEŞENLER

6.1 PersistentVolume (PV) & PersistentVolumeClaim (PVC)

PV/PVC soyutlaması, pod'ların kalıcı depolama istemesini sağlar. StorageClass ile dinamik provisioning yapılabilir. Durability, performance ve backup/restore stratejileri storage seçiminde belirleyici faktörlerdir.

6.2 CSI (Container Storage Interface)

CSI, depolama sağlayıcılarının Kubernetes ile entegrasyonunu standartlaştırır. CSI driver'ları ile cloud provider block storage, NFS veya özel depolama çözümleri kolayca entegre edilir.

6.3 StatefulSet ve volumeClaimTemplates

StatefulSet, stateful uygulamalar için ordered, stable network identity ve per‑pod persistent storage sağlar. Database veya message queue gibi stateful servisler için uygun yapı StatefuSet ile sağlanır; migration ve snapshot işlemleri ayrıca planlanmalıdır.

7. GÜVENLİK VE POLİTİKALAR

7.1 RBAC (Role‑Based Access Control)

RBAC ile kullanıcı, service account ve sistem bileşenlerinin erişimleri tanımlanır. Least privilege ilkesini uygulamak, yönetimsel riskleri azaltır. Role ve RoleBinding politikaları namespace seviyesinde, ClusterRole ve ClusterRoleBinding cluster seviyesinde uygulanır.

7.2 Pod Security ve Admission Controls

PodSecurity (eski PSP yerine PodSecurity admission) ve admission controllers ile runtime güvenlik politikaları enforce edilir: privileged container'ların engellenmesi, hostPath limitleri, seccomp profilleri gibi. OPA/Gatekeeper policy as code ile daha kompleks kurallar CI veya runtime aşamasında doğrulanır.

7.3 NetworkPolicy

NetworkPolicy ile pod seviyesinde inbound/outbound trafik kısıtlanır. Default deny yaklaşımı ile başlangıç yapmak ve sadece gerekli iletişimi açmak en güvenli yöntemdir. CNI desteği ve policy enforcement göz önünde bulundurulmalıdır.

7.4 Secrets yönetimi

Kubernetes Secrets objeleri küçük, baz64 ile saklanan veriler için uygundur ancak daha güvenli yöntemler Vault, ExternalSecrets veya KMS‑backed secret store entegrasyonlarıdır. Secrets'ın erişim kontrolleri, encryption at rest ve audit logging ile güvenlik sağlanmalıdır.

8. OBSERVABILITY: METRICS, LOGS, TRACING

8.1 Metrics

metrics‑server veya Prometheus ile pod/node metrikleri toplanır. Horizontal Pod Autoscaler (HPA) custom metriclerle de tetiklenebilir. Metriklerin cardinality'si ve retention politikalari izleme maliyetini belirler.

8.2 Logs

Centralized logging (Fluentd/FluentBit → Elasticsearch/Logstash/Opensearch) uygulama ve platform loglarını toplar. Log seviyeleri, structured logging ve log sampling ile maliyet yönetimi yapılmalıdır.

8.3 Tracing ve Distributed Context

OpenTelemetry ile tracing veri toplanır; service mesh veya sidecar approach ile trace propagation sağlanır. Tracing, latency root cause analysis ve performance optimization için vazgeçilmezdir.

9. EXTENSIBILITY: CRD, OPERATORS, CONTROLLERS

9.1 CRD (Custom Resource Definition)

CRD'ler Kubernetes API'sini genişletir. Organizasyonel domain objelerini cluster içinde temsil ederek operator pattern'lerini mümkün kılar. CRD tasarımında versioning ve conversion webhook'ları planlanmalıdır.

9.2 Operator Pattern

Operator'lar domain‑specific otomasyon sağlayan kontrolörlerdir. Stateful application'ların lifecycle yönetimi, backup/restore, scale/upgrade operasyonları operator ile otomatikleştirilebilir. Operator'lar dikkatli test ve RBAC yapılandırması gerektirir.

9.3 Controller Runtime & Kubebuilder

controller-runtime ve Kubebuilder, custom controller geliştirirken kullanılan framework'lerdir. Bu araçlar reconciliation loop'larını standartlaştırır ve test edilmesi kolay controller'lar üretir.

10. GERÇEK DÜNYA UYGULAMALARI

Netflix — Canary, Chaos ve Observability

Netflix ölçeğinde Kubernetes (veya benzeri orkestrasyon) kullanımı canary deploy, chaos engineering ve kapsamlı observability ile birleşir. Trafik yönetimi ve otomatik rollback stratejileri platformun temel parçalarıdır.

Uber — Coğrafi Dağıtım ve Edge

Uber gibi firmalar, bölgesel cluster'lar, lokasyon bazlı routing ve edge deploy stratejileri uygular. Kubernetes bileşenlerinin konfigürasyonu regional gereksinimlere göre optimize edilir.

Amazon / GKE / AKS — Managed Kubernetes

Managed hizmetler control plane yönetimini devralır; kullanıcılar worker node ve uygulama yönetimine odaklanır. Ancak RBAC, network ve storage entegrasyonları hâlâ kullanıcı sorumluluğundadır.

OpenAI — GPU scheduling ve Model Serving

ML uygulamaları için GPU node pool'ları, device plugin'lar ve nodal taint/toleration konfigürasyonları kullanılır. Model serving için rollout stratejileri ve resource isolation kritik rol oynar.

11. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Taşınabilir, deklaratif ve yeniden üretilebilir altyapı
• Yüksek otomasyon, self‑healing ve ölçeklenebilirlik
• Zengin eklenti ekosistemi (CNI, CSI, service mesh, operators)

Sınırlamalar

• Yüksek operasyonel karmaşıklık ve öğrenme eğrisi
• Yanlış konfigürasyonlarda maliyet ve performans sorunları
• Stateful uygulamalar için özel planlama gerekmesi

12. ALTERNATİFLER VE KARŞILAŞTIRMA

13. EN İYİ PRATİKLER

Production kullanım için

• Control plane HA, etcd yedekleme ve restore prosedürleri oluşturun.
• Resource requests/limits, readiness/liveness probe'larını zorunlu kılın.
• Namespace ve RBAC politikalarını kullanarak erişimi sınırlandırın.
• NetworkPolicy ile default deny yaklaşımını benimseyin.

Performans ve ölçek

• Node pool'ları ve taints/tolerations ile workload yerleşimini optimize edin.
• IPVS, eBPF tabanlı CNI ve scheduler tuning ile ağ ve scheduling performansını iyileştirin.

Güvenlik

• Admission controller ve policy as code ile deploy öncesi kontrolleri otomatize edin.
• Image signing, vulnerability scanning ve supply chain güvenliğini sağlayın.

Observability

• Metrics, logs ve tracing'in uçtan uca toplanmasını sağlayın; SLIs/SLOs tanımlayın.
• Alert fatigue'i önlemek için doğru threshold ve runbook'lara yatırım yapın.

14. SIK YAPILAN HATALAR

• etcd yedeksiz ve tek node produciton kurulumu yapmak
• Pod'lara resource limit tanımlamamak — node instability
• Secrets'ı ConfigMap veya düz metinle saklamak
• Observability ve alerting olmadan autoscaling konfigürasyonu uygulamak
• Admission policies olmadan third‑party operator'lara geniş yetki vermek

15. GELECEK TRENDLER

1. GitOps ve declarative operasyonların yaygınlaşması: Kubernetes işletimi Git tabanlı workflow'larla daha da entegre olacak.
2. eBPF ve ağ optimizasyonu: eBPF tabanlı CNI'ler daha yaygınlaşacak, ağ gözlemlenebilirliği artacak.
3. AI destekli operasyon: Anomali tespiti, otomatik remediation ve kapasite tahmini ML ile desteklenecek.
4. Edge ve federated Kubernetes: Hafif control plane ve federated cluster yaklaşımları edge/IoT senaryolarını destekleyecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Kubernetes'te etcd neden kritik?

   etcd cluster, Kubernetes'in tek source of truth'udur; metadata ve config burada saklanır. etcd'nin bozulması cluster bütünlüğünü etkiler, bu yüzden yedekleme ve HA gereklidir.

2. 2. kubelet'in rolü nedir?

   Kubelet, node'da çalışan agent'tır; API Server ile iletişim kurar, pod manifest'lerini uygular ve container runtime'ı kontrol eder.

3. 3. Service mesh gerekli mi?

   Small monolithic uygulamalar için anlamsız olabilir. Büyük mikroservis mimarilerinde observability, güvenlik ve traffic management için faydalıdır fakat operational yük getirir.

4. 4. Ingress ile LoadBalancer arasındaki fark nedir?

   LoadBalancer genelde cloud provider düzeyinde L4 load balancing sağlar; Ingress HTTP/HTTPS L7 routing ve path/host bazlı yönlendirme sunar.

5. 5. StatefulSet ve Deployment farkı nedir?

   Deployment stateless workload'lar içindir; StatefulSet ise stable network identity ve persistent storage gerektiren stateful uygulamalar içindir.

6. 6. Kubernetes güvenliği için nereden başlanmalı?

   RBAC, NetworkPolicy, image scanning, admission policies ve secrets yönetimi ile başlayın. Ardından PodSecurity ve runtime politikalarına geçin.

7. 7. Kubernetes'te observability nasıl kurulur?

   Prometheus + Grafana (metrics), Fluentd/FluentBit + ELK/Opensearch (logs) ve OpenTelemetry (tracing) ile uçtan uca gözlemlenebilirlik sağlanır.

8. 8. Managed Kubernetes mi yoksa self‑managed mı tercih etmeliyim?

   Managed Kubernetes (EKS/AKS/GKE) kontrol düzlemi yönetimini devralarak operasyon yükünü azaltır; ancak ağ, storage ve güvenlik entegrasyonları yine yönetilmelidir. Organizasyon yetkinliği ve compliance gereksinimleri seçimde belirleyicidir.

9. 9. CRD ve Operator ne zaman kullanılmalı?

   Domain‑specific automation, stateful application management veya kompleks lifecycle yönetimi gerektiğinde CRD ve Operator pattern'i uygundur.

Anahtar Kavramlar

Control Plane

Cluster'i yöneten merkezi bileşenler (API Server, etcd, Scheduler, Controller Manager).

Worker Node

Uygulama pod'larını çalıştıran makineler; kubelet ve container runtime içerir.

Pod

Kubernetes'teki en küçük çalıştırılabilir birim; bir veya daha fazla container içerir.

Service

Pod grubuna sabit erişim sağlayan ağ soyutlaması.

CRD / Operator

Kubernetes'i genişleten ve domain‑specific otomasyon sağlayan yapılar.

Öğrenme Yol Haritası

1. 0–1 ay: Docker, temel kubectl komutları ve minikube/kind ile basit uygulama deploy etme.
2. 1–3 ay: Deployments, Services, ConfigMap, Secret, PV/PVC ve temel networking (CNI) öğrenin.
3. 3–6 ay: Helm, Ingress, Prometheus/Grafana, logging stack ve PodSecurity konularında deneyim kazanın.
4. 6–12 ay: Service mesh, CRD/Operator geliştirme (Kubebuilder), cluster scaling ve HA, etcd yönetimi becerileri edinin.
5. 12+ ay: Multi‑cluster yönetimi, federated control planes, edge Kubernetes ve platform engineering konularında uzmanlaşın.