Azure Kubernetes Service ile CoreDNS hizmetini özelleştirme

2025-06-20

Azure Kubernetes Service (AKS), tüm 1.12.x ve üzeri kümelerle küme DNS yönetimi ve çözümlemesi için CoreDNS projesini kullanır. CoreDNS özelleştirmesi ve Kubernetes hakkında daha fazla bilgi için resmi yukarı akış belgelerine bakın.

AKS yönetilen bir hizmet olduğundan CoreDNS ( CoreFile) için ana yapılandırmayı değiştiremezsiniz. Bunun yerine, varsayılan ayarları geçersiz kılmak için Kubernetes ConfigMap kullanırsınız. Varsayılan AKS CoreDNS ConfigMaps'i görmek için komutunu kullanın kubectl get configmaps --namespace=kube-system coredns -o yaml .

Bu makalede, AKS'de temel CoreDNS özelleştirme seçenekleri için ConfigMap'lerin nasıl kullanılacağı gösterilmektedir. Bu yaklaşım, CoreDNS'yi CoreFile gibi diğer bağlamlarda yapılandırmaktan farklıdır.

Not

Daha önce küme DNS yönetimi ve çözümlemesi için kube-dns kullanılıyordu, ancak artık kullanım dışı bırakılıyordu. kube-dns Kubernetes yapılandırma haritası aracılığıyla farklı özelleştirme seçenekleri sundu. CoreDNS, kube-dns ile geriye dönük olarak uyumlu değildir . Daha önce kullandığınız tüm özelleştirmeler CoreDNS için güncelleştirilmelidir.

Başlamadan önce

Bu makalede, mevcut bir AKS kümeniz olduğu varsayılır. AKS kümesine ihtiyacınız varsa Azure CLI, Azure PowerShell veya Azure portalını kullanarak bir küme oluşturabilirsiniz.
Çalıştırdığınız CoreDNS sürümünü doğrulayın. Yapılandırma değerleri sürümler arasında değişebilir.
Aşağıdaki örnekler gibi yapılandırmalar oluşturduğunuzda, veri bölümündeki adlarınızın .server veya .override ile bitmesi gerekir. Bu adlandırma kuralı, komutunu kullanarak kubectl get configmaps --namespace=kube-system coredns -o yaml görüntüleyebileceğiniz varsayılan AKS CoreDNS ConfigMap içinde tanımlanır.

Eklenti desteği

Tüm yerleşik CoreDNS eklentileri desteklenir. Hiçbir eklenti/üçüncü taraf eklentisi desteklenmez.

DNS'yi yeniden yazma

Anında DNS adı yeniden yazma işlemleri gerçekleştirmek için CoreDNS'yi AKS ile özelleştirebilirsiniz.

adlı corednsms.yaml bir dosya oluşturun ve aşağıdaki örnek yapılandırmayı yapıştırın. <domain to be rewritten> ile kendi tam etki alanı adınızı değiştirdiğinizden emin olun.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
    <domain to be rewritten>.com:53 {
    log
    errors
    rewrite stop {
      name regex (.*)\.<domain to be rewritten>\.com {1}.default.svc.cluster.local
      answer name (.*)\.default\.svc\.cluster\.local {1}.<domain to be rewritten>.com
    }
    forward . /etc/resolv.conf # you can redirect this to a specific DNS server such as 10.0.0.10, but that server must be able to resolve the rewritten domain name
    }

Önemli

CoreDNS hizmeti IP'si gibi bir DNS sunucusuna yeniden yönlendirirseniz, bu DNS sunucusunun yeniden yazılan etki alanı adını çözümleyebilmesi gerekir.

komutunu kullanarak ConfigMap'i kubectl apply configmap oluşturun ve YAML bildiriminizin adını belirtin.
```
kubectl apply -f corednsms.yaml
```
Özelleştirmelerin uygulandığını kubectl get configmaps kullanarak doğrulayın ve coredns-custom ConfigMap'inizi belirtin.
```
kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
```
ConfigMap'i yeniden yükleyip Kubernetes Scheduler'ın kapalı kalma süresi olmadan CoreDNS'yi yeniden başlatmasını sağlamak için sıralı bir yeniden başlatma kubectl rollout restart kullanarak gerçekleştirin.
```
kubectl -n kube-system rollout restart deployment coredns
```

Özel iletme sunucusu

Ağ trafiğiniz için bir iletme sunucusu belirtmeniz gerekiyorsa, DNS'yi özelleştirmek için bir ConfigMap oluşturabilirsiniz.

adlı corednsms.yaml bir dosya oluşturun ve aşağıdaki örnek yapılandırmayı yapıştırın. forward adı ve adresi kendi ortamınızın değerleriyle değiştirdiğinizden emin olun.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    <domain to be rewritten>.com:53 {
        forward foo.com 1.1.1.1
    }

komutunu kullanarak ConfigMap'i kubectl apply configmap oluşturun ve YAML bildiriminizin adını belirtin.
```
kubectl apply -f corednsms.yaml
```
ConfigMap'i yeniden yükleyip Kubernetes Scheduler'ın kapalı kalma süresi olmadan CoreDNS'yi yeniden başlatmasını sağlamak için sıralı bir yeniden başlatma kubectl rollout restart kullanarak gerçekleştirin.
```
kubectl -n kube-system rollout restart deployment coredns
```

Özel alan adlarını kullanma

Sadece dahili olarak çözülebilen özel etki alanlarını yapılandırmak isteyebilirsiniz. Örneğin, geçerli bir üst düzey etki alanı olmayan özel puglife.local etki alanını çözümlemek isteyebilirsiniz. Özel etki alanı ConfigMap olmadan AKS kümesi adresi çözümleyemez.

adlı corednsms.yaml yeni bir dosya oluşturun ve aşağıdaki örnek yapılandırmayı yapıştırın. Özel etki alanını ve IP adresini kendi ortamınızın değerlerine göre güncelleştirdiğinizden emin olun.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  puglife.server: | # you may select any name here, but it must end with the .server file extension
    puglife.local:53 {
        errors
        cache 30
        forward . 192.11.0.1  # this is my test/dev DNS server
    }

komutunu kullanarak ConfigMap'i kubectl apply configmap oluşturun ve YAML bildiriminizin adını belirtin.
```
kubectl apply -f corednsms.yaml
```
ConfigMap'i yeniden yükleyip Kubernetes Scheduler'ın kapalı kalma süresi olmadan CoreDNS'yi yeniden başlatmasını sağlamak için sıralı bir yeniden başlatma kubectl rollout restart kullanarak gerçekleştirin.
```
kubectl -n kube-system rollout restart deployment coredns 
```

Kısmi etki alanları

CoreDNS, kısmi etki alanlarını yapılandırmak için de kullanılabilir.

adlı corednsms.yaml bir dosya oluşturun ve aşağıdaki örnek yapılandırmayı yapıştırın. Özel etki alanlarını ve IP adreslerini kendi ortamınızın değerleriyle güncellemeniz gerektiğinden emin olun.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    abc.com:53 {
     errors
     cache 30
     forward . 1.2.3.4
    }
    my.cluster.local:53 {
        errors
        cache 30
        forward . 2.3.4.5
    }

komutunu kullanarak ConfigMap'i kubectl apply configmap oluşturun ve YAML bildiriminizin adını belirtin.
```
kubectl apply -f corednsms.yaml
```
ConfigMap'i yeniden yükleyip Kubernetes Scheduler'ın kapalı kalma süresi olmadan CoreDNS'yi yeniden başlatmasını sağlamak için sıralı bir yeniden başlatma kubectl rollout restart kullanarak gerçekleştirin.
```
kubectl -n kube-system rollout restart deployment coredns
```

Konaklar eklentisi

Tüm yerleşik eklentiler desteklenir, bu nedenle CoreDNS konakları eklentisi /etc/hosts'ı da özelleştirmek için kullanılabilir.

adlı corednsms.yaml bir dosya oluşturun ve aşağıdaki örnek yapılandırmayı yapıştırın. IP adreslerini ve ana bilgisayar adlarını kendi ortamınızın değerleriyle güncelleştirdiğinden emin olun.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    test.override: | # you may select any name here, but it must end with the .override file extension
          hosts { 
              10.0.0.1 example1.org
              10.0.0.2 example2.org
              10.0.0.3 example3.org
              fallthrough
          }

komutunu kullanarak ConfigMap'i kubectl apply configmap oluşturun ve YAML bildiriminizin adını belirtin.
```
kubectl apply -f corednsms.yaml
```
ConfigMap'i yeniden yükleyip Kubernetes Scheduler'ın kapalı kalma süresi olmadan CoreDNS'yi yeniden başlatmasını sağlamak için sıralı bir yeniden başlatma kubectl rollout restart kullanarak gerçekleştirin.
```
kubectl -n kube-system rollout restart deployment coredns
```

internal.cloudapp.net ve reddog.microsoft.com için geçersiz arama etki alanı tamamlamaları

Azure DNS, Azure DNS kullanarak sanal ağlarda varsayılan bir arama etki alanı <vnetId>.<region>.internal.cloudapp.net yapılandırır ve özel DNS sunucuları kullanan sanal ağlarda işlevsel olmayan bir saplama reddog.microsoft.com oluşturur (daha fazla ayrıntı için kaynaklar için ad çözümleme belgelerine bakın). Kubernetes, ndots: 5 ile pod DNS ayarlarını, küme hizmeti ana bilgisayar adı çözümlemesini düzgün bir şekilde destekleyecek şekilde yapılandırmaktadır. Bu iki yapılandırma, sistem etki alanı arama listesini işlerken hiçbir zaman başarılı olmayan geçersiz arama etki alanı tamamlama sorgularının yukarı akış adı sunucularına gönderilmesine neden olur. Bu geçersiz sorgular ad çözümleme gecikmelerine neden olur ve yukarı akış DNS sunucularına ek yük yükleyebilir.

v20241025 AKS sürümünden itibaren AKS, bu geçersiz arama etki alanı tamamlama sorgularının yukarı akış DNS'sine iletilmesini önlemek için aşağıdaki iki durumda CoreDNS'yi NXDOMAIN ile yanıt verecek şekilde yapılandırıyor:

Kök etki alanı veya alt etki reddog.microsoft.comalanı için herhangi bir sorgu.
internal.cloudapp.net alanının alt etki alanı için, etki alanı adında yedi veya daha fazla etiket bulunan herhangi bir sorgu.
- Bu yapılandırma, konak adına göre sanal makine çözümlemenin yine başarılı olmasını sağlar. Örneğin, CoreDNS Azure DNS'ye (6 etiket) gönderir aks12345.myvnetid.myregion.internal.cloudapp.net ancak reddeder mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 etiket)

Bu blok, kümenin Corefile dosyasındaki varsayılan sunucu bloğunda uygulanır. Gerekirse, bu reddetme yapılandırması uygun etki alanı için özel sunucu blokları oluşturularak ve ileriye doğru eklenti etkinleştirilerek devre dışı bırakılabilir:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.cloudapp.net:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

komutunu kullanarak ConfigMap'i kubectl apply configmap oluşturun ve YAML bildiriminizin adını belirtin.
```
kubectl apply -f corednsms.yaml
```
ConfigMap'i yeniden yükleyip Kubernetes Scheduler'ın kapalı kalma süresi olmadan CoreDNS'yi yeniden başlatmasını sağlamak için sıralı bir yeniden başlatma kubectl rollout restart kullanarak gerçekleştirin.
```
kubectl -n kube-system rollout restart deployment coredns
```

Sorun giderme

Uç noktaları veya çözümü denetleme gibi genel CoreDNS sorun giderme adımları için bkz . DNS çözümlemesinde hata ayıklama.

CoreDNS yatay pod ölçeklendirmesini yapılandırma

AKS kümeleri içindeki DNS trafiğindeki ani ani artışlar, AKS'nin iş yükleri için sağladığı esneklik nedeniyle sık karşılaşılan bir durumdur. Bu ani artışlar CoreDNS podlarının bellek tüketiminde artışa neden olabilir. Bazı durumlarda bu artan bellek tüketimi sorunlara neden Out of memory olabilir. Aks kümeleri bu sorunu önceden ele almak için CoreDNS podlarını otomatik olarak ölçeklendirin ve pod başına bellek kullanımını azaltın. Bu otomatik ölçeklendirme mantığının varsayılan ayarları ConfigMap'te coredns-autoscaler depolanır. Ancak, CoreDNS podlarının varsayılan otomatik ölçeklendirmesinin, CoreDNS podlarınızın sorunlarını önlemek Out of memory için her zaman yeterince agresif olmadığını gözlemleyebilirsiniz. Bu durumda, doğrudan ConfigMap'i coredns-autoscaler değiştirebilirsiniz. Sorunun kök nedenini ele almadan CoreDNS podlarının sayısını artırmanın Out of memory yalnızca geçici bir düzeltme sağlayabileceğini lütfen unutmayın. CoreDNS podlarının çalıştığı düğümlerde yeterli bellek yoksa, CoreDNS podlarının sayısını artırmak yararlı olmaz. Daha fazla araştırma yapmanız ve kaynak kullanımını iyileştirme, kaynak isteklerini ve sınırlarını ayarlama veya düğümlere daha fazla bellek ekleme gibi uygun çözümleri uygulamanız gerekebilir.

CoreDNS, pod otomatik ölçeklendirmesi için yatay küme orantılı otomatik ölçeklendiricisi kullanır. coredns-autoscaler ConfigMap, CoreDNS podlarının sayısı için ölçeklendirme mantığını yapılandırmak üzere düzenlenebilir. coredns-autoscaler ConfigMap şu anda iki farklı ConfigMap anahtar değerini destekler: linear ve ladder desteklenen iki denetim moduna karşılık gelir. Denetleyici , linear ile eşdeğer [min,max] aralığında bir dizi çoğaltma verir max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ). Denetleyici ladder , biri çekirdek ölçeklendirme ve diğeri düğüm ölçeklendirme için iki farklı adım işlevine başvurarak çoğaltma sayısını hesaplar ve iki çoğaltma değerinin en yüksek değerini verir. Denetim modları ve ConfigMap biçimi hakkında daha fazla bilgi için lütfen yukarı akış belgelerine bakın.

Önemli

Küme başına en az 2 CoreDNS pod replika önerilir. En az 1 CoreDNS pod çoğaltmasının yapılandırılması, küme yükseltme işlemleri gibi düğüm boşaltma gerektiren işlemler sırasında hatalara neden olabilir.

ConfigMap'i coredns-autoscaler almak için kubectl get configmap coredns-autoscaler -n kube-system -o yaml komutunu çalıştırabilirsiniz, bu da aşağıdaki çıktıyı verecektir:

apiVersion: v1
data:
  ladder: '{"coresToReplicas":[[1,2],[512,3],[1024,4],[2048,5]],"nodesToReplicas":[[1,2],[8,3],[16,4],[32,5]]}'
kind: ConfigMap
metadata:
  name: coredns-autoscaler
  namespace: kube-system
  resourceVersion: "..."
  creationTimestamp: "..."

CoreDNS dikey podların otomatik ölçeklendirme davranışı

CoreDNS, AKS tarafından yönetilen ve varsayılan olarak etkinleştirilen temel bir eklentidir. CoreDNS hizmetinin kullanılabilirliğini korumak için CoreDNS, CoreDNS pod yeniden başlatma işleminin hizmetin kullanılamamasına neden olmasını önlemek için eklenti otomatik ölçeklendirme özelliğini etkinleştirirken sağlanan özgün kaynak isteklerinin/sınırlarının kullanımını korur.

AKS tarafından yönetilen CoreDNS eklentisi için varsayılan CPU istekleri/sınırları 100m /3 çekirdek ve bellek istekleri/sınırları 70Mi/500Mi olarak ayarlanır. Bu varsayılan değerlere bağlı olarak CPU için istek-sınır oranı yaklaşık 1:30'dır ve bellek için ise yaklaşık 1/7'dir. Önerilen CPU istekleri 500m ise VPA, bu oranı korumak için CPU sınırlarını 15 olarak ayarlar. Benzer şekilde, önerilen bellek istekleri 700Mi ise, VPA bellek sınırını 5000Mi olarak ayarlar.

VPA, CoreDNS CPU ve bellek sınırlarını VPA tarafından önerilen CPU/Mem isteğine ve AKS tanımlı istek-sınır oranına göre büyük değerlere ayarlar. Bu ayarlamalar, yoğun hizmet zamanlarında birden çok isteği işlemek için yararlıdır. Bunun dezavantajı, CoreDNS'nin hizmet süresinin en yoğun olduğu durumlarda düğümdeki kullanılabilir tüm CPU ve belleği kullanabilecek olmasıdır.

Hem büyük hem de küçük küme gereksinimlerini aynı anda karşılamak için tek bir ideal CPU ve bellek istekleri/sınırları değeri ayarlamak zordur. İyileştirilmiş eklenti ölçeklendirmesini etkinleştirerek CoreDNS CPU ve bellek isteklerini/sınırlarını özelleştirme veya belirli küme gereksinimlerini karşılamak üzere CoreDNS'yi otomatik ölçeklendirmek için VPA kullanma esnekliğine sahipsiniz. Dikkate alınması gereken bazı senaryolar şunlardır:

VPA'nın CoreDNS hizmetiniz için uygun olup olmadığını düşünüyor ve yalnızca VPA önerilerini görüntülemek istiyorsunuz. VPA'nın podları otomatik olarak güncelleştirmesini istemiyorsanız VPA güncelleştirme modunu geçersiz kıl ayarını Kapalı olarak etkinleştirerek CoreDNS için VPA'yi devre dışı bırakabilirsiniz. CPU/bellek isteklerini/sınırlarını tercih ettiğiniz değere ayarlamak için Dağıtım'daki kaynak yapılandırmasını özelleştirin.
VPA kullanmayı düşünüyorsanız ancak VPA'nın CPU ve bellek sınırını aynı anda büyük değerlere çarpmaması için istek sınırı oranını kısıtlamak istiyorsunuz. Dağıtım'daki kaynakları özelleştirebilir ve istek sınırı oranını 1/2 veya 1/3'e korumak için CPU ve bellek istekleri/sınırları değerini güncelleştirebilirsiniz.
VPA kapsayıcı ilkesi maxAllowed CPU ve belleği ayarlarsa, önerilen kaynak istekleri bu sınırları aşmaz. Kaynak yapılandırmasını özelleştirmek maxAllowed değerlerini artırmanıza veya azaltmanıza ve VPA'nın önerilerini denetlemenize olanak tanır.

Daha fazla bilgi için bkz. AKS kümenizde eklenti otomatik ölçeklendirmeyi etkinleştirme (Önizleme).

DNS sorgu günlüğünü etkinleştirme

Coredns-custom ConfigMap'inize aşağıdaki yapılandırmayı ekleyin:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # you may select any name here, but it must end with the .override file extension
        log

Yapılandırma değişikliklerini uygulayın ve aşağıdaki komutları kullanarak CoreDNS'yi ConfigMap'i yeniden yüklemeye zorlar:

# Apply configuration changes
kubectl apply -f corednsms.yaml

# Force CoreDNS to reload the ConfigMap
kubectl -n kube-system rollout restart deployment coredns

CoreDNS hata ayıklama günlüğünü, kubectl logs komutunu kullanarak görüntüleyin.
```
kubectl logs --namespace kube-system -l k8s-app=kube-dns
```

CoreDNS pod trafiği dengesizliği sorunlarını giderme

AKS kümenizde birden çok CoreDNS podu çalışıyor olsa bile bir veya iki CoreDNS pod'unda önemli ölçüde daha yüksek CPU kullanımı olduğunu ve diğerlerinden daha fazla DNS sorgusu işlendiğini görebilirsiniz. Bu, Kubernetes'te bilinen bir sorundur ve CoreDNS podlarından birinin aşırı yüklenmesine ve kilitlenmesine neden olabilir.

DNS sorgularının bu eşit olmayan dağıtımı öncelikle Kubernetes'teki UDP yük dengeleme sınırlamalarından kaynaklanır. Platform UDP trafiğini dağıtmak için beş tanımlama grubu karması (kaynak IP, kaynak bağlantı noktası, hedef IP, hedef bağlantı noktası, protokol) kullanır. Bu nedenle bir uygulama DNS sorguları için aynı kaynak bağlantı noktasını yeniden kullanırsa, bu istemciden gelen tüm sorgular aynı CoreDNS poduna yönlendirilir ve tek bir pod orantısız miktarda trafiği işler.

Ayrıca, bazı uygulamalar bağlantı havuzunu kullanır ve DNS bağlantılarını yeniden kullanır. Bu davranış, DNS sorgularını tek bir CoreDNS pod'una daha fazla yoğunlaştırarak dengesizliği artırır ve aşırı yükleme ve olası kilitlenme riskini artırır.

CoreDNS pod trafik dağıtımınızı denetleme

Başlamadan önce, CoreDNS podlarından gerekli DNS sorgu günlüklerini yakalamak için yukarıdaki DNS sorgu günlüğünü etkinleştirme bölümündeki adımları izleyin. Bu etkinleştirildikten sonra aşağıdaki komutları çalıştırın:

Kümenizdeki tüm CoreDNS podlarının adlarını almak için aşağıdaki komutu çalıştırın:
```
kubectl get pods --namespace kube-system -l k8s-app=kube-dns
```

DNS sorgu desenlerini analiz etmek için her CoreDNS podunun günlüklerini gözden geçirin:

kubectl logs --namespace kube-system <coredns-pod1>
kubectl logs --namespace kube-system <coredns-pod2>
# Repeat on all CoreDNS pods

Yalnızca tek bir CoreDNS podunun günlüklerinde görünen yinelenen istemci IP adreslerini ve bağlantı noktalarını arayın. Bu, belirli istemcilerden gelen DNS sorgularının eşit olarak dağıtılmadığını gösterir.

Örnek günlük girdisi:
```
[INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
```
- 10.244.0.247: DNS sorgusunu yapan istemci IP adresi
- 5556: İstemci kaynak bağlantı noktası
- 42621: Sorgu Kimliği
Aynı istemci IP'sini ve bağlantı noktasını yalnızca bir pod'un günlüklerinde tekrar tekrar görürseniz, bu bir trafik dengesizliği olduğunu doğrular.

Bu dengesizliği fark ederseniz uygulamanız UDP kaynak bağlantı noktalarını yeniden kullanıyor veya bağlantılarını havuza ediyor olabilir. Kök nedene bağlı olarak aşağıdaki risk azaltma eylemlerini gerçekleştirebilirsiniz:

UDP kaynak bağlantı noktasının yeniden kullanımı nedeniyle oluştu:

BIR istemci uygulaması aynı UDP kaynak bağlantı noktasından birden çok DNS sorgusu gönderdiğinde UDP kaynak bağlantı noktasının yeniden kullanılması gerçekleşir. Sorun buysa, uygulamalarınızı veya DNS istemcilerinizi her DNS sorgusu için kaynak bağlantı noktalarını rastgele dağıtacak şekilde güncelleştirin ve bu da istekleri podlar arasında daha eşit bir şekilde dağıtmanıza yardımcı olur.
Bağlantı havuzundan kaynaklanır:
Bağlantı havuzları, uygulamalar tarafından her istek için yeni bir bağlantı oluşturmak yerine mevcut ağ bağlantılarını yeniden kullanmak için kullanılan mekanizmalardır. Bu, verimliliği artırırken, bir uygulamadan gelen tüm DNS sorgularının aynı bağlantı üzerinden gönderilmesine ve bu nedenle aynı CoreDNS pod'a yönlendirilmeye neden olabilir. Bunu azaltmak için, bağlantı TTL'lerini (Yaşam Süresi) azaltarak veya bağlantı oluşturmayı rastgele belirleyerek, sorguların tek bir CoreDNS pod'una odaklanmadığından emin olarak uygulamanızın DNS bağlantı işlemesini ayarlayın.

Bu değişiklikler daha dengeli bir DNS sorgu dağıtımına yardımcı olabilir ve tek tek podları aşırı yükleme riskini azaltabilir.

Sonraki adımlar

Bu makalede CoreDNS özelleştirmesi için bazı örnek senaryolar gösterildi. CoreDNS projesi hakkında bilgi için CoreDNS yukarı akış projesi sayfasına bakın.

Temel ağ kavramları hakkında daha fazla bilgi edinmek için bkz . AKS'deki uygulamalar için ağ kavramları.