Vor nicht allzu langer Zeit haben wir Kubernetes 1.9 unter AWS mit Kops gestartet. Gestern, als ich reibungslos neuen Datenverkehr auf den größten unserer Kubernetes-Cluster übertrug, bemerkte ich ungewöhnliche DNS-Namensauflösungsfehler, die von unserer Anwendung protokolliert wurden.
GitHub hat eine ganze Weile darüber gesprochen, also habe ich mich auch entschlossen, es herauszufinden. Am Ende wurde mir klar, dass dies in unserem Fall auf die erhöhte Belastung von kube-dns und dnsmasq . Das Interessanteste und Neueste für mich war der Grund für eine signifikante Zunahme des Datenverkehrs bei DNS-Abfragen. Darüber und was damit zu tun ist, mein Beitrag.
Die Auflösung des DNS im Container wird - wie bei jedem Linux-System - durch die Konfigurationsdatei /etc/resolv.conf . Standardmäßig ist Kubernetes dnsPolicy ClusterFirst bedeutet, dass jede DNS-Abfrage an dnsmasq umgeleitet wird, das im kube-dns innerhalb des Clusters ausgeführt wird. kube-dns wird die Abfrage an die kube-dns Anwendung umgeleitet, wenn der Name mit einem Clustersuffix endet, oder Andernfalls auf einen übergeordneten DNS-Server.
Die Datei /etc/resolv.conf in jedem Container sieht standardmäßig folgendermaßen 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 können, gibt es drei Richtlinien:
- Der Nameserver ist der IP-Dienst von
kube-dns - 4 lokale Suchdomänen angegeben
- Es gibt eine Option
ndots:5
Ein interessanter Teil dieser Konfiguration ist, wie lokale ndots:5 und ndots:5 Einstellungen miteinander auskommen. Um dies zu verstehen, müssen Sie verstehen, wie die DNS-Auflösung für Teilnamen funktioniert.
Wie lautet der vollständige Name?
Ein vollständig qualifizierter Name ist ein Name, für den keine lokale Suche durchgeführt wird, und der Name wird bei der Namensauflösung als absolut betrachtet. Gemäß der Konvention betrachtet die DNS-Software einen Namen als vollständig qualifiziert, wenn er mit einem Punkt (.) Endet, und nicht vollständig anders. Das ist google.com. vollständig definiert, aber google.com nicht.
Wie wird mit einem unvollständigen 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() . Wenn der Name jedoch unvollständig ist (endet nicht mit.), Frage ich mich, ob der Systemaufruf zuerst versucht, den Namen als absolut aufzulösen, oder ob er zuerst die lokalen Suchdomänen durchläuft. ndots hängt von der Option ndots .
Aus dem Handbuch auf resolv.conf :
ndots:n , , . n 1, , - , , - .
Dies bedeutet, dass, wenn ndots auf 5 gesetzt ist und der Name weniger als 5 Punkte enthält, der Systemaufruf versucht, ihn nacheinander aufzulösen, indem zuerst alle lokalen ndots durchlaufen werden, und wenn er nicht erfolgreich ist, wird er schließlich als absoluter Name aufgelöst.
Warum können ndots:5 die Anwendungsleistung beeinträchtigen?
Wenn Ihre Anwendung für jede hergestellte TCP-Verbindung (oder genauer für jeden aufgelösten Namen) viel externen Datenverkehr verwendet, werden, wie Sie verstehen, 5 DNS-Abfragen ausgegeben, bevor der Name korrekt aufgelöst wird, da zuerst 4 durchlaufen werden lokale Suchdomäne, und am Ende wird eine absolute Namensauflösungsanforderung ausgegeben.
Das folgende Diagramm zeigt den gesamten Datenverkehr auf unseren 3 kube-dns-Modulen vor und nach dem Umschalten mehrerer in unserer Anwendung konfigurierter Hostnamen auf vollständig definierte.
Das folgende Diagramm zeigt die Anwendungsverzögerung vor und nach dem Umschalten mehrerer in unserer Anwendung konfigurierter Hostnamen auf "Vollständig" (die vertikale blaue Linie ist die Bereitstellung):
Lösung 1 - Verwenden Sie vollständig qualifizierte Namen
Wenn Sie nur wenige statische externe Namen haben (dh in der Anwendungskonfiguration definiert), zu denen Sie eine große Anzahl von Verbindungen erstellen, besteht die einfachste Lösung darin, diese durch einfaches Hinzufügen zu vollständig definierten zu wechseln. Am Ende.
Dies ist keine endgültige Entscheidung, 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 wurden in den obigen Screenshots gezeigt.
Lösung 2 - Anpassen von ndots in dnsConfig
In Kubernetes 1.9 wurde im Alpha-Modus (Beta-Version v1.10) eine Funktion angezeigt, die eine bessere Steuerung der DNS-Parameter über die pod-Eigenschaft in dnsConfig . Unter anderem können Sie den ndots Wert für einen bestimmten Herd anpassen, 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: