Kubernetes'e Geçiş: 14 Günde Üretime Hazır Cluster

Heroku veya elle yönetilen sunuculardan Kubernetes'e geçiş, çoğu yazılım ekibinin er ya da geç verdiği bir karardır. Bu rehber, kararın ne zaman doğru olduğunu, 14 günlük gerçekçi bir geçiş planını ve sürecin en sık tökezlediği noktaları anlatır.

Kubernetes neden, ne zaman

Kubernetes bir hedef değil, bir araçtır. Yatay ölçeklenme, dayanıklılık ve tekrarlanabilir dağıtım gerçek bir ihtiyaçsa doğru araçtır. Sadece sektör gündeminde olduğu için geçilmez; aksi halde size çözdüğünden fazla operasyonel yük getirir.

Doğru soru "Kubernetes'e geçmeli miyiz" değil, "hangi somut sorunu çözüyoruz" sorusudur. Karar verirken üç ölçüte bakın:

• Trafik profili: Yük değişkense veya hızlı büyüyorsa yatay ölçeklenme kazandırır.
• Dağıtım sıklığı: Günde birden fazla deploy yapıyorsanız manuel süreç sürdürülemez.
• Dayanıklılık beklentisi: Tek sunucu çökünce hizmet duruyorsa, kendini iyileştiren bir platform gerekir.

14 günlük geçiş planı

Takvim sıkı ama gerçekçidir, çünkü her adım bir öncekinin üzerine kurulur. Atlanan bir adım sonraki haftaya borç olarak biner. Planı üç aşamaya bölüyoruz:

Gün 1-4: Paketleme ve imajlar

Mevcut uygulama container'a alınır, imajlar oluşturulur ve temel Kubernetes manifestleri yazılır. Bu aşamada hedef üretim değil, uygulamanın cluster içinde sağlıklı ayağa kalktığını doğrulamaktır.

Gün 5-9: Cluster ve altyapı

Cluster kurulur; ağ, kalıcı depolama ve gizli anahtar yönetimi devreye alınır. Bu aşama görünmez ama kritiktir: yanlış kurulan ağ veya depolama, sonraki her adımı yavaşlatır ve geri dönüşü pahalılaştırır.

Gün 10-14: CI/CD, gözlemlenebilirlik ve kesim

CI/CD bağlanır, gözlemlenebilirlik entegre edilir ve trafik aşamalı olarak yeni ortama taşınır. Eski ortam, kesim tamamlanana kadar ayakta tutulur; böylece sorun çıkarsa geri dönüş anlık olur.

Gözlemlenebilirlik önce gelir

Cluster'ı ölçeklemeden önce göremediğiniz şeyi yönetemezsiniz. Üretim Kubernetes'i, gözlemlenebilirlik katmanı olmadan kör uçuştur. Standart yığınımız üç parçadan oluşur:

• Prometheus: Metrik toplama ve alarm.
• Loki: Merkezî log toplama ve sorgulama.
• Grafana: Tek panelde görselleştirme ve dashboard.

CI/CD ve GitOps

Manuel kubectl komutu üretimde sürdürülemez. Her değişikliğin izlenebilir, gözden geçirilebilir ve geri alınabilir olması gerekir. Bunu GitOps ile sağlarız: tek doğruluk kaynağı Git deposudur, cluster'ın durumu bu depoyla sürekli eşitlenir. Argo CD veya benzeri bir araçla, kullandığınız mevcut hattı (GitHub Actions, GitLab CI) bozmadan entegre ederiz.

Sık yapılan hatalar

• Gözlemlenebilirliği sona bırakmak: Sorun çıkınca kör kalırsınız.
• Her şeyi ilk gün taşımak: Aşamalı kesim yerine tek seferde geçiş, geri dönüşü imkânsızlaştırır.
• Gizli anahtarları manifeste gömmek: Güvenlik açığı ve sızıntı riski doğar.
• Tek kişiye bağımlılık: Cluster'ı tek mühendis biliyorsa, o kişi tek nokta riskidir.

Dynamis bu işi nasıl yapıyor

Kubernetes karmaşıklığını yönetilen hizmet olarak devralırız: kurar, işletir ve 7/24 izleriz. Bu soyut bir vaat değil; Raff altyapısını biz işletiyoruz, 10.000+ sanal makine ve 1.000+ müşteri ölçeğinde. Aynı operasyonel disiplini sizin geçişinize getiriyoruz.

Sözleşme bittiğinde kurulum sizde kalır. Tamamı open source olduğu için lock-in yoktur; isterseniz başka bir partnerle devam edebilirsiniz.