Kubernetes ConfigMap'leri Gerçek Zamanlı State Store Olarak Kullanmak

ConfigMap'ler genellikle pod başlangıcında okunup bellekte tutulan statik yapılandırma parçaları olarak kullanılır; değişiklik olduğunda ya pod yeniden başlatılır ya da API periyodik olarak yoklanır. Oysa Kubernetes API sunucusu ConfigMap'lerdeki ADDED, MODIFIED ve DELETED olaylarını sürekli açık kalan bir bağlantı üzerinden anlık olarak ittiriyor. Bu makalede anlatılan Python demosu, kr8s kütüphanesinin async watch generator'ını kullanarak bu akışı gerçek zamanlı bir pub/sub sistemine dönüştürüyor.

Mimari üç katmandan oluşuyor: tek bir uzun ömürlü watch bağlantısı tutan bir Watcher, gelen her olayı asyncio.Queue tabanlı abonelere kopyalayan bir Notifier (fan-out broker) ve farklı davranışlar sergileyen bağımsız istemciler. Bağlantı kopmalarına karşı watch döngüsü while True içinde sarmalanıp httpx.ReadError yakalanarak otomatik yeniden bağlanma sağlanıyor; bu sırada abone istemciler kesintiyi hiç fark etmiyor. Notifier'daki asyncio.Lock ise abone listesinin, notify() olayları dağıtırken eşzamanlı değiştirilmesini engelliyor.

Demo, aynı olayı üç farklı şekilde tüketen Logger, Counter ve Filter istemcileriyle bu deseni somutlaştırıyor: tüm olayları loglayan, toplam olay sayısını tutan ve yalnızca ADDED olaylarına tepki veren bileşenler. Gerçek sistemlerde bunlar önbellek geçersiz kılma, canlı config yeniden yükleme veya feature flag güncelleme gibi işlevlere karşılık gelebilir — hepsi tek bir Kubernetes watch bağlantısını paylaşarak.

Bu yaklaşımın önemi, Kubernetes'in zaten her cluster'da hazır bulunan bir reaktif state store sunduğunu göstermesinde yatıyor: ConfigMap'in data alanı durumu, watch stream'i değişiklik akışını, Notifier ise bu akışı gözlemcilere dağıtan katmanı temsil ediyor. Mühendisler için bu, ayrı bir mesaj broker'ı ya da polling mekanizması kurmadan, standart kütüphane araçlarıyla reaktif konfigürasyon yönetimi kurulabileceği anlamına geliyor.