ProHoster > Blog > yönetim > Kubernetes bölmeleri için /etc/resolv.conf, ndots:5 seçeneği, bunun uygulama performansını nasıl olumsuz etkileyebileceği

Kubernetes bölmeleri için /etc/resolv.conf, ndots:5 seçeneği, bunun uygulama performansını nasıl olumsuz etkileyebileceği

Kubernetes bölmeleri için /etc/resolv.conf, ndots:5 seçeneği, bunun uygulama performansını nasıl olumsuz etkileyebileceği

Yakın zamanda Kops'u kullanarak Kubernetes 1.9'u AWS'de başlattık. Dün, Kubernetes kümelerimizin en büyüğüne sorunsuz bir şekilde yeni trafik dağıtırken, uygulamamız tarafından kaydedilen olağandışı DNS adı çözümleme hatalarını fark etmeye başladım.

GitHub'da bununla ilgili pek çok şey var adı geçen, ben de bunu çözmeye karar verdim. Sonunda bizim durumumuzda bunun artan yükten kaynaklandığını fark ettim. kube-dns и dnsmasq. Benim için en ilginç ve yeni olan şey, DNS istek trafiğindeki önemli artışın nedeniydi. Yazım bununla ve bu konuda ne yapılması gerektiğiyle ilgili.

Kapsayıcının içindeki DNS çözünürlüğü - herhangi bir Linux sisteminde olduğu gibi - yapılandırma dosyası tarafından belirlenir /etc/resolv.conf. Varsayılan Kubernet'ler dnsPolicy bu ClusterFirstbu, herhangi bir DNS isteğinin şu adrese iletileceği anlamına gelir: dnsmasq, bir bölmede koşuyor kube-dns kümenin içinde, bu da isteği uygulamaya iletecek kube-dnsAd bir küme son ekiyle bitiyorsa veya aksi halde daha yüksek düzeydeki bir DNS sunucusuna.

Dosya /etc/resolv.conf her kabın içinde varsayılan şu şekilde görünecektir:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Gördüğünüz gibi üç direktif var:

  1. Ad sunucusu hizmetin IP'sidir kube-dns
  2. 4 yerel arama alanı belirtildi search
  3. Bir seçenek var ndots:5

Bu yapılandırmanın ilginç kısmı, yerel arama etki alanlarının ve ayarlarının nasıl yapıldığıdır. ndots:5 Birbirinizle iyi geçinin. Bunu anlamak için niteliksiz adlara yönelik DNS çözümlemesinin nasıl çalıştığını anlamanız gerekir.

Tam ad nedir?

Tam nitelikli ad, hiçbir yerel aramanın gerçekleştirilmeyeceği ve ad çözümlemesi sırasında adın mutlak olarak kabul edileceği bir addır. Geleneksel olarak, DNS yazılımı bir adın nokta (.) ile bitmesi durumunda tam nitelikli olduğunu, aksi halde tam olarak nitelenmemiş olduğunu kabul eder. Yani google.com. tam olarak tanımlanmış ve google.com - HAYIR.

Niteliksiz bir isim nasıl ele alınır?

Bir uygulama adında belirtilen uzak ana bilgisayara bağlandığında, DNS ad çözümlemesi genellikle bir sistem çağrısı kullanılarak yapılır; getaddrinfo(). Ancak eğer isim niteliksizse (. ile bitmiyorsa), acaba sistem çağrısı önce ismi mutlak bir isim olarak mı çözümlemeye çalışacak, yoksa önce yerel arama etki alanlarından mı geçecek? Seçeneğe bağlıdır ndots.

Kılavuzdan resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

Bu şu anlama gelir: ndots 5 değeri verildiğinde ve ad 5'ten az noktadan oluştuğunda, sistem çağrısı önce tüm yerel arama etki alanlarını geçerek ve başarısız olursa sonunda onu mutlak bir ad olarak çözerek onu sırayla çözmeye çalışacaktır.

Neden aynı ndots:5 uygulama performansını olumsuz etkileyebilir mi?

Tahmin edebileceğiniz gibi, eğer uygulamanız çok fazla harici trafik kullanıyorsa, kurulan her TCP bağlantısı için (veya daha doğrusu, çözümlenen her ad için), ad doğru şekilde çözümlenmeden önce 5 DNS sorgusu yayınlayacaktır, çünkü ilk olarak bu TCP üzerinden geçecektir. 4 yerel arama alanı ve sonunda mutlak bir ad çözümleme isteği yayınlanacaktır.

Aşağıdaki grafik, uygulamamızda yapılandırılan birkaç ana bilgisayar adını tam nitelikli olanlarla değiştirmemizden önce ve sonra 3 kube-dns modülümüzdeki toplam trafiği göstermektedir.

Kubernetes bölmeleri için /etc/resolv.conf, ndots:5 seçeneği, bunun uygulama performansını nasıl olumsuz etkileyebileceği

Aşağıdaki şema, uygulamamızda yapılandırılan birkaç ana bilgisayar adını tam adlarla değiştirmemizden önceki ve sonraki uygulama gecikmesini göstermektedir (dikey mavi çizgi dağıtımdır):

Kubernetes bölmeleri için /etc/resolv.conf, ndots:5 seçeneği, bunun uygulama performansını nasıl olumsuz etkileyebileceği

1. Çözüm - Tam nitelikli adlar kullanın

Çok sayıda bağlantı oluşturduğunuz az sayıda statik harici adınız varsa (yani uygulama yapılandırmasında tanımlanmışsa), belki de en basit çözüm, bunları yalnızca ekleyerek tam nitelikli adlara dönüştürmektir. sonunda.

Bu nihai bir çözüm değildir, ancak temiz bir şekilde olmasa da hızlı bir şekilde durumun iyileştirilmesine yardımcı olur. Sonuçları yukarıdaki ekran görüntülerinde gösterilen sorunumuzu çözmek için bu yamayı uyguladık.

Çözüm 2 - özelleştirme ndots в dnsConfig

Kubernetes 1.9'da, işlevsellik alfa modunda (beta sürümü v1.10) ortaya çıktı; bu, DNS parametrelerini içindeki pod özelliği aracılığıyla daha iyi kontrol etmenize olanak tanır. dnsConfig. Diğer şeylerin yanı sıra, değeri yapılandırmanıza olanak tanır ndots belirli bir bölme için, yani

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

kaynaklar

Ayrıca blogumuzdaki diğer makaleleri de okuyun:

Kaynak: habr.com

Yorum ekle