Kubernetes nedir sorusu çoğu zaman teknik bir meraktan ziyade, mimari bir kararın başlangıcıdır. Birçok ekip için asıl konu teknoloji trendlerini izlemek değil; artan trafik, kesintisiz dağıtım ihtiyacı, çoklu servis yapısı ve operasyon yükü karşısında hangi altyapının sürdürülebilir olduğuna karar vermektir.
Kubernetes, konteyner tabanlı uygulamaları çalıştırmak, ölçeklemek ve yönetmek için geliştirilmiş bir orkestrasyon platformudur. En temel düzeyde uygulamanın kaç kopya çalışacağını, bir sunucu düştüğünde ne olacağını, yeni sürümün nasıl devreye alınacağını ve servislerin birbirini nasıl bulacağını merkezi biçimde yönetir. Yine de bu tanım tek başına yeterli değildir. Çünkü Kubernetes, her kurumsal uygulama için otomatik olarak doğru tercih değildir.
Asıl soru şudur: Hangi noktada sanal sunucu, basit Docker kurulumu veya PaaS yaklaşımı yetersiz kalır? Hangi eşikten sonra Kubernetes operasyonel maliyeti azaltır, hangi durumda ise gereksiz karmaşıklık yaratır? Bu rehber; kurumsal web platformları, ERP/CRM çözümleri, API servisleri ve ölçeklenebilir SaaS ürünleri için karar vermeyi kolaylaştıracak teknik bir çerçeve sunar.
Kubernetes nedir? Kısa tanım ve pratik çerçeve
Kubernetes, ilk olarak Google’ın iç sistemlerinden gelen deneyimle şekillenen ve 2014 yılında açık kaynak olarak yayımlanan bir konteyner orkestrasyon sistemidir. Uygulamalar genellikle container olarak paketlenir; Kubernetes ise bu container’ları kümeler üzerinde çalıştırır.
Pratikte şu görevleri üstlenir:
- Bir servisten örneğin 2 yerine 10 kopya çalıştırmak
- Arızalanan bir pod’u saniyeler içinde yeniden ayağa kaldırmak
- Yeni sürümü kademeli olarak dağıtmak ve hata varsa geri almak
- Servis keşfi, iç ağ iletişimi ve yük dağıtımı sağlamak
- CPU ve bellek limitlerini politika bazlı yönetmek
Basit bir örnek düşünelim. Kurumsal bir müşteri portalınız var. Aynı sistemde kullanıcı girişi, dosya yükleme, raporlama ve bildirim servisi ayrı container’larda çalışıyor. Trafik mesai saatlerinde 3 kat artıyor, gece ise düşüyor. Kubernetes bu servislerin kaynak kullanımını ayrı ayrı yönetebilir. Dosya işleme servisi 1 pod’dan 4 pod’a çıkarken raporlama servisi aynı seviyede kalabilir. Böylece tüm sistemi tek bir sanal sunucuda büyütmek yerine, iş yükünü servis bazında ölçeklersiniz.
Kubernetes ne zaman gerçekten gerekli olur?
En kritik karar noktası burada başlar. Kubernetes genellikle tek uygulamalı küçük sistemlerde değil, büyüyen operasyonlarda anlam kazanır. İhtiyaç sinyallerini ölçülebilir şekilde değerlendirmek gerekir.
1. Uygulama birden fazla servise ayrıldıysa
Monolit bir uygulama tek sunucuda yönetilebilir. Ancak sistem 6-8 ayrı servise bölündüğünde tablo değişir. Örneğin kimlik doğrulama, sipariş akışı, stok senkronizasyonu, raporlama motoru ve harici entegrasyon katmanı birbirinden bağımsız deploy ediliyorsa, manuel yönetim kısa sürede kırılgan hale gelir.
Bu aşamada Kubernetes, servislerin yaşam döngüsünü standardize eder. Her servisin kendi deployment tanımı, health check’i ve kaynak limiti olur. Özellikle ekip sayısı 5 kişiden 15 kişiye çıktığında bu disiplin ciddi fark yaratır.
2. Dağıtım sıklığı arttıysa
Ayda 1 sürüm alan bir uygulama ile günde 10 kez güncellenen bir ürün aynı operasyon modelini taşımaz. Sürüm sıklığı arttıkça kesintisiz dağıtım, rollback ve gözlemlenebilirlik kritik hale gelir.
Örneğin CI/CD hattınız her commit sonrası test, image build ve deploy yapıyorsa; Kubernetes rolling update ile yeni sürümü parça parça devreye alabilir. 12 pod çalışan bir serviste önce 2 pod güncellenir, sistem sağlıklıysa kalanlar geçer. Bu yaklaşım, tüm sistemi tek seferde yeniden başlatmaktan daha kontrollüdür.
3. Trafik öngörülemez hale geldiyse
Kampanya dönemleri, B2B sipariş yoğunluğu, dönem sonu raporlama veya e-fatura akışları bazı kurumsal sistemlerde ani yük oluşturur. Eğer trafik hafta içi 09:00-11:00 arasında normal seviyenin 4 katına çıkıyorsa, sabit kapasiteli altyapı ya yetersiz kalır ya da sürekli fazla maliyet üretir.
Kubernetes, Horizontal Pod Autoscaler gibi mekanizmalarla CPU, bellek ya da özel metriklere göre ölçekleme yapabilir. Buradaki kritik nokta şudur: Ölçekleme ancak uygulama gerçekten stateless veya buna yakın bir yapıda tasarlandıysa verimli olur.
4. Yüksek erişilebilirlik hedefi varsa
Tek sunucu üzerinde çalışan bir sistemde planlı bakım bile kesinti anlamına gelir. Oysa bazı kurumsal uygulamalarda 7/24 erişim beklentisi vardır. Özellikle müşteri self-servis portalları, saha operasyon uygulamaları ve bayi sistemleri bu gruba girer.
En az 3 worker node içeren bir kümede servisleri dağıtmak, tek nokta arızası riskini azaltır. Bir node erişilemez olduğunda pod’lar diğer node’larda yeniden başlatılır. Elbette bu yaklaşımın işe yaraması için veritabanı, dosya depolama ve ağ katmanının da doğru tasarlanmış olması gerekir.
Kubernetes hangi durumlarda gereksiz olabilir?
Doğru teknoloji kararı, yalnızca neyi kullanacağınızı değil, neyi kullanmayacağınızı da bilmeyi gerektirir. Kubernetes bazen çok erken devreye alınır ve ekip üzerinde ek yük yaratır.
Aşağıdaki senaryolarda daha yalın çözümler daha uygun olabilir:
- Tek uygulama, düşük trafik, ayda birkaç deploy
- 2-3 geliştiricili ekip, ayrılmış DevOps sorumluluğu yok
- Tek müşteri ya da sınırlı kullanıcı grubu için çalışan iç uygulamalar
- Yatay ölçek yerine daha güçlü tek sunucuyla çözülebilen iş yükleri
Örneğin şirket içinde kullanılan bir onay uygulaması günde 300 kullanıcı tarafından açılıyor ve yalnızca mesai saatlerinde aktifse, yönetilen bir App Service, basit Docker Compose altyapısı veya doğrudan sanal makine üzerinde çalıştırma daha mantıklı olabilir. Kubernetes burada hız değil, operasyon borcu üretir.
Bu borcun somut karşılıkları vardır: cluster yönetimi, ingress yapılandırması, secret yönetimi, log toplama, metrik izleme, ağ politikaları, yedekleme ve maliyet görünürlüğü. Bu başlıklar çözülmeden Kubernetes yalnızca “kurulmuş” olur; sağlıklı biçimde işletilmiş olmaz.
Kurumsal uygulamalarda karar verirken bakılması gereken 6 teknik kriter
Kararı sezgiyle değil, sistem davranışıyla vermek gerekir. Aşağıdaki kriterler değerlendirme için net bir çerçeve sunar.
Servis sayısı ve bağımlılık yoğunluğu
2 servisten 12 servise çıkıldığında bağımlılık matrisi hızla karmaşıklaşır. API gateway, kuyruk, cache, worker ve webhook tüketicileri devreye girdiyse orkestrasyon ihtiyacı daha belirgin hale gelir.
Dağıtım frekansı
Haftada 1 dağıtım ile günde 20 dağıtım arasında büyük fark vardır. Sürüm sayısı yükseldikçe standart deployment süreçleri, health probe’lar ve rollback mekanizmaları daha değerli hale gelir.
Ortam sayısı
Yalnızca test ve production değil; bazen staging, UAT ve müşteri özel ortamları da bulunur. 4 ayrı ortam yönetiliyorsa, altyapı tanımını kod olarak sürdürmek ciddi avantaj sağlar.
Gözlemlenebilirlik ihtiyacı
Merkezi log, metrik ve iz sürme olmadan çok servisli yapı yönetilemez. Kubernetes tek başına bunu sağlamaz; fakat Prometheus, Grafana, Loki, OpenTelemetry gibi araçlarla düzenli bir temel sunar.
Ekip yetkinliği
En azından bir kişinin container yaşam döngüsü, ağ modeli, kaynak yönetimi ve CI/CD konusunda yetkin olması gerekir. Teoride güçlü görünen bir mimari, sahada bilgi açığı nedeniyle yavaşlayabilir.
Maliyet modeli
3 node’lu yönetilen bir cluster ile tek sanal sunucunun maliyeti aynı değildir. Üstelik hesaba katılması gereken yalnızca altyapı faturası değildir; izleme, yedekleme, trafik çıkışı ve operasyon zamanı da değerlendirilmelidir. Bazı projelerde bu maliyetin karşılığı vardır, bazılarında yoktur.
Tipik kurumsal senaryolar: Hangi projede mantıklı, hangisinde değil?
Somut senaryolar karar vermeyi kolaylaştırır.
Mantıklı olduğu senaryo
Bir üretim şirketi için geliştirilen B2B sipariş platformunu düşünelim. Bayi girişi, fiyat motoru, kampanya servisi, stok entegrasyonu, ERP senkronizasyonu ve raporlama katmanı ayrı servislerden oluşuyor. Sistem 8 entegrasyon noktasına bağlı. Ay içinde 40’tan fazla sürüm çıkıyor. Dönemsel kampanyalarda trafik 5 katına kadar yükseliyor. Bu yapı için Kubernetes güçlü bir adaydır.
Erken olduğu senaryo
Tek panelden yönetilen, 2.000 aktif kullanıcılı bir saha form uygulaması var. Arka planda tek API, tek veritabanı ve sınırlı dosya yükleme trafiği bulunuyor. Deploy haftada 1 kez yapılıyor. Böyle bir sistem için önce iyi yapılandırılmış bir cloud app service, managed database ve otomatik yedekleme çoğu zaman yeterlidir.
Kubernetes geçişinde en sık yapılan hatalar
Geçiş kararının doğru olması yeterli değildir; uygulamanın buna uygun şekilde hazırlanması da gerekir.
- Monolit uygulamayı aynen taşıyıp ölçeklenebilir sanmak
- Stateful bileşenleri plansız şekilde cluster içine sıkıştırmak
- Readiness ve liveness probe tanımlamamak
- Log ve metrik altyapısını sonraya bırakmak
- Kaynak limitlerini tanımsız bırakıp node tüketimini öngörememek
Örneğin aşağıdaki gibi temel bir readiness probe bile sürüm geçişlerinde önemlidir:
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10Bu tanım yoksa uygulama ayağa kalkmadan trafik almaya başlayabilir. Kullanıcı hata görür; ekip ise sorunun kodda mı yoksa altyapıda mı olduğunu anlamaya çalışırken zaman kaybeder.
Sonuç: Kubernetes bir araçtır, hedef değil
Kubernetes; özellikle çok servisli, sık deploy edilen, yüksek erişilebilirlik beklenen ve değişken trafik taşıyan kurumsal uygulamalarda güçlü bir çözümdür. Buna karşılık küçük ekipli, sınırlı trafik alan ve düşük operasyon karmaşıklığına sahip projelerde gereksiz yük oluşturabilir.
Sağlıklı yaklaşım şudur: Önce uygulamanın davranışını ölçün. Servis sayısını, sürüm sıklığını, kesinti toleransını, trafik desenini ve ekibin operasyon kapasitesini netleştirin. Karar bu veriler üzerinden verildiğinde Kubernetes gerçekten değer üretir. Aksi durumda yalnızca modern görünen, ama pahalı ve yorucu bir katmana dönüşür.
Kurumsal yazılım projelerinde altyapı seçimi, geliştirme kalitesi kadar önemlidir. İyi mimari; bugün çalışan değil, 12 ay sonra da yönetilebilir kalan sistemdir.
