Container Service for Kubernetes:DNS best practices

DNS en iyi uygulamaları hem istemci tarafı hem de sunucu tarafı optimizasyonlarını kapsar:

• İstemci tarafında, uygun konteyner görüntüleri, düğüm işletim sistemleri ve NodeLocal DNSCache kullanarak alan adı çözümleme isteklerini optimize edebilir, gecikme süresini azaltabilir ve çözümleme hatalarını en aza indirebilirsiniz.

  • Alan adı çözümleme isteklerini optimize edin

  • Konteynerlerdeki DNS yapılandırmalarını anlayın

  • IPVS hatalarından kaynaklanan aralıklı DNS çözümleme zaman aşımlarından kaçının

  • NodeLocal DNSCache kullanın

  • Uygun bir CoreDNS sürümü kullanın

• CoreDNS sunucu tarafında, CoreDNS çalışma durumunu izleyerek DNS istisnalarını tespit edebilir ve kök nedenlerini hızla bulabilirsiniz. Ayrıca yüksek kullanılabilirliği ve saniye başına sorgu (QPS) aktarım hızını artırmak için CoreDNS dağıtımını ayarlayabilirsiniz.

  • CoreDNS çalışma durumunu izleyin

    • Ölçümler

    • Günlükler

    • Kubernetes olay iletimi

  • CoreDNS yüksek kullanılabilirliğini sağlayın

    • CoreDNS bileşeni baskısını değerlendirin

    • CoreDNS pod sayısını ayarlayın

    • CoreDNS pod teknik özelliklerini ayarlayın

    • CoreDNS pod'larını zamanlayın

  • CoreDNS yapılandırmalarını optimize edin

    • kube-dns Hizmeti için oturum bağlılığını devre dışı bırakın

    • autopath eklentisini devre dışı bırakın

    • CoreDNS için sorunsuz kapatmayı yapılandırın

    • forward eklentisi ve upstream VPC DNS sunucuları için varsayılan protokolü yapılandırın

    • Hazır durum denetimleri için ready eklentisini yapılandırın

DNS çözümleme, bir Kubernetes kümesindeki en sık yapılan ağ işlemlerinden biridir. Bu isteklerin çoğu optimize edilebilir veya önlenebilir; böylece DNS altyapısındaki gecikme süresi ve yük azaltılır. Alan adı çözümleme isteklerini aşağıdaki yollarla optimize edebilirsiniz:

• (Önerilir) Bağlantı havuzları kullanın: Konteyner uygulamanız başka bir hizmeti sık sık istediğinde, upstream hizmetlere yönelik aktif bağlantıları bellekte önbelleğe almak için bir bağlantı havuzu kullanın. Bu, her istek için DNS çözümlemesi ve TCP el sıkışması ek yükünü ortadan kaldırır.

• Bir alan adı için IP adreslerini elde etmek üzere eşzamansız veya uzun oylama (long-polling) modu kullanın.

• DNS önbellekleme kullanın:

  • (Önerilir) Uygulamanız bağlantı havuzu kullanacak şekilde değiştirilemiyorsa, uygulama tarafında DNS çözümleme sonuçlarını önbelleğe almayı düşünün. Daha fazla bilgi için bkz. NodeLocal DNSCache kullanın.

  • NodeLocal DNSCache kullanamıyorsanız, konteynerlerinizde yerleşik Name Service Cache Daemon (NSCD) önbelleğini kullanabilirsiniz. Daha fazla bilgi için bkz. Kubernetes kümelerinde NSCD kullanma.

• resolv.conf dosyasını optimize edin: resolv.conf dosyasındaki ndots ve search parametrelerinin mekanizmaları nedeniyle, bir konteynerde alan adlarını yazma biçiminiz çözümleme verimliliğini belirler. ndots ve search parametrelerinin mekanizmaları hakkında daha fazla bilgi için bkz. DNS İlkesi Yapılandırması ve Alan Adı Çözümleme.

• Alan adı yapılandırmalarını optimize edin: Bir konteynerdeki bir uygulama bir alan adına eriştiğinde, çözümleme denemelerini en aza indirmek ve çözümleme gecikme süresini azaltmak için şu şekilde yapılandırın.

  • Bir pod'dan aynı ad alanındaki bir Service'e erişmek için <service-name> kullanın; burada service-name Service'in adıdır.

  • Bir pod'dan farklı bir ad alanındaki bir Service'e erişmek için <service-name>.<namespace-name> kullanın; burada namespace-name Service'in bulunduğu ad alanıdır.

  • Bir pod harici bir alan adına eriştiğinde, search listesinden alan adlarının eklenmesi nedeniyle oluşan birden çok geçersiz DNS aramasını önlemek için sonunda nokta (.) bulunan Tam Nitelikli Alan Adı (FQDN) kullanın. Örneğin, www.aliyun.com adresine erişmek için FQDN'si olan www.aliyun.com. kullanın.

    • Kubernetes 1.22 veya sonraki sürümleri çalıştıran kümelerde, benzer bir etki elde etmek için arama alanını tek bir nokta (.) olarak yapılandırabilirsiniz (bkz. Issue 125883):

      dnsPolicy: None
      dnsConfig:
        nameservers: ["192.168.0.10"]  ## Replace with the actual ClusterIP of your CoreDNS Service.
        searches:
        - .
        - default.svc.cluster.local  ## Note: Replace default with the actual namespace.
        - svc.cluster.local
        - cluster.local

      Yukarıdaki yapılandırmayı uyguladıktan sonra, pod'daki /etc/resolv.conf dosyası aşağıdaki gibi yapılandırılır:

      search . default.svc.cluster.local svc.cluster.local cluster.local
      nameserver 192.168.0.10

      İlk arama alanı "." şeklindedir; bu, çözücünün hedef alan adını FQDN olarak ele almasını sağlar. Çözücü, gereksiz arama alanı genişletmelerini atlayarak önce alan adını olduğu gibi çözümlemeye çalışır.

      Önemli

      Yukarıdaki yapılandırmanın etkili olması için dnsPolicy değerini None olarak ayarlamanız gerekir.

      Tam iş yükü örneği

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: nginx
        name: nginx
        namespace: default
      spec:
        progressDeadlineSeconds: 600
        replicas: 3
        revisionHistoryLimit: 10
        selector:
          matchLabels:
            app: nginx
        strategy:
          rollingUpdate:
            maxSurge: 25%
            maxUnavailable: 25%
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
              imagePullPolicy: Always
              name: nginx
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: None
            dnsConfig:
              nameservers: ["192.168.0.10"]  ## Replace with the actual ClusterIP of your CoreDNS Service.
              searches:
              - .
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
            hostname: nginx
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            subdomain: subdomain
            terminationGracePeriodSeconds: 30

IPVS hatasının etkisini azaltmak için aşağıdaki yöntemlerden birini kullanabilirsiniz:

• NodeLocal DNSCache kullanın. Daha fazla bilgi için bkz. NodeLocal DNSCache kullanın.

• kube-proxy içindeki IPVS UDP oturum kalıcılığı için zaman aşımı süresini değiştirin. Daha fazla bilgi için bkz. kube-proxy içindeki IPVS UDP oturum kalıcılığı için zaman aşımı süresini nasıl değiştiririm?.

CoreDNS, Kubernetes sürümleriyle iyi bir geriye dönük uyumluluk sunar. CoreDNS'i en son kararlı sürüme güncel tutun. ACK konsolundaki Add-ons sayfası CoreDNS'i yüklemenize, yükseltmenize ve yapılandırmanıza olanak tanır. Add-ons sayfasında CoreDNS bileşeninin durumunu kontrol edin. Yükseltme mevcutsa, yükseltmeyi yoğun olmayan saatlerde planlayın.

• CoreDNS'i nasıl yükselteceğiniz hakkında daha fazla bilgi için bkz. Yönetilmeyen CoreDNS için otomatik yükseltme.

• CoreDNS sürüm notları için bkz. CoreDNS.

v1.7.0 öncesi CoreDNS sürümleri, aşağıdakiler dahil olmak üzere birkaç potansiyel risk taşır:

• CoreDNS ile API sunucusu arasındaki bağlantı anormal olduğunda (örneğin API sunucusu yeniden başlatmaları, geçişler veya ağ dalgalanmaları nedeniyle), CoreDNS hata günlüklerini yazamadığı için yeniden başlatılabilir. Daha fazla bilgi için bkz. Set klog's logtostderr flag.

• CoreDNS başlangıçta ekstra bellek tüketir. Varsayılan bellek sınırı, büyük ölçekli kümelerde bellek yetersizliği (OOM) sorunlarını tetikleyebilir. Ağır durumlarda bu, CoreDNS pod'larının yeniden başlatma döngüsüne girmesine ve kurtulamamasına neden olabilir. Daha fazla bilgi için bkz. CoreDNS uses a lot memory during initialization phase.

• CoreDNS, headless Service alan adlarının ve küme dışı alan adlarının çözümlemesini etkileyebilecek birkaç soruna sahiptir. Daha fazla bilgi için bkz. plugin/kubernetes: handle tombstones in default processor ve Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection.

• Bir küme düğümü anormal hale gelirse, bazı eski CoreDNS sürümlerindeki varsayılan tolerasyon ilkesi CoreDNS pod'larının anormal düğüme zamanlanmasına neden olabilir. Bu pod'lar otomatik olarak tahliye edilemez ve bu durum DNS çözümleme hatalarına yol açar.

Önerilen minimum CoreDNS sürümü, kümenin Kubernetes sürümüne bağlı olarak değişir.

Ölçümler

CoreDNS, çözümleme sonuçları dahil olmak üzere sağlık ölçümlerini standart bir Prometheus arayüzü aracılığıyla sunar. Bu, CoreDNS sunucusundaki ve hatta upstream DNS sunucularındaki anormallikleri tespit etmeye yardımcı olur.

Managed Service for Prometheus CoreDNS için yerleşik ölçüm izleme panoları ve uyarı kuralları sağlar. Prometheus ve pano özelliklerini ACK konsolunda etkinleştirebilirsiniz. Daha fazla bilgi için bkz. CoreDNS bileşenini izleme.

Kubernetes kümenizi izlemek için kendi kendine yönetilen bir Prometheus örneği kullanıyorsanız, ilgili ölçümleri Prometheus'ta gözlemleyebilir ve önemli göstergeler için uyarılar ayarlayabilirsiniz. Daha fazla bilgi için bkz. Prometheus için resmi CoreDNS belgeleri.

Günlükler

Bir DNS anormalliği durumunda, CoreDNS günlükleri kök nedeni hızlı bir şekilde teşhis etmenize yardımcı olabilir. CoreDNS alan adı çözümleme günlüğünü etkinleştirmenizi ve günlüklerinizi Log Service ile toplamanızı öneririz. Daha fazla bilgi için bkz. CoreDNS günlüklerini analiz etme ve izleme.

Kubernetes olay iletimi

CoreDNS v1.9.3.6-32932850-aliyun ve sonraki sürümlerde, kritik CoreDNS günlüklerini Kubernetes olayları olarak Event Center'a iletmek için k8s_event eklentisini etkinleştirebilirsiniz. k8s_event eklentisi hakkında daha fazla bilgi için bkz. k8s_event.

Bu özellik, yeni CoreDNS dağıtımlarında varsayılan olarak etkindir. Daha eski bir sürümden CoreDNS v1.9.3.6-32932850-aliyun veya sonraki bir sürüme yükseltiyorsanız, bunu etkinleştirmek için yapılandırma dosyasını manuel olarak değiştirmeniz gerekir.

1. CoreDNS yapılandırma dosyasını açmak için aşağıdaki komutu çalıştırın.

   kubectl -n kube-system edit configmap/coredns

2. kubeapi ve k8s_event eklentilerini ekleyin.

   apiVersion: v1
   data:
     Corefile: |
       .:53 {
           errors
           health {
               lameduck 15s
           }
           // Start of addition (ignore other differences).
           kubeapi
           k8s_event {
             level info error warning // Deliver critical logs with info, error, and warning statuses.
           }
           // End of addition.
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // ... (remaining content omitted)
       }

3. CoreDNS pod'larının çalışma durumunu ve günlüklerini kontrol edin. Günlüklerde reload kelimesi varsa, değişiklik başarılı olmuştur.

CoreDNS bileşeni baskısını değerlendirin

Bileşen baskısını değerlendirmek için kümede bir DNS stres testi gerçekleştirebilirsiniz. DNSPerf dahil olmak üzere birçok açık kaynak araç bu konuda size yardımcı olabilir. Kümenizdeki DNS baskısını doğru bir şekilde değerlendiremiyorsanız aşağıdaki önerileri izleyin.

• CoreDNS pod sayısını her zaman en az 2 olarak ayarlayın ve tek bir pod için en az 1 çekirdek ve 1 GiB kaynak sınırı belirleyin.

• CoreDNS'in alan adı çözümleme QPS değeri CPU tüketimiyle pozitif korelasyona sahiptir. NodeLocal DNSCache etkinleştirildiğinde, her CPU çekirdeği 10.000'den fazla QPS'yi destekleyebilir. Alan adı istekleri için QPS talebi, farklı hizmet türleri arasında önemli ölçüde değişir. Her CoreDNS pod'unun tepe CPU kullanımını gözlemleyebilirsiniz. Bir pod yoğun saatlerde bir CPU çekirdeğinden fazla kullanıyorsa, CoreDNS çoğaltmalarını ölçeklendirmenizi öneririz. Tepe CPU kullanımını belirleyemiyorsanız, pod'lar ile küme düğümleri arasında konservatif olarak 1:8 oranını kullanabilirsiniz. Yani, eklediğiniz her 8 küme düğümü için bir CoreDNS pod'u ekleyin.

CoreDNS pod sayısını ayarlayın

CoreDNS pod sayısı, CoreDNS'in kullanabileceği hesaplama kaynaklarını doğrudan belirler. Değerlendirmenize göre CoreDNS pod sayısını ayarlayabilirsiniz.

• Önerilen ilkeye göre otomatik olarak ayarlama

  Aşağıdaki dns-autoscaler öğesini dağıtabilirsiniz. Bu araç, önerilen ilkeye (pod'lar ile küme düğümleri arasında 1:8 oranı) göre CoreDNS pod sayısını gerçek zamanlı olarak otomatik ayarlar. Pod sayısı şu formül kullanılarak hesaplanır: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)) ve max ve min parametreleriyle sınırlıdır.

  dns-autoscaler

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: dns-autoscaler
    namespace: kube-system
    labels:
      k8s-app: dns-autoscaler
  spec:
    selector:
      matchLabels:
        k8s-app: dns-autoscaler
    template:
      metadata:
        labels:
          k8s-app: dns-autoscaler
      spec:
        serviceAccountName: admin
        containers:
        - name: autoscaler
          image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
          resources:
            requests:
              cpu: "200m"
              memory: "150Mi"
          command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --nodelabels=type!=virtual-kubelet
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=9

• Manuel olarak ayarlama

  CoreDNS pod sayısını manuel olarak ayarlamak için aşağıdaki komutu çalıştırabilirsiniz.

  kubectl scale --replicas={target} deployment/coredns -n kube-system # Replace {target} with the desired number of pods.

• İş yükü otomatik ölçeklendirmeyi kullanmayın

  Horizontal Pod Autoscaler (HPA) ve CronHPA gibi iş yükü otomatik ölçeklendirme özellikleri pod sayısını otomatik olarak ayarlayabilse de, bunlar sık ölçeklendirme işlemleri gerçekleştirir. Pod'ların ölçeği indirildiğinde oluşan çözümleme istisnaları nedeniyle, CoreDNS pod sayısını kontrol etmek için iş yükü otomatik ölçeklendirmeyi kullanmayın.

CoreDNS pod teknik özelliklerini ayarlayın

CoreDNS kaynaklarını ayarlamanın bir diğer yolu da pod teknik özelliklerini değiştirmektir. Bir ACK yönetilen Pro kümesinde, CoreDNS pod'ları için varsayılan bellek sınırı 2Gi olup CPU sınırı yoktur. CPU sınırını en az 1024m olacak şekilde 4096m olarak ayarlayın. CoreDNS pod yapılandırmasını konsolda ayarlayabilirsiniz.

CoreDNS pod'larını zamanlayın

Tek düğüm veya tek kullanılabilirlik alanı arızalarından kaçınmak için CoreDNS pod'larını farklı kullanılabilirlik alanlarına ve küme düğümlerine dağıtmanızı öneririz. v1.8.4.3 öncesi CoreDNS bileşen sürümleri, düğüm düzeyinde varsayılan bir yumuşak anti-affinity ilkesine sahiptir; bu durum, kaynaklar yetersiz kaldığında bazı veya tüm pod'ların aynı düğüme dağıtılmasına neden olabilir. Böyle bir durumda, pod'ları silerek yeniden zamanlamayı tetikleyin veya bileşeni en son sürüme yükseltin. v1.8 öncesi CoreDNS bileşen sürümleri artık bakımı yapılmamaktadır ve mümkün olan en kısa sürede yükseltilmelidir.

CoreDNS'in çalıştığı küme düğümlerinin CPU veya belleği tamamen kullanılmamalıdır, çünkü bu durum alan adı çözümlemesinin QPS değerini ve yanıt gecikme süresini etkiler. Küme düğümü koşulları izin verdiğinde, stabil bir alan adı çözümleme hizmeti sağlamak için özel parametreler kullanarak CoreDNS'i özel küme düğümlerine zamanlamayı düşünün.

Daha eski Kubernetes küme sürümleriyle dağıtılan varsayılan CoreDNS yapılandırmalarında bazı riskler olabilir. Bunları aşağıdaki gibi kontrol edin ve optimize edin:

• kube-dns Hizmeti için oturum bağlılığını devre dışı bırakın

• autopath eklentisini devre dışı bırakın

• CoreDNS için sorunsuz kapatmayı yapılandırın

• forward eklentisi ve upstream VPC DNS sunucuları için varsayılan protokolü yapılandırın

• Hazır durum denetimleri için ready eklentisini yapılandırın

kube-dns için oturum bağlılığını devre dışı bırakın

autopath eklentisini devre dışı bırakın

CoreDNS'in bazı eski sürümleri autopath eklentisini etkinleştirmiştir; bu durum bazı uç durumlarda çözümleme hatalarına neden olabilir. Etkin olup olmadığını kontrol edin ve devre dışı bırakmak için yapılandırma dosyasını düzenleyin. Daha fazla bilgi için bkz. Autopath.

1. CoreDNS yapılandırma dosyasını açmak için kubectl -n kube-system edit configmap coredns komutunu çalıştırın.

2. autopath @kubernetes satırını silin ve dosyayı kaydedin.

3. CoreDNS pod'larının çalışma durumunu ve günlüklerini kontrol edin. Günlüklerde reload kelimesi varsa, değişiklik başarılı olmuştur.

Sorunsuz kapatmayı yapılandırın

lameduck, CoreDNS'te sorunsuz kapatmayı sağlayan bir mekanizmadır. CoreDNS'in durması veya yeniden başlaması gerektiğinde, devam eden isteklerin ani bir şekilde kesilmeden tamamlanmasını garanti eder. lameduck şu şekilde çalışır:

• Bir CoreDNS işlemi sonlanmak üzereyken Lameduck moduna girer.

• lameduck modunda, CoreDNS yeni istekleri kabul etmeyi durdurur ancak mevcut isteklerin tümü tamamlanana veya lameduck zaman aşımı süresi dolana kadar işlemeye devam eder.

forward eklentisi için varsayılan protokolü yapılandırın

NodeLocal DNSCache, CoreDNS ile iletişim kurmak için TCP kullanır. CoreDNS daha sonra upstream DNS sunucularıyla gelen istekle aynı protokolü kullanarak iletişim kurar. Bu nedenle, varsayılan olarak iş konteynerlerinden küme dışı alan adlarını çözümlemek için gelen istekler NodeLocal DNSCache ve CoreDNS üzerinden geçer ve sonunda ECS örneklerinde varsayılan olarak 100.100.2.136 ve 100.100.2.138 olan VPC DNS sunucularına TCP üzerinden ulaşır.

# Before modification
forward . /etc/resolv.conf
# After modification
forward . /etc/resolv.conf {
  prefer_udp
}

ready eklentisini yapılandırın

1.5.0 sonrası CoreDNS sürümlerinde, hazır durum denetimlerini etkinleştirmek için ready eklentisinin yapılandırılması gerekir.

1. CoreDNS yapılandırma dosyasını açmak için aşağıdaki komutu çalıştırın.

   kubectl -n kube-system edit configmap/coredns

2. Dosyada ready satırının olup olmadığını kontrol edin. Yoksa, ready satırını ekleyin, Esc tuşuna basın, :wq! girin ve ardından Enter tuşuna basarak değiştirilen yapılandırma dosyasını kaydedin ve düzenleme modundan çıkın.

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # If this line does not exist, add it. Make sure that the indentation is consistent with Kubernetes.
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods verified
         fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf {
         max_concurrent 1000
               prefer_udp
       }
       cache 30
       loop
       log
       reload
       loadbalance
     }

3. CoreDNS pod'larının çalışma durumunu ve günlüklerini kontrol edin. Günlüklerde reload kelimesi varsa, değişiklik başarılı olmuştur.

multisocket eklentisiyle performansı artırın

CoreDNS v1.12.1, multisocket eklentisini tanıttı. Bu eklentinin etkinleştirilmesi, CoreDNS'in aynı bağlantı noktasında dinlemek için birden çok soket kullanmasına olanak tanır ve yüksek CPU senaryolarında CoreDNS performansını artırır. Eklenti hakkında ayrıntılı açıklama için bkz. topluluk belgeleri.

multisocket'i coredns ConfigMap kullanarak etkinleştirmeniz gerekir:

.:53 {
        ...
        prometheus :9153
        multisocket [NUM_SOCKETS]
        forward . /etc/resolv.conf
        ...
}

NUM_SOCKETS aynı bağlantı noktasında dinleyen soket sayısını belirtir.

Önerilen yapılandırma: NUM_SOCKETS değerini tahmini CPU kullanımı, CPU kaynak sınırları ve mevcut küme kaynaklarıyla hizalayın. Örneğin:

• CoreDNS tepe noktada 4 çekirdek tüketiyor ve 8 çekirdek mevcutsa, NUM_SOCKETS değerini 2 olarak ayarlayın.

• CoreDNS tepe noktada 8 çekirdek tüketiyor ve 64 çekirdek mevcutsa, NUM_SOCKETS değerini 8 olarak ayarlayın.

En uygun yapılandırmayı belirlemek için farklı ayarlarla QPS ve yükü test etmenizi öneririz.

NUM_SOCKETS belirtmezseniz, varsayılan değer CoreDNS pod'unun CPU sınırına eşit olan GOMAXPROCS olur. Pod'un CPU sınırı ayarlanmamışsa, değer pod'un çalıştığı düğümdeki CPU çekirdek sayısına eşittir.