Kubernetes maliyeti mimari kararla başlar

Kubernetes cluster kurarken ilk gündem çoğu zaman node sayısı ve CPU/RAM olur. Oysa uzun vadeli maliyet ve kesinti riski; high availability, ingress, storage ve backup kararlarında belirlenir. Küçük bir SaaS ekibi veya ajans için yanlış ingress/controller seçimi, tek noktadan arıza, pahalı storage sınıfı ya da plansız replica modeli bütçeyi hızla büyütebilir.

Narweb’in Kubernetes Cluster Hosting ve teklif yaklaşımında amaç, cluster’ı sadece ayağa kaldırmak değil; işletilebilir, izlenebilir ve güncellenebilir hale getirmektir.

HA: her şeyi çoğaltmak çözüm değildir

High availability tasarımında kritik olan, hangi bileşenin gerçekten kesintiye duyarlı olduğunu bilmektir. Control plane, ingress, veritabanı, storage, DNS ve CI/CD bağımlılıkları aynı seviye risk taşımaz. Her şeyi üçlemek maliyeti büyütür; hiçbir şeyi yedeklememek ise tek arızada tüm servisi durdurur.

Pratik yaklaşım; müşteri etkisi yüksek servisleri replica ile çalıştırmak, stateful bileşenleri ayrıca planlamak, maintenance sırasında pod dağılımını test etmek ve node kaybı senaryosunu düzenli denemektir.

Ingress: güvenlik ve trafik yönetimi birlikte düşünülmeli

Ingress katmanı yalnızca domain yönlendirme değildir. TLS yenileme, rate limit, body size, timeout, WAF entegrasyonu, blue/green veya canary dağıtım stratejisi burada şekillenir. Reklam trafiği alan landing page, API endpoint’i ve admin paneli aynı kurallarla açılırsa gereksiz risk oluşur.

KOBİ ve SaaS ekipleri için ayrı ingress sınıfları, ortam bazlı domain düzeni, health-check ve log formatı standardı operasyonu kolaylaştırır.

Storage: persistent volume seçimi uygulama kaderini belirler

Kubernetes’te stateless servisleri taşımak kolaydır; asıl risk verinin nerede ve nasıl tutulduğudur. Veritabanı, kullanıcı dosyaları, cache, queue ve backup aynı storage beklentisine sahip değildir. Performans, snapshot, restore süresi, bölgesel dayanıklılık ve maliyet ayrı ayrı değerlendirilmelidir.

PostgreSQL gibi kritik servislerde cluster içi disk yeterli olmayabilir; PostgreSQL Cluster Hosting veya yönetilen yedek/replika modeli ayrıca konuşulmalıdır.

Karar kontrol listesi

• Control plane ve worker node arıza senaryosu test edildi mi?
• Ingress timeout, TLS, rate limit ve log standardı belirlendi mi?
• Stateful servisler için snapshot ve restore süresi ölçüldü mü?
• Node upgrade ve rollback prosedürü yazılı mı?
• Monitoring, alert ve bakım sorumluluğu kimde?

CTA

Cluster maliyeti, HA seviyesi ve storage kararlarını netleştirmek için Kubernetes Cluster Hosting teklif formunu doldurabilir veya DevOps Hizmeti kapsamında bakım modeli konuşabilirsiniz.

Bakım modeli: upgrade günü gelmeden önce karar verin

Kubernetes tarafında en pahalı kesintiler genellikle “upgrade sırasında fark edilen” bağımlılıklardan çıkar. Eski API kullanımı, ingress anotasyonları, storage class davranışı, pod disruption budget eksikliği ve node drain sırasında düşen tekil worker süreçleri önceden test edilmezse bakım penceresi uzar. Bu nedenle cluster kurulum dokümanı kadar bakım dokümanı da hazırlanmalıdır.

İyi bir bakım modeli; versiyon matrisi, yedek/restore kontrolü, canary deployment, rollback komutu, sorumlu kişi ve müşteri iletişim penceresini içerir. Özellikle reklam veya kampanya trafiği alan uygulamalarda maintenance tarihi pazarlama takvimiyle de kontrol edilmelidir.

Maliyet azaltan teknik tercihler

• Her ortam için ayrı büyük cluster yerine geliştirme/test iş yüklerini daha küçük kaynaklarla sınırlayın.
• Autoscaling kullanılsa bile minimum ve maksimum sınırları iş saatlerine göre gözden geçirin.
• Log retention süresini uygulama ihtiyacına göre ayırın; her log sonsuza kadar tutulmamalı.
• Storage performans sınıfını veritabanı, dosya ve cache için ayrı değerlendirin.
• Ingress ve TLS ayarlarını standartlaştırarak her yeni uygulamada tekrar iş çıkmasını önleyin.

Narweb ile Kubernetes konuşurken yalnızca node fiyatı değil; HA seviyesi, backup, izleme, ingress güvenliği ve bakım sorumluluğu birlikte değerlendirilmelidir. Böylece teklif, gerçek production ihtiyacını yansıtır.

Uygulama ekibi ile altyapı ekibi aynı tabloya bakmalı

Kubernetes projelerinde başarısızlığın önemli bir kısmı teknik eksiklikten değil, sorumluluk sınırının belirsiz olmasından kaynaklanır. Deployment manifestini kim güncelliyor, TLS yenilemesini kim takip ediyor, ingress değişikliği sonrası test kimin sorumluluğunda, storage alarmı geldiğinde kimin aksiyon alacağı baştan yazılmalıdır. Bu netlik yoksa cluster sağlıklı olsa bile operasyon yavaşlar.

Bir başka pratik konu da ortam ayrımıdır. Development, staging ve production aynı cluster üzerinde koşacaksa namespace, resource quota, secret yönetimi ve erişim rolleri dikkatle ayrılmalıdır. Aksi halde test uygulaması production kaynağını tüketebilir veya yanlış secret yanlış pod’a bağlanabilir.

Teklif almadan önce hazırlanacak bilgiler

• Uygulama sayısı, beklenen trafik ve kritik servislerin listesi.
• Stateful bileşenler: veritabanı, dosya deposu, queue ve cache ihtiyaçları.
• Kabul edilebilir kesinti süresi ve bakım penceresi.
• Mevcut CI/CD aracı ve deployment sıklığı.
• Log, monitoring ve backup sorumluluğu için beklenti.

Bu bilgilerle istenen cluster yalnızca “çalışan Kubernetes” olmaktan çıkar; gerçek iş yüküne uygun, maliyeti açıklanabilir ve bakım sorumluluğu belli bir production platformuna dönüşür. Narweb tarafında teklif süreci de bu yüzden node sayısından önce mimari ihtiyacı anlamaya odaklanmalıdır.