Geçen hafta sabah kahvemi içerken SIG-Etcd’nın duyurusuna denk geldim: etcd v3.7.0-beta.0 sonunda çıkmış. Bir Kubernetes operatörü olarak yıllardır beklediğim o özellik, yani RangeStream, nihayet içeri girmiş. Hemen lab ortamında kurcalamaya başladım, çünkü insan böyle şeyleri görür görmez duramıyor; ilk hissim de netti aslında: güzel tarafı var, ama birkaç yer baya kaşınıyor.
Ne yalan söyleyeyim, Bu yazıda hem yeni gelen şeylere bakacağız, hem de sahada başınıza çıkabilecek dertleri konuşacağız (evet, doğru duydunuz). Açık konuşayım: 3.7 bana biraz “geçiş sürümü” gibi geldi. Heves veriyor, tamam, ama elinizi cebinize atıp bir daha düşünmenizi de istiyor.
etcd Neden Bu Kadar Önemli? Kısaca Hatırlatma
Bilen için tekrar olacak, bilmeyen içinse işin kalbi burası. etcd, Kubernetes’in hafızası gibi çalışıyor; pod tanımları, secret’lar, configmap’ler, node durumları, ne varsa orada duruyor. Yani etcd sendeleyince Kubernetes de sendelemeye başlıyor, bu kadar net.
Logosoft’ta geçen yıl bir bankacılık müşterisinde etcd disk I/O darboğazına girince tam 4 saat boyunca API server timeout yedik. O günden beri etcd’nın her sürümüne daha (belki yanilıyorum ama) farklı bakıyorum; çünkü bu component sessizken kimse fark etmiyor. Bir aksayınca bütün cluster’ın morali bozuluyor, sonra da herkes birbirine bakıyor.
İşin aslı şu: Türkiye’deki çoğu kurumsal Kubernetes kullanıcısı managed hizmetlere — AKS, EKS, GKE — yaslanıyor. Yani etcd’yi doğrudan yönetmiyorlar. Ama on-prem k8s yapan ekipler, OpenShift ya da Rancher kullananlar veya kubeadm ile kendi cluster’ını ayağa kaldıranlar için etcd sürüm yönetimi öyle kenarda köşede kalacak bir konu değil.
Şimdi gelelim işin can alıcı noktasına.
RangeStream: Asıl Yıldız Bu
Şunu fark ettim: Gelelim can alıcı yere. RangeStream, etcd’nın büyük sonuç setleriyle uğraşma şeklini değiştiriyor. Hani ne farkı var diyorsunuz, değil mi? 3.6 ve öncesinde bir Range isteği attığınızda — mesela 50 bin pod’un listesini çekmeye kalktığınızda — client tarafı tüm cevabı bekliyordu; sonra latency uzuyor, memory şişiyor, bazen de OOM pat diye geliyor.
Yeni RangeStream RPC işe sonucu chunk chunk getiriyor. Parça parça yani. Streaming yaklaşımı bu; gRPC’nın server-side streaming tarafını ilk kez adam akıllı kullanan etcd özelliği demek bence yanlış olmaz.
Pratikte Ne Değişiyor?
Şöyle düşünün: tek bir prefix altında 100.000 anahtarınız var diyelim. Eski yöntemle iş biraz kabalaşıyordu:
# Eski yontem (v3.6 ve öncesi)
etcdctl get /kubernetes/pods/ --prefix
# Cluster patlayana kadar bekleyin...Açık konuşayım, Yeni yöntemle tablo farklı: Daha fazla bilgi için C# 16 Unsafe Yeniden Doğuyor: Bellek Güvenliğinde Yeni Çağ yazımıza bakabilirsiniz. Visual Studio Plan Agent: Önce Düşün, Sonra Kodla yazımızda bu konuya da değinmiştik.
# Yeni RangeStream (v3.7+)
etcdctl get /kubernetes/pods/ --prefix --stream --chunk-size=1000
# Parca parca akiyor, memory stabilBu sadece etcdctl için önemli değil tabi. Asıl mesele kube-apiserver’ın bunu nasıl kullanacağı. Sharded watch ile birlikte düşününce — ki bu konuyu daha önce Kubernetes v1.36 Server-Side Sharded Watch: Saha Notları yazımda detaylıca işlemiştim — büyük cluster’larda API server’ın bellek profili ciddi şekilde toparlanabilir. Daha fazla bilgi için npm Staged Publishing GA: Tedarik Zinciri Artık Daha Güvenli yazımıza bakabilirsiniz.
Bir Anekdot: Jeffrey Ying’in Hikâyesi
RangeStream’in büyük kısmını Google’da çalışan görece yeni bir contributor olan Jeffrey Ying yazmış. Bu ayrıntı hoşuma gitti açıkçası. Çünkü etcd gibi kritik bir projede yeni gelen birinin böyle bir etki bırakabilmesi açık kaynak tarafının en güzel taraflarından biri; kıdemden çok çözüm konuşuyor burada (yanlış duymadınız) Daha fazla bilgi için PowerShell macOS’ta Notarize Edildi: Gatekeeper Çilesi Bitti yazımıza bakabilirsiniz.
“Üretimde Kubernetes ile yaşadığımız darboğazı çözmek harika bir fırsattı. Yeni bir katkıcı olarak etcd’ye atlamak biraz öğrenme eğrisi gerektirdi ama topluluk inanılmaz sıcakkanlı.” — Jeffrey Ying
v2store’a Veda: Temizlik Vakti
Bu sürümün en sessiz ama en etkili değişikliği burada saklı duruyor olabilir. v2store’un son kırıntıları da temizlenmiş; yani artık etcd tamamen v3store üstünde dönüyor.
Neler gitmiş? Daha fazla bilgi için .NET 11 Process API: Deadlock’suz Süreç Yönetimi Geldi yazımıza bakabilirsiniz.
- Discovery v2 — eski cluster bootstrap mekanizması
- v2 client API — hâlâ kullanan varsa pek hoş haber değil
- v2 request handler’ları — HTTP üzerinden gelen eski istekler — ciddi fark yaratıyor
- Bir sürü deprecated experimental flag
Lafı gevelemeden söyleyeyim: kulağa basit geliyor ama hiç öyle değil. 2017-2018 döneminde yazılmış eski operatörler, dağıtım script’leri ya da bazı CI/CD pipeline’ları hâlâ v2 API’ye dokunuyor olabilir; geçen ay bir e-ticaret müşterisinde tam da böyle oldu — 2019’dan kalma bir backup script’i v2 endpoint’ine vuruyormuş, kimsenin haberi yoktu bile.
Kurumsal Yapılar İçin Tavsiyem
Kendi deneyimimden konuşuyorum, Türkiye’deki büyük şirketler — özellikle finans, telekom ve kamu tarafındakiler — production’a yamalı geçişlerde tarihsel olarak yavaş davranıyor. Bu bazen iyi bile oluyor aslında; acele edilmeyince saçma sürprizler azalıyor ama iş fazla uzayınca da başka dert çıkıyor.
Kısa bir not düşeyim buraya.
Evet, hâlâ 3.4 kullanan müşterilerim var. “Biz dokunmuyoruz ki çalışıyor” cümlesini duyunca insanın yüzü biraz düşüyor ama gerçek bu işte.
Bence sorun şu noktada patlayacak: (bizzat test ettim)
- v3.4’tan direkt v3.7’ye geçemezsiniz — sürüm atlamak yok — bunu es geçmeyin
- Önce 3.4 → 3.5 → 3.6 → 3.7 yolunu izlemeniz gerekiyor — bunu es geçmeyin
- Her adımda v2 bağımlılıklarını temizlemek zorundasınız
3.4 Resmen Tarihte Kaldı
Şöyle söyleyeyim, SIG-Etcd’nın community support politikasına göre normalde sadece son iki minor sürüm destekleniyor zaten falan derken konu hemen netleşiyor: şu an v3.6 (ben de ilk duyduğumda şaşırmıştım). V3.5 destek içinde sayılıyor.
Hani, Soru şu: peki v3.4? O iş bitti sayılır; 15 Mayıs 2026’dan beri EOL durumunda ve belki son bir güvenlik yaması daha görürsünüz, o kadar.
| endtable td? no need to alter because keep exact html? |
|---|
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
| endtable td? no need to alter because keep exact html? |
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.
