Teknoloji dünyasında son 5-6 yılın en büyük yalanı şudur: "Uygulamanı Kubernetes'e koy, gerisini o halleder." Konferanslarda sahneye çıkanlar size Kubernetes'in (K8s) ne kadar "self-healing" (kendi kendini iyileştiren) ve muhteşem bir orkestrasyon aracı olduğunu anlatır. Ama kimse size, o orkestrayı yönetmek için gereken mühendislik ordusunun maliyetinden bahsetmez.
Acı gerçek şu: Google değilsiniz. Muhtemelen Google'ın ölçeklenme problemlerine de sahip değilsiniz. Ancak sektördeki "FOMO" (geri kalma korkusu) yüzünden, basit bir web sitesini bile nükleer denizaltı kontrol paneli karmaşıklığında bir sistemle yönetmeye çalışıyorsunuz. Gelin, bu "YAML cehennemi"nin görünmeyen faturasına bir göz atalım.
1. "Day 2" Operasyonları: Rüya Bitti, Gerçekler Başladı
Kubernetes kümesini (cluster) ayağa kaldırmak işin kolay kısmıdır ("Day 1"). Asıl kâbus "Day 2" operasyonlarında başlar. Cluster'ı güncel tutmak, sertifika rotasyonları, versiyon uyumsuzlukları ve çöken Node'ları yönetmek...
- İnsan Kaynağı Maliyeti: K8s yönetmek, başlı başına bir tam zamanlı iştir. Developer'larınızın işi kod yazmak mı, yoksa Ingress Controller'ın neden trafiği yönlendirmediğini debug etmek mi?
- Soyutlama Sızıntısı: K8s donanımı soyutlar derler ama yalan. CPU limitlerini (`requests` ve `limits`) yanlış ayarladığınız an, uygulamanız "OOMKilled" (Out of Memory) hatasıyla sessizce ölür.
- Networking: Pod'lar arası iletişim, Service Mesh, CNI plugin'leri... Basit bir HTTP isteği, bir anda içinden çıkılmaz bir ağ mühendisliği problemine dönüşebilir.
2. Resume Driven Development (CV Odaklı Geliştirme)
Şüpheci bir uzman olarak bir şirkete girdiğimde ilk şuna bakarım: Bu mimariyi işin gereksinimi mi dayattı, yoksa mühendislerin CV'lerine "Kubernetes Uzmanı" yazma isteği mi?
Eğer uygulamanız tek bir sanal sunucuya (VM) sığıyorsa ve siz onu 3 node'lu bir K8s cluster'ına bölüyorsanız; çözdüğünüz tek şey teknik problem değil, egonuzdur.
3. Karmaşıklığın Getirdiği Güvenlik Açıkları
Karmaşıklık, güvenliğin bir numaralı düşmanıdır. Kubernetes'in varsayılan ayarları genellikle "güvenli" değil, "çalışmaya odaklı"dır.
Bir Docker container'ını root yetkisiyle çalıştırmak, secrets yönetimini (etcd şifrelemesi) atlamak veya yanlış yapılandırılmış RBAC (Role-Based Access Control) kuralları... Hackerlar için K8s, yanlış yapılandırıldığında bir lunaparktır. K8s güvenliğini sağlamak için ekstra araçlara (trivy, falco vs.) ve bunları yönetecek ekstra zamana ihtiyacınız var.
4. Ne Zaman K8s, Ne Zaman PaaS?
Peki, Kubernetes'i çöpe mi atalım? Hayır. Sadece doğru çiviyi bulalım.
- Mikroservis Cehennemi: Eğer gerçekten yönetmeniz gereken 50+ mikroservisiniz varsa ve bunlar birbirleriyle yoğun konuşuyorsa, K8s bir kurtarıcıdır.
- Monolitik Uygulamalar: Monolitik bir uygulamanız varsa, onu Dockerize edip basit bir PaaS (Heroku, DigitalOcean App Platform vb.) veya yönetilen bir Container Service (AWS ECS) üzerinde çalıştırmak, size %80 daha az operasyonel yük getirir.
- Hibrit Bulut: Eğer gerçekten Vendor Lock-in'den kaçmak ve uygulamanızı her yerde (On-prem, AWS, Azure) aynı şekilde çalıştırmak istiyorsanız, K8s standarttır.