🥇/etc/resolv.conf für Kubernetes-Pods, Option ndots:5, wie sich dies negativ auf die Anwendungsleistung auswirken kann

Mit Hilfe von Kops haben wir kürzlich Kubernetes 1.9 auf AWS eingeführt. Als ich gestern reibungslos neuen Datenverkehr zu unserem größten Kubernetes-Cluster einführte, bemerkte ich ungewöhnliche Fehler bei der DNS-Namensauflösung, die von unserer Anwendung protokolliert wurden.

GitHub hat einiges darüber zu bieten. redete, also beschloss ich auch, mich damit zu befassen. Dadurch wurde mir klar, dass dies in unserem Fall durch eine erhöhte Belastung verursacht wurde kube-dns и dnsmasq. Am interessantesten und neusten für mich war der eigentliche Grund für den deutlichen Anstieg des DNS-Abfrageverkehrs. Darüber und was man damit machen kann, mein Beitrag.

Die DNS-Auflösung innerhalb des Containers wird – wie in jedem Linux-System – durch die Konfigurationsdatei bestimmt /etc/resolv.conf. Standard-Kubernetes dnsPolicy es ClusterFirst, was bedeutet, dass jede DNS-Anfrage umgeleitet wird dnsmasqläuft in einer Kapsel kube-dns innerhalb des Clusters, der wiederum die Anfrage an die Anwendung weiterleitet kube-dns, wenn der Name mit einem Cluster-Suffix endet, oder andernfalls an einen übergeordneten DNS-Server.

Datei /etc/resolv.conf in jedem Container sieht standardmäßig so aus:

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

Wie Sie sehen, gibt es drei Anweisungen:

Der Nameserver ist die IP des Dienstes kube-dns
4 lokale Suchdomänen angegeben search
Diese Option ndots:5

Der interessante Teil dieser Konfiguration besteht darin, wie die lokalen Suchdomänen und -einstellungen aussehen ndots:5 koexistieren zusammen. Um dies zu verstehen, müssen Sie verstehen, wie die DNS-Auflösung für nicht qualifizierte Namen funktioniert.

Was ist ein vollständiger Name?

Ein vollständig qualifizierter Name ist ein Name, der nicht lokal durchsucht wird und bei der Namensauflösung als absoluter Name behandelt wird. Konventionell betrachtet die DNS-Software einen Namen als vollständig qualifiziert, wenn er mit einem Punkt (.) endet, andernfalls als nicht vollständig qualifiziert. Also google.com. vollständig definiert und google.com - Nein.

Wie wird mit einem unqualifizierten Namen umgegangen?

Wenn eine Anwendung eine Verbindung zu dem im Namen angegebenen Remote-Host herstellt, erfolgt die DNS-Namensauflösung normalerweise mithilfe eines Systemaufrufs, z. B. getaddrinfo(). Aber wenn der Name unvollständig ist (nicht mit . endet), frage ich mich, ob der Systemaufruf versucht, den Namen als absoluten ersten aufzulösen, oder ob er zuerst die lokalen Suchdomänen durchsucht? Das hängt von der Option ab ndots.

Aus dem Handbuch für resolv.conf:

ndots:n

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

Das bedeutet, wenn z ndots auf 5 gesetzt ist und der Name weniger als 5 Punkte enthält, versucht der Systemaufruf, ihn der Reihe nach aufzulösen, indem er zunächst alle lokalen Suchdomänen durchläuft, fehlschlägt und ihn schließlich als absoluten Namen auflöst.

Warum auch `ndots:5` Kann sich die Anwendungsleistung negativ auswirken?

Wie Sie sich vorstellen können, wird Ihre Anwendung, wenn sie viel externen Datenverkehr verwendet, für jede hergestellte TCP-Verbindung (oder genauer gesagt für jeden aufgelösten Namen) 5 DNS-Anfragen stellen, bevor der Name ordnungsgemäß aufgelöst wird, da er zuerst durchgeht 4 lokale Suchdomäne und stellt am Ende eine Anfrage zur absoluten Namensauflösung aus.

Das folgende Diagramm zeigt den gesamten Datenverkehr auf unseren 3 kube-dns-Pods vor und nach der Umstellung mehrerer in unserer Anwendung konfigurierter Hostnamen auf vollständig qualifizierte.

Das folgende Diagramm zeigt die Latenz der Anwendung vor und nachdem wir mehrere in unserer Anwendung konfigurierte Hostnamen auf vollständige Hostnamen umgestellt haben (die vertikale blaue Linie ist die Bereitstellung):

Lösung Nr. 1 – Verwenden Sie vollständig qualifizierte Namen

Wenn Sie nur wenige statische externe Namen (d. h. in der Anwendungskonfiguration definiert) haben, zu denen Sie eine große Anzahl von Verbindungen erstellen, besteht die vielleicht einfachste Lösung darin, sie durch einfaches Hinzufügen in vollqualifizierte Namen umzuwandeln. Am Ende.

Dies ist keine endgültige Lösung, aber es hilft, die Situation schnell, wenn auch nicht sauber, zu verbessern. Wir haben diesen Patch angewendet, um unser Problem zu lösen. Die Ergebnisse sind in den Screenshots oben zu sehen.

Entscheidung Nr. 2 – Anpassung `ndots` в `dnsConfig`

Mit Kubernetes 1.9 wurde im Alpha-Modus (Betaversion v1.10) eine Funktion eingeführt, mit der Sie DNS-Einstellungen über eine Pod-Eigenschaft besser steuern können dnsConfig. Unter anderem können Sie den Wert anpassen ndots für einen bestimmten Pod, d.h.

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

Quellen

Lesen Sie auch andere Artikel in unserem Blog:

Source: habr.com

/etc/resolv.conf für Kubernetes-Pods, Option ndots:5, wie sich dies negativ auf die Anwendungsleistung auswirken kann