- Gitpod, 6 yıldır Kubernetes kullanarak bir "uzaktan geliştirme ortamı platformu" inşa ediyor; 1,5 milyon kullanıcıyı destekliyor ve her gün binlerce geliştirme ortamı sunuyor
- Ancak Kubernetes'in geliştirme ortamları kurmak için uygun olmadığını fark etti
- Bu, üretim iş yüklerinde Kubernetes kullanılıp kullanılmamasıyla ilgili bir yazı değil; K8s'e uygulama dağıtmak için geliştirici deneyiminin nasıl oluşturulacağına dair bir konu da değil
→ Bu yazı, bulutta geliştirme ortamlarının nasıl inşa edileceğiyle (veya edilmeyeceğiyle) ilgili
[Geliştirme ortamlarının neden özel olduğu]
- Çok durumludur ve yoğun etkileşim barındırır
- Düğümler arasında taşınamaz
- Büyük miktarda kaynak kodu, build cache, Docker container'ları, test verileri vb. sık değişir ve taşınma maliyeti yüksektir
- Üretim servislerinden farklı olarak geliştirici ile ortam arasında bire bir etkileşim gerçekleşir
- Geliştiriciler kaynak koda ve değişikliklerine derinden bağlıdır
- Kaynak kodu değişikliklerini kaybetmekten veya sistem tarafından engellenmekten hoşlanmazlar
- Geliştirme ortamları arızalara karşı özellikle hassastır
- Öngörülemeyen kaynak kullanım kalıplarına sahiptir
- Zamanın büyük bölümünde çok fazla CPU bant genişliği gerekmez, ancak yüzlerce ms içinde birden fazla çekirdeğe ihtiyaç duyulabilir
- Bundan daha yavaşsa kabul edilemez gecikme ve yanıtsızlık olarak hissedilir
- Geniş yetkiler ve işlevler gerektirir
- Üretim iş yüklerinden farklı olarak root erişimi ve paket indirme/kurma yeteneği gerekir
- Üretim iş yüklerinde güvenlik sorunu sayılan şeyler geliştirme ortamlarında beklenen davranışlardır (root erişimi, genişletilmiş ağ özellikleri, ek dosya sistemi mount'ları vb.)
- Bu özellikler onu tipik uygulama iş yüklerinden ayırır ve altyapı kararlarını büyük ölçüde etkiler
[Mevcut sistem: Kubernetes]
- Gitpod'un ilk dönemlerinde Kubernetes altyapı için ideal bir seçim gibi görünüyordu
- Ölçeklenebilirlik, container orkestrasyonu ve zengin ekosistem gibi özellikler bulut geliştirme ortamları vizyonuyla iyi uyuşuyordu
- Ancak ölçek ve kullanıcı tabanı büyüdükçe güvenlik ve durum yönetimi tarafında zorluklar yaşandı
- Kubernetes, iyi kontrol edilen uygulama iş yüklerini çalıştırmak için tasarlandı; yönetmesi zor geliştirme ortamları için değil
- Büyük ölçekte Kubernetes yönetmek karmaşıktır
- GKE, EKS gibi yönetilen servisler bazı sorunları hafifletse de kendilerine özgü kısıtlar ve sınırlamalar getirir
- CDE işletmek isteyen birçok ekip Kubernetes'in karmaşıklığını hafife alma eğilimindedir
- Bu da Gitpod'un önceki self-hosted ürününde ciddi bir destek yüküne yol açtı
Kaynak yönetiminin zorlukları
- CPU ve bellek tahsisi en büyük sorun
- Bir düğüm üzerinde ortamları paylaşmak cazip görünse de pratikte noisy neighbor etkisi ciddi şekilde ortaya çıkıyor
- CPU sorunları
- Geliştirme ortamları bazen çok az CPU isterken bazen ani şekilde çok fazla CPU isteyebilir
- CFS tabanlı çözümler, özel controller'lar vb. denendi ancak tahmin etmek zordu
- Statik CPU limitleri kullanılsa bile birden fazla sürecin yarışması sorunu ortaya çıkıyor
- Bellek yönetimi
- Sabit bellek atamak basit ama kısıtlayıcıdır
- Overbooking süreçlerin sonlandırılmasına yol açabilir
- Swap alanının devreye alınması, overbooking ihtiyacını bir ölçüde azalttı
Depolama performansını optimize etme
- IOPS ve gecikme, geliştirme ortamı deneyimini etkiler
- Çeşitli kurulumlar denenerek hız, kararlılık, maliyet ve performans arasında denge arandı
- SSD RAID 0
- EBS, kalıcı disk gibi blok depolama
- PVC
- Yedekleme/geri yükleme maliyetli işlemlerdir
Otomatik ölçeklendirme ve başlangıç süresini optimize etme
- Başlangıç süresini en aza indirmek en yüksek öncelik
- Tek bir düğümde birden fazla workspace çalıştırmanın paylaşılan cache sayesinde başlangıç süresini iyileştireceği düşünüldü, ancak öyle olmadı
- Kubernetes başlangıç süresine bir alt sınır koyuyor
- Ölçek büyütme yöntemlerinin evrimi
- Ghost workspace'ler, ballast pod'lar kullanılarak scale-out denemeleri yapıldı
- Autoscaler eklentisinin devreye alınmasıyla ölçeklendirme stratejisi büyük ölçüde iyileşti
- Zirve yükleri karşılamak için oransal otomatik ölçeklendirme
- Talep artışlarına hızlı yanıt verebilmek için boş pod'lar başlatıldı
- Image pull optimizasyonu için çeşitli girişimler
- DaemonSet ile önceden pull etme, katman yeniden kullanımını en üst düzeye çıkarma, önceden hazırlanmış image'lar, Stargazer ile gecikmeli pull, Registry-facade + IPFS
Ağ karmaşıklığı
- Geliştirme ortamı erişim kontrolü
- Ortamlar birbirinden tamamen izole edilmelidir
- Ağ politikaları yardımcı olur, ancak servis sayısı arttığında güvenilirlik sorunları ortaya çıkar
- Ağ bant genişliğinin paylaşımı
- CNI ağ şekillendirmeyi destekleyebilir, ancak bu da ayrıca yönetilmesi gereken bir katman oluşturur
Güvenlik ve izolasyon: esneklik ile koruma arasında denge
- Kullanıcılara esneklik verirken güvenli bir ortam sunmak en büyük zorluk
- Kullanıcılara root yetkisi vermek birçok kusur doğurur
- User namespace daha ayrıntılı bir çözüm
- Dosya sistemi UID dönüşümü, maskelenmiş proc mount'ları, FUSE desteği, ağ yetenekleri sağlama, Docker'ı etkinleştirme
- User namespace uygulamasının zorlukları
- Performans etkisi, uyumluluk sorunları, karmaşıklık, Kubernetes sürümleriyle uyum
[Micro VM deneyi]
- Kubernetes'in sınırlarını hissettikçe Firecracker, Cloud Hypervisor, QEMU gibi micro VM (uVM) teknolojileri bir ara çözüm olarak keşfedilmeye başlandı
- Kaynak izolasyonunu iyileştirme, diğer iş yükleriyle (Kubernetes vb.) uyumluluk ve güvenliği güçlendirme beklentisi vardı; aynı zamanda containerlaşmanın avantajlarını koruyabileceği düşünüldü
- Micro VM'lerin avantajları
- Bulut geliştirme ortamları hedefleriyle iyi örtüşen çekici faydalar sunuyordu
- Daha iyi kaynak izolasyonu: overbooking yeteneği düşse de container'lara kıyasla kaynak izolasyonu iyileşir. Paylaşılan kernel kaynakları üzerindeki çekişme ortadan kalkar ve geliştirme ortamı başına performansın öngörülebilirliği artar
- Bellek snapshot'ları ve hızlı devam etme: Firecracker'ın userfaultfd özelliği bellek snapshot'larını destekler. Bu, çalışan süreçler dahil tüm makinenin neredeyse anında devam etmesini sağlar. Geliştirici açısından ortam başlatma çok daha hızlanır ve iş kaldığı yerden sürdürülebilir
- Daha güçlü güvenlik sınırı: uVM'ler güçlü bir güvenlik sınırı görevi görebilir; böylece Kubernetes üzerinde kurulan karmaşık user namespace mekanizmaları gereksiz hale gelir. Bu, iç içe container çalıştırma da dahil olmak üzere (geliştirme ortamı içinde Docker veya Kubernetes çalıştırmak gibi) daha geniş iş yükleriyle tam uyumluluk sağlayabilir
- Micro VM'lerin zorlukları
- Ancak micro VM denemeleri birkaç önemli zorluğu da ortaya çıkardı
- Ek yük: Hafif VM olsalar da uVM'ler container'lardan daha fazla ek yük oluşturur. Bu hem performansı hem de kaynak verimliliğini etkiler; bulut geliştirme ortamı platformları için bu kritik bir konudur
- Image dönüştürme: OCI image'larını uVM'lerde kullanılabilir dosya sistemlerine dönüştürmek özel çözümler gerektirir. Bu, image yönetim hattını karmaşıklaştırır ve başlangıç süresini olumsuz etkileyebilir
- Teknolojiye özgü sınırlamalar
- Firecracker: GPU desteğinin olmaması (bazı geliştirme iş akışları için giderek daha önemli hale geliyor), virtiofs desteğinin olmaması (verimli dosya sistemi paylaşımı seçeneklerini sınırlar)
- Cloud Hypervisor: userfaultfd desteğinin olmaması nedeniyle snapshot ve restore süreçleri yavaşlar (uVM'lerin temel avantajlarından birini zayıflatır)
- Veri taşıma sorunu: uVM'ler nedeniyle büyük bellek snapshot'larıyla uğraşmak gerektiğinden veri taşımak daha zor hale gelir. Bu hem zamanlamayı hem de başlangıç süresini etkiler; bunlar bulut geliştirme ortamı kullanıcı deneyiminin temel unsurlarıdır
- Depolama değerlendirmeleri: EBS volume'lerini micro VM'lere bağlama denemeleri yeni olasılıklar açsa da yeni sorular da doğurdu
- Kalıcı depolama: Workspace içeriğinin bağlı volume'lerde tutulması, veriyi tekrar tekrar S3'ten çekme ihtiyacını azaltarak başlangıç süresini iyileştirebilir ve ağ kullanımını düşürebilir
- Performans değerlendirmeleri: Yüksek throughput'lu volume'lerin workspace'ler arasında paylaşılması I/O performansını iyileştirebilir, ancak etkili quota uygulama, gecikme yönetimi ve ölçeklenebilirliği garanti etme gibi kaygılar da doğurur
- Micro VM deneyinden çıkarılan dersler
- Micro VM'ler nihayetinde ana altyapı çözümü olmadı, ancak deneyler değerli içgörüler sağladı
- Geliştirme ortamları için tam workspace yedekleme ile çalışma zamanı durumunu durdurup devam ettirme deneyimi beğenildi
- İlk kez Kubernetes'ten uzaklaşma düşüncesi doğdu. KVM ve uVM'leri pod'lara entegre etme çabalarının ardından Kubernetes dışındaki seçenekler keşfedilmeye başlandı
- Kararlı başlangıç performansı, kararlı workspace'ler (veri kaybını önleme) ve optimum makine kullanımı arasında denge kurmak için depolamanın yine temel unsur olduğu görüldü
Kubernetes, geliştirme ortamı platformu olarak oldukça zorludur
- Daha önce de belirtildiği gibi, geliştirme ortamları için bu ortamlara özgü durum yapısını dikkate alan sistemler gerekir
- Geliştiricilere üretken olmaları için gerekli yetkileri verirken güvenli sınırlar da sağlanmalıdır
- Tüm bunlar düşük operasyonel ek yükle ve güvenlikten taviz vermeden yapılmalıdır
- Bugün bunların hepsini Kubernetes ile başarmak mümkün olsa da maliyeti oldukça yüksektir
- Uygulama iş yükleri ile sistem iş yükleri arasındaki farkı zor yoldan öğrendiler
- Kubernetes inanılmaz derecede harika bir teknolojidir
- Tutkulu bir topluluğun desteğiyle gerçekten zengin bir ekosistem oluşturmuştur
- Uygulama iş yükleri çalıştırıyorsanız Kubernetes hâlâ iyi bir seçimdir
- Ancak geliştirme ortamları gibi sistem iş yüklerinde Kubernetes, güvenlik ve operasyonel ek yük açısından büyük zorluklar yaratır
- Micro VM'ler ve net kaynak bütçeleri yardımcı olur, ancak bu kez maliyet daha baskın hale gelir
- Bu nedenle yıllarca geliştirme ortamlarını Kubernetes platformuna etkili biçimde tersine uyarlayıp zorla oturttuktan sonra, bir adım geri çekilip geleceğin geliştirme mimarisinin nasıl olması gerektiğini düşünmeye başladılar
- Ocak 2024'te bunu inşa etmeye başladılar ve Ekim'de Gitpod Flex'i piyasaya sürdüler
- İnternet ölçeğinde geliştirme ortamlarını güvenli şekilde çalıştırmaya dair 6 yılı aşkın, çok zor kazanılmış içgörü mimarinin temeline işlendi
Geliştirme ortamlarının geleceği
- Gitpod Flex'te, Kubernetes'in temel bazı yönleri — yani kontrol teorisinin serbest uygulanışı ve deklaratif API'ler — korunurken mimari sadeleştirildi ve güvenlik temeli güçlendirildi
- Geliştirme ortamlarını orkestre etmek için Kubernetes'ten güçlü biçimde ilham alan bir control plane kullanılıyor
- Geliştirme ortamlarına özel gerekli soyutlama katmanları eklendi ve gereksiz altyapı karmaşıklığının büyük bölümü kaldırıldı
- Tüm bunlar yapılırken zero-trust güvenlik en yüksek öncelik oldu
- Bu yeni mimari sayesinde devcontainer'lar sorunsuz biçimde entegre edilebildi
- Ayrıca masaüstünde geliştirme ortamı çalıştırma imkânı da açıldı
- Artık Kubernetes platformunun ağır yükü taşınmadığı için Gitpod Flex, 3 dakikadan kısa sürede self-hosted olarak dağıtılabiliyor ve istenen sayıda bölgede kurulabiliyor
- Bu da uyumluluk üzerinde daha ayrıntılı kontrol ve organizasyon sınırları ile domain'leri modellemede daha fazla esneklik sağlıyor
(Aslında ayrı bir yazıydı, ama birlikte vermek daha iyi olur diye buraya eklenmiş.)
Gitpod Flex
- Zero-trust geliştirme ortamları için ilk otomasyon platformu
- Laptop, bulut ve on-premises üzerinde çalışacak şekilde tasarlandı; kaynak kodunu, verileri ve fikri mülkiyeti özel ağ içinde tutuyor
- Geliştirme ortamlarından başlayarak yazılım geliştirme yaşam döngüsünü otomatikleştirmek için yapı taşları sunuyor
- Automations
- Repository veya API üzerinden tanımlanan programlanabilir işler ve servisler
- Geliştiricilerin sorunları kendi başlarına çözmesine yardımcı olurken, geliştirici verimliliği ekiplerinin geliştirme ortamı iyileştirmelerini merkezi olarak yönetmesini sağlar
- Basit script çalıştırmanın ötesine geçer
- Veritabanı hazırlama ve seed etme, geliştirici iş akışlarını özelleştirme, geçici cluster çalıştırma, LLM tabanlı agent iş akışları kurma, küresel/bölgesel güvenlik ve uyumluluğu merkezi olarak uygulama gibi işleri yapabilir
- Zero-trust environments
- Tüm aktörler ve servisler için 'asla güvenme, her zaman doğrula' yaklaşımını benimser
- Kötü niyetli aktörleri tamamen engeller, saldırı yüzeyini büyük ölçüde azaltır, zararlı yazılım veya kod sızıntısı riskini düşürür
- Sürekli değerlendirme ve açık doğrulama, doğrulanmış kurumsal düzey şifreleme, ayrıntılı erişim kontrolü, ağ üzerinde tam denetim ve eksiksiz denetim kayıtları içerir
- Kaynak kodunun, verilerin ve fikri mülkiyetin özel ağ içinde kalması en kritik noktadır
- Gitpod Desktop
- Yerel geliştirme ortamlarını standartlaştırıp otomatikleştirebilir
- İlk destek Apple Silicon ile başlıyor
- Sıfıra yakın gecikme, geliştirme için Docker Desktop'a daha hızlı, daha hafif ve daha basit bir alternatif, yerel hesaplama ile maliyet optimizasyonu ve bulut ya da uç nokta kesintilerine karşı felaket kurtarma desteği sunar
- Development Container desteği
- Dev Container spesifikasyonunu tam olarak entegre eder
- Mevcut Dev Container yapılandırmaları değişiklik yapmadan kullanılabilir
- VS Code ve diğer desteklenen araçlarla uyumluluk sağlar
- İster yerelde ister bulutta tutarlı şekilde çalışmayı mümkün kılar
- Dev Container standardının benimsenmesi, geliştirme ortamlarını tanımlamayı, paylaşmayı ve yönetmeyi kolaylaştırır
Önümüzdeki 10 yılın yazılım geliştirme otomasyonunun temeli olacak
- Geliştirme ortamlarını fazla dar çerçevede düşünmüşüz
- Geliştirme ortamı, IDE, bağımlılıklar ve araçların ötesinde; yazılımın üretildiği temel alandır
- Kod prototipleme, insan ve makine tarafından şekillendirme, test etme, refactor etme, derleme, paketleme, imzalama ve dağıtım burada gerçekleşir
- Geliştirme bağlamına, iş akışlarına ve içgörülere eşsiz erişim sağlayarak diğer geliştirme platformlarından ayrışan yetenekler sunar
- Ürünün vizyonu
- Sürekli entegrasyonun (CI) geliştirme ortamıyla birleşmesi
- Yazılım geliştirme için System of record rolü
- Yeni nesil geliştirici araçları için bir platform olması
- Amaç yalnızca kodlama pratiklerini iyileştirmek değil; startup'lardan Fortune 50 şirketlerine kadar kurumların önümüzdeki 10 yılda ölçeklenip başarıya ulaşması için en hızlı ve en güvenli yolu inşa etmek
3 yorum
Güvenliği bahane edip 8 GB bellek özellikli sanal masaüstünü zorla kullandırtan yerli şirketler. Acı bir durum.
Kubernetes konusunda yetkin insan bulmak zaten zorken, burada alternatif olarak sunulan şeyleri anlayıp denemeye çalışacak insanları bulmanın daha da zor olacağını düşünüyorum.
Hacker News görüşleri
Geliştiriciler, kullandıkları geliştirme cihazının sahibi olmalı. Tutarlı bir ortam gerekiyorsa, geliştirici kendi cihazına sahip olmalı ve kendisine kararlı VM imajları sağlanmalı. Geliştirme ortamını uzak bir ana makineye taşıma girişimleri çoğunlukla başarısız olur. Geliştiriciye uygun donanım sağlamak, uzak kaynaklardan daha maliyet etkindir. Yerel stack’in çalıştırılması desteklenmeli; bu da container’lar aracılığıyla tutarlılığı korumaya yardımcı olur. Yerel ortamda veri üreten araçlara ihtiyaç vardır ve bu otomatikleştirilebilir. Veri yönetiminin bazı dezavantajları olsa da, çoğu şirkette takımın uygulama gücü kaynak kodundan daha önemlidir.
Kubernetes’i production workload’larda kullanmak ayrı bir konu; burada anlatılan, bulutta geliştirme ortamının nasıl kurulacağı. Kubernetes’in karmaşık mühendislik ödünleşimlerine dair ilginç bir yazı.
Kubernetes’in sorunları ve denenen çözümler anlatılıyor, ancak sonunda seçilen alternatif yeterince açıklanmıyor. Gitpod Flex adlı yeni bir çözümden bahsediliyor ama bununla ilgili pek bilgi yok.
Kubernetes stateless workload’lar için uygundur, ancak stateful durumlarda LXC daha uygun olabilir. LXC, K8S benzeri şekilde cluster edilebilir ve araçları data plane’e açar. VM’e benzer şekilde sistem instance’ları sunar ve Docker container’larına benzer performans sağlar. Deklaratif bir sözdizimi kullanır ve Kubernetes cluster’ının temel katmanı olarak kullanılabilir.
Bir CI çözümü kurarken Kubernetes’i seçmek, sorunun tam olarak anlaşılmadığını gösterir. Güvenlik amacıyla Firecracker gibi araçlar kullanılmalı.
Kubernetes geliştirme ortamları için uygun değil. Geliştirme ortamları her zaman değişen bir duruma sahiptir. Bulut geliştirme ortamlarına duyulan ihtiyacı anlamıyorum. Containerize edilmiş uygulamaların amacı, takımlar arasında geliştirme ortamı senkronizasyonundan kaçınmaktır.
Kubernetes makalesi, düşük gecikmeli ve yüksek gecikmeli iş akışlarının birleşimini tek kullanım senaryosu olarak anıyor. Gitpod’un sorununa Kubernetes’i dahil etmeyi gerekçelendirmek zor.
Gitpod’a benzer bir proje üzerinde çalıştım ve Kubernetes’in yerine micro VM kullanılmasını anlamıyorum. Kubernetes harici container’ları orkestre edebilir ve micro VM çalıştırmak için kullanılabilir. En büyük sorun storage ile ilgili meseleler.
Kubernetes üzerinde geliştirme ortamı kurmak israf. Ürün müşterinin altyapısında self-hosted olarak çalışıyorsa, debugging ve destek zorlaşıyor. Ağ, bellek, compute ve storage sorunlarını mühendislere görünür kılmak daha etkili. Kubernetes büyük takımlar için bir upgrade.