Kubestack catalog ve kbst.xyz module registry'yi emekliye ayırıyor; kullanıcıların 31 Aralık 2026'ya kadar geçiş yapması gerekiyor

Kubestack, hem catalog yapısını hem de ona hizmet veren module registry'yi emekliye ayırıyor. dev.to'da yayımlanan bir duyuruya göre GitHub'daki catalog repository'si ve kbst.xyz adresindeki registry etkili olmak üzere kullanımdan kaldırıldı ve registry 31 Aralık 2026'da tamamen kapatılacak. Platform özelliklerini catalog'dan sağlayan herkesin, mevcut module source'lar çözülmeyi bırakmadan önce Kubestack'in platform feature modules adını verdiği yeni desene geçmesi gerekiyor.

Neler değişiyor

Catalog repository'si ve kbst.xyz registry'sine artık yeni module sürümleri yayımlanmayacak ve bunlar için başka upstream sürümü paketlenmeyecek. Catalog'un, yeni platform özellikleri eklemek için önerilen yol olmaktan açıkça çıktığı belirtildi.

Registry, mevcut sürümleri 2026 sonuna kadar sunmaya devam edecek; böylece terraform init geçiş süresince çalışmaya devam ediyor ve ekipler geçiş zamanlamasını kendileri belirliyor. Kapanma tarihinden sonra herhangi bir kbst.xyz module source'unun çözümlenmesi başarısız olacak ve registry'ye hâlâ referans veren repository'ler başlatılamayacak. Mevcut catalog dokümantasyon sayfaları referans için çevrimiçi kalacak ancak güncellenmeyecek.

Etkilenip etkilenmediğinizi nasıl kontrol edersiniz

Duyuru, etkilenen durumu tam olarak tanımlıyor: source değerinin registry'ye işaret ettiği module blokları içeren bir repository — örneğin 1.3.1-kbst.1 sürümüyle kbst.xyz/catalog/nginx/kustomization kaynağından sağlanan bir nginx module'ü.

Tek bir grep komutu tüm referansları bulur:

grep -rn "kbst.xyz/catalog" *.tf

Arama boş dönerse bu değişiklik sizi etkilemiyor. Framework ve module sürümlerini sabitleyen, provider ve modülleri dahili olarak önbelleğe alan ekiplerin biraz daha nefes payı var; ancak duyuru yine de geçişi tavsiye ediyor: catalog'a yeni module sürümleri yayımlanmadığı için catalog'dan sağlanan özellikler hiçbir tür güncelleme almamayı bırakacak.

Yerine geçen çözüm: platform feature modules

Kubestack, upstream projelerini sürümlü catalog modülleri halinde yeniden paketleme yaklaşımından uzaklaştı. Yeni varsayılan altında bir repository, özelliğin upstream kaynağını doğrudan dağıtan küçük bir yerel Terraform module'ü içeriyor — bu ya helm template ile render edilip commit edilen bir manifests/upstream.yaml dosyasına dönüştürülen bir Helm chart, ya da upstream'den çekilen düz bir YAML manifest oluyor.

Hem render edilen manifestler hem de module kullanıcının repository'sinde yaşıyor, platformun geri kalanı gibi sahipleniliyor ve arada yeniden paketleme adımı olmadan güncellemeleri doğrudan upstream'den alıyor. Module, catalog modülleriyle aynı kustomization overlay module tipini ve aynı yapılandırma kalıtımı modelini sarmalıyor; bu nedenle ortam başına yapılandırma neredeyse birebir taşınıyor. Özellikle dikkat çekici olan, Kubestack'in bu modüllerin iskeletini kurmayı ve bakımını yapmayı bir AI coding agent'tan beklemesi; yayımlanmış bir Kubestack skill'i bu doğrultuda izlenecek yolu gösteriyor.

Kaynakları yeniden oluşturmadan geçiş

Geçiş, agent odaklı olacak şekilde tasarlandı: kullanıcılara önce agent'larının Kubestack skill'ini öğrenmesi, ardından her catalog module'ünü geçirmesini istemesi talimatı veriliyor. Agent, yerel module'ü modules/<feature_name>/ altında oluşturuyor, cluster başına bir binding dosyası üretiyor, mevcut ortam başına yapılandırmayı taşıyor ve kullanıcının yeni upstream.yaml'ı üreten helm template komutunu çalıştırmasını istiyor.

İki ayrıntı, geçişi cluster'larda halihazırda çalışan kaynaklar için güvenli kılıyor. Birincisi, her binding dosyası catalog module'ünün Terraform state'ini devralan bir moved bloğu içeriyor. Bu blok olmadan değişen module adresi Terraform'ın özelliğin tüm kaynaklarını yok edip yeniden oluşturmasına neden olurdu; blokla birlikte geçiş, planda yerinde bir taşıma (in-place move) olarak görünüyor. İkincisi, render edilen upstream.yaml her kaynağı mevcut namespace'i içinde ve mevcut adıyla korumalı ve kimliği etkileyen yapılandırma değiştirilmeden taşınmalı.

Kubestack normal GitOps iş akışını izlemeyi öneriyor: her pull request'te bir feature module ve promotion öncesi Terraform plan'ının incelenmesi. Doğru bir plan, o özelliğin kaynakları için hiçbir destroy-and-create çifti olmadan module taşınmasını gösterir. Örnek dosyalar içeren adım adım bir geçiş rehberi mevcut; rehberin kapsamadığı sorunlar GitHub discussion'ları olarak bildirilmeli.

Neden önemli

Son tarih kesin: kbst.xyz kapandığında, ona hâlâ işaret eden her repository için terraform init bozuluyor ve bu, pipeline'ları durdurup etkilenen repo'ların yeni klonlarını engelleyebilir. Sabitlenmiş sürümler ve dahili önbellekler sayesinde ani kırılmadan kurtulan ekipler bile upstream düzeltmeleri veya güvenlik güncellemeleri olmayan donmuş özelliklere mahkum kalıyor. Bu emeklilik kararı ayrıca altyapı araçlarının nereye gittiğinin bir fotoğrafı — özenle derlenip yeniden paketlenmiş module catalog'larından, upstream kaynaklarını doğrudan kendi repository'nize taşıma ve iskelet kurma ile bakımı AI agent'lara bırakma yönüne.