Kurumsal altyapılarda servis keşfi (service discovery) çoğu zaman “DNS kaydı ekle” sürecine indirgenir. Sonra şu sorunlar görünür:
- Bir servis taşıdığınızda DNS gerçekliği gecikir (TTL/caching).
- Bir node bozulduğunda DNS hâlâ onu döndürür (health yok).
- Ekipler, “hangi servis neredeydi?” sorusunu wiki/Excel/ticket’ten arar.
Consul gibi bir discovery katmanı burada sadece “yeni bir ürün” değil; altyapının değişkenliğini yönetilebilir hâle getiren bir kontrol düzlemidir. Bu yazıda, özellikle health check + DNS arayüzü üzerinden, sahada işletilebilir bir model kurmaya odaklanıyorum.
1) Sorunu doğru tarif et: discovery mi, routing mi?
Discovery’nin hedefi “trafiği taşıma” değil; doğru hedefi bulmadır.
- Routing/LB katmanı trafiği taşır (L4/L7).
- Discovery katmanı “hangi instance sağlıklı?” sorusunu cevaplar.
Bu ayrımı yapmazsanız, discovery’ye gereksiz beklenti yükler ve tasarım büyür.
2) Consul’u nerede konumlandırmalı? (minimum viable)
Temel bileşenler:
- Consul server cluster (odd sayı, ör. 3/5)
- Consul agent’lar (node üzerinde)
- Servis kayıt modeli (katalog)
- Health check’ler (kritik)
- DNS arayüzü (istemciler için)
3) Health check tasarımı: ping değil, iş yapabilirlik
Health check’i üç sınıfa ayırın:
- Process check: servis process ayakta mı?
- Port check: port dinliyor mu?
- Functional check: servis gerçekten iş yapabiliyor mu? (kritik yol)
Discovery kararını mümkünse 3. sınıfa yaklaştırın. Çünkü yanlış “healthy” sonucu, en pahalı tip sorundur: kullanıcıya hata verir, triage’ı uzatır.
4) DNS arayüzü: TTL ve caching ile barış
DNS arayüzü pratik ve yaygın istemci uyumluluğu sağlar. Ama DNS’in doğası gereği:
- Cache vardır
- TTL davranışı her yerde aynı değildir
Bu yüzden DNS tabanlı discovery için iki pratik yaklaşım:
- Düşük TTL + gözlem: değişiklik hızlı yayılır ama load artar
- Orta TTL + stabilite: daha az load, daha yavaş yayılım
Benim sahada gördüğüm doğru yaklaşım: “en düşük TTL” değil; işletilebilir TTL. Ayrıca “yüksek churn” servisleri (çok sık değişen pod/instance) için DNS yerine istemci tarafı keşif (örn. sidecar) daha uygun olabilir.
5) Runbook: “Yanlış hedefe gidiyor” incident’inde ne yaparım?
Belirti: Bazı istekler hata alıyor, bazıları almaz; yük dalgalı.
- DNS cevabı hangi instance’ları döndürüyor? (örneklem)
- Health check sonucu gerçekten doğru mu?
- Problemli instance’ı katalogdan düşürün (geçici) ve sebebi bulun
- TTL/cache yüzünden eski cevaplar dolaşıyor mu?
- Consul server/agent latency artmış mı? (raft, disk, network)
6) Güvenlik: discovery = envanter + hedef haritası
Consul katalog bilgisi saldırgan için de değerlidir. Bu yüzden:
- UI/API erişimini yönetim ağına alın
- ACL/policy modelini kullanın
- Audit log’ları merkezi log/SIEM hattına bağlayın
Discovery’nin “kolaylık” yüzünden envanter sızıntı yüzeyine dönüşmesine izin vermeyin.
7) Kapanış
Consul ile servis keşfi; DNS kaydı yönetmekten daha fazlasıdır: sağlık sinyaliyle yaşayan bir hedef listesi üretir. Doğru tasarım; TTL/caching gerçekliğini kabul eder, health check’i iş yapabilirliğe yaklaştırır ve discovery katmanını kritik servis olarak işletir. Bu disiplin kurulduğunda “servis nerede?” sorusu ticket değil, sistem cevabı olur.