Sevgili dostum, Kubernetes’i sen yaptın

• Arkadaşa mektup

  • Kubernetes’ten kaçınmaya çalışırken sonunda benzer bir sistem kurmuş olduğunu anlatıyor.
  • Arkadaşı, basit konteyner çalıştırma için “sıkıcı teknoloji”yi seçmek istedi, ancak sonunda karmaşık betikler ve yapılandırmalar yüzünden sorunlar yaşadı.
  • Docker Compose’a geçmenin de tüm sorunları çözmediğini; dağıtım, rolling update, rollback ve scaling için ayrı çözümlere ihtiyaç duyulduğunu fark etti.

• Sunucu ölçekleme ve ağ karmaşıklığı

  • İkinci bir sunucuya genişleme ihtiyacı hissetti.
  • Servis keşfi için Tailscale gibi overlay network’leri kullanmayı denedi.
  • Ağ karmaşıklığını çözmeye çalışırken sonunda daha fazla sorunla karşılaştı.

• Bakım ve otomasyon

  • Betikleri yazan kişi tatile gittiğinde ya da işten ayrıldığında, karmaşık yapılandırmayı ve belgelenmemiş ayar değişikliklerini kimin yöneteceği sorusu ortaya çıktı.
  • Özel betiklerin bakım sorununu çözmek için Ansible kullanarak VM’leri immutable ve sürüm kontrollü hale getirdi.
  • Kubernetes kullanmadığı için bakımın daha kolay olacağını düşündü.

• Konteyner oluşturma ve güvenlik sorunları

  • Programatik olarak başka konteynerler oluşturma gereksinimi ortaya çıktı.
  • Docker socket’ini web uygulamasına mount etmenin güvenlik açısından riskli olması nedeniyle, bunu çözmek için ayrı bir servis yazdı.
    • Docker API’sinin yalnızca güvenli kısımlarını açığa çıkaran ayrı bir servis yazarak sorunu çözdü.

• Sonuç

  • Sonunda Kubernetes’e benzer bir sistem inşa etmiş olduğunu fark etti.
    • Standart yapılandırma formatı, dağıtım yöntemi, overlay network, servis keşfi, immutable node’lar ve API server içeren karmaşık bir sistemi tamamladı.

• PS

  • Kubernetes’in yerine daha iyi çözümler olabileceği ihtimalini reddetmiyor.
  • Ancak, Kubernetes’i karmaşık diye damgalamadan önce, çözmeye çalıştığı problemleri yeterince anlamayı tavsiye ediyor.

[savvykang]

Dağıtım devir teslimini çözmek için Kubernetes’in devreye alınmasından bahsedilmesini pek anlayamıyorum.

[kandk]

Bakım ve otomasyon kod seviyesinde kolayca yapılabiliyor.
Infra as code da mümkün.

[savvykang]

EKS gibi yönetilen k8s hizmet ortamlarında load balancer da var ve Route 53 entegrasyonu da mümkün, ancak self-hosted k8s'te ne bir load balancer implementasyonu oluyor ne de DNS entegrasyonu yeterince esnek oluyor. k8s yönetim ekibinin ayrı olduğu şirketlerde bahsettiğiniz avantajlar gerçekten geçerli olabilir.

İlk bakışta iyi bir çözüm gibi görünse de, pratikte kullanınca her durumda çalışmıyor.

[kandk]

k8s yönetim ekibi olmasa da kullanımı kolay. EKS kullanırsanız yeterli.

[savvykang]

Bu, sadece kaynak kodu verirsen devir teslimin tamamlandığını iddia etmekle aynı şey değil mi? İş kılavuzu ve işin yürütülme geçmişi hâlâ gerekli gibi görünüyor.

[kbumsik]

Infrastructure as Code zaten sadece kaynak kodunu verip işi bitirmek için var. Tabii ki hangi kod olursa olsun, temel düzeyde dokümantasyonun yapılmış olması gerekir.

[kandk]

Kaynak kodu iyi yazılmışsa ve belgeler iyi hazırlanmışsa mümkündür.
İş kılavuzu ile işin yürütülme geçmişinin ayrıca bulunması faydalı olabilir, ancak bu bu yazıdan farklı bir konu gibi görünüyor.

[GN⁺]

Hacker News görüşü

• Birden fazla şirkette shell script kullanarak dağıtımı başarıyla gerçekleştirme deneyimi var

  • İki PHP servisiyle günde 1 milyardan fazla isteği işlerken, sunucuya dosya gönderip migration çalıştırarak kesinti olmadan dağıtım yapıldı
  • Emeklilik hesabı gibi web ölçeği gerektirmeyen sektörlerde Jenkins üzerinden Docker komutlarıyla dağıtım yapıldı
  • Test ortamları ihtiyaç oldukça birkaç dakika içinde kullanılabilir hale getirilebiliyordu
  • Mevcut şirket Kubernetes’e geçmeye çalışıyor ancak karmaşıklık nedeniyle zorlanıyor

• Kubernetes, YAML dosyalarını yönetmek için iki ya da üç tam zamanlı çalışan gerektiriyor

  • Bir bulut sağlayıcısı seçilirse karmaşık kısımlar çözülebilir ama bu ek maliyet getirir
  • YAML dosyaları insanların yazacağı değil, araçların üretmesi gereken yapılandırma dosyalarıdır
  • Çoğu web sitesi ve servis Kubernetes’e ihtiyaç duymaz

• Basit olanın kırılgan olduğu düşüncesi yanlıştır

  • YAML dosyalarını ve Kubernetes’in karmaşıklığını anlamak ve debug etmek daha zordur
  • Kubernetes’e alternatif olarak shell script’ler vardır

• Kubernetes’in gerekli olmadığı durumlar da vardır

  • EC2 instance’ları ve basit shell script’lerle 100.000’den fazla eşzamanlı kullanıcı yönetilebilir
  • Sorun yoksa sırf değiştirmek için değiştirmeye gerek yoktur

• Shell script’lerle iptables kurallarını ve sysctl düzenlemelerini kolayca yönetmek mümkündür

  • Bir iş kuyruğu kullanarak container’ları programatik olarak oluşturmak yerine işleri kuyruğa itebilirsiniz

• Kubernetes’i eleştirmek profesyonellik dışı değildir

  • Google ya da Netflix gibi büyük ölçekli uygulamalarınız yoksa basit script’ler yazmak daha iyidir

• Kendi geliştirilmiş bir sistemin tüm kısıtlarının maliyet, genel amaçlı bir çözümün tüm esnekliğinin de avantaj olduğu varsayımı yanlıştır

  • Kod tabanında benzer kalıpların izlenmesini ve servislerin aynı şekilde dağıtılmasını istersiniz

• Kubernetes’in sorunu, sayısız açık kaynak kütüphanenin sistemi anlamayı zorlaştırması ve bug’lara yol açmasıdır

• Kubernetes’in öğrenme eğrisini aşmış olanlar, karmaşıklığın o kadar da kötü olmadığını söylüyor

  • Geliştiricilere Kubernetes öğretmek için verilen eğitim yaklaşık 30 dakika sürüyor ve Helm chart yazabilir hale gelmelerini sağlıyor