Kubernetes’te Doğrulama Artık Kod Değil: v1.36’da Ne Değişti?
Kubernetes tarafında bazen öyle bir değişiklik geliyor ki, ilk anda “tamam ya, fena değil” deyip geçiyorsunuz. Sonra biraz eşeleyince anlıyorsunuz; mesele performans değil, asıl dert bakım yükü (ki bu çoğu kişinin gözünden kaçıyor). Declarative Validation için de hikâye tam olarak bu. v1.36 ile artık GA öldü ve açık konuşayım, bu haber sadece çekirdek Kubernetes katkıcılarını değil, API tasarlayan herkesi ilgilendiriyor.
Ben bunu ilk okuduğumda aklıma direkt şu geldi: yıllardır elle yazılmış doğrulama kodlarıyla uğraşan ekipler için küçük görünen. Etkisi baya büyük bir kırılma. 2019’da bir finans müşterisinde benzer bir problem yaşamıştık; form alanları çoğaldıkça validation mantığı da çorap söküğü gibi büyümüştü. Her yeni kural yeni bir if bloğu demekti. Bir süre sonra kimse hangi kuralın nerede çalıştığını tam hatırlamıyordu… işte Kubernetes’in kaçmak istediği yer de tam burası.
Neden Bu Geçiş Gerekliydi?
İşin aslı şu: handwritten validation ilk başta gayet masum dürüyor. Küçük bir alan için iki satır kontrol yazarsınız, biter gider. Ama Kubernetes gibi yüzlerce kaynak tipi olan bir sistemde o iki satır çok hızlı şekilde binlerce satıra dönüşüyor. Ben AZ-305’e hazırlanırken mimarı kararların “bugün iyi görünen ama yarın teknik borca dönen” tarafını tekrar tekrar düşünmüştüm; burada da aynı hikâye var (kendi tecrübem)
Evet, doğru duydunuz.
Kod tabanı büyüdükçe tutarlılık bozuluyor. Bir resource için minimum değer ayrı yerde kontrol ediliyor, başka resource için farklı biçimde yapılıyor, üçüncü yerde işe hata mesajı bile başka çıkıyor. Kullanıcı açısından sonuç net: API davranışı tahmin edilemez hâle geliyor. E tabi bunun dokümantasyon tarafı da sıkıntılı;. Kurallar source code içinde gizlenince tooling bunları rahat okuyamıyor — dürüst olayım, biraz hayal kırıklığı —
Geçen yıl İzmir’deki bir telekom projesinde buna benzer bir düzensizlik gördüm. Aynı işi yapan üç servis vardı. Her biri kendi validasyon stilini yazmıştı; biri JSON schema kullanıyor, biri custom middleware ile gidiyor, biri de doğrudan handler içinde patlatıyordu. Dışarıdan bakınca hepsi “çalışıyor” gibiydi ama operasyon ekibi loglara bakarken resmen dedektiflik yapıyordu.
Şahsen, Kubernetes topluluğunun burada verdiği karar bana baya mantıklı geliyor: doğrulamayı kodun içine gömmek yerine deklaratif hâle getirmek hem sürdürülebilirliği artırıyor hem de ileride başka araçlarla konuşmayı kolaylaştırıyor. Kağıt üstünde süper değil mi? Pratikte göreceğiz tabiî… ama yön doğru.
validation-gen Nasıl Çalışıyor?
Sistemin kalbinde validation-gen var. Mantık basit: sız type tanımlarında +k8s marker tag’lerini yazıyorsunuz, generator da bundan Go validation fonksiyonlarını üretiyor. Deep copy ya da conversion generator’larına alışkın olanlar için çok yabancı gelmez bu yaklaşım.
Bana göre burada en kıymetli nokta şu: insan eliyle yazılan tekrar eden kontrol blokları azalıyor. Tek tek if/else kovalamak yerine modelin kendisine bakıyorsunuz. “bu alan ne bekliyor?” sorusunun cevabını orada görüyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Bu da review süreçlerini rahatlatıyor — özellikle büyük ekiplerde ciddi fark yaratır.
// Basit örnek fikir
type DemoSpec struct {
// +k8s:required
// +k8s:minimum=1
Replicas int32 `json:"replicas"`
// +k8s:maxLength=16
Name string `json:"name"`
}Bu örnekte doğrulama mantığı ayrı bir dosyada kaybolmuyor; tipin yanında dürüyor (inanın bana). Açık konuşayım, küçük ekiplerde bu düzenlilik hayat kurtarıyor çünkü onboarding süresi düşüyor. Büyük enterprise yapılarda işe asıl kazanç denetlenebilirlik oluyor; compliance ekipleri de mutlu oluyor (şaşırtıcı ama gerçek). Kuralın izi daha net sürülüyor.
Peki bunun eksik yanı yok mu?
Şöyle söyleyeyim, Var tabiî ki var! Yeni framework ne kadar iyi olsa da eski dünyadan kalan alışkanlıklar hemen kaybolmuyor (ben de ilk duyduğumda şaşırmıştım). Elinizde çok fazla legacy API varsa hepsini dönüştürmek zaman alacak demektir. O sırada çift sistemle yaşamak zorunda kalabilirsiniz (pek eğlenceli değil).
Ne yalan söyleyeyim, Ayrıca generator yaklaşımı herkesin gözünde otomatik olarak “kolay” görünür ama debug anında işler biraz yavaşlayabiliyor. Benim hoşuma gitmeyen taraflardan biri bu öldü diyebilirim; generated code’u anlamak için yine araçlara güveniyorsunuz ve bazen o katman sizi hafif yoruyor.
Yeni Tag Düzeni Ne Sağlıyor?
Doğrusu, Kubernetes artık validation kurallarını daha zengin marker tag set’i ile ifade ediyor: required/optional alanlar, minimum-maksimum sınırlar, list davranışları, union üyeleri… yanı bildiğiniz kuralları daha standart biçimde söylüyorsunuz.
| Kategori | Örnek Tag | Sahadaki Karşılığı |
|---|---|---|
| Zorunluluk | +k8s:required | “Bu alan boş geçilmesin” |
| Sayı Sınırı | +k8s:minimum=0 | “Negatif olmasın” |
| Dizi Davranışı | +k8s:listType=map | “Listeyi anahtar üzerinden yönet” |
Bence en kritik kazanım burada tutarlılık hissi veriyor olmasıdır. Bir field’a bugün konan kural yarın başka kaynakta aynı şekilde uygulanabiliyorsa işletme tarafı rahat eder.
Eh, Neyse uzatmayalım; bu iş sadece geliştirici konforu değil aynı zamanda platform güvenilirliği meselesi.
Küçük startup mı kurumsal yapı mı?
İtiraf edeyim, Küçük startup tarafında avantaj net: az kişiyle daha temiz API tasarımı yapabilirsiniz ve kurallarınızı tek noktadan takip edersiniz.
Ama başlangıç aşamasında gereksiz karmaşıklığa kaçmamaya dikkat etmek lazım; her şeyi tag’e boğarsanız ekip yeni konu öğrenmekten ürünü çıkaramaz hâle gelir.
Enterprise tarafta işe declarative yaklaşım çok daha değerli çünkü onlarca takım aynı platformu tüketirken ortak dil şart oluyor.
Bir bankacılık müşterisinde 2024 Kasım ayında yaşadığımız şey buydu:
validasyon standardı yoksa entegrasyon hızı düşüyor.
Standart varsa işlem hızlanıyor.
Bitti.
Bana Göre Asıl Fırsat Nerede?
Bence GA ilanının en önemli sonucu sadece bugünkü kullanım kolaylığı değil. Asıl oyun ileride açılıyor:
OpenAPI üzerinden validation rule yayınlama,
Kubebuilder gibi araçlarla entegrasyon,
hatta müşteri yüzlü dokümantasyonu otomatik üretme ihtimali… Bu kısmı heyecan verici buluyorum çünkü API tasarımını “kod bilenlerin iç işi” olmaktan çıkarıp platform dili hâline getiriyor. Yanı validator artık perde arkasındaki gizemli adam değil; görünür ve paylaşılabilir hâle geliyor.
Doğrusu, Şimdi gelelim para tarafına… Doğrudan Azure fiyatlaması gibi satır satır ücret çıkarmasa da dolaylı maliyeti azaltabilir.
Daha az manuel bakım = daha az hata = daha az incident demek.
Türkiye’de çalışan şirketlerde bunun TL karşılığını anlatmak gerekirse şöyle söyleyeyim:
Bir validation bug’ının production’a sızması bazen saatlerce mühendis zamanı yakar,
üstüne müşteri memnuniyeti gider,
bir de operasyon ekibi gece uyanır…
Yanı ucuz değil!
toplu dönüşüm yapmak çoğu zaman gereksiz risk yaratır.
Migrasyona nasıl yaklaşmalı?
- Tespit et: En çok hata üreten veya en fazla tekrarlanan doğrulamaları listele.
- Ayrıştır: Business logic ile saf schema validation’ı ayırmaya çalış.
- Dönüştür:
- Metrik koy:
Sahada Görünmeyen Ama Önemli Detaylar
”
“Benim deneyimimde en büyük sorun teknoloji seçimi değil, geçiş sırasıdır.
2023’te Ankara’da bir kurumda benzer modernizasyon yaptığımızda, önce core path’i değiştirmeye kalkınca ekip dağıldı.
Sonra taktik değiştirdik ; önce edge case’leri toparladık, ardından ana yolu çevirdik.
Burada da aynı disiplin lazım.”
“Kuberenetes topluluğu genelde bunu iyi yönetiyor ama kullanıcı tarafında sabırsızlık oluşabilir ; ‘neden neredeyse tüm eski kod hemen silinmedi?’ diye soranlar olacak.
Cevap basit : çünkü gerçek dünya tertemiz ilerlemiyor.”
“Aslında — durun bir dakika — mesele yalnızca validasyon değil ;
platform sahipliği.
Eğer sız kaynak şemasını düzgün tarif edemezseniz, sizin yerinize runtime konuşur…
ve runtime pek nazik olmaz.”
Doğrulamayı koda saklamak kısa vadede hızlı görünür; uzun vadede işe ekip hafızasını kemirir.
Deklaratif yaklaşım biraz disiplin ister ama sonunda herkes aynı not defterine yazar.
Tavsiyem Ne Olur?
”
Eh, “Eğer bugün Kubernetes üzerinde CRD veya native type geliştiren biriyseniz, Aslında çok pratik bir yaklaşım bu. Yanı Kubernetes native type’larının doğrulama kurallarını elle Go kodu içine yazmak yerine, o kuralları direkt type tanımlarına marker tag’lerle koyuyorsun. Böylelikle validation kodu otomatik üretiyor ve her şey çok daha tutarlı hâle geliyor. General Availability, hani özelliğin artık “deneysel” etiketinden kurtulup üretime uygun hâle geldiğini gösteriyor. Pratikte bence bu çok önemli — daha güvenilir kullanım, daha iyi dokümantasyon zemini. Ekosistem araçlarıyla uyum potansiyeli demek. Açıkçası GA öncesinde üretime almaktan kaçınırdım. Native type’lar için declarative validation hedefleniyorsa evet, framework’ün omurgasında o var. Ama geçiş stratejisi tamamen size bağlı; mesela bazı parçaları eski modelde bırakıp adım adım ilerleyebilirsiniz (en azından benim deneyimim böyle). Tecrübeme göre kademeli geçiş genellikle daha az baş ağrısı yaratıyor. Bir dakika — bununla bitmedi. Çok sayıda API objesi yöneten platform takımları, operatör geliştiren mühendisler. Büyük organizasyonlardaki altyapı grupları özellikle fayda görüyor. Startup’larda da düzen sağlıyor, ama açıkçası aşırıya kaçılırsa öğrenme yükü ciddi bir sorun hâline gelebilir. KEP — Declarative Validation Tasarımı (GitHub) (buna dikkat edin)
ilk iş olarak mevcut doğrulama mantığınızı haritalayın.
Hangi kontroller gerçekten schema seviyesinde ?
Hangileri business rule ?
Hangileri aslında yanlış yere taşınmış helper fonksiyonlar ?”
“AZ-104. AZ-500 hazırlıkları sırasında öğrendiğim önemli şeylerden biri şu olmuştu :
kontrol mekanizması sadeleşince güvenlik modeli de sadeleşiyor.
Karmaşık sistemler çoğu zaman kötü değildir ;
yalnızca gereksiz yere konuşkandır.”
“Denemek istiyorsanız, önce küçük başlayın :
tek namespace,
tek CRD,
tek pipeline.
Büyük patlamalar yerine kontrollü adımlar sizi korur.”
“
Aşağıdaki sıralama işinizi kolaylaştırır :”
Sıkça Sorulan Sorular
Kubernetes Declarative Validation nedir?
GA olması bana ne kazandırır?
Validation-gen kullanmak zorunlu mu?
Hangi takımlara özellikle faydalı?
Kaynaklar ve İleri Okuma
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