Geçenlerde bir arkadaşımla sohbet ederken, kendi kişisel web sitesi için bir altyapı kurmaktan bahsediyordu. “Mustafa, sence Kubernetes mi kursam bu site için?” diye sordu. O an durdum, içimden “Yine mi?” dedim. Kendi VPS’imde 13’ten fazla Docker container’ı yöneten ve bu blogun da dahil olduğu dört yan ürünümü tek bir sunucuda koşturan biri olarak, bazen bu “her şeyi Kubernetes ile çözelim” yaklaşımını anlamakta zorlanıyorum.
Özellikle basit bir blog, bir e-ticaret sitesinin statik ön yüzü veya birkaç mikroservis için bu kadar karmaşık bir yapıya girmek, bana gereksiz bir operasyonel yük ve maliyet gibi geliyor. Deneyimlerim bana gösterdi ki, her zaman en son ve en popüler teknoloji, her problemin en iyi çözümü olmak zorunda değil. Hatta bazen, var olan problemi daha da büyütmenin kestirme yolu olabiliyor.
Kubernetes’in Cazibesi ve Asıl Tuzak
Kubernetes, ölçeklenebilirlik, yüksek erişilebilirlik ve otomasyon vaatleriyle gerçekten göz kamaştırıcı bir teknoloji. Büyük, dağınık sistemleri yönetmek, binlerce mikroservisi koordineli bir şekilde çalıştırmak için tasarlanmış bir canavar. Ancak, bu canavarı evcilleştirmek, onu anlamak ve operasyonel olarak yönetmek, sandığımızdan çok daha fazla efor, bilgi ve kaynak gerektiriyor.
Pek çok geliştirici ve mimarın, daha projeye başlamadan “Kubernetes kullanmalıyız” ön yargısıyla yola çıktığını görüyorum. Bu genellikle, problemin gerçek boyutunu ve mevcut alternatif çözümleri tam olarak analiz etmeden yapılan bir tercih oluyor. Elde bir çekiç varsa, her şeyi çivi gibi görmeye başlamak gibi bir durum.
Küçük Bir Problemi Dev Bir Çözüme Dönüştürmek
Basit bir örnek vereyim: Kendi finansal hesaplayıcı sitem olan hesapciyiz.com projesini düşünün. Bu, Astro ile yazılmış, statik dosyalardan oluşan ve birkaç Node.js API’si ile beslenen bir yapı. Böyle bir projeyi Kubernetes üzerinde çalıştırmak için neye ihtiyacım olurdu? Minimumda 3 node’lu bir cluster, bir Ingress Controller, bir Load Balancer, Persistent Volume’lar, çeşitli Deployments, Services, ConfigMaps ve muhtemelen bir Helm chart.
Tüm bu katmanları kurmak, yönetmek, izlemek ve sorun gidermek için harcayacağım zaman ve para, sitenin sağladığı değere kıyasla absürt olurdu. Kendi VPS’imde bu siteyi Nginx, PM2 ve systemd ile çok daha basit, maliyetsiz ve hızlı bir şekilde ayağa kaldırdım. Günde birkaç yüz istek alan bir site için Kubernetes’in getireceği fayda marjinal kalırken, operasyonel karmaşıklık katlanarak artacaktı.
Kendi VPS’imdeki Deneyimlerim ve Karşılaştırmalar
Benim kendi VPS’im, aslında bir nevi “minimalist orkestrasyon” örneği. Üzerinde PostgreSQL, Redis, bu blog, hesapciyiz.com, islistesi.com ve birkaç başka araç olmak üzere 13’ten fazla Docker container çalışıyor. Bunların hepsini docker compose ve systemd servisleri ile yönetiyorum. Her şey tıkır tıkır çalışıyor ve operasyonel yüküm oldukça düşük.
Elbette, zaman zaman problemlerle karşılaşıyorum. Mesela, kendi VPS’imde 28 Nisan sabahı yaşadığım disk %100 doluluk sorununu düşünün. docker system prune yapmayı unuttuğum için 33 GB build cache ve 23 GB unused image birikmişti. Bu durumda kcompactd %92 CPU ile sshd accept edemez hale geliyordum. Böyle bir senaryoda Kubernetes’in getireceği ek karmaşıklık, sorunu daha da derinleştirirdi. O an tek istediğim basit bir komutla temizlik yapıp rahat bir nefes almaktı, yoksa problemin kök nedenini bulup çözmek bile zorlaşırdı.
Docker ve systemd ile Operasyonel Basitlik
Küçük ve orta ölçekli projeler için Docker ve systemd ikilisi, Kubernetes’in sunduğu otomasyonun büyük bir kısmını çok daha düşük bir karmaşıklıkla sağlayabilir. docker compose ile servislerimi kolayca tanımlıyor, ağlarını ve persistent volume’larını yönetiyorum. systemd servisleri ile de container’larımın açılışta otomatik başlamasını, çöktüğünde yeniden başlatılmasını ve kaynak limitlerinin belirlenmesini sağlıyorum.
Örneğin, bu blogun Astro build süreci bazen 2.5 GB RAM yiyip sistemde 7.6 GB RAM kullanımı varken OOM (Out Of Memory) olabiliyor. Böyle bir tekil süreci Kubernetes’te yönetmek için bile bir sürü resource request, limit, liveness/readiness probe tanımlamanız gerekir. Oysa benim için bir systemd servisi, restart=on-failure parametresi ve basit bir MemoryMax ayarı yeterli oluyor. Bu kadar basit bir çözümü, Kubernetes gibi devasa bir sistemin karmaşıklığına feda etmeyi mantıklı bulmuyorum.
Maliyet, Karmaşıklık ve Öğrenme Eğrisi
Kubernetes’e geçiş, sadece teknolojik bir karar değil, aynı zamanda ciddi bir maliyet ve insan kaynağı yatırımıdır. Yönetilen bir Kubernetes servisi (EKS, GKE, AKS) kullanmak, düz bir VM kiralamaktan çok daha pahalıdır. Kendi Kubernetes cluster’ınızı kurup yönetmek ise, uzmanlık gerektiren bir iştir ve operasyonel maliyetleri artırır.
Ayrıca, Kubernetes’in öğrenme eğrisi diktir. Ekibinizdeki herkesin bu sistemi anlaması, sorunları gidermesi ve yeni uygulamaları dağıtması zaman alır. Küçük bir ekip veya tek kişilik bir proje için bu yatırım, çoğu zaman geri dönüşü olmayan bir gider kalemine dönüşebilir. Bir CVE mitigation yapmanız gerektiğinde (örneğin algif_aead modülünü blacklist’e almak gibi), Kubernetes’in katmanlı yapısı işleri daha da zorlaştırabilir. Düz bir Linux sunucuda bu tür işler çok daha basittir.
Kubernetes Ne Zaman Gerçekten Gerekli?
Bu kadar “Kubernetes’e hayır” dedikten sonra, ne zaman evet dediğimi de açıklayayım. Kubernetes, belirli senaryolarda gerçekten vazgeçilmez bir araçtır:
- Büyük Ölçekli Mikroservis Mimarileri: Yüzlerce veya binlerce mikroservisin olduğu, sürekli değişen ve birbirleriyle etkileşimli çalışan sistemlerde.
- Yüksek Erişilebilirlik ve Otomatik Ölçeklendirme İhtiyacı: Uygulamalarınızın anlık olarak yüzbinlerce isteği karşılaması ve otomatik olarak yatayda ölçeklenmesi gerektiğinde.
- Karmaşık Dağıtım Stratejileri: Canary deployment, blue/green deployment gibi gelişmiş dağıtım modellerini otomatikleştirmek istediğinizde.
- Kaynak Optimizasyonu: Sunucu kaynaklarını çok verimli kullanmak ve çeşitli uygulamaları aynı küme üzerinde izole bir şekilde çalıştırmak istediğinizde.
- Ekip Büyüklüğü ve Yetkinlik: Büyük bir DevOps ekibiniz varsa ve bu ekibin Kubernetes operasyonlarına hakimiyeti varsa.
Bu senaryoların dışında, genellikle daha basit ve uygun maliyetli çözümler mevcuttur.
Pragmatik Yaklaşım: Doğru Aracı Seçmek
Benim mimari felsefem her zaman pragmatizm üzerine kuruludur. Bir problemi çözmek için en karmaşık veya en popüler aracı seçmek yerine, en uygun, en sürdürülebilir ve en maliyet-etkin aracı seçmeye çalışırım. Bazen bu, düz bir VM ve Docker Compose olabilir; bazen basit bir PaaS çözümü (Heroku, Render); bazen de evet, Kubernetes olabilir.
Özellikle AI destekli içerik pipeline’ımı kurarken bile, preflight resource guard, auto-fix ve dedup-alert gibi pattern’leri Kubernetes’e ihtiyaç duymadan, kendi VPS’imdeki basit systemd servisleri ve custom script’lerle uyguladım. Bu, bana hem kontrol sağladı hem de gereksiz karmaşıklıktan kaçınmamı sağladı.