Benim Kubernetes’e ihtiyacım yoktu; muhtemelen sizin de yok

(benhouston3d.com)

19 puan yazan GN⁺ 2024-11-28 | 12 yorum | WhatsApp'ta paylaş

Kubernetes’ten ayrılıp Google Cloud Run’ı seçmemin nedeni

Kubernetes’i benimseme arka planı

2013’te kullanıma sunulan çevrimiçi 3D düzenleme platformu Clara.io’da altyapıyı optimize etmek için bare metal sunucular kullanıldı; ancak donanım yönetimi ve izleme için aşırı emek gerekiyordu.
2018’deki Threekit.com projesinde Kubernetes seçildi. O dönemde Azure, AWS, Docker Kubernetes’i standart olarak benimsiyor ve ana akım haline getiriyordu.

Kubernetes’in sınırlamaları

Maliyet sorunu:
- Yönetim düğümleri, küme yedekliliği gibi nedenlerle temel bir cluster kurulum maliyeti yüksektir.
- Yavaş auto-scaling nedeniyle hizmetleri fazla provision etmek gerekir ve kullanılmayan kaynaklar için maliyet oluşur.
İş yükü yönetiminin zorluğu:
- İş planlaması karmaşıktır; yerleşik scheduler ve Argo bile büyük hacimli işler için verimsizdir.
Aşırı karmaşıklık:
- Zengin özellik seti, basit işleri bile karmaşık hale getirir.
- Kubernetes yönetimi için özel DevOps personeli gerekir; bu da maliyeti artırır.

Google Cloud Run’a geçiş

Cloud Run, Kubernetes’in karmaşıklığının yerine daha sade ve maliyet açısından verimli bir ortam sunar.

Yeni kurulum

Docker container tabanlı altyapı:
- Otomatik ölçeklenen servisler ve uzun süre çalışan işler için container’lar içerir.
- Cloud Run; container dağıtımını, ölçeklendirmeyi, kesinti yönetimini ve iş çalıştırmayı otomatikleştirir.

Cloud Run’ın avantajları

Maliyet verimliliği:
- CPU ve bellek kullanım süresine göre ücretlendirilir.
- Boştaki servisler için ücret alınmaz.
- Örnek: Web3D Survey sitesi, ayda 500.000 istek işlerken aylık 4 $ maliyetle çalışabilir.
Hızlı ve istikrarlı auto-scaling:
- Kubernetes’ten daha hızlı, birkaç saniye içinde ölçeklenir.
- Talep artışlarını hızla karşılayabilir.
Kubernetes yönetim yükü yok:
- Cloud Run, Google’ın Borg altyapısı üzerinde çalıştığından Kubernetes cluster yönetimi gerekmez.
Basit asenkron işler:
- Cloud Run Tasks ile otomatik yeniden deneme ve büyük hacimli iş çalıştırma kolaydır.

Kubernetes’in olası sorunu: cluster lock-in

Kubernetes özelliklerine bağımlı hale gelince, cluster dışı kaynaklarla entegrasyon veya genişleme zorlaşır.
Belirli bir altyapıya bağımlılık, ölçekleme ve migrasyonu daha karmaşık ve maliyetli hale getirir.

Cloud Run kullanımıyla ilgili yaygın sorular

“GCP bağımlılığı endişe yaratmıyor mu?”

Docker tabanlı kurulum sayesinde AWS gibi başka bir buluta migrasyon yaklaşık 1 haftada yapılabilir.
Gerçekte, siyasi etkenler dışında bulut sağlayıcısı değiştirmek nadirdir.

“Cloud Run da sonuçta Managed Kubernetes değil mi?”

Cloud Run, Knative arayüzünü kullanır; ancak Kubernetes değil, Google’ın Borg sistemi üzerinde çalışır.
Kubernetes’in karmaşıklığını ortadan kaldırır ve sadeleştirilmiş bir arayüz sunar.

Mevcut iş akışının dezavantajları

Servis adı yönetiminin zahmeti:
- Yerelde ve sunucuda tutarlı yapılandırma yönetimi için bir soyutlama katmanı gerekir.
- Kubernetes’teki isim yönetimi özellikleri yoktur.
Cloud Run Task emülasyonu eksikliği:
- İşleri yerelde geliştirirken log çıktısı yakalama ve izlemeyi içeren basit bir emülasyon ortamı yoktur.

Sonuç

Cloud Run, maliyet, hız, ölçeklenebilirlik ve sadelik açısından en iyi çözümdür.
Büyük şirketler veya karmaşık gereksinimleri olan durumlarda Kubernetes faydalı olabilir; ancak
Sadelik ve verimliliğin önemli olduğu projelerde Cloud Run çok daha pratiktir.
PS: Belki Kubernetes’e özel bazı eklentiler eklenerek bu sorunlar çözülebilir; ancak bu yalnızca karmaşıklığı artırır ve basit ihtiyaçların ötesine geçen bir Kubernetes ortamına bağımlı olmak istemiyorum.

12 yorum

blurblah 2024-12-01

Orada bir sihirli değnek yok sonuçta. Duruma göre iyi kullanmak gerekiyor tabii :)
Sırf trend diye Kubernetes’i eleştirel düşünmeden devreye almak işleri zorlaştırabilir, ama yine de biraz daha büyük ölçekli ortamlarda iyi bir araç olduğunu düşünüyorum.
Devreye alsanız bile sadece kurup bırakılırsa gerektiği gibi kullanılamaz.
Ayrıca her araçta olduğu gibi, hiçbir şey geliştiricilerin ya da kullanıcıların ihtiyaçlarını %100 karşılayamaz; bu yüzden uygun düzeyde otomasyonun şart olduğunu düşünüyorum.

bungker 2024-11-29

Kubernetes kurulduktan sonra geriye sadece keyif sürmek kalıyor ama ... TT

riki3 2024-11-29

Kubernetes benim ekmek teknem ve bir zamanlar bunun doğru cevap olduğuna inandığım bir dönem vardı.
Ama zaman geçtikçe birçok sorun yaşayıp zamanımı boşa harcadığımı fark ediyorum.

Başkalarına k8s öneriyorum ama kendi servislerimde kullanacağımı sanmıyorum. k8s bir yana, artık konteynerlerden bile yoruldum.

joon14 2024-11-28

AWS kullanıyorsanız, ECS ile benzer olduğunu düşünebilir miyiz?

tujuc 2024-11-29

Evet, tam olarak o diyebilirsiniz. :)

eclipsense 2024-11-28

Kubernetes kullanamıyor olmanız sizin hatanız; buna bakıp Kubernetes pek iyi değil demek biraz yanlış olur.

tujuc 2024-11-28

Ben de yazarın düşüncesine benzer düşünüyorum.
Şirketimiz henüz kube kullanacak ölçekte değil.

Tüm geliştiricilerin Kube kullanarak yönetim yapabileceğini düşünmek sadece benim varsayımımmış.
Şirketteki ortalama geliştirici seviyesinin altında kalsa bile altyapıyı kurup sorunları çözebilmeleri için rehberlik etmek daha iyi oldu...

doolayer 2024-11-28

???: Benim yapay zekaya ihtiyacım yoktu ve muhtemelen sizin de olmayacak.

ilbanin00 2024-11-28

Her ürünün bazı trade-off'ları vardır.

bbulbum 2024-11-28

managed servisleri kullanınca açıkçası yönetim tarafında pek zorlanmadım,,
her araç da kararında kullanılırsa faydalı ama konu Kubernetes olunca özellikle "karmaşık yapılandırmalara izin vermesi"nin başlıca eleştiri noktası hâline geldiğini düşünüyorum.