Tüm Ürünler
Search

Bu Ürün

    Container Service for Kubernetes:Troubleshoot DNS resolution errors

    Belge Merkezi

    Container Service for Kubernetes:Troubleshoot DNS resolution errors

    Son Güncelleme:Oct 06, 2026

    CoreDNS, ağ, ilke veya çekirdek kaynaklı sorunlardan kaynaklanan ACK kümelerindeki DNS arızalarını teşhis edin ve düzeltin.

    DNS çözümleme nasıl çalışır

    Bir uygulama podu bir DNS sorgusu gönderdiğinde süreç şu yolu izler:

    1. Pod, genellikle kube-dns Hizmet IP'si olan /etc/resolv.conf dosyasındaki adrese bir DNS sorgusu gönderir.

    2. kube-dns, sorguyu kube-system ad alanındaki bir CoreDNS poduna iletir.

    3. Sonu .cluster.local ile biten dahili etki alanı adları için CoreDNS, üst sunucularla iletişime geçmeden önbelleğinden çözümleme yapar.

    4. Harici etki alanı adları için CoreDNS, yapılandırmasında belirtilen üst DNS sunucularına sorguyu iletir. Varsayılan üst sunucular, her ikisi de sanal özel cloud (VPC) içinde konuşlandırılmış olan 100.100.2.136 ve 100.100.2.138 adresleridir.

    NodeLocal DNSCache kullanıldığında, sorgular öncelikle yerel önbelleğe (169.254.20.10) gider ve yalnızca çözümlenememesi durumunda kube-dns'e geri döner.

    Temel kavramlar


    Terim


    Açıklama


    Dahili etki alanı adı


    Sonu .cluster.local ile biten etki alanı adı. CoreDNS, bu adları üst sunuculardan değil önbelleğinden çözümler.


    Harici etki alanı adı


    Sonu .cluster.local ile bitmeyen etki alanı adı. CoreDNS bu sorguları üst DNS sunucularına iletir.


    Uygulama podu


    Sistem bileşeni olmayan herhangi bir pod.


    kube-dns Hizmeti


    DNS trafiğini CoreDNS podlarına yönlendiren Kubernetes Hizmeti. IP adresi, uygulama podları için varsayılan nameserver'dır.


    NodeLocal DNSCache


    Her düğümde yerel bir DNS önbelleği çalıştıran DaemonSet. Etkinleştirildiğinde, podlar kube-dns yerine yerel önbelleği (169.254.20.10) sorgular.


    Üst DNS sunucusu


    CoreDNS'in harici etki alanları için başvurduğu DNS sunucusu. Varsayılan olarak 100.100.2.136 ve 100.100.2.138 adreslerini kullanır.

    Adım 1: Hata iletinizi belirleyin

    Olası arıza kategorisini belirlemek için hata iletinizi eşleştirin.


    İstemci


    Hata iletisi


    Olası neden


    ping


    ping: xxx.yyy.zzz: Name or service not known


    Etki alanı adı mevcut değil veya DNS sunucusuna ulaşılamıyor. Gecikme süresi >5 saniye ise sunucuya ulaşılamıyor demektir.


    curl


    curl: (6) Could not resolve host: xxx.yyy.zzz


    Yukarıdakiyle aynı.


    PHP HTTP istemcisi


    php_network_getaddresses: getaddrinfo failed: Name or service not known in xxx.php on line yyy


    Yukarıdakiyle aynı.


    Golang HTTP istemcisi


    dial tcp: lookup xxx.yyy.zzz on 100.100.2.136:53: no such host


    Etki alanı adı mevcut değil.


    dig


    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: xxxxx


    Etki alanı adı mevcut değil.


    Golang HTTP istemcisi


    dial tcp: lookup xxx.yyy.zzz on 100.100.2.139:53: read udp 192.168.0.100:42922->100.100.2.139:53: i/o timeout


    DNS sunucusuna ulaşılamıyor.


    dig


    ;; connection timed out; no servers could be reached


    DNS sunucusuna ulaşılamıyor.

    • Domain does not exist → Etki alanı adının doğru olup olmadığını kontrol edin. Yalnızca harici etki alanları başarısız oluyorsa bkz. Harici etki alanı adı çözümlenemiyor.

    • DNS server unreachable → Adım 2 bölümüne ilerleyin.

    Adım 2: DNS ilkesini ve sunucu adresini kontrol edin

    Pod'un DNS sunucusu olarak CoreDNS'i kullandığını doğrulayın.

    DNS ilkesini ve yapılandırmayı alın:

    # View the pod's DNS policy
kubectl get pod <pod-name> -o yaml

# Log in to the pod and inspect the DNS configuration
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

    dnsPolicy alanını ve /etc/resolv.conf dosyasındaki nameserver girdilerini kontrol edin.


    dnsPolicy değeri


    Davranış


    ClusterFirst


    Varsayılan değerdir. Pod, DNS sunucusu olarak kube-dns Hizmet IP'sini kullanır.


    ClusterFirstWithHostNet


    Ana ağ kullanan podlar için ClusterFirst ile aynıdır.


    Default


    Pod, DNS ayarlarını Elastic Compute Service (ECS) düğümünden devralır. Pod küme içi adları çözümlüyorsa yalnızca bu durumda kullanın.


    None


    DNS tamamen dnsConfig aracılığıyla yapılandırılır. NodeLocal DNSCache, nameserver olarak 169.254.20.10 ve kube-dns IP'sini enjekte etmek için bunu kullanır.

    Pod CoreDNS kullanmıyorsa (nameserver, kube-dns Hizmet IP'si değil), pod aşırı yüklenmiş olabilir veya conntrack tablosu dolu olabilir. Bkz. İstemci aşırı yüklü ve Conntrack tablosu dolu.

    Pod NodeLocal DNSCache kullanıyorsa (nameserver 169.254.20.10), bkz. NodeLocal DNSCache çalışmıyor ve Alibaba Cloud DNS PrivateZone adları çözümlenemiyor.

    Pod CoreDNS kullanıyorsa, Adım 3'e devam edin.

    Adım 3: CoreDNS pod durumunu kontrol edin

    CoreDNS podlarını inceleyin:

    # View CoreDNS pod status and placement
kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns

    Beklenen çıktı:

    NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE
coredns-xxxxxxxxx-xxxxx   1/1     Running   0          25h   172.20.6.53   cn-hangzhou.192.168.0.198
    # View real-time CPU and memory usage
kubectl -n kube-system top pod -l k8s-app=kube-dns

    Beklenen çıktı:

    NAME                      CPU(cores)   MEMORY(bytes)
coredns-xxxxxxxxx-xxxxx   3m           18Mi

    Adım 4: CoreDNS işlem günlüklerini kontrol edin

    kubectl -n kube-system logs -f --tail=500 --timestamps <coredns-pod-name>


    Bayrak


    Açıklama


    -f


    Günlük çıktısını akış olarak görüntüler.


    --tail=500


    Son 500 satırı gösterir.


    --timestamps


    Her günlük satırına zaman damgası ekler.

    Bilinen sorunlarla eşleşen hata desenlerini arayın. DNS sorgu düzeyi günlükleri için önce CoreDNS log eklentisini etkinleştirin. Bkz. DNS çözümlemeyi yapılandırma.

    Log eklentisi etkinleştirildiğinde, çözümlenen her sorgu aşağıdakine benzer bir giriş oluşturur:

    [INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s

    Yaygın yanıt kodları:


    Yanıt kodu


    Anlamı


    Ne yapılmalı


    NOERROR


    Başarıyla çözümlendi.


    İşlem gerekmez.


    NXDOMAIN


    Etki alanı adı üst sunucuda mevcut değil.


    Etki alanı adının çözümlenmeyen bir arama soneki içerip içermediğini kontrol edin.


    SERVFAIL


    Üst DNS sunucusu bir hata döndürdü.


    CoreDNS'in üst sunuculara bağlantısını kontrol edin.


    REFUSED


    Üst sunucu sorguyu reddetti.


    CoreDNS Corefile yapılandırmasını ve düğümün /etc/resolv.conf dosyasını kontrol edin.

    DNS yanıt kodları RFC 1035 standardında tanımlanmıştır.

    Adım 5: Hatayı yeniden üretin ve nedeni izole edin

    Hata tutarlı şekilde oluşuyorsa:

    1. Hatalı yanıt kodları için DNS sorgu günlüğünü kontrol edin. Bkz. Harici etki alanı adı çözümlenemiyor.

    2. Uygulama podları ile CoreDNS arasındaki ağ bağlantısını test edin. Bkz. Uygulama podları ile CoreDNS arasındaki ağ bağlantısını test etme.

    3. Konteyner ağını teşhis edin. Bkz. Konteyner ağını teşhis etme.

    Hata aralıklı olarak oluşuyorsa:

    Kanıt toplamak için paket yakalama yapın. Bkz. Paket yakalama.

    Tanılama yöntemleri

    Uygulama podları ile CoreDNS arasındaki ağ bağlantısını test etme

    Aşağıdaki yöntemlerden birini kullanarak uygulama podunun ağ ad alanına girin:

    • Yöntem 1 (önerilen): Poda girmek için kubectl exec -it <pod-name> -- bash komutunu çalıştırın.

    • Yöntem 2: Düğüme giriş yapın, ps aux | grep <application-process-name> ile işlem kimliğini bulun ve ardından nsenter -t <pid> -n bash ile ağ ad alanına girin.

    • Yöntem 3 (sık yeniden başlatılan podlar için):

      1. Düğüme giriş yapın.

      2. Sandbox konteyner kimliklerini (adları k8s_POD_ ile başlar) bulmak için docker ps -a | grep <application-container-name> komutunu çalıştırın.

      3. /var/run/docker/netns/xxxx yolundaki ağ ad alanı yolunu bulmak için docker inspect <sandboxed-container-ID> | grep netns komutunu çalıştırın.

      4. Ad alanına girmek için nsenter -n bash komutunu çalıştırın. > Note: -n ile <netns-path> arasında boşluk bırakmayın.

    Pod'un ağ ad alanından bağlantıyı test edin:

    # Test connectivity to the kube-dns Service
dig <domain> @<kube-dns-svc-ip>

# Test Internet Control Message Protocol (ICMP) connectivity to the CoreDNS pod
ping <coredns-pod-ip>

# Test DNS query directly to the CoreDNS pod
dig <domain> @<coredns-pod-ip>

    <kube-dns-svc-ip> yerine kube-system ad alanındaki kube-dns Hizmet IP'sini ve <coredns-pod-ip> yerine bir CoreDNS podunun IP adresini yazın.


    Belirti


    Olası neden


    Sonraki adım


    kube-dns Hizmetine ulaşılamıyor


    Düğüm aşırı yüklü, kube-proxy kapalı veya güvenlik grubu User Datagram Protocol (UDP) 53 numaralı bağlantı noktasını engelliyor


    Güvenlik grubu kurallarının UDP 53 numaralı bağlantı noktasına izin verdiğini doğrulayın.


    CoreDNS poduna (ICMP) ulaşılamıyor


    Konteyner ağ hatası veya güvenlik grubu ICMP'yi engelliyor


    Konteyner ağını teşhis edin.


    CoreDNS poduna (DNS) ulaşılamıyor


    Düğüm aşırı yüklü veya güvenlik grubu UDP 53 numaralı bağlantı noktasını engelliyor


    Güvenlik grubu kurallarının UDP 53 numaralı bağlantı noktasına izin verdiğini doğrulayın.

    CoreDNS ağ bağlantısını test etme

    1. CoreDNS podunun çalıştığı düğüme giriş yapın.

    2. CoreDNS işlem kimliğini almak için ps aux | grep coredns komutunu çalıştırın.

    3. CoreDNS ağ ad alanına girmek için nsenter -t <pid> -n bash komutunu çalıştırın.

    4. Bağlantıyı test edin:

      # Test connectivity to the Kubernetes API server
telnet <apiserver_clusterip> 6443  # apiserver_clusterip is the ClusterIP of the kubernetes Service in the default namespace.

# Test connectivity to upstream DNS servers
dig <domain> @100.100.2.136
dig <domain> @100.100.2.138


    Belirti


    Olası neden


    Sonraki adım


    Kubernetes API sunucusuna ulaşılamıyor


    API sunucusu hatası, düğüm aşırı yüklü veya kube-proxy kapalı


    API sunucusunun kullanılabilirliğini kontrol edin.


    Üst DNS sunucularına ulaşılamıyor


    Düğüm aşırı yüklü, CoreDNS yanlış yapılandırılmış veya Express Connect yönlendirme hatası


    Bir destek talebi oluşturun.

    Konteyner ağını teşhis etme

    1. ACK konsoluACK konsolu üzerinde giriş yapın.

    2. Clusters sayfasında, kümenizin adına tıklayın veya Actions sütununda Details seçeneğine tıklayın.

    3. Sol gezinme bölmesinde Operations > Cluster Check seçeneğini belirleyin.

    4. Container Intelligence Service sayfasında Cluster Check > Diagnosis seçeneğini belirleyin.

    5. Diagnosis sayfasında Network Diagnosis sekmesine tıklayın.

    6. Source address alanını uygulama podu IP'sine, Destination address alanını kube-dns Hizmet IP'sine ve Destination port alanını 53 olarak ayarlayın. Enable packet tracing ve I know and agree seçeneklerini işaretleyin, ardından Create diagnosis seçeneğine tıklayın.

    7. Tanılama listesinde, kaydınız için Diagnosis details seçeneğine tıklayın.

    Sonuçlar, belirlenen hata nedenleriyle birlikte Diagnosis result, Packet paths ve All possible paths bilgilerini gösterir. Bkz. Küme sorunlarını gidermek için küme tanılama özelliğini kullanma.

    Paket yakalama

    Hatalar aralıklı olduğunda ve yeniden üretilmesi zor olduğunda paket yakalamayı kullanın.

    1. Uygulama podlarının ve CoreDNS podunun çalıştığı düğümlere giriş yapın.

    2. Her ECS örneğinde DNS trafiğini yakalayın:

      tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

      Bu komut, her biri 20 MB boyutunda en fazla 200 dosya arasında döngü yaparak 53 numaralı bağlantı noktasındaki tüm trafiği yakalar.

    3. Hatayı yeniden üretin ve arıza zaman diliminden paketleri analiz edin. Kesin zaman damgaları için uygulama günlüklerini kontrol edin.

    Paket yakalamanın hizmet üzerindeki etkisi ihmal edilebilir düzeydedir; yalnızca CPU kullanımında ve disk G/Ç'sinde hafif bir artışa neden olur.

    Bilinen sorunlar

    Daha derinlemesine araştırma yapmadan önce bu ortama özgü sorunları kontrol edin.


    Sorun


    Etkilenen ortamlar


    Hızlı tanımlama


    Eşzamanlı A ve AAAA kayıt sorguları


    Tümü (özellikle Alpine tabanlı görüntüler ve PHP uygulamaları)


    Aralıklı arızalar; paket yakalama aynı bağlantı noktasında eşzamanlı A/AAAA sorguları gösterir


    IPVS UDP kaynak bağlantı noktası çakışmaları


    IP Virtual Server (IPVS) modunda kube-proxy; çekirdeği 4.19.91-25.1.al7.x86_64 sürümünden eski olan CentOS veya Alibaba Cloud Linux 2


    Düğüm ölçeklendirme veya CoreDNS ölçeklendirme sırasında yaklaşık 5 dakika süren arızalar


    Conntrack tablosu dolu


    Yüksek trafikli düğümler


    dmesg -H çıktısında conntrack full görünür; yoğun saatlerde arızalar yaşanır


    NodeLocal DNSCache ile Alibaba Cloud DNS PrivateZone


    Hem NodeLocal DNSCache hem de DNS PrivateZone kullanan kümeler


    PrivateZone veya vpc-proxy etki alanı adları çözümlenemez veya yanlış adreslere çözülür


    autopath eklenti hatası


    Sık konteyner oluşturan kümeler


    Harici adlar aralıklı olarak başarısız olur veya yanlış IP'lere çözülür; dahili adlar genellikle normal çözülür ancak sık konteyner oluşturan kümelerde dahili hizmet adları da yanlış IP'lere çözülebilir


    DNS PrivateZone ve vpc-proxy adları


    Hem dahili hem de harici etki alanı adlarının başarısız olduğu kümeler


    Çözümleme hataları yalnızca Alibaba Cloud DNS PrivateZone'a eklenen etki alanı adlarında ve vpc-proxy içeren etki alanı adlarında görülür

    SSS

    Harici etki alanı adı çözümlenemiyor

    Yanıt kodunu görmek için CoreDNS sorgu günlüğünü kontrol edin. Henüz etkinleştirilmemişse log eklentisini etkinleştirin (bkz. DNS çözümlemeyi yapılandırma), ardından başarısız olan etki alanını arayın. NXDOMAIN kodu, etki alanının üst sunucuda mevcut olmadığı anlamına gelir; bu durum genellikle geçersiz bir tam nitelikli etki alanı adı (FQDN) oluşturan bir arama sonekinin eklenmesinden kaynaklanır. SERVFAIL veya REFUSED kodları, üst sunucuda bir sorun olduğunu gösterir; CoreDNS yapılandırmasını ve 100.100.2.136 ile 100.100.2.138 adreslerine bağlantıyı kontrol edin.

    Headless Hizmetlerin etki alanı adları çözümlenemiyor

    1.7.0 öncesi CoreDNS sürümlerinde, API sunucusu ağ dalgalanmaları CoreDNS'in çıkmasına neden olarak headless Hizmet kayıtlarının güncellenmesini durdurabilir. 1.7.0 veya sonraki bir sürüme güncelleyin. Bkz. [\[Bileşen Güncellemeleri\] CoreDNS'i güncelleme](t1964489.dita#task_1964489).

    StatefulSet podlarının etki alanı adları çözümlenemiyor

    StatefulSet pod şablonunda serviceName alanı headless Hizmet adına ayarlanmalıdır. Bu ayar yapılmazsa, Hizmet düzeyindeki ad (örneğin, headless-svc.ns.svc.cluster.local) çalışsa bile pod başına DNS adları (örneğin, pod.headless-svc.ns.svc.cluster.local) çözümlenemez. StatefulSet spesifikasyonunda serviceName alanını ayarlayın.

    DNS sorguları güvenlik grubu kuralları veya ağ ACL'leri tarafından engelleniyor

    Güvenlik grubu kuralları veya ağ erişim denetim listeleri (ACL'ler) UDP 53 numaralı bağlantı noktasını engelleyerek etkilenen düğümlerde DNS arızalarına neden olur. Gelen ve giden UDP 53 numaralı bağlantı noktası trafiğine izin verin.

    Konteyner ağ bağlantısı hataları DNS arızalarına neden oluyor

    Konteyner ağ hataları UDP 53 numaralı bağlantı noktasını engeller. Bozuk yolu ve kök nedeni belirlemek için Ağ Tanılama özelliğini kullanın.

    CoreDNS podları aşırı yüklü

    Sorgu hacmi CoreDNS çoğaltma kapasitesini aştığında gecikme süresi artar ve arızalar oluşur. CPU ve bellek kullanımının limite yakın olup olmadığını kontrol edin (kubectl -n kube-system top pod -l k8s-app=kube-dns).

    İki çözüm:

    • Sorguları yerel olarak karşılamak ve CoreDNS üzerindeki yükü azaltmak için NodeLocal DNSCache dağıtın. Bkz. NodeLocal DNSCache'i yapılandırma.

    • Pod başına tepe CPU kullanımı düğümün mevcut CPU'sunun çok altında kalacak şekilde CoreDNS çoğaltmalarını yatay olarak ölçeklendirin.

    DNS sorguları CoreDNS podları arasında eşit dağıtılmıyor

    Dengesiz pod zamanlaması veya kube-dns üzerinde bir sessionAffinity ayarı, sorgu dağılımının dengesiz olmasına neden olabilir. Belirti: CoreDNS podları arasında belirgin şekilde farklı CPU kullanımı.

    İki çözüm:

    • CoreDNS podlarını ölçeklendirin ve farklı düğümlere yayın.

    • kube-dns Hizmetinden sessionAffinity ayarını kaldırın. Bkz. kube-dns Hizmetini yapılandırma.

    CoreDNS podları normal çalışmıyor

    Yanlış yapılandırılmış YAML veya ConfigMap, CoreDNS'in başlamasını engelleyebilir veya çökmelere neden olabilir. Belirtiler: podların Running durumunda olmaması, yeniden başlatma sayısının artması veya günlük hataları.

    Aşağıdaki yaygın hatalar için CoreDNS günlüğünü kontrol edin:


    Hata


    Neden


    Çözüm


    /etc/coredns/Corefile:4 - Error during parsing: Unknown directive 'ready'


    CoreDNS ConfigMap, geçerli sürüm tarafından desteklenmeyen bir eklenti içeriyor.


    Desteklenmeyen eklentiyi (örneğin, ready) kube-system ad alanındaki ConfigMap'ten silin. Hatalardaki diğer eklentiler için tekrarlayın.


    Failed to watch *v1.Pod: ... connect: connection refused


    Günlük oluşturulduğunda API sunucusu bağlantıları kesintiye uğradı.


    DNS arızası yaşanmadıysa bu kök neden değildir. Aksi takdirde CoreDNS bağlantısını test edin. Bkz. CoreDNS ağ bağlantısını test etme.


    [ERROR] plugin/errors: 2 www.aliyun.com. A: read udp ...->100.100.2.136:53: i/o timeout


    CoreDNS üst DNS sunucularına ulaşamadı.


    CoreDNS podundan 100.100.2.136 ve 100.100.2.138 adreslerine bağlantıyı test edin.

    İstemci aşırı yüklü olduğu için DNS çözümlemeleri başarısız oluyor

    ECS örneği tamamen yüklendiğinde, UDP paketleri CoreDNS'e ulaşmadan önce düşebilir. İzleme verilerinde anormal ağ arabirimi denetleyicisi (NIC) yeniden iletim oranı ve yüksek CPU kullanımı arayın.

    Düğümler arası DNS trafiğini azaltmak için NodeLocal DNSCache dağıtın. Bkz. NodeLocal DNSCache'i yapılandırma.

    Conntrack tablosu dolu

    Conntrack tablosu dolduğunda yeni UDP ve TCP bağlantıları düşer. Bu durum genellikle yoğun saatlerde DNS arızalarına neden olur ve yoğun olmayan saatlerde düzelir. Onaylamak için, etkilenen düğümde dmesg -H komutunu çalıştırın ve arıza penceresi sırasında conntrack full mesajını arayın.

    Conntrack tablosundaki maksimum giriş sayısını artırın. Bkz. Linux çekirdeğinin conntrack tablosundaki izlenen maksimum bağlantı sayısını nasıl artırırım?

    autopath eklentisi normal çalışmıyor

    Bilinen bir autopath eklenti hatası, harici etki alanları için aralıklı çözümleme arızalarına veya yanlış IP'lere neden olur. Dahili etki alanları doğru şekilde çözülür. Sorun, yüksek konteyner oluşturma oranına sahip kümelerde daha da kötüleşir.

    Autopath eklentisini devre dışı bırakın:

    1. kubectl -n kube-system edit configmap coredns komutuyla CoreDNS ConfigMap'i düzenleyin.

    2. autopath @kubernetes satırını silin. Kaydedip çıkın.

    3. CoreDNS günlüklerinde reload mesajını kontrol ederek yapılandırmanın yüklendiğini doğrulayın.

    Eşzamanlı A ve AAAA kayıt sorguları nedeniyle DNS çözümlemeleri başarısız oluyor

    Bazı Linux dağıtımları, aynı bağlantı noktası üzerinden eşzamanlı olarak A ve AAAA sorguları gönderir; bu durum UDP paketlerinin düşmesine neden olan conntrack çakışmalarını tetikler.

    Belirtiler: Aralıklı çözümleme arızaları; paket yakalama aynı kaynak bağlantı noktasından eşzamanlı A ve AAAA sorguları gösterir.

    Çözümler görüntü temelınıza bağlıdır:

    • CentOS veya Ubuntu: DNS çözücü yapılandırmasına options timeout:2 attempts:3 rotate single-request-reopen seçeneğini ekleyin.

    • Alpine Linux: Alpine tabanlı görüntüyü başka bir işletim sistemi tabanlı bir görüntüyle değiştirin. Bkz. Alpine uyarıları.

    • cURL ile PHP: Yalnızca IPv4 çözümlemesini zorlamak için CURL_IPRESOLVE_V4 seçeneğini ekleyin. Bkz. cURL işlevleri.

    • Tüm ortamlar: Yarış durumunu hafifleten NodeLocal DNSCache'i dağıtın. Bkz. NodeLocal DNSCache'i yapılandırma.

    IPVS hataları nedeniyle DNS çözümlemeleri başarısız oluyor

    CentOS veya Alibaba Cloud Linux 2 (çekirdeği 4.19.91-25.1.al7.x86_64 sürümünden önce) ile IPVS modunda, UDP arka uç podlarının kaldırılması paketlerin düşmesine neden olan kaynak bağlantı noktası çakışmalarına yol açar. Düğüm veya CoreDNS ölçeklendirme olayları sırasında DNS arızaları yaklaşık 5 dakika sürer.

    İki çözüm:

    NodeLocal DNSCache çalışmıyor

    Aşağıdaki koşullardan biri geçerli olduğunda DNS sorguları NodeLocal DNSCache'i bypass eder:

    • dnsConfig uygulama podlarına enjekte edilmediğinden podlar hala kube-dns Hizmet IP'sini işaret ediyor.

    • Podlar bir Alpine Linux temel görüntüsü kullanıyor; bu görüntü, doğrudan CoreDNS dahil olmak üzere tüm nameserver'ları eşzamanlı olarak sorgular.

    İlk durum için otomatik dnsConfig enjeksiyonunu etkinleştirin. Bkz. NodeLocal DNSCache'i yapılandırma. Alpine görüntüleri için başka bir işletim sistemi üzerine oluşturulmuş bir görüntü kullanın. Bkz. Alpine uyarıları.

    Alibaba Cloud DNS PrivateZone adları çözümlenemiyor

    Alibaba Cloud DNS PrivateZone TCP yerine UDP gerektirir. NodeLocal DNSCache ile PrivateZone etki alanları, vpc-proxy API uç noktaları veya diğer etki alanı adları çözümlenemeyebilir veya yanlış IP'lere çözülebilir.

    Üst sorgular için UDP'yi zorlamak amacıyla CoreDNS yapılandırmasına prefer_udp seçeneğini ekleyin. Bkz. CoreDNS'i yapılandırma.

    Sonraki adımlar