Bir e-ticaret şirketi düşünün: Kargo takip servisi çöktüğünde tüm sipariş yönetim sistemi de erişilemez hale geliyor. Bunun nedeni mimarinin monolitik olması. Mikro servis geçişi yapılıyor, ama asıl soru şu: onlarca bağımsız servisi kim yönetecek, sağlık kontrolleri kim yapacak, trafik dengesini kim kuracak? İşte Kubernetes tam bu noktada devreye giriyor.
Orkestrasyon Olmadan Mikro Servis Kaosa Dönüşür
Servisleri container’a alıp Docker ile çalıştırmak başlangıç için yeterli görünür. Fakat 10 servis 50’ye, 50 servis 200’e çıktığında elle müdahale mümkün olmaktan çıkar. Hangi container hangi node’da çalışacak? Bellek dolduğunda ne olacak? Bir pod çökerse nasıl yeniden ayağa kalkacak? Yeni bir servis versiyonu canlıya alınırken kullanıcı trafiği nasıl kesilmeden yönlendirilecek? Bunların hepsine yanıt veren tek olgun araç Kubernetes’tir. Google’ın iç orkestrasyon sistemi Borg’dan türetilen bu platform 2014’te açık kaynak olarak yayınlandı; bugün AWS EKS, Google GKE ve Azure AKS gibi managed servisler üzerinde milyonlarca cluster çalıştırılıyor.
Pod, Deployment ve Service: Üç Temel Kavram
Kubernetes öğreniminde çoğu kişi terminoloji yükünde kaybolur. Sade bir çerçeve: Pod, bir veya birkaç container’ın birlikte çalıştığı en küçük birimdir. Deployment, o pod’un kaç kopyasının (replica) çalışacağını ve güncelleme stratejisini tanımlar. Service ise bu pod’lara sabit bir erişim noktası sağlar; podlar ölüp yenilendiğinde IP adresleri değişse de servis adresi sabit kalır.
Bu üçlü doğru kurulduğunda bir pod çöktüğünde Kubernetes onu fark eder, 30-60 saniye içinde yerine yenisini başlatır ve trafik kesilmez. Deployment’taki replicas: 3 tanımı yeterli; Kubernetes bu üç pod’un her zaman ayakta kalmasını güvence altına alır, siz başka şeylerle ilgilenebilirsiniz.
Rolling Update ile Sıfır Kesintili Yayın
Kubernetes’in gerçek değeri burada ortaya çıkar. Bir uygulamayı güncellerken varsayılan strateji RollingUpdate‘tir: yeni sürüm pod’lar birer birer devreye girer, eski sürüm pod’lar kapanır. maxSurge: 1 ve maxUnavailable: 0 parametreleriyle güncelleme boyunca her zaman en az mevcut kapasite korunur. Yayın hatalıysa kubectl rollout undo deployment/siparis-servisi komutuyla önceki versiyona saniyeler içinde dönülür. Gece yarısı bakım penceresi, kullanıcılara gönderilen “şu an bakım yapılıyor” bildirimi — bunların hiçbirine gerek yoktur.
Kaynak Limitleri Olmadan Cluster Felç Olur
Sık yapılan hata: resource request ve limit tanımlamamak. Bir servis bellek sızıntısı yaşarsa tüm node’u tüketebilir ve aynı node’daki diğer podlar da çöker. Her deployment’a mutlaka şu blok eklenmelidir:
requests.memory: "128Mi"— Kubernetes bu pod’u yerleştirirken bu kadar alan rezerve eder; node’un kapasitesi buna göre hesaplanır.limits.memory: "256Mi"— Bu sınırı aşan pod OOMKilled ile sonlandırılır, node kurtarılır ve diğer podlar etkilenmez.requests.cpu: "100m"/limits.cpu: "500m"— CPU throttling ve adil paylaşım için; 1000m = 1 tam CPU çekirdeği.
Bu değerler ilk kurulumda tahmin edilir, gerçek metriklerle ayarlanır. Prometheus + Grafana üzerinden haftalık kullanım grafiği incelenip değerler revize edilmelidir.
Horizontal Pod Autoscaler: Yük Geldiğinde Otomatik Büyü
Black Friday senaryosu: trafik aniden 10 katına çıkıyor. HPA (Horizontal Pod Autoscaler), CPU kullanımı belirlenen eşiği (örneğin %70) aştığında otomatik olarak yeni pod’lar başlatır; trafik sakinleştiğinde fazla pod’ları kaldırır. Bu davranış için Metrics Server kurulu olmalı ve deployment’ta resource request tanımlı olmalıdır — HPA, resource limit olmayan deployment’ı ölçekleyemez. İleri düzeyde özel metriklerle (örneğin saniyede gelen sipariş sayısına göre) KEDA (Kubernetes Event-Driven Autoscaling) kullanılabilir.
Ingress ile Dış Trafik Yönetimi
Cluster içinde servisler birbiriyle konuşabilir ama dış dünyadan nasıl erişilecek? Her servise LoadBalancer tipi atamak hem maliyetli (her biri için ayrı cloud load balancer ücreti) hem de karmaşıktır. Bunun yerine tek bir Ingress Controller (nginx-ingress veya Traefik) tüm dış trafiği alır, URL path veya hostname kurallarına göre doğru servise yönlendirir. Tek bir SSL sertifikası burada sonlandırılır; iç servisler HTTP ile konuşabilir. cert-manager ile Let’s Encrypt entegrasyonu sağlanırsa SSL sertifika yenileme de otomatikleşir.
Namespace ile Ortam İzolasyonu
Aynı cluster’da production, staging ve development çalıştırılabilir. Farklı namespace’ler kaynak kotaları ve RBAC politikalarıyla birbirinden yalıtılır. Bir geliştirici production namespace’e erişemez; staging’deki hatalı deployment production’ı etkilemez. Bu yapı özellikle küçük-orta ekiplerde cluster maliyetini düşürürken disiplini korur. Her namespace için ayrı ResourceQuota tanımlanarak staging’in production kaynaklarını tüketmesi engellenir.
Nereden Başlamalı?
Kubernetes’e geçiş büyük bir monoliti parçalayarak değil, küçük ve bağımsız bir servisle başlamalıdır. Önce bir local cluster kurun (minikube veya kind ile birkaç dakika yeterli), basit bir uygulama için Deployment + Service + Ingress yazın, ardından HPA ekleyin. Bu döngüyü küçük ölçekte tamamlayan bir ekip, büyük geçişlerde hangi adımların kritik olduğunu zaten biliyor olacaktır. Managed bir Kubernetes servisi (EKS, GKE, AKS) tercih etmek control plane yönetimini cloud sağlayıcısına bırakır; küçük ekipler için bu başlangıç maliyetini önemli ölçüde düşürür.