- 01Kubernetes kararı ekip büyüklüğüne değil, servis sayısı, deployment sıklığı, HA ihtiyacı ve platform sahipliğine göre verilmelidir.
- 02Tek uygulama, sabit trafik ve seyrek deployment senaryosunda iyi otomatikleştirilmiş VM veya daha basit container platformu Kubernetes'ten daha düşük toplam karmaşıklık sağlayabilir.
- 03Managed Kubernetes control plane ve cluster yaşam döngüsünün bir kısmını sağlayıcıya devreder; workload, node, backup ve uygulama operasyonu yine sahiplik gerektirir.
- 04Production Kubernetes HA, RBAC, scaling, upgrade ve resource management gerektirir; öğrenme cluster'ı ile production platformu aynı operasyon modeli değildir.
- 0519 Eylül 2026 itibarıyla aktif Kubernetes minor dalları 1.37, 1.36 ve 1.35'tir; sürüm ve EOL takvimi platform kararının parçası olmalıdır.
Kısaca
Kubernetes küçük ekipler için otomatik olarak fazla değildir; fakat tek uygulama, düşük değişim hızı ve sınırlı yüksek erişilebilirlik ihtiyacında getirdiği operasyon yükü sağladığı faydayı aşabilir. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak Kubernetes kararını ekip büyüklüğüne değil; servis sayısı, dağıtım sıklığı, HA ihtiyacı, platform sahipliği ve yükseltme sorumluluğuna göre verir.
Küçük ekip için doğru soru: Kubernetes hangi problemi çözecek?
Kubernetes bir hedef değil, operasyon problemlerini çözmek için kullanılan bir platformdur.
Şu problemler yoksa Kubernetes çoğu küçük ekip için gereksiz karmaşıklık oluşturabilir:
- Birden fazla servis için ortak deployment standardı
- Otomatik yeniden planlama ve self-healing ihtiyacı
- Yüksek erişilebilirlik
- Yatay ölçekleme
- Ortak servis keşfi
- Tekrarlanabilir environment yönetimi
- Birden fazla ürün ekibi için ortak platform
- Sık deployment ve rollback
Tek bir uygulamayı iki ayda bir deploy ediyor, trafik tahmin edilebilir kalıyor ve bir VM'in yeniden başlatılması iş hedefinizi karşılıyorsa Kubernetes'e geçiş için güçlü bir gerekçeniz olmayabilir.
Hızlı karar tablosu
| Durum | İlk öneri | Neden |
|---|---|---|
| Tek uygulama, düşük trafik, seyrek deploy | VM veya basit container platformu | Kubernetes'in operasyon maliyeti gereksiz olabilir |
| 3-5 bağımsız servis, sık deploy | Kubernetes değerlendirilebilir | Ortak deployment ve service discovery anlamlı hale gelir |
| Yüksek erişilebilirlik zorunlu | Kubernetes güçlü aday | Scheduling ve self-healing değer üretir |
| Tek DevOps sahibi, nöbet yok | Managed Kubernetes veya daha basit platform | Cluster sahipliği tek kişide risk yaratır |
| Birden fazla ürün ekibi ortak platform kullanacak | Kubernetes + platform yaklaşımı | Standardizasyon değeri yükselir |
| Stateful workload ağırlıklı, ekip deneyimsiz | Daha basit başlangıç | Depolama ve recovery operasyonu zorlaşabilir |
| Çok hızlı ölçek değişimi | Kubernetes veya managed platform | Autoscaling ve scheduling değer sağlar |
| Platform operasyonu stratejik değil | Managed Kubernetes | Control plane yükü sağlayıcıya bırakılır |
Kubernetes'in küçük ekipte fazla geldiği dört sinyal
1. Tek uygulama için platform kuruyorsanız
Kubernetes'in en büyük değeri ortak bir çalışma modeli yaratmasıdır.
Tek bir uygulama:
- tek database
- tek deployment pipeline
- sabit trafik
- düşük availability hedefi
ile çalışıyorsa aynı problemi iyi otomatikleştirilmiş bir VM veya container host daha düşük operasyon yüküyle çözebilir.
Bu durumda Kubernetes:
- yeni network modeli
- manifest yönetimi
- cluster upgrade
- RBAC
- observability
- storage
- certificate
- ingress/gateway
gibi yeni sorumluluklar ekler.
2. Cluster'ın sahibi belli değilse
Kubernetes'in kurulması ile işletilmesi farklı işlerdir.
Production cluster için şu soruların sahibini yazabilmelisiniz:
- Kubernetes sürümünü kim yükseltecek?
- Node patch işlemini kim yapacak?
- Control plane veya node incident'ına kim bakacak?
- RBAC değişikliklerini kim yönetecek?
- Backup ve restore testlerini kim takip edecek?
- Ingress/Gateway ve certificate değişiklikleri kimde?
- Capacity planning kimde?
Bu sorular "ekipçe bakıyoruz" seviyesinde kalıyorsa cluster sahibi yok demektir.
3. Deployment probleminiz yoksa
Kubernetes bazen uygulama sayısı az olduğu halde "modernleşme" projesi olarak seçilir.
Ancak mevcut deployment süreciniz:
- otomatik
- tekrar üretilebilir
- rollback yapılabilir
- konfigürasyon yönetimi düzgün
- downtime kabul edilebilir düzeyde
ise Kubernetes geçişi mevcut bir problemi çözmeden platform maliyetini artırabilir.
4. Platform bilişsel yükü artırıyorsa
DORA platform mühendisliğinin amacını geliştiriciler için karmaşıklığı azaltmak olarak konumlandırır.
Küçük ekipte her geliştiricinin:
- Kubernetes object modellerini
- Helm
- network policy
- storage class
- RBAC
- deployment troubleshooting
öğrenmesi gerekiyorsa platform doğru soyutlama seviyesinde değildir.
Platform geliştiricinin işini basitleştirmeli, cluster uzmanlığı talep etmemelidir.
Kubernetes'in küçük ekipte değer ürettiği durumlar
Küçük ekip olmak Kubernetes kullanmamak için tek başına sebep değildir.
Birden fazla servis aynı standardı paylaşacaksa
Uygulamanız:
- API
- worker
- scheduler
- frontend
- queue consumer
- background service
gibi ayrı servislerden oluşuyorsa deployment ve resource yönetimi ortak modele bağlanabilir.
Deployment sıklığı yüksekse
Günde veya haftada çok sayıda deployment yapıyorsanız:
- rollout
- rollback
- health check
- deployment history
- resource limit
gibi Kubernetes primitive'leri operasyonu standardize edebilir.
Self-healing iş hedefi için önemliyse
Pod veya node hatasında workload'un başka bir node üzerinde otomatik ayağa kalkması önemliyse Kubernetes doğrudan değer sağlar.
Birden fazla ekip ortak altyapı kullanıyorsa
DORA'nın platform yaklaşımında ortak platformun değeri, ekiplerin tekrar eden altyapı sorunlarını ayrı ayrı çözmesini önlemektir.
Birden fazla ürün ekibi aynı:
- deployment standardını
- logging modelini
- secret yönetimini
- network politikasını
- observability modelini
kullanacaksa Kubernetes ortak platformun temeli olabilir.
Production Kubernetes tek node cluster değildir
Kubernetes resmi dokümantasyonu production ortamının öğrenme veya test cluster'ından daha fazla gereksinim taşıdığını açıkça belirtir.
Production ortamında değerlendirilmesi gerekenler arasında:
- control plane availability
- yeterli worker kapasitesi
- load balancing
- RBAC
- authentication
- resource limits
- scaling
- backup
- upgrade
bulunur.
Tek node Kubernetes, öğrenmek veya küçük test workload'u çalıştırmak için uygun olabilir; ancak "Kubernetes kullanıyoruz" demek production dayanıklılığının otomatik olarak sağlandığı anlamına gelmez.
Managed Kubernetes küçük ekip için neyi çözer?
Managed Kubernetes, Kubernetes'in tüm operasyonunu ortadan kaldırmaz.
Sağlayıcıya göre şu sorumluluklar devredilebilir:
- control plane availability
- control plane patching
- Kubernetes version lifecycle
- cluster API availability
- bazı upgrade işlemleri
Ancak çoğu modelde sizin tarafınızda kalan işler vardır:
- workload deployment
- node sizing
- resource requests/limits
- application observability
- secrets
- network policy
- backup
- stateful workload recovery
- cost control
Bu nedenle managed Kubernetes "Kubernetes ops yok" değil, "cluster ops'un bir kısmını sağlayıcıya devretmek" anlamına gelir.
Kubernetes'in resmi production rehberi de üretim ortamında hangi sorumlulukları kendiniz üstleneceğiniz ve hangilerini sağlayıcıya bırakacağınız kararını temel seçimlerden biri olarak tanımlar.
Küçük ekipte K3s daha doğru olabilir mi?
K3s, küçük footprint ve daha sade kurulum gereken ortamlarda güçlü bir seçenek olabilir.
Uygun olabileceği durumlar:
- küçük cluster
- edge
- homelab dışına çıkan ama sınırlı kapasite
- az sayıda node
- Kubernetes API uyumluluğu isteniyor
- tam upstream cluster operasyonu ağır geliyor
Ancak K3s kullanmak Kubernetes operasyonunu sıfırlamaz.
Yine:
- upgrade
- backup
- certificates
- storage
- networking
- observability
- RBAC
sorumlulukları vardır.
K3s daha hafif Kubernetes olabilir; "ops gerektirmeyen Kubernetes" değildir.
Kubernetes cost yalnızca node maliyeti değildir
Küçük ekiplerde cluster cost hesaplanırken sık yapılan hata yalnızca node fiyatına bakmaktır.
Toplam maliyet:
Node maliyeti + operasyon zamanı + gözlemlenebilirlik + backup + network + upgrade + incident maliyeti
olarak değerlendirilmelidir.
Örneğin iki node'lu cluster düşük compute maliyetine sahip olabilir; fakat her ay birkaç saat:
- upgrade
- troubleshooting
- certificate
- storage
- alert
- backup
operasyonu gerekiyorsa mühendislik zamanı gerçek TCO'nun parçasıdır.
Upgrade takvimi olmadan Kubernetes seçmeyin
19 Eylül 2026 itibarıyla Kubernetes'in en güncel minor sürümü 1.37'dir ve 26 Ağustos 2026'da yayımlanmıştır. Upstream proje en güncel üç minor dalı aktif olarak destekler. Kubernetes 1.37'nin EOL tarihi 28 Ekim 2027'dir. citeturn683820search1turn683820search2
Bu nedenle Kubernetes kullanan küçük ekip şunu cevaplayabilmelidir:
- Hangi minor sürümdeyiz?
- EOL tarihi nedir?
- Bir sonraki upgrade ne zaman?
- Upgrade test ortamı var mı?
- Workload compatibility nasıl doğrulanacak?
Bu sorulara cevap veremiyorsanız managed model daha güvenli olabilir.
Üç seviyeli karar modeli
Seviye 1: Basit VM/container host
Uygun olduğunda:
- 1-2 uygulama
- sabit trafik
- düşük HA hedefi
- küçük ekip
- seyrek deployment
Avantaj:
- düşük karmaşıklık
- doğrudan debug
- düşük operasyon yükü
Seviye 2: Managed Kubernetes
Uygun olduğunda:
- Kubernetes primitive'lerine ihtiyaç var
- ekip küçük
- control plane işletmek istemiyorsunuz
- standart deployment önemli
Avantaj:
- Kubernetes kabiliyeti
- daha düşük cluster yönetim yükü
Seviye 3: Kendi Kubernetes platformunuz
Uygun olduğunda:
- platform operasyonu stratejik
- birden fazla ekip var
- özel network/storage ihtiyacı var
- dedicated platform ownership var
- internal developer platform geliştiriliyor
Bu seviye teknoloji seçimi değil, organizasyon yatırımıdır.
Küçük ekip için beş soruluk test
Kubernetes'e geçmeden önce şu sorulara cevap verin:
- Kubernetes hangi mevcut problemi çözüyor?
- Cluster'ın operasyon sahibi kim?
- Upgrade takvimi kimin sorumluluğunda?
- Basit bir VM veya managed app platformu aynı ihtiyacı çözebilir mi?
- Kubernetes geliştiricilerin işini azaltacak mı, artıracak mı?
İlk dört soruya net cevap veremiyorsanız geçişi ertelemek çoğu zaman daha doğru olur.
Dynamis'te küçük ekip Kubernetes kararı
Dynamis'in DevOps hizmetinde ilk hedef her müşteriye Kubernetes kurmak değildir.
Önce:
- workload sayısı
- deployment sıklığı
- HA hedefi
- stateful dependency
- ekip kapasitesi
- incident ownership
- üç yıllık operasyon maliyeti
çıkarılır.
Kubernetes değer üretiyorsa managed veya self-managed model seçilir. Daha basit bir VM veya container platformu aynı iş hedefini daha düşük operasyon yüküyle karşılıyorsa Kubernetes önerilmez.
Geçiş kararı kesinleştiyse Kubernetes'e geçiş rehberi pilot ve cutover planını detaylandırır.
Sık yapılan hatalar
Kubernetes'i ekip büyüklüğüne göre seçmek: Beş kişilik ekip de Kubernetes kullanabilir; 50 kişilik ekip de ihtiyaç duymayabilir.
Tek uygulama için platform yatırımı yapmak: Çözülen problem platform maliyetinden küçük olabilir.
Managed Kubernetes'i sıfır operasyon sanmak: Workload, node, backup ve uygulama operasyonu devam eder.
Upgrade'i proje sonrası düşünmek: Upstream sürüm desteği sonludur.
Her geliştiriciyi Kubernetes uzmanı yapmak: Platform bilişsel yükü azaltmalıdır.
Node fiyatını toplam maliyet sanmak: Mühendislik ve incident zamanı TCO'nun parçasıdır.
Sırada ne var
- Kubernetes vs Docker: hangisi ne zaman kullanılmalı?: küçük ekipte Docker/Compose ile devam etmenin ve Kubernetes'e geçmenin operasyon farklarını karşılaştırın.
- Kubernetes nedir? Ne işe yarar ve ne zaman kullanılmalı?: karar vermeden önce pod, node, control plane, scaling ve self-healing temellerini görün.
- CI/CD nedir? Yazılım deployment süreci nasıl otomatikleştirilir?: Kubernetes olmasa da küçük ekipte tekrarlanabilir build, test ve deployment otomasyonu kurun.
- DevOps nedir? Yazılım ekipleri için nasıl çalışır?: Kubernetes kararı vermeden önce DevOps'un Kubernetes'ten daha geniş çalışma modeli olduğunu görün.
- Kubernetes'e geçiş rehberi: Kubernetes kararı kesinleştiyse migration ve production hazırlığını planlayın.
- Kubernetes ekibi kurmak mı, operasyonu dış kaynak kullanmak mı?: Kubernetes özelinde ekip, nöbet, yükseltme ve operasyon sorumluluğunu karşılaştırın.
- Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi: platform operasyonunun kimde kalacağını belirleyin.
- AWS alternatifi: hangi iş yükü nerede kalmalı?: Kubernetes workload'larının cloud placement kararını inceleyin.
- DevOps hizmeti: Kubernetes veya daha basit platform seçimini birlikte değerlendirin.
Kaynaklar
Kaynaklar
- 1.Production environmentThe Kubernetes Authors · 2026-09-19
- 2.Getting started with KubernetesThe Kubernetes Authors · 2026-09-19
- 3.Kubernetes releases and supported branchesThe Kubernetes Authors · 2026-09-19
- 4.Platform engineering capabilityGoogle Cloud DORA · 2026-09-19
- 5.2024 Accelerate State of DevOps ReportGoogle Cloud DORA · 2026-09-19
Sık sorulan sorular
Kubernetes için kaç kişilik ekip gerekir?
Sabit bir ekip sayısı yoktur. Asıl soru cluster yükseltmesi, güvenlik, gözlemlenebilirlik, yedekleme ve olay müdahalesi için kimin sürekli sahiplik taşıdığıdır. Bu sorumlulukları küçük ekip içinde karşılayamıyorsanız yönetilen Kubernetes veya daha basit bir platform değerlendirilmelidir.
Tek uygulama için Kubernetes gerekir mi?
Genellikle zorunlu değildir. Tek uygulama, düşük değişim hızı ve sabit kapasite ihtiyacında iyi otomatikleştirilmiş bir sanal sunucu veya daha basit container platformu yeterli olabilir. Kubernetes; çoklu servis, yüksek erişilebilirlik, ortak platform standardı veya ölçek ihtiyacı olduğunda daha anlamlı hale gelir.
Managed Kubernetes küçük ekip için mantıklı mı?
Kubernetes'in scheduling, self-healing ve standart deployment modeline ihtiyaç var ancak control plane, upgrade ve cluster yaşam döngüsünü yönetmek istemiyorsanız yönetilen Kubernetes küçük ekip için daha uygun olabilir. Node ve uygulama operasyonu yine sahiplik gerektirir.
Kubernetes küçük ekip için ne zaman fazla gelir?
Platformun sağladığı faydadan daha fazla operasyon yükü üretiyorsa fazla gelir. Tek uygulama, seyrek deployment, düşük HA ihtiyacı ve sınırlı platform sahipliği varsa Kubernetes yerine daha basit bir model genellikle daha düşük toplam karmaşıklık sağlar.