- 0114 günlük plan tek ve görece basit uygulama için pilot çerçevesidir; karmaşık bağımlılıklarda migration wave'lere ayrılmalıdır.
- 02Ingress-NGINX 24 Mart 2026'da emekli edildi; yeni cluster'larda Gateway API veya aktif olarak desteklenen başka bir ingress controller değerlendirilmelidir.
- 03Kubernetes 1.37.0, 26 Ağustos 2026'da yayımlandı ve upstream patch serileri yaklaşık 14 ay desteklenir; yükseltme takvimi migration projesinin parçasıdır.
- 04Stateful iş yüklerinin cluster içinde veya dışında çalışması ayrı bir mimari karardır; ilk migration wave'inde mevcut veritabanını korumak riski azaltabilir.
- 05GitOps Kubernetes'in zorunlu şartı değildir; hedef izlenebilir, deklaratif, tekrar üretilebilir ve geri alınabilir bir delivery akışıdır.
Kısaca
Kubernetes'e geçiş, konteyner çalıştırmaktan daha büyük bir karardır: uygulama yaşam döngüsünü, ağ girişini, gözlemlenebilirliği, gizli anahtar yönetimini ve yükseltme sorumluluğunu birlikte değiştirir. Basit tek uygulama için 14 günlük bir pilot plan mümkün olabilir; ancak süreyi uygulama sayısı, stateful bağımlılıklar ve ekip hazırlığı belirler. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak Kubernetes geçişini araç seçimi değil, işletim modeli değişikliği olarak ele alır.
Kubernetes'e geçmek için önce problemi tanımlayın
Kubernetes; konteyner iş yüklerini dağıtmak, ölçeklemek, servis keşfi ve yeniden planlama gibi operasyonları standartlaştırmak için kullanılan taşınabilir ve genişletilebilir bir platformdur. Ancak her uygulama bu karmaşıklığa ihtiyaç duymaz.
Şu sinyaller Kubernetes'i değerlendirmeyi anlamlı hale getirir:
- Birden fazla servis aynı dağıtım ve ağ standardını paylaşacaksa
- Sık ve tekrarlanabilir dağıtım ihtiyacı varsa
- Yatay ölçekleme veya yüksek erişilebilirlik önemliyse
- Ortamlar arasında taşınabilirlik ve deklaratif konfigürasyon isteniyorsa
- Birden fazla ürün ekibi ortak bir platform standardına ihtiyaç duyuyorsa
- Mevcut sanal sunucu düzeninde yapılandırma farkları ve elle müdahale operasyon yükü oluşturuyorsa
Buna karşılık tek uygulama, düşük dağıtım sıklığı ve sabit kapasite ihtiyacı olan küçük bir ekipte iyi otomatikleştirilmiş sanal sunucu veya daha basit bir platform daha düşük operasyon maliyeti yaratabilir.
Kubernetes'e geçiş kararını trafik artışı gibi tek bir sinyale bağlamayın. Platformun getireceği yükseltme, ağ, güvenlik ve gözlemlenebilirlik sorumluluğunun da ekibiniz veya hizmet sağlayıcınız tarafından karşılanması gerekir.
14 günlük plan bir garanti değil, pilot çerçevesidir
Bu sayfadaki 14 günlük plan, tek ve görece basit bir uygulama için çalışma çerçevesidir. Birden fazla servis, yoğun veri katmanı, karmaşık ağ politikaları veya regülasyon gereksinimleri varsa süre uzar ve geçiş wave'lere ayrılmalıdır.
| Aşama | Örnek süre | Çıktı | Bitti sayılması için |
|---|---|---|---|
| Uygulama hazırlığı | Gün 1-4 | Konteyner imajı, health check, temel kaynak tanımları | Uygulama test cluster'ında çalışıyor |
| Cluster ve platform | Gün 5-9 | Ağ, depolama, secrets, giriş katmanı, RBAC | Test ortamı uçtan uca erişilebilir |
| Delivery ve cutover | Gün 10-14 | CI/CD veya GitOps, gözlemlenebilirlik, rollback planı | Ölçümler kabul kriterlerinde, trafik yeni ortamda |
Bu takvimi proje sözü olarak değil, hazır oluş kontrol listesi olarak kullanın.
Gün 1-4: uygulamayı konteyner ortamına hazırlayın
İlk aşama Dockerfile yazmakla bitmez. Uygulamanın Kubernetes varsayımlarına uyup uymadığını doğrulayın.
Kontrol edin:
- Uygulama yerel diske kalıcı veri yazıyor mu?
- Başlangıç ve kapanış davranışı düzgün mü?
- Readiness ve liveness kontrolleri tanımlanabilir mi?
- Konfigürasyon ortamdan ayrılmış mı?
- Secret'lar imaja veya Git deposuna gömülü mü?
- Uygulama tek bir sabit IP veya hostname'e bağlı mı?
- Loglar stdout/stderr veya merkezi sisteme aktarılabiliyor mu?
İlk hedef yüksek erişilebilir üretim değil, aynı imajın tekrar üretilebilir şekilde test cluster'ında çalışmasıdır.
Gün 5-9: cluster'dan çok platform katmanını kurun
Cluster kurulumu genellikle işin kolay kısmıdır. Üretime hazır platform için aşağıdaki katmanların birlikte çalışması gerekir:
- Ağ ve servis keşfi
- Giriş veya Gateway katmanı
- TLS ve sertifika yönetimi
- RBAC ve kimlik erişimi
- Secret yönetimi
- Kalıcı depolama
- Gözlemlenebilirlik
- Yedekleme ve geri dönüş
- Sürüm ve yükseltme takvimi
Kubernetes 1.19 ve sonrası sürümlerde upstream patch desteği yaklaşık 14 aydır. 19 Eylül 2026 itibarıyla en güncel minor sürüm 1.37.0, 26 Ağustos 2026'da yayımlandı. Upstream proje aynı anda son üç minor dalı aktif olarak destekliyor; bu nedenle cluster kurarken yalnızca bugünkü sürümü değil, yükseltme sürecini de tasarlayın.
Dynamis'te cluster açılışında sürüm ve EOL takvimini ayrı operasyon kalemi olarak tanımlıyoruz.
Ingress-NGINX emekli oldu; yeni kurulumda bunu görmezden gelmeyin
Kubernetes topluluğunun yönettiği Ingress-NGINX projesi 24 Mart 2026'da emekli edildi. Bu tarihten sonra yeni sürüm, hata düzeltmesi veya güvenlik güncellemesi yayımlanmıyor. Mevcut kurulumlar çalışmaya devam edebilir ancak yeni güvenlik açıkları upstream proje tarafından giderilmeyecek.
Yeni cluster kuruyorsanız Gateway API'yi veya aktif olarak bakımı yapılan başka bir ingress controller'ı değerlendirin. Gateway API'de Gateway kaynağı Standard Channel'da ve GA durumunda; API, altyapı sahibi ile uygulama ekibinin sorumluluklarını daha net ayıran bir model sunuyor.
Ingress-NGINX kullanan mevcut ortamı tek seferde çevirmeyin. Annotation, rewrite, regex, timeout ve özel davranışları envanterleyin; Kubernetes projesinin ingress2gateway aracı geçişte başlangıç noktası olabilir.
Stateful iş yükleri için tek doğru yer yoktur
"Veritabanı Kubernetes dışında kalmalıdır" evrensel bir kural değildir. StatefulSet, PersistentVolume, CSI ekosistemi ve veritabanı operatörleri sayesinde stateful iş yükleri Kubernetes üzerinde çalıştırılabilir.
Ancak ilk migration wave'inde veritabanını mevcut yönetilen servis veya sanal sunucu üzerinde bırakmak kapsamı azaltabilir. Bu özellikle şu durumlarda mantıklıdır:
- Mevcut veritabanı HA ve yedekleme düzeni zaten çalışıyorsa
- Ekip Kubernetes üzerinde stateful operasyon deneyimine sahip değilse
- Uygulama katmanını taşımak tek başına yeterli fayda sağlıyorsa
- Veritabanı taşıması ayrı kesinti ve veri doğrulama planı gerektiriyorsa
Stateful iş yükünü cluster içine almak istiyorsanız depolama performansı, volume snapshot/backup, pod disruption, node failure ve database-level recovery ayrı olarak test edilmelidir.
Gözlemlenebilirlik cutover öncesinde hazır olmalıdır
Yeni ortamın daha iyi çalıştığını ölçmeden trafik taşımayın. Metrik, log ve trace araçlarının isimleri değişebilir; ihtiyaç değişmez.
Cutover panelinde en az şu ölçümler bulunmalı:
- İstek hata oranı
- p50/p95/p99 gecikme
- Pod restart ve readiness hataları
- CPU ve bellek doygunluğu
- Node ve volume durumu
- Veritabanı bağlantı hataları
- Uygulamanın kendi iş metriği, örneğin başarılı sipariş veya job sayısı
Prometheus, Grafana ve Loki kullanılabilir seçeneklerdir; bunlar Kubernetes'in zorunlu bileşenleri değildir. Mevcut gözlemlenebilirlik sisteminiz aynı sinyalleri güvenilir biçimde topluyorsa onu koruyabilirsiniz.
CI/CD ve GitOps aynı şey değildir
CI/CD hattı imajı oluşturabilir, test edebilir ve deployment tetikleyebilir. GitOps ise cluster'ın istenen durumunu Git'te tanımlayıp bir denetleyicinin bu duruma yakınsamasını sağlar.
Argo CD kendisini Kubernetes için deklaratif bir GitOps continuous delivery aracı olarak tanımlar ve Git deposunu uygulama durumunun kaynağı olarak kullanır.
GitOps güçlü bir modeldir ama Kubernetes kullanmanın zorunlu şartı değildir. Küçük ekiplerde iyi tanımlanmış CI/CD ve kontrollü deployment prosedürü de yeterli olabilir. GitOps özellikle aşağıdaki durumlarda daha fazla değer üretir:
- Birden fazla cluster veya ortam varsa
- Değişiklik onayı ve audit trail gerekiyorsa
- Drift tespiti önemliyse
- Platform ve uygulama konfigürasyonu birlikte yönetiliyorsa
Dynamis'te yeni üretim cluster'larında tercihimiz deklaratif ve Git tabanlı durum yönetimidir; ancak araç seçimini mevcut delivery akışına göre yapıyoruz.
Gün 10-14: cutover ve rollback birlikte tasarlanır
Trafik taşıma modeli uygulamanın mimarisine göre değişir. Canary, blue/green veya kademeli ağırlıklandırma kullanılabilir. Her ortamın %10, %25, %50 şeklinde aynı basamaklarla ilerlemesi gerekmez.
Cutover başlamadan önce şu koşulları yazın:
- Hangi metrikler kabul kriteridir?
- Hangi eşikte rollback yapılır?
- DNS veya load balancer değişikliği ne kadar sürede geri alınabilir?
- Veri yazma noktası hangi anda değişir?
- Eski ortam ne kadar süre rollback için tutulacak?
- Eski ortam kapatılırken hangi kaynaklar ve secret'lar temizlenecek?
Eski ortamı sabit "iki hafta" açık tutmak yerine risk, veri tutarlılığı ve gözlem süresine göre kapanış kriteri belirleyin.
Küçük ekip için karar çerçevesi
| Durum | Yaklaşım |
|---|---|
| Tek uygulama, az değişiklik, sabit kapasite | Önce daha basit platform veya sanal sunucu |
| Birden fazla servis ve sık deployment | Kubernetes güçlü aday |
| Yüksek erişilebilirlik ve otomatik yeniden planlama gerekiyor | Kubernetes değerlendirin |
| Ortak platform birden fazla ürün ekibi tarafından kullanılacak | Kubernetes + platform yaklaşımı anlamlı |
| Ekip cluster işletimi için zaman ayıramıyor | Yönetilen Kubernetes veya yönetilen DevOps |
| Yoğun stateful iş yükleri var, ekip deneyimsiz | Uygulama katmanını önce taşıyın veya managed data service kullanın |
| Ingress-NGINX kullanılıyor | Gateway API veya aktif controller'a migration planı başlatın |
Kubernetes'i kullanmak ile Kubernetes'i kendiniz işletmek iki ayrı karardır. Küçük ekip için platformun faydası yüksek, control plane ve node operasyonunun maliyeti de yüksek olabilir; bu durumda yönetilen model denge sağlar.
Dynamis'te Kubernetes geçişi
Dynamis'in DevOps hizmeti, uygulama hazırlığından cluster işletimine kadar geçişi müşterinin mevcut mimarisine göre yürütür. Hedef, her müşteriye aynı 14 günlük şablonu zorlamak değil; bağımlılık ve riskleri çıkarıp pilot wave'i ölçülebilir hale getirmektir.
Raff üzerinde yönetilen Kubernetes kullanıldığında control plane, cluster yaşam döngüsü ve platform tarafındaki operasyonlar hizmet kapsamına göre yönetilir; uygulama manifestleri ve delivery akışı müşteri ekibiyle birlikte tasarlanır.
Kubernetes sürümleri yaklaşık 14 aylık upstream patch destek döngüsüne sahiptir; örneğin Kubernetes 1.37'nin upstream EOL tarihi 28 Ekim 2027 olarak listeleniyor. Bu nedenle migration projesi, ilk yükseltme tarihini belirlemeden tamamlanmış sayılmamalıdır.
Sık yapılan hatalar
Kubernetes'i yalnızca autoscaling için seçmek: Trafik değişkenliği tek başına platform değişimini haklı çıkarmayabilir. Operasyon ve delivery ihtiyacını birlikte değerlendirin.
14 günü proje garantisi sanmak: İki hafta basit pilot için örnek takvimdir; bağımlılık arttıkça wave planı gerekir.
Ingress-NGINX ile yeni cluster kurmak: Proje 24 Mart 2026'da emekli edildi. Yeni kurulumda desteklenen alternatifleri değerlendirin.
Veritabanını otomatik olarak cluster içine veya dışına koymak: Stateful tasarım ayrı bir karar ve operasyon modelidir.
Gözlemlenebilirliği cutover sonrasına bırakmak: Yeni ortamın eski ortamla karşılaştırılmasını imkânsız hale getirir.
GitOps'u araç dini haline getirmek: GitOps faydalıdır ama asıl hedef izlenebilir, tekrar üretilebilir ve geri alınabilir delivery akışıdır.
Yükseltme takvimi olmadan üretime çıkmak: Upstream destek süresi sonludur; aktif minor sürüm ve EOL tarihi operasyon planında bulunmalıdır.
Sırada ne var
- Küçük ekip için Kubernetes: ne zaman fazla gelir?: migration başlamadan önce Kubernetes'in gerçekten gerekli olup olmadığını doğrulayın.
- Kubernetes production ortamında en sık yaşanan operasyon sorunları: migration sonrası oluşabilecek pod, node, DNS, storage ve upgrade problemleri için operasyon baseline'ını hazırlayın.
- Kubernetes ekibi kurmak mı, operasyonu dış kaynak kullanmak mı?: production geçişinden önce yükseltme, nöbet ve cluster operasyonunun kimde kalacağını netleştirin.
- Kubernetes vs Docker: hangisi ne zaman kullanılmalı?: migration kararı öncesinde mevcut Docker/Compose modelinin sınırlarını Kubernetes ihtiyaçlarıyla karşılaştırın.
- Kubernetes nedir? Ne işe yarar ve ne zaman kullanılmalı?: migration adımlarına geçmeden önce cluster, pod, Service ve control plane kavramlarını netleştirin.
- CI/CD nedir? Yazılım deployment süreci nasıl otomatikleştirilir?: Kubernetes'e geçmeden önce build, test, artifact ve deployment pipeline'ını standardize edin.
- DevOps nedir? Yazılım ekipleri için nasıl çalışır?: Kubernetes migration'ını CI/CD, observability ve ortak production ownership modeli içine yerleştirin.
- Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi: cluster işletiminin kimde kalacağını belirleyin.
- AWS alternatifi: hangi iş yükü nerede kalmalı?: EKS veya diğer AWS workload'larını taşımadan önce workload placement kararını verin.
- AWS'den çıkış: maliyeti düşüren bulut göçü: hedef platforma geçişi dependency-based wave planıyla tasarlayın.
- 3-2-1 yedekleme kuralı: stateful iş yükü ve cluster yedeklerini gerçek geri dönüş testine bağlayın.
- DevOps hizmeti: Kubernetes geçişi ve işletimini yönetilen hizmet olarak planlayın.
Kaynaklar
Kaynaklar
- 1.Kubernetes ReleasesThe Kubernetes Authors · 2026-09-19
- 2.Kubernetes Patch Releases and support periodThe Kubernetes Authors · 2026-09-19
- 3.Ingress NGINX Retirement: What You Need to KnowThe Kubernetes Authors · 2026-09-19
- 4.Kubernetes v1.36 release - Ingress NGINX retirementThe Kubernetes Authors · 2026-09-19
- 5.Kubernetes Gateway APIKubernetes SIG Network · 2026-09-19
- 6.Ingress2Gateway 1.0The Kubernetes Authors · 2026-09-19
- 7.Argo CD DocumentationArgo Project · 2026-09-19
Sık sorulan sorular
Küçük ekibe Kubernetes fazla mı gelir?
Geçebilir. Ekip küçükse ama birden fazla servis, sık dağıtım, yüksek erişilebilirlik veya standartlaştırılmış platform ihtiyacı varsa Kubernetes anlamlı olabilir. Cluster işletimi için yeterli zaman veya uzmanlık yoksa yönetilen hizmet ya da daha basit bir platform daha uygun olabilir.
Heroku'dan Kubernetes'e geçiş ne kadar sürer?
Süre uygulama sayısı, stateful bağımlılıklar, ağ, güvenlik ve CI/CD hazırlığına göre değişir. Basit tek uygulama için iki haftalık bir pilot plan kullanılabilir; daha karmaşık sistemlerde geçiş wave'ler halinde planlanmalıdır.
Kubernetes'e ne zaman geçilmeli?
Konteyner iş yüklerinde birden fazla servis, sık dağıtım, yüksek erişilebilirlik, yatay ölçeklenme veya ortak platform standardı gibi ihtiyaçlar varsa Kubernetes değerlendirilir. Tek uygulamalı ve düşük değişim hızındaki ekiplerde daha basit altyapı yeterli olabilir.
Kubernetes'e geçişte veritabanı ne olur?
Veritabanı cluster içinde veya dışında çalışabilir. İlk göçte yönetilen ya da mevcut dış veritabanını korumak risk ve kapsamı azaltabilir; ancak uygun operatör, depolama ve kurtarma modeli varsa stateful iş yükleri Kubernetes üzerinde de çalıştırılabilir.
GitOps nedir ve neden kullanılır?
GitOps, istenen uygulama ve altyapı durumunu Git'te tanımlayıp bir denetleyiciyle cluster'a uygulayan çalışma modelidir. Argo CD gibi araçlar değişiklikleri izlenebilir ve tekrar üretilebilir hale getirir; ancak GitOps Kubernetes kullanmanın zorunlu şartı değildir.