Kubernetes'te DNS Çözümleme: ndots, Arama Alanları, CoreDNS Önbelleği ve Beş Saniyelik Takılmalar

Kubernetes içindeki uygulamalar dış bir API'ye ya da başka bir servise giderken kimse DNS'i düşünmez; ta ki tail gecikmesi açıklanamaz biçimde 5 saniye sıçrayana ya da CoreDNS pod'ları küme büyüdükçe yük altında ezilene kadar. Problemin kaynağı çoğu zaman uygulama değil, pod'un içine yazılan çözümleyici ayarlarıdır. Bu yazı bir pod'un bir adı nasıl çözdüğünü, varsayılanların neden yanlış ölçekte kalabildiğini ve hangi durumda hangi düzeltmenin işe yaradığını anlatır.

Bir pod adı nasıl çözer

Varsayılan dnsPolicy: ClusterFirst ile kubelet her pod'a şöyle bir çözümleyici dosyası yazar: küme DNS servisinin adresi, üç arama alanı (<namespace>.svc.cluster.local, svc.cluster.local, cluster.local) ve options ndots:5. Bu üç arama alanı sayesinde aynı ad alanındaki bir servise sadece veritabani, başka ad alanındaki bir servise veritabani.diger-ns diyebilirsiniz.

ndots:5 kuralı şudur: sorgulanan adda beşten az nokta varsa ad "göreli" sayılır ve önce arama alanlarıyla sırayla denenir, en son mutlak hâliyle sorulur. api.example.com iki nokta taşıdığı için önce api.example.com.<namespace>.svc.cluster.local, sonra svc.cluster.local ve cluster.local ekleriyle sorulur; üçü NXDOMAIN döndükten sonra gerçek ad gider. Her deneme için hem A hem AAAA kaydı istendiğinde dış bir adrese giden tek bir çağrı sekiz DNS sorgusuna dönüşür. Kümeye dokunmayan bir HTTP isteği, yolun başında CoreDNS'e dört gidiş dönüş yaptırır.

Bunu doğrulamak için kendi pod'unuzda bakın:

kubectl exec -it <pod> -- cat /etc/resolv.conf
kubectl exec -it <pod> -- dig +search api.example.com

dig varsayılan olarak arama alanlarını uygulamaz; +search bayrağı uygulamanın gerçekten gördüğü davranışı gösterir. Çıktıdaki sorgu sayısı ve süresi yazının geri kalanının somut gerekçesidir.

Üç düzeltme, üç farklı yer

Uygulama tarafında: adı mutlak yaz. Adın sonuna nokta koymak (api.example.com.) çözümleyiciye "bu ad tamdır, arama alanı ekleme" der ve tüm ek sorguları kaldırır. Kod ya da yapılandırma sizdeyse en ucuz düzeltme budur. Tuzağı: bazı HTTP istemcileri ve TLS kütüphaneleri sondaki noktayı Host başlığına ya da SNI'ya taşır ve sunucu sanal konağı eşleştiremez. Kütüphanenizde deneyin, varsayarak geçmeyin.

Pod tarafında: ndots'u düşür. Kaynağa dokunamıyorsanız pod spesifikasyonundan çözümleyici seçeneklerini değiştirin:

spec:
  dnsPolicy: ClusterFirst
  dnsConfig:
    options:
      - name: ndots
        value: "2"

ndots:2 ile api.example.com doğrudan mutlak sorulur, veritabani ve veritabani.diger-ns hâlâ arama alanlarından geçer. Kırdığı tek şey tam biçimli iç adlar değil, üç parçalı kısaltmalardır: servis.ns.svc biçimini kullanan bir kütüphane iki nokta taşıdığı için artık arama yapmadan mutlak sorulur ve çözülmez. Dağıtmadan önce ekip içinde bu kısaltmanın kullanılıp kullanılmadığını grep ile arayın.

Sunucu tarafında: CoreDNS'i arama yolunu yürütmeye ikna et. CoreDNS'in autopath eklentisi arama yürüyüşünü istemci yerine sunucuda yapar: ilk sorguya, doğru sonucu işaret eden bir CNAME ile birlikte yanıt döner ve istemci geri kalan denemeleri hiç yapmaz. Bunun bedeli kubernetes eklentisinin pods verified modunda çalışması, yani CoreDNS'in hangi IP'nin hangi ad alanına ait olduğunu bilmek için tüm pod'ları izlemesidir. Büyük kümede bu izleme belleği ve API sunucusu yükünü gözle görülür artırır. Kaynağı ve pod'u değiştiremediğiniz üçüncü parti iş yükleri için mantıklı, genel varsayılan olarak değil.

Önbellek ve zaman aşımı

CoreDNS'in cache eklentisi hem olumlu hem olumsuz yanıtları saklar; ndots yürüyüşünün ürettiği NXDOMAIN'ler olumsuz önbellekten döner, bu da aynı dış adı sık soran iş yüklerinde yükü ciddi düşürür. Varsayılan cache 30 olumlu yanıtların TTL'ini 30 saniyeyle sınırlar. Kısa TTL küme içi servis değişimini hızlı yansıtır ama sorgu sayısını artırır; dış adlar için ayrı bir sunucu bloğunda daha uzun önbellek tutmak makul bir denge verir.

example.com:53 {
    forward . /etc/resolv.conf
    cache 300
}
.:53 {
    errors
    health { lameduck 5s }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

Bu Corefile'ın ilk bloğu yalnız example.com altındaki adları uzun önbellekle yanıtlar, ikincisi kubeadm'in kurduğu varsayılandır. reload eklentisi ConfigMap değişince yeniden başlatma gerektirmez; loop eklentisi CoreDNS'in kendine yönlendirdiği döngüleri yakalayıp pod'u durdurur, bu yüzden CrashLoopBackOff gördüğünüzde önce düğümün kendi çözümleyici dosyasına bakın.

Ölçmeden ayar yapmayın. coredns_dns_requests_total, coredns_dns_request_duration_seconds ve coredns_cache_hits_total metrikleri sorgu tipine ve bölgeye göre etiketlidir; ndots değişikliğinin etkisi bu üçünde dakikalar içinde görünür.

Beş saniyelik takılmalar

DNS gecikmesinin klasik belirtisi ortalamanın değil kuyruğun bozulmasıdır: çoğu istek milisaniye, bazıları tam 5 saniye. Bu sayı glibc çözümleyicisinin varsayılan zaman aşımıdır ve neredeyse her zaman kaybolan bir UDP paketine işaret eder. Kaybın en bilinen nedeni, A ve AAAA sorgularının aynı soketten aynı anda çıkması ve küme DNS servisine giden DNAT sırasında conntrack tablosuna iki kaydın yarışarak girmesidir; kaybeden paket sessizce düşer, istemci zaman aşımını bekleyip yeniden dener.

Üç çare vardır. glibc tabanlı imajlarda single-request-reopen seçeneği iki sorguyu ayrı soketlerden yollayarak yarışı ortadan kaldırır; dnsConfig.options ile eklenir. Alpine gibi musl tabanlı imajlar bu seçeneği tanımaz ve sessizce yok sayar, bu yüzden Alpine'de sorun devam eder ve çoğu ekip bunu "DNS bazen yavaş" diye kabullenir. Kalıcı çözüm NodeLocal DNSCache'tir: her düğümde bir DaemonSet, pod'ların sorgusunu düğümdeki yerel önbellekten karşılar, üst kaynağa TCP ile gider ve conntrack'i hiç devreye sokmaz. Yerel önbellek isabet oranı yüksek olduğu için CoreDNS'e giden yük de düşer. Bedeli bir ek bileşen ve kubelet'in küme DNS adresinin değiştirilmesidir; yükseltmelerde bu DaemonSet'i unutmak tüm kümenin DNS'ini keser.

Sık düşülen tuzaklar

hostNetwork: true olan bir pod'a ClusterFirst politika verirseniz düğümün çözümleyicisini alır ve küme servislerini çözemez; doğru değer ClusterFirstWithHostNettir. dnsPolicy: None yalnız dnsConfig içinde eksiksiz nameservers verildiğinde çalışır, aksi hâlde pod hiç başlamaz.

Küme alan adı cluster.local dışında bir şeyse, kaynak kodda ya da Helm şablonlarında cluster.local sabitlenmiş her bileşen çözümlenemeyen adlar üretir ve belirtisi çoğu zaman DNS hatası değil, bağlantı reddi olur. Şablonun küme alan adını bir değerden aldığını ve o değerin boş kalmadığını kurulumdan önce kontrol edin; boş değer svc. ile biten yarım bir ad üretir ve hiçbir yerde uyarı vermez.

Sık sorgulanan iş yükleri için TTL'i sıfıra yaklaştırmak, her isteği CoreDNS'e taşıyıp tam da kaçınmak istediğiniz yükü yaratır. TTL'i düşürmek yerine değişimin kaynağını, örneğin çok sık yeniden oluşturulan headless servis pod'larını, azaltmayı deneyin.

Ne zaman dokunmamalı

Küçük bir küme, tek ad alanı ve az sayıda dış bağımlılık varsa varsayılanlar iyidir; ndots:5 işe yarar bir kolaylık sağlar ve CoreDNS'in iki replikası her şeyi karşılar. Sorun küme büyüdükçe, dış API çağrıları arttıkça ve gecikme hedefi sıkılaştıkça çıkar. O noktada sıra hep aynıdır: önce dig +search ile ne olduğunu gör, sonra en az müdahaleyle, uygulama ya da pod seviyesinde düzelt, ancak ölçüm hâlâ kötüyse CoreDNS'e ve düğüm seviyesindeki önbelleğe geç.