Kubernetes’in iç mutfağında uzun süredir konuşulan. Dışarıdan pek görünmeyen bir hikâye var: — itiraz edebilirsiniz tabi — API doğrulama (validation) kodunun nasıl yazıldığı. Yıllardır core ekibin sırtında kambur gıbı taşıdığı, herkesin bildiği. Kimsenin tek seferde temizleyemediği bir teknik borç (buna dikkat edin). v1.36 ile bu hikâye yeni bir bölüme girdi — Declarative Validation artık GA.
Açık konuşayım: Bu konuyu ilk duyduğumda “tamam, güzel bir refactor işte” diye geçiştirmiştim. Ama biraz kurcalayınca, olayın sadece kod toparlamak olmadığını gördüm; Kubernetes tarafında önümüzdeki birkaç yılı etkileyebilecek, sessiz. Baya kritik bir altyapı dönüşümü var burada. Neden mi? Hemen anlatıyorum.
18 Bin Satırlık Bir Yangın: Eski Validation Modeli
Kubernetes’in core API’lerinde, yanı Pod, Deployment, Service gıbı tiplerde, alan doğrulamaları uzun süre elle yazılmış Go fonksiyonlarıyla yapılıyordu. “Bu alan boş olamaz”, “şu sayı 0-100 arasında olmalı”, “bu iki alan aynı anda dolu olamaz” gıbı kurallar… Hepsi tek tek yazılan Go kodu. Kulağa basit geliyor, ama iş büyüyünce tablo biraz dağılıyor.
Sonuç? Yaklaşık 18.000 satır boilerplate validation kodu. Dürüst olayım, bu bildiğiniz bakım kabusu. Bir yerden sonra kim neyi neden yazmış unutuluyor, küçük bir değişiklik bile yan tarafta saçma bir kırılma çıkarabiliyor; yanı işin aslı, kod var ama güven hissi pek yok.
Tuhaf ama, Bu mesele neden bu kadar kötüleşti? Çünkü API yüzeyi büyüdükçe, her yeni alan için aynı türden kontrolleri farklı dosyalarda farklı stillerde yazıyordu insanlar. Code review’larda kimse 18 bin satırı baştan sona okuyamadığı için tutarsızlıklar birikiyordu. Bir alan için required kontrolü yapılıp diğerinde unutulmuş olabiliyordu — ki bu tıp durumlara Kubernetes v1.36 Controller Staleness: Artık Daha Az Acı yazımda da değindiğim controller seviyesindeki sorunlarla benzer bir yaklaşımla bakmak lazım: temel altyapı temiz olmalı ki üst katmanlar dert çıkarmasın. Neyse uzatmayalım, aşağı taraf dağınıksa yukarıda da sürpriz eksik ölmüyor.
Bir başka problem daha vardı, belki de en sinsi olanı: API’ler şeffaf değildi. İstemci tarafındaki tooling — kubectl, client-go, hatta Kubebuilder gıbı framework’ler — bir alanın hangı kurallara tabi olduğunu öğrenmek için ya kaynak koda bakmak ya da çalışma anında hata almak zorundaydı. Yanı validation rule’ları “saklı bilgi” gıbı duruyordu. Bu da dokümantasyonu ayrı yerde, gerçeği ayrı yerde bırakıyordu; hani güzel görünmüyor değil ama pratikte biraz can sıkıyor.
Peki bu durum kullanıcıyı nasıl etkiliyordu?
Hani bazen kubectl apply dersiniz, garip bir hata alırsınız, sonra dokümantasyonda o kuralın hiçbir yerde yazmadığını fark edersiniz… İşte tam o his. Geçen sene bir telekom müşterisinde StatefulSet manifest’lerini hazırlarken, bir alan için “must be a valid DNS-1123 subdomain” hatası aldık. Dokümanda yoktu. Source kodda buldum — elle yazılmış bir validator’ın içine gömülmüştü. Açık konuşayım, insanın morali bozuluyor; çünkü sorun teknikten çok görünmezlikten vuruyor.
Çözüm: +k8s: İşaretçileri ve validation-gen
SIĞ API Machinery burada baya mantıklı bir yere gelmiş. Validation kurallarını doğrudan tıp tanımının üstüne, yorum satırı gıbı yazalım demişler. Deepcopy ve conversion tarafında nasıl code generator kullanıyorsak, aynı mantıkla bu işaretçileri okuyup Go validation fonksiyonlarını üreten bir araç da çalışsın istiyorlar.
İşte olayın kalbi de burada atıyor. validation-gen, types.go içindeki +k8s: ile başlayan tag’leri okuyor, sonra corresponding validator fonksiyonlarını çıkarıyor; üretilen kod da ardından API scheme’e otomatik şekilde register ediliyor. Kulağa kuru geliyor olabilir ama pratikte epey iş görüyor, çünkü elle yazılan tekrarları ciddi biçimde azaltıyor.
Bunu biraz açayım.
Bakın, Basit bir örnekle gidelim. Eskiden şu tarz bir şey yazıyordunuz, yanı işin aslı bayağı el emeği vardı:
// Eski yöntem — elle yazılmış validation
func ValidateMySpec(spec *MySpec, fldPath *field.Path) field.ErrorList {
allErrs := field.ErrorList{}
if spec.Replicas < 0 {
allErrs = append(allErrs, field.Invalid(
fldPath.Child("replicas"), spec.Replicas,
"must be non-negative"))
}
if spec.Replicas > 100 {
allErrs = append(allErrs, field.Invalid(
fldPath.Child("replicas"), spec.Replicas,
"must not exceed 100"))
}
if len(spec.Name) == 0 {
allErrs = append(allErrs, field.Required(
fldPath.Child("name"), ""))
}
return allErrs
}Yeni yaklaşımda işe aynı kuralları tipin yanına koyuyorsunuz. Şey gıbı düşünün: kural başka yerde değil, alanın tam dibinde duruyor.
type MySpec struct {
// +k8s:required
// +k8s:minimum=0
// +k8s:maximum=100
Replicas int32 `json:"replicas"`
// +k8s:required
// +k8s:maxLength=63
// +k8s:format=k8s-short-name
Name string `json:"name"`
}Bence burada asıl güzel taraf okunabilirlik değil sadece. Hata yapma ihtimali de düşüyor. Bir de açık konuşayım, bu işaretçilerin ileride OpenAPI schema’ya yansıyabilmesi ayrı bir rahatlık; yanı kubectl ya da başka bir client alanın kurallarını runtime’da görebilecek, source koda gidip bakma derdi azalacak. Tam da böyle bir şey bekliyordum diyemem ama valla işe yarar duruyor.
Evet.
Tag Kataloğu: Hangı Validator’lar Var?
v1.36 ile gelen tag’ler baya geniş, yanı öyle iki üç etiketle geçilecek bir konu değil. Hepsini tek tek dökmek bu yazının boyunu aşar ama en çok işinize yarayacak olanları aşağıda toparladım; kafada bir çerçeve oluşsun diye tabloyu kısa tuttum, yoksa konu uzayıp gidiyor. Bu konuyla ilgili Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımıza da göz atmanızı tavsiye ederim.
| Kategori | Tag | Ne İşe Yarar? |
|---|---|---|
| Varlık | +k8s:required |
Alan zorunlu olmalı |
| Varlık | +k8s:optional |
Alan opsiyonel |
| Sayısal | +k8s:minimum=0 |
Minimum değer kontrolü |
| Sayısal | +k8s:maximum=100 |
Maksimum değer kontrolü |
| String | +k8s:maxLength=16 |
String uzunluk limiti |
| String | +k8s:format=k8s-short-name |
Format doğrulama |
| Koleksiyon | +k8s:listType=map |
Liste tipini belirtir |
Koleksiyon`+k8s:listMapKey=type`?`**`? Wait must preserve html only. Need correct final without corruption.
|
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.
