{"id":37372,"date":"2019-10-31T22:17:16","date_gmt":"2019-10-31T19:17:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya\/"},"modified":"2019-10-31T22:17:16","modified_gmt":"2019-10-31T19:17:16","slug":"etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/etc-resolv-conf-dlya-kubernetes-pods-optsiya-ndots-5-kak-eto-mozhet-negativno-skazatsya-na-proizvoditelnosti-prilozheniya","title":{"rendered":"\/etc\/resolv.conf \u0434\u043b\u044f Kubernetes pods, \u043e\u043f\u0446\u0438\u044f ndots:5, \u043a\u0430\u043a \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u043d\u0435\u0433\u0430\u0442\u0438\u0432\u043d\u043e \u0441\u043a\u0430\u0437\u0430\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\/etc\/resolv.conf<\/p>\n

<\/p>\n

Vor nicht allzu langer Zeit haben wir Kubernetes 1.9 auf AWS mittels Kops gestartet. Gestern, w\u00e4hrend des sanften Rollouts neuer Traffic auf einem unserer gr\u00f6\u00dften Kubernetes-Cluster, begann ich ungew\u00f6hnliche DNS-Namensaufl\u00f6sungsfehler zu bemerken, die von unserer Anwendung protokolliert wurden.<\/p>\n

<\/a><\/noindex><\/p>\n

Auf GitHub wurde schon lange dar\u00fcber gesprochen<\/a><\/noindex>, daher habe ich beschlossen, mir das auch anzuschauen. Letztendlich stellte ich fest, dass dies in unserem Fall durch eine erh\u00f6hte Last auf kube-dns<\/code> und dnsmasq<\/code>. Am interessantesten und neu f\u00fcr mich war die Ursache f\u00fcr den signifikanten Anstieg des DNS-Anfragenverkehrs. Dar\u00fcber und dar\u00fcber, was man dagegen tun kann, handelt mein Post.<\/p>\n

<\/p>\n

Die DNS-Aufl\u00f6sung innerhalb des Containers \u2014 wie in jedem Linux-System \u2014 wird durch die Konfigurationsdatei \/etc\/resolv.conf<\/code>bestimmt. Standardm\u00e4\u00dfig lautet die dnsPolicy<\/code> dieses ClusterFirst<\/code>, was bedeutet, dass jede DNS-Anfrage an dnsmasq<\/code>umgeleitet wird, die in einem Pod kube-dns<\/code> innerhalb des Clusters l\u00e4uft, der wiederum die Anfrage an die Anwendung kube-dns<\/code>weiterleitet, wenn der Name mit dem Cluster-Suffix endet, oder ansonsten an einen DNS-Server h\u00f6heren Niveaus.<\/p>\n

<\/p>\n

Die Datei \/etc\/resolv.conf<\/code> Innerhalb jedes Containers sieht die Standardkonfiguration so aus:<\/p>\n

<\/p>\n

nameserver 100.64.0.10\nsearch namespace.svc.cluster.local svc.cluster.local cluster.local \neu-west-1.compute.internal\noptions ndots:5<\/code><\/pre>\n
<\/p>\n
Wie man sehen kann, gibt es hier drei Direktiven:<\/p>\n
<\/p>\n
    \n
  1. Der Nameserver ist die IP des Dienstes kube-dns<\/code><\/li>\n
  2. Es sind 4 lokale Suchdomains angegeben search<\/code><\/li>\n
  3. Es gibt die Option ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Ein interessanter Teil dieser Konfiguration ist, wie lokale Suchdomains und Einstellungen ndots:5<\/code> koexistieren. Um das zu verstehen, muss man sich ansehen, wie die DNS-Aufl\u00f6sung f\u00fcr unvollst\u00e4ndige Namen funktioniert.<\/p>\n
    <\/p>\n
    Was ist ein vollqualifizierter Name?<\/h3>\n
    <\/p>\n
    Ein vollqualifizierter Name ist ein Name, f\u00fcr den keine lokale Suche durchgef\u00fchrt wird, und der Name wird w\u00e4hrend der Namensaufl\u00f6sung als absolut betrachtet. Nach Vereinbarung betrachtet die DNS-Software einen Namen als vollqualifiziert, wenn er mit einem Punkt (.) endet, und als nicht vollqualifiziert, wenn nicht. Das hei\u00dft, google.com.<\/code> ist vollqualifiziert, w\u00e4hrend google.com<\/code> es nicht ist. <\/p>\n
    <\/p>\n
    Wie wird ein unvollst\u00e4ndiger Name verarbeitet?<\/h3>\n
    <\/p>\n
    Wenn eine Anwendung sich mit einem Remote-Host verbindet, der im Namen angegeben ist, erfolgt die DNS-Namensaufl\u00f6sung normalerweise \u00fcber einen Systemaufruf, z. B. getaddrinfo()<\/code>. Wenn der Name jedoch unvollst\u00e4ndig ist (nicht mit . endet), stellt sich die interessante Frage, ob der Systemaufruf zun\u00e4chst versucht, den Namen als absolut aufzul\u00f6sen oder zuerst durch die lokalen Suchdomains geht. Das h\u00e4ngt von der Option ndots<\/code>.<\/p>\n
    <\/p>\n
    ab. resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nlegt den Schwellenwert f\u00fcr die Anzahl der Punkte fest, die im Namen enthalten sein m\u00fcssen, bevor eine erste absolute Abfrage durchgef\u00fchrt wird. Der Standardwert f\u00fcr n betr\u00e4gt 1, was bedeutet, dass, wenn der Name Punkte enth\u00e4lt, dieser zuerst als absoluter Name ausprobiert wird, bevor ihm Suchlisten-Elemente hinzugef\u00fcgt werden.<\/code><\/pre>\n
    <\/p>\n
    Das bedeutet, dass, wenn f\u00fcr ndots<\/code> der Wert 5 festgelegt ist und der Name weniger als 5 Punkte enth\u00e4lt, der Systemaufruf versuchen wird, ihn nacheinander aufzul\u00f6sen, indem er zun\u00e4chst alle lokalen Suchdomains durchl\u00e4uft und im Falle eines Misserfolgs schlie\u00dflich versucht, ihn als absoluten Namen aufzul\u00f6sen.<\/p>\n
    <\/p>\n
    Warum kann ndots:5<\/code> die Leistung der Anwendung negativ beeinflussen?<\/h3>\n
    <\/p>\n
    Wie Sie sehen, wenn Ihre Anwendung viel externen Verkehr nutzt, wird f\u00fcr jede hergestellte TCP-Verbindung (oder genauer gesagt, f\u00fcr jeden aufgel\u00f6sten Namen) es 5 DNS-Anfragen ausl\u00f6sen, bevor der Name korrekt aufgel\u00f6st wird, da es zuerst 4 lokale Suchdomains durchlaufen wird und am Ende eine Abfrage zur Aufl\u00f6sung des absoluten Namens abgibt.<\/p>\n
    <\/p>\n
    Im folgenden Diagramm ist der Gesamtraum in unseren 3 kube-dns Modulen vor und nach der Umstellung mehrerer Hostnamen, die in unserer Anwendung konfiguriert sind, auf vollst\u00e4ndig qualifizierte Namen dargestellt.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Im folgenden Diagramm ist die Verz\u00f6gerung der Anwendung vor und nach der Umstellung mehrerer Hostnamen, die in unserer Anwendung konfiguriert sind, auf vollst\u00e4ndige Namen dargestellt (die vertikale blaue Linie ist das Deployment):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    L\u00f6sung #1 \u2013 Verwendung vollst\u00e4ndiger Namen<\/h3>\n
    <\/p>\n
    Wenn Sie nur wenige statische externe Namen (d. h. in der Anwendungs-Konfiguration definiert), zu denen Sie eine gro\u00dfe Anzahl an Verbindungen herstellen, ist es m\u00f6glicherweise die einfachste L\u00f6sung, sie auf vollst\u00e4ndig qualifizierte Namen umzustellen, indem Sie einfach . am Ende hinzuf\u00fcgen.<\/p>\n
    <\/p>\n
    Dies ist keine endg\u00fcltige L\u00f6sung, hilft aber schnell, auch wenn nicht perfekt, die Situation zu verbessern. Diesen Patch haben wir angewendet, um unser Problem zu l\u00f6sen, dessen Ergebnisse in den obigen Screenshots gezeigt wurden.<\/p>\n
    <\/p>\n
    L\u00f6sung #2 \u2013 Anpassung ndots<\/code> in dnsConfig<\/code><\/h3>\n
    <\/p>\n
    In Kubernetes 1.9 wurde ein in Alpha-Modus eingef\u00fchrtes Feature (Beta-Version v1.10), das eine bessere Steuerung der DNS-Parameter \u00fcber die Eigenschaften des Pods in dnsConfig<\/code>. Unter anderem erm\u00f6glicht es, den Wert ndots<\/code> f\u00fcr einen bestimmten Pod zu konfigurieren, d. h.<\/p>\n
    <\/p>\n
    apiVersion: v1\nkind: Pod\nmetadata:\n  namespace: default\n  name: dns-example\nspec:\n  containers:\n    - name: test\n      image: nginx\n  dnsConfig:\n    options:\n      - name: ndots\n        value: \"1\"<\/code><\/pre>\n
    <\/p>\n
    Quellen<\/h3>\n
    <\/p>\n