- 01Kendi Kubernetes ekibi, platform şirket için stratejik bir iç ürün haline geldiğinde ve birden fazla ürün ekibine sürekli platform geliştirmesi sunduğunda daha anlamlıdır.
- 02Dış kaynak Kubernetes operasyonu, küçük teknik ekiplerde yükseltme, node bakımı, gözlemlenebilirlik, yedekleme ve olay müdahalesini ayrı bir platform departmanı kurmadan yönetmeye yardımcı olabilir.
- 03Managed Kubernetes ile yönetilen Kubernetes operasyonu aynı şey değildir; control plane yönetimi workload ve production operasyonunun tamamını ortadan kaldırmaz.
- 04Kendi ekip ile dış kaynak modeli aynı sorumluluk kapsamı ve üç yıllık toplam sahiplik maliyeti üzerinden karşılaştırılmalıdır.
- 05Sağlayıcı bağımlılığını azaltmak için hesaplar, altyapı kodu, Kubernetes kaynakları ve operasyon belgeleri müşterinin kontrolünde tutulmalıdır.
Kısaca
Kubernetes için kendi ekibinizi kurmak, platform şirketinizin ürün geliştirme biçiminin kalıcı bir parçasıysa ve platform mühendisliği içeride stratejik değer üretiyorsa daha doğru olabilir. Kubernetes operasyonunu dış kaynak kullanmak ise küçük veya orta ölçekli teknik ekiplerde, küme yaşam döngüsü, yükseltme, olay müdahalesi, gözlemlenebilirlik ve yedekleme gibi sürekli işleri ayrı bir ekip kurmadan yönetmek istediğinizde daha uygundur. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak bu kararı yalnız personel maliyetiyle değil, production sorumluluğu ve üç yıllık toplam sahiplik maliyetiyle değerlendirir.
Kubernetes ekibi kurmak ile dış kaynak kullanmak arasındaki temel fark
Temel fark teknoloji değil, operasyon sorumluluğunun kimde olduğudur.
Her iki modelde de aynı Kubernetes sürümleri, CI/CD araçları, Infrastructure as Code, gözlemlenebilirlik ve yedekleme yaklaşımı kullanılabilir.
Kendi ekip modelinde şu sorumlulukların sahibi sizsiniz:
- Kubernetes sürüm yaşam döngüsü
- Control plane ve worker node operasyonu
- Node işletim sistemi güncellemeleri
- RBAC ve erişim yönetimi
- Ağ politikaları
- Depolama
- Ingress veya Gateway yönetimi
- Sertifikalar
- Gözlemlenebilirlik
- Yedekleme ve geri dönüş
- Olay müdahalesi
- Kapasite planlama
Dış kaynak modelinde ise bu görevlerin sözleşmeyle tanımlanan bölümü yönetilen hizmet sağlayıcısına devredilir.
Uygulama kodu, ürün mimarisi ve iş kararları müşteride kalabilir.
Hızlı karar tablosu
| Durum | Daha uygun model | Neden |
|---|---|---|
| Kubernetes platformu ürünün stratejik parçası | Kendi ekip | Platform kararları ürün kararlarıyla birlikte alınır |
| 5-20 kişilik yazılım ekibi, ayrı platform ekibi yok | Dış kaynak veya hibrit | Sürekli operasyon için ayrı ekip kurma yükü azalır |
| Birden fazla ürün ekibi ortak iç platform kullanıyor | Kendi platform ekibi | Platform iç ürün haline gelir |
| Tek Kubernetes uzmanına bağımlılık var | Hibrit veya dış kaynak | Yedek sorumluluk ve farklı uzmanlıklar eklenir |
| 7/24 olay müdahalesi gerekiyor | Dış kaynak veya çok kişili iç ekip | Tek kişi gerçek nöbet sürekliliği sağlayamaz |
| Sık özel platform geliştirmesi gerekiyor | Kendi ekip | Şirkete özgü platform kararları içeride kalır |
| Küme kurulmuş ancak yükseltme ve bakım sahipsiz | Dış kaynak | Yaşam döngüsü sürekli operasyona bağlanır |
| Uygulama kodu içeride, altyapı operasyonu dışarıda kalsın | Hibrit | Sorumluluk katmanları ayrılır |
Kendi Kubernetes ekibi ne zaman daha anlamlıdır?
Kendi Kubernetes ekibi, platform yalnız altyapı değil şirket içinde geliştirilen bir ürün haline geldiğinde güçlüdür.
Bu durum genellikle şu koşullarda ortaya çıkar:
- Birden fazla ürün ekibi aynı platformu kullanıyor
- Geliştiriciler için self-service platform geliştiriliyor
- Şirkete özgü dağıtım standartları var
- Çok sayıda Kubernetes kümesi işletiliyor
- Ağ, güvenlik veya depolama ihtiyaçları standart hizmetlerin ötesine geçiyor
- Platform kararları müşteri deneyimini doğrudan etkiliyor
DORA platform mühendisliğinin temel amacını geliştiricilerin bilişsel yükünü azaltmak ve altyapı karmaşıklığını uygun soyutlamalarla gizlemek olarak ele alır.
Bu nedenle kendi ekip kurmak yalnız bir Kubernetes mühendisi işe almak anlamına gelmemelidir.
İyi bir iç platform ekibi:
- geliştiricilerin ihtiyaçlarını toplar
- ortak deployment yolu geliştirir
- otomasyonu ürün gibi yönetir
- platform kullanımını ölçer
- gereksiz Kubernetes ayrıntılarını uygulama ekiplerinden gizler
Platform şirket içinde bu seviyede değer üretiyorsa operasyon bilgisinin içeride kalması önemlidir.
Kendi ekip modelinin avantajları
Ürün bağlamı içeride kalır
İç ekip, uygulama mimarisi ile platform kararlarını aynı bağlamda değerlendirir.
Yeni bir servis oluşturulduğunda yalnız Kubernetes kaynağını değil, ürünün neden böyle tasarlandığını da bilir.
Platform geliştirme daha hızlı olabilir
Şirkete özgü ihtiyaçlar için:
- iç geliştirici portalı
- deployment şablonları
- standart Helm chart'ları
- politika otomasyonu
- özel gözlemlenebilirlik standardı
gibi çalışmalar dış hizmet kapsamı beklenmeden geliştirilebilir.
Uzun vadeli platform bilgisi kurumda kalır
Küme mimarisi, teknik borç ve geçmiş kararlar doğrudan iç ekibin bilgisinde kalır.
Bu özellikle Kubernetes altyapısı şirketin rekabet avantajının bir parçasıysa değerlidir.
Kendi ekip modelinin maliyetleri
Kendi Kubernetes ekibinin maliyeti yalnız çalışan maaşı değildir.
Toplam maliyet içinde şunları değerlendirin:
- işe alım
- işe alışma süreci
- deneyimli mühendis ihtiyacı
- yedek personel
- nöbet düzeni
- eğitim
- sertifikasyon
- gözlemlenebilirlik araçları
- güvenlik araçları
- platform geliştirme zamanı
- olay ve bakım zamanı
Bir kişinin bütün Kubernetes operasyonunu üstlenmesi düşük maliyetli görünebilir, ancak tek kişiye bağımlılık yaratır.
İzin, hastalık veya işten ayrılma durumunda küme bilgisi ve production sorumluluğu tek noktada kalabilir.
7/24 Kubernetes operasyonu tek kişilik rol değildir
Production Kubernetes ortamı sürekli sahiplik gerektirir.
Gece yaşanan bir olayda şu sorunlardan biri ortaya çıkabilir:
- node erişilemez
- depolama bağlantısı bozulur
- sertifika sona erer
- DNS problemi oluşur
- ingress trafiği kesilir
- kaynak tüketimi kümenin kapasitesini aşar
- yeni deployment sürekli yeniden başlar
Tek Kubernetes mühendisi bu operasyonu haftanın her saati sürdürülebilir biçimde taşıyamaz.
İç ekip modelinde gerçek 7/24 kapsam gerekiyorsa nöbet, ikinci seviye destek ve yedek sahipler planlanmalıdır.
Kubernetes sürüm yaşam döngüsü sürekli iş yaratır
Kubernetes kurulumu bir defalık proje değildir.
Kubernetes topluluğu aktif patch serilerini yaklaşık 14 ay boyunca destekler. 21 Eylül 2026 itibarıyla aktif minor sürüm dalları 1.37, 1.36 ve 1.35'tir.
Bu durum şu operasyonları sürekli hale getirir:
- sürüm takibi
- compatibility testi
- node güncellemesi
- eklenti kontrolü
- API değişikliği kontrolü
- yükseltme planı
- geri dönüş planı
Sürüm sahipliği olmayan Kubernetes ortamı zamanla destek dışı sürüme düşebilir.
Dış kaynak Kubernetes operasyonu ne zaman daha uygundur?
Dış kaynak model, Kubernetes gerekli olduğu halde ayrı bir platform ekibi kurmanın iş açısından anlamlı olmadığı şirketlerde daha uygundur.
Özellikle şu durumlarda değerlendirilebilir:
- teknik ekip ürün geliştirmeye odaklanmak istiyor
- yalnız birkaç Kubernetes kümesi var
- ayrı DevOps/SRE ekibi yok
- cluster yükseltmeleri gecikiyor
- olay müdahalesi tek kişiye bağlı
- yedekleme ve geri dönüş düzenli test edilmiyor
- farklı uzmanlıklara dönemsel ihtiyaç duyuluyor
Bu modelde amaç altyapıyı tamamen şirket dışına bırakmak değildir.
Doğru yapı, uygulama ve ürün sahipliğini içeride tutarken tekrar eden production operasyonunu tanımlı bir hizmet kapsamına bağlamaktır.
Yönetilen Kubernetes ile yönetilen Kubernetes operasyonu aynı değildir
Yönetilen Kubernetes hizmeti ile Kubernetes operasyon hizmeti farklı kapsamları çözebilir.
Yönetilen Kubernetes sağlayıcısı çoğu zaman control plane'in:
- erişilebilirliği
- ölçeklenmesi
- patch işlemleri
- bazı yükseltmeleri
gibi alanlarını yönetir.
Ancak müşteride kalan işler devam eder:
- worker node boyutlandırma
- uygulama deployment'ları
- resource request ve limit'leri
- RBAC
- ağ politikaları
- gözlemlenebilirlik
- yedekleme
- stateful iş yükleri
- kapasite
- maliyet
- olay müdahalesi
Kubernetes'in resmi production rehberi de üretim ortamını planlarken hangi yönetim sorumluluklarını kendiniz üstleneceğinizi ve hangilerini dışarı devredeceğinizi değerlendirmenizi önerir.
Bu nedenle “managed Kubernetes kullanıyoruz, operasyon ihtiyacımız yok” yaklaşımı eksiktir.
Dış kaynak modelinin avantajları
Farklı uzmanlıklara tek ekipten erişim
Production Kubernetes yalnız Kubernetes bilgisi istemez.
Zaman zaman şu alanlarda derin bilgi gerekir:
- Linux
- ağ
- depolama
- DNS
- TLS
- CI/CD
- gözlemlenebilirlik
- yedekleme
- güvenlik
Yönetilen hizmet modeli bu uzmanlıkları tek kişide toplamaya çalışmak yerine ekip üzerinden sağlayabilir.
Nöbet yükü ürün ekibinden ayrılabilir
Ürün geliştiricileri production olaylarını anlamalıdır, ancak cluster node bakımı veya certificate yenileme gibi işler her zaman ürün ekibinin ana işi olmak zorunda değildir.
Yaşam döngüsü sahipliği netleşir
Yükseltme, güvenlik yaması ve bakım işleri takvime bağlanabilir.
Dokümantasyon zorunlu hale getirilebilir
Runbook, erişim matrisi ve envanter hizmet kapsamının teslim kalemleri olarak tanımlanabilir.
Dış kaynak modelinin riskleri
Sağlayıcı bağımlılığı
Kubernetes kaynakları, altyapı kodu ve dokümantasyon yalnız sağlayıcıda kalırsa geçiş maliyeti yükselir.
Bu riski azaltmak için:
- bulut hesabı müşterinin olmalı
- Terraform/OpenTofu kodu müşterinin deposunda olmalı
- Kubernetes manifest'leri müşterinin deposunda olmalı
- DNS ve sertifika sahipliği görünür olmalı
- runbook müşteriye açık olmalı
Ürün bağlamı daha sınırlıdır
Harici ekip uygulamanın iş mantığını ürün ekibi kadar iyi bilmeyebilir.
Bu nedenle application owner müşteri tarafında kalmalıdır.
Yanlış hizmet kapsamı boşluk yaratabilir
Sözleşmede “Kubernetes yönetimi” yazması yeterli değildir.
Şunlar ayrı ayrı belirtilmelidir:
- yükseltme
- node işletim sistemi
- yedekleme
- geri dönüş testi
- gözlemlenebilirlik
- alarm müdahalesi
- olay yönetimi
- kapasite planlama
- ağ
- güvenlik
- çalışma saatleri
Üç yıllık toplam maliyet nasıl karşılaştırılmalı?
Kendi ekip ile dış kaynak modeli aynı sorumluluk kapsamı üzerinden karşılaştırılmalıdır.
Kendi ekip tarafı
- tam yüklü personel maliyeti
- yedek personel
- nöbet
- işe alım
- işe alışma
- eğitim
- operasyon araçları
- platform geliştirme zamanı
Dış kaynak tarafı
- yönetilen hizmet bedeli
- kapsam dışı proje işleri
- içeride kalacak teknik ürün sahibinin zamanı
- üçüncü taraf araç ve lisanslar
- ek çalışma veya özel SLA maliyeti
İki modelde ortak maliyetler
- Kubernetes node'ları
- depolama
- network
- gözlemlenebilirlik altyapısı
- yedekleme
- registry
- bulut servisleri
Bu ortak altyapı kalemlerini yalnız bir modele yazmak karşılaştırmayı bozar.
Hibrit model çoğu yazılım şirketi için güçlü seçenektir
Hibrit modelde mimari ve ürün bağlamı içeride kalırken tekrar eden Kubernetes operasyonu dışarı paylaşılır.
Örnek sorumluluk dağılımı:
İç ekip
- uygulama mimarisi
- deployment içeriği
- ürün öncelikleri
- uygulama hataları
- release onayı
Yönetilen hizmet ekibi
- cluster yaşam döngüsü
- node operasyonu
- gözlemlenebilirlik altyapısı
- yedekleme
- kapasite
- Kubernetes olayları
- sertifika ve platform bakımı
Bu model özellikle 5-20 kişilik yazılım ekiplerinde ayrı bir platform departmanı kurmadan production sahipliğini netleştirebilir.
Sorumluluk matrisi olmadan dış kaynak kullanmayın
Kubernetes hizmeti başlamadan önce en az şu tablo yazılı olmalıdır.
| Alan | Müşteri | Hizmet sağlayıcı |
|---|---|---|
| Uygulama kodu | Sahip | Değiştirmez |
| Kubernetes kümesi | Görünürlük/sahiplik | Operasyon |
| Yükseltme | Onay | Planlama ve uygulama |
| Gözlemlenebilirlik | Uygulama sinyalleri | Platform katmanı |
| Yedekleme | RPO/RTO onayı | Operasyon ve test |
| Olay müdahalesi | Uygulama escalation | Platform ilk müdahale |
| Kapasite | İş beklentisi | Teknik plan |
| Erişim | Politika sahibi | Sınırlı rol bazlı erişim |
Bu tablo her şirket için aynı olmayabilir.
Önemli olan gri alan bırakmamaktır.
Sağlayıcı değişikliği yeni bir Kubernetes göçüne dönüşmemeli
Dış kaynak modelinin en önemli tasarım ilkelerinden biri çıkış planıdır.
Geçiş için şu varlıklar müşterinin kontrolünde tutulmalıdır:
- bulut hesabı
- Kubernetes erişimleri
- altyapı kodu
- manifest ve Helm kaynakları
- CI/CD tanımları
- DNS
- sertifikalar
- yedekleme yapılandırmaları
- operasyon belgeleri
Dynamis yönetilen altyapı çalışmalarında mümkün olduğunda müşterinin kendi hesapları ve depoları üzerinde çalışır.
Amaç sağlayıcı değiştiğinde yeniden altyapı kurmak değil, sorumluluğu devretmektir.
Hangi model sizin için uygun?
Kendi ekip daha uygunsa
Şunların çoğu doğruysa iç platform ekibi düşünün:
- platform şirket için stratejik
- çok sayıda ürün ekibi var
- şirket içi platform sürekli geliştiriliyor
- özel Kubernetes ihtiyaçları yoğun
- yeterli mühendislik bütçesi var
- nöbet ve yedek sorumluluk içeride kurulabiliyor
Dış kaynak daha uygunsa
Şunların çoğu doğruysa yönetilen hizmet değerlendirin:
- küçük teknik ekip
- Kubernetes gerekli ancak platform ana ürün değil
- 7/24 sahiplik eksik
- tek Kubernetes uzmanına bağımlılık var
- yükseltmeler gecikiyor
- ekip ürün geliştirmeye odaklanmak istiyor
Hibrit model daha uygunsa
Şunlar doğruysa hibrit model güçlüdür:
- mimari bilgiyi içeride tutmak istiyorsunuz
- fakat operasyon nöbetini büyütmek istemiyorsunuz
- içeride DevOps bilgisi var ancak kapasite yetersiz
- platform zamanla iç ekibe devredilebilir
Dynamis'te Kubernetes operasyon modeli
Dynamis'in DevOps hizmeti kapsamında ilk adım müşteriye otomatik olarak Kubernetes operasyonu satmak değildir.
Önce:
- mevcut küme sayısı
- Kubernetes sürümleri
- node yapısı
- iş yükü sayısı
- stateful servisler
- yükseltme durumu
- gözlemlenebilirlik
- yedekleme
- olay geçmişi
- mevcut ekip kapasitesi
çıkarılır.
Ardından kendi ekip, yönetilen hizmet veya hibrit model için sorumluluk matrisi oluşturulur.
Kubernetes'in gereksiz olduğu bir ortamda ise daha basit platform seçeneği önerilebilir.
Küçük ekip için Kubernetes rehberi bu teknoloji kararını ayrıca ele alır.
Sık yapılan hatalar
Tek Kubernetes uzmanını platform ekibi sanmak: Yedek sorumluluk ve nöbet olmadan tek kişi riski devam eder.
Managed Kubernetes'i tam operasyon hizmeti sanmak: Control plane'in yönetilmesi uygulama ve cluster operasyonunun tamamını kapsamaz.
Maaş ile aylık hizmet bedelini doğrudan karşılaştırmak: Aynı sorumluluk kapsamını üç yıllık toplam maliyetle karşılaştırın.
Altyapı kodunu sağlayıcıda bırakmak: Terraform/OpenTofu ve Kubernetes kaynakları müşterinin kontrolündeki depolarda tutulmalıdır.
Çıkış planını sözleşme sonunda düşünmek: Devir kriterleri hizmet başlarken tanımlanmalıdır.
Sırada ne var
- Küçük ekip için Kubernetes: ne zaman fazla gelir?: Kubernetes'in ekibiniz için gerçekten gerekli olup olmadığını değerlendirin.
- Kubernetes production ortamında en sık yaşanan operasyon sorunları: dış kaynak veya iç ekip kararında gerçek production incident yükünü ve troubleshooting kapsamını görün.
- Kubernetes'e geçiş rehberi: production geçişinin hangi operasyonları sürekli hale getirdiğini görün.
- Kubernetes vs Docker: daha basit konteyner modeliyle Kubernetes arasındaki operasyon farklarını karşılaştırın.
- DevOps hizmeti: mevcut Kubernetes operasyon modelinizi değerlendirin.
Kaynaklar
Kaynaklar
- 1.Production environmentKubernetes · 2026-09-21
- 2.Patch releases and support periodKubernetes · 2026-09-21
- 3.Kubernetes releasesKubernetes · 2026-09-21
- 4.Platform engineering capabilityDORA · 2026-09-21
Sık sorulan sorular
Kubernetes operasyonunu dış kaynak kullanmak ne anlama gelir?
Kubernetes operasyonunu dış kaynak kullanmak; cluster yükseltme, node bakımı, izleme, olay müdahalesi, kapasite, yedekleme ve runbook gibi tanımlı operasyon sorumluluklarını dış bir ekiple paylaşmak veya devretmektir. Uygulama kodu ve ürün kararları müşterinin ekibinde kalabilir.
Kubernetes için kendi ekip ne zaman daha uygundur?
Kubernetes platformu ürünün rekabet avantajının parçasıysa, birden fazla ürün ekibi ortak bir iç platform kullanıyorsa ve platform mühendisliği sürekli ürün kararı gerektiriyorsa kendi platform ekibi daha uygundur. 7/24 operasyon ve yedek sorumluluk da içeride kurulmalıdır.
Managed Kubernetes ile yönetilen Kubernetes operasyonu aynı şey mi?
Hayır. Managed Kubernetes çoğunlukla control plane gibi platform katmanının bir bölümünü sağlayıcıya devreder. Yönetilen Kubernetes operasyonu ise workload, node, yükseltme, gözlemlenebilirlik, yedekleme, kapasite ve olay müdahalesi gibi daha geniş operasyon sorumluluklarını kapsayabilir.
Kubernetes dış kaynak modelinde altyapı kimin hesabında olmalı?
Sağlayıcı bağımlılığını azaltmak için bulut hesabı, cluster kaynakları, DNS, sertifikalar, altyapı kodu ve operasyon dokümantasyonunun mümkün olduğunca müşterinin sahipliğinde kalması tercih edilir. Erişimler rol bazlı ve geri alınabilir olmalıdır.
Kubernetes ekibi ile dış kaynak modelini nasıl karşılaştırmalıyım?
Aynı sorumluluk kapsamını karşılaştırın: nöbet, cluster ve node yükseltmeleri, gözlemlenebilirlik, yedekleme, olay müdahalesi, güvenlik, kapasite, dokümantasyon ve devir. Yalnız maaş ile aylık hizmet bedelini karşılaştırmak gerçek toplam maliyeti göstermez.