etcd v3.7.0 Çıktı: RangeStream Devri ve v2store’a Elveda
Bence, Kubernetes’in kalbinde atan şu küçük ama huysuz veritabanı var ya — etcd — sonunda v3.7.0 ile yeni bir sürüm yayınladı. Açık konuşayım, bu sürümü epeydir bekliyordum (ciddiyim). Neden mi? Birazdan geliriz ona,. Önce şunu söyleyeyim: prod ortamında büyük Kubernetes cluster’ları yönetiyorsanız, bu sürüm size baya nefes aldırıyor.
Lafı gevelemeden konuya girelim.
Neden bu sürüm önemli?
Araya gireyim: etcd v3.7, öyle sıradan bir minör release değil. İçinde yıllardır beklenen bir parça var: RangeStream. Bunun yanında v2 store’un son kırıntıları da temizlenmiş, protobuf tarafı elden geçirilmiş, bir de Kubernetes control plane tarafında CPU tüketimini aşağı çeken birkaç performans dokunuşu eklenmiş (buna dikkat edin). Kısacası, sessiz ama iş gören bir paket.
Sahadan konuşayım: Kubernetes cluster’ı büyüdükçe etcd’nın yüzü düşüyor. Hele bir de 5000+ node ya da on binlerce pod olan ortamlarda, bellek kullanımı ve latency insanın sınırını bozabiliyor. Büyük LIST istekleri — mesela tüm pod’ları çekmek — hem API server’ı hem de etcd’yi yoruyor, bazen de işin üçü garip gecikmelere gidiyor. Neden önemli bu? İşte v3.7 tam buraya dokunuyor.
Kısa bir not düşeyim buraya.
“Kubernetes ve etcd geliştirme süreçlerinin 2023’te birleşmesi, artık meyvelerini vermeye başladı. RangeStream’in Kubernetes v1.37 ile aynı takvimde kullanılabilir olması bunun en somut örneği.”
RangeStream: Büyük sorgulara akış tabanlı çözüm
Doğrusu, Şimdi işin güzel tarafına gelelim. v3.6 ve öncesinde büyük result set’lerle uğraşmak biraz sancılıydı, hatta bazen gereksiz yere can sıkıyordu; etcd sonucu komple belleğe yükler, sonra tek seferde gönderirdi. Yanı 50 bin key döndüren bir range request attığınızda hem sunucu hem client tarafında RAM şişerdi, latency de bazen 200ms olurdu bazen 3 saniye, insan neye uğradığını şaşırırdı.
Peki RangeStream ne yapıyor?
Adı üstünde: veriyi stream ediyor. Sonuçları chunk chunk yolluyor, client da geldikçe işliyor. Böyle olunca iş biraz toparlanıyor: (ben de ilk duyduğumda şaşırmıştım)
- Bellek kullanımı daha öngörülebilir hâle geliyor (chunk ne kadarsa RAM de o kadar gidiyor)
- İlk byte’ın gelme süresi (TTFB) ciddi biçimde düşüyor
- Büyük list operasyonlarında etcd sunucusu daha az tıkanıyor
Bir de şu var: Kubernetes v1.37’de EtcdRangeStream feature gate’ını açtığınızda kube-apiserver bunu doğrudan kullanmaya başlıyor. Yanı “büyük cluster’da kubectl get pods -A attım, apiserver kilitlendi” senaryosu yavaş yavaş tarih oluyor — tabi feature gate’i açarsanız. Evet, küçük bir detay gibi dürüyor ama kilit nokta orası.
etcdctl ile nasıl deneyebilirsiniz?
Şahsen, Basit bir örnek üzerinden gidelim, çünkü teoriyi uzatınca olay dağılıyor:
# Klasik range request
etcdctl get --prefix /registry/pods/
# v3.7 ile stream mode
etcdctl get --prefix /registry/pods/ --stream
Farkı özellikle 10 binin üzerinde key olan prefix’lerde net görürsünüz. gRPC tarafında da benzer bir API var; uygulama geliştiriyorsanız SDK dokümantasyonuna bakmanız iyi olur, çünkü orada ufak ama önemli nüanslar çıkabiliyor.
Performans iyileştirmeleri: Sessiz kahramanlar
RangeStream göz önüne çıkıyor ama v3.7’nın asıl işi arka tarafta dönüyor bence. Bak şimdi, birkaç tanesini tek tek açalım; çünkü burada küçük görünen şeyler pratikte baya fark ettiriyor. Deutsche Telekom OpenAI ile Telekomu Baştan Kuruyor yazımızda bu konuya da değinmiştik.
Keys-only range optimize etmeu
Bu değişiklik benim özellikle hoşuma gitti. Önceden --keys-only ile sorgu attığınızda bile etcd, bbolt backend’inden tüm serialized değerleri okuyordu; yanı “sadece key ver” deseniz bile arkada value’lar da çekiliyordu. Garipti biraz, hatta açık konuşayım gereksizdi (kendi tecrübem) Daha fazla bilgi için Visual Studio Haziran Güncellemesi: Kullanım, Güven ve C++ Ajanı yazımıza bakabilirsiniz.
v3.7 ile artık keys-only istekler doğrudan in-memory index’ten karşılanıyor. bbolt’a hiç dokunulmuyor. Tek istisna şu: sort target VALUE işe değerleri yüklemek zorunda kalıyor. Ama dürüst olayım, çoğu senaryoda buna ihtiyaç yok zaten. Daha fazla bilgi için Agent Harness: Kıskacı Büyütmek ve Yetenekleri Kuşanmak yazımıza bakabilirsiniz.
Sonuç ne? Mesela de Kubernetes gibi çok sayıda küçük key üzerinde çalışan sistemlerde CPU ve disk I/O belirgin biçimde düşüyor.
Lease iyileştirmeleri
Lease sistemi de epey elden geçmiş. Daha hızlı davranıyor, daha az naz yapıyor diyelim. Detaya fazla girmeyeyim. Şunu söyleyeyim: node churn’ün yüksek olduğu ortamlarda (autoscaling’i sert çalışan cluster’lar mesela) lease expiration kaynaklı karmaşa azalacak gibi dürüyor. Bu konuyla ilgili CodeQL 2.26.0: Kotlin 2.4 Desteği ve AI Prompt Injection Taraması yazımıza da göz atmanızı tavsiye ederim. Agent Skills for .NET Kararlı Sürümde: Uzmanlık Artık Paketli yazımızda bu konuya da değinmiştik.
Tam da öyle.
v2store’a elveda
Bunu görünce ben içimden “nihayet” dedim. etcd v2 API’si zaten 2020’de deprecate edilmişti ama v2store denen legacy depolama katmanı boot süreçlerinde hâlâ dolaşıyordu. Neden? Uzun hikâye; biraz tarih kokuyor, biraz da geriye dönük uyumluluk borcu var işin içinde (ben de ilk duyduğumda şaşırmıştım)
v3.7 ile etcd artık bayağı v3store üzerinden boot ediyor. Pratikte ne değişiyor derseniz:
- Kod tabanı daha temiz kalıyor — bakım yükü azalıyor (bence en önemlisi)
- Boot süreleri toparlanıyor
- v2 API’ye bağlı eski araçlar artık çalışmayacak (ama zaten yıllardır bırakmış olmanız gerekiyordu)
Protobuf overhaul
Bir şey dikkatimi çekti: Ha bu arada arkada büyük bir protobuf temizliği de yapılmış durumda. Eski ve artık düzgün şekilde maintain edilmeyen protobuf kütüphaneleri (gogo/protobuf başta olmak üzere) yerine güncel ve desteklenen seçenekler gelmiş. Kullanıcı olarak bunu hemen hissetmezsiniz belki ama uzun vadede güvenlik ve performans tarafında iyi bir yatırım bu.
Türkiye’deki kurumsal ekipler için ne anlama geliyor?
Açık konuşayım, Biraz da yerel taraftan bakalım şimdi. Türkiye’de kurumsal Kubernetes kabul etmesi artıyor ama etcd tarafını konuşan kişi sayısı hâlâ az gibi geliyor bana. Sahada gördüğüm kadarıyla çoğu ekip AKS ya da benzeri managed servisleri kullanıyor ve etcd’yi “kara kutu” diye bırakıyor; belli ölçüde mantıklı aslında.
Ama şöyle bir durum var: yönetilen bile olsa cluster büyüdüğünde etcd’nın davranışını anlamazsanız gereksiz yere büyük node type’lar seçip para yakabiliyorsunuz. Ben AKS’te 3 node’lük control plane’i olan bir müşteride sadece etcd request pattern’lerini düzelterek node type’ı bir alt kademeye indirtmiştim; aylık maliyette gözle görülür fark çıkmıştı, şaşırmıştık açıkçası.
Ne zaman upgrade etmeli?
Kendi cluster’ınızı yönetiyorsanız (bare metal, kubeadm ya da self-managed etcd):
- Küçük ekip / 3-5 node cluster: Acele etmeyin derim. Bir ay bekleyin, patch sürümlerine bakın; v3.7.1 veya v3.7.2 çıkınca geçmek daha rahat olabilir.
- Enterprise / büyük cluster: Test ortamınızda bugün deneyin bence. Bilhassa CPU kullanımını ölçün, v3.6 ile kıyaslayın; fark görürseniz staging’e alın, bir sprint izleyin, sonra prod’a geçin.
- AKS / EKS / GKE kullanıcısı: Sizin yapacağınız şey sınırlı; cloud provider ne verirse önü kullanıyorsunuz zaten. Ama v1.37 Kubernetes’e geçince RangeStream feature gate’ını mutlaka test edin.
v3.6 → v3.7 kısa karşılaştırma
| Özellik | v3.6 | v3..7 |
|---|---|---|
| Büyük range request’ler | Tam buffer, öngörülemez latency | ? RangeStream ile chunk chunk |
| ? Keys-only sorgular | bbolt’tan tüm değer okunuyor | Sadece in-memory index |
| ? Boot süreci | ?v2store + v3store | Sadece ?v? store?Protobuf?>gogo/protobuf (legacy)Güncel?, destekli kütüphaneler?>?bbolt?>v1?.4.x?>v1?.5?.1?>?raft?>v?3?.6.x?>v?3?.7?.0?>?Upgrade sürecinde dikkat edilecekler?Şimdi can alıcı noktaya geldik.? etdc upgrade’i her zaman biraz streslidir.? Yanlış yaparsanız cluster’?ınız komple çöker.? O yüzden şu adımları atlamayın?:?Backup alın.? Ama gerçekten alın.?etcdctl snapshot saveile.? Hem de test edin — restore çalışıyor mu diye.?Node’?ları tek tek upgrade edin.?Rolling upgrade — hepsini birden yeniden başlatmak intihar.?Health check yapın.?Her node’dan sonraetcdctl endpoint healthveetcdctl endpoint statusile durumu kontrol edin.?Bu sürümde v?store gitti — hâlâ v? API kullanan bir script varsa bulun ve migrate edin.?Kubernetes control plane’i self-manage ediyorsanız, konuyla bağlantılı olarakNode Readiness Controller: Kubernetes’te Ready’nın Ötesi\ yazıma da göz atmanızı öneririm.? etdc sağlığı ile node readiness arasındaki ilişki bazen gözden kaçıyor.?FinOps açısından bir notSık gözlemlediğim bir yanlış:? ekipler etdc’yii “sadece ?MB RAM harcıyor işte” diye görüyor.? Halbuki büyük cluster’larda etdc’nın yarattığı IOPS baskısı disk maliyetlerini uçurabiliyor.? Mesela Azure’da premium SSD kullanan managed disk’lerde bu farkı fatura kalemlerinde görürsünüz.v?37’nın getirdiği keys-only optimize etmeu. RangeStream bu IOPS baskısını da azaltacak.? Yanı sadece performans değil maliyet açısından da anlamlı bir sürüm bu.? FinOps tarafına ilgi duyanlar içinAzure IaaS Maliyet Optimizasyonu: Sahadan FinOps Notları\ yazımda benzer konuları uzun uzun anlatmıştım.Kişisel değerlendirmemAçık konuşayım:? RangeStream etdc tarafında son ? yılın en önemli özelliği bence.? Kubernetes’in ölçek problemlerini çözmek için yıllardır api-server tarafında yamalar atılıyor (?watch cache?, priority & fairness vb.) ama sorunun kaynağı hep etdc katmanındaydı.? Şimdi tam da doğru yerden ele alınmış.Evet eleştirim var mı? Var tabiî.? RangeStream’in Kubernetes tarafında feature gate arkasında olması prod ortamlarda benimseme sürecini yavaşlatacak.? En az bir-iki minör sürüm daha bekleyeceğiz stable olması için.? Ayrıca dokümantasyon hâlâ biraz zayıf — özellikle client-side implementation örnekleri az.? Umarım topluluk bunu doldurur.>Sıkça Sorulan Sorularetcd v3.7’ye geçmek için v3.6’dan mı başlamalıyım?Evet, başlamalısın. etcd, minör sürümler arasında sadece bir adım atlamayı destekliyor. Yanı v3.5 veya daha eskisindeysen, önce v3.6’ya çık ve her şeyin stabil olduğundan emin ol — ondan sonra v3.7’ye geç. Direkt atlama yaparsan veri bütünlüğü ve raft protokolü tarafında ciddi sorunlarla karşılaşabilirsin. Bence bu adımı es geçmek gereksiz risk almak demek.RangeStream, mevcut istemcilerimi kırar mı?Hayır, kırmıyor. RangeStream aslında yeni bir gRPC RPC’si — mevcut Range API’sının yerini almıyor. Eski istemcilerin eskisi gibi çalışmaya devam ediyor. Sadece bu yeni özellikten faydalanmak istiyorsan istemci kodunu güncellemen gerekiyor, o kadar.AKS veya EKS kullanıyorum, benim için değişen ne var?Kendi deneyimimden konuşuyorum, Kısa vadede pek bir şey değişmiyor açıkçası — cloud provider’ın hangi Kubernetes sürümünü destekliyorsa, onun altındaki etcd sürümünü de o yönetiyor zaten. Ama Kubernetes v1.37 kullanılabilir olduğunda EtcdRangeStream feature gate’ını test etmeni öneririm. Managed servislerde bu feature gate’lerin açılması genelde 1-2 sürüm gecikiyor, bunu aklında bulundur.v2 API kullanan eski script’lerim var, ne yapmalıyım?Hemen migrate et, bekletme. v3.7 ile birlikte v2store tamamen kaldırıldı — yanı v2 API’ye bağımlı araçlar bu sürümde çalışmıyor. etcdctl v3 komutlarına geç, uygulamalarında etcd v3 SDK’sını kullan. Peki bunu neden söylüyorum? Nasıl yapacağını bilmiyorsan etcd resmî dokümantasyonundakigeçiş kılavuzunabakabilirsin.Bu sürümü hemen prod’a almalı mıyım?Bakın, Önermem açıkçası. Majör özellikler içeren minör sürümlerde ilk 4-8 hafta patch beklemeyi tercih ederim. Tecrübeme göre en mantıklısı şu: v3.7.1 veya v3.7.2 çıktığında, community feedback’ını de gördükten sonra önce staging’e al. En az bir sprint gözlemle, sonra prod’a taşı. Bu tavsiye aslında tüm kritik infra bileşenleri için geçerli.Kaynaklar ve İleri OkumaKubernetes Blog: Announcing etcd v3.7.0etcd v3.7 Resmî Dokümantasyonuetcd v3.7.0 GitHub Release Notlarıbbolt v1.5.1 Release Notları |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder