{"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 mit Kops gestartet. Gestern, w\u00e4hrend des sanften Rollouts des neuen Traffics 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

Dar\u00fcber wird schon seit einiger Zeit auf GitHub gesprochen<\/a><\/noindex>, daher wollte ich das auch genauer untersuchen. Letztendlich stellte ich fest, dass dies in unserem Fall durch eine erh\u00f6hte Last verursacht wurde kube-dns<\/code> und dnsmasq<\/code>. Am interessantesten und neu f\u00fcr mich war die Ursache des signifikanten Anstiegs der DNS-Anfragen. In meinem Beitrag erf\u00e4hrst du mehr dar\u00fcber und was man dagegen tun kann.<\/p>\n

<\/p>\n

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

<\/p>\n

Die Datei \/etc\/resolv.conf<\/code> Innerhalb jedes Containers sieht das standardm\u00e4\u00dfig 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 Servername ist die IP des Dienstes kube-dns<\/code><\/li>\n
  2. Es sind 4 lokale Suchdom\u00e4nen angegeben search<\/code><\/li>\n
  3. Es gibt eine Option ndots:5<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Ein interessanter Teil dieser Konfiguration ist, wie lokale Suchdom\u00e4nen und Einstellungen ndots:5<\/code> zusammenarbeiten. Um dies 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 den Konventionen gilt ein DNS-Name 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> nicht vollqualifiziert ist. <\/p>\n
    <\/p>\n
    Wie wird ein unvollst\u00e4ndiger Name behandelt?<\/h3>\n
    <\/p>\n
    Wenn sich eine Anwendung mit einem Remote-Host verbindet, der im Namen angegeben ist, erfolgt die DNS-Namensaufl\u00f6sung normalerweise \u00fcber einen Systemaufruf wie getaddrinfo()<\/code>. Wenn jedoch der Name unvollst\u00e4ndig ist (nicht auf . endet), stellt sich die interessante Frage, ob der Systemaufruf zuerst versucht, den Namen als absolut zu l\u00f6sen, oder ob er zuerst die lokalen Suchdom\u00e4nen durchl\u00e4uft. Das h\u00e4ngt von der Option ab. ndots<\/code>.<\/p>\n
    <\/p>\n
    Aus dem Handbuch zu resolv.conf<\/code>:<\/p>\n
    <\/p>\n
    ndots:n\n\nlegt die Schwelle f\u00fcr die Anzahl der Punkte fest, die im Namen vorhanden sein m\u00fcssen, bevor eine erste absolute Abfrage durchgef\u00fchrt wird. Der Standardwert f\u00fcr n betr\u00e4gt 1, was bedeutet, dass, wenn im Namen Punkte vorhanden sind, der Name zun\u00e4chst als absoluter Name ausprobiert wird, bevor ihm Elemente aus der Suchliste 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 zuerst alle lokalen Suchdom\u00e4nen durchl\u00e4uft und, falls dies fehlschl\u00e4gt, ihn schlie\u00dflich als absoluten Namen aufl\u00f6sen wird.<\/p>\n
    <\/p>\n
    Warum kann ndots:5<\/code> die Performance der Anwendung negativ beeinflussen?<\/h3>\n
    <\/p>\n
    Wie Sie wissen, erzeugt Ihre Anwendung, wenn sie viel externen Datenverkehr verwendet, f\u00fcr jede bestehende TCP-Verbindung (oder genauer gesagt, f\u00fcr jeden aufgel\u00f6sten Namen) 5 DNS-Abfragen, bevor der Name korrekt aufgel\u00f6st wird, da sie zun\u00e4chst durch 4 lokale Suchdom\u00e4nen geht und schlie\u00dflich eine Abfrage zur Aufl\u00f6sung des absoluten Namens ausgibt.<\/p>\n
    <\/p>\n
    Die folgende Diagramm zeigt den Gesamtdatentransfer auf unseren 3 kube-dns Modulen vor und nach der Umstellung mehrerer Hostnamen, die in unserer Anwendung konfiguriert sind, auf vollst\u00e4ndig qualifizierte Namen.<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    Die folgende Diagramm zeigt die Anwendungs-Latenz vor und nach der Umstellung mehrerer Hostnamen, die in unserer Anwendung konfiguriert sind, auf vollst\u00e4ndige (die vertikale blaue Linie stellt das Deployment dar):<\/p>\n
    <\/p>\n
    \"\/etc\/resolv.conf<\/p>\n
    <\/p>\n
    L\u00f6sung #1 \u2013 Verwendung von vollst\u00e4ndig qualifizierten Namen<\/h3>\n
    <\/p>\n
    Wenn Sie nur wenige statische externe Namen haben (d. h. in der Konfiguration der Anwendung definiert), zu denen Sie zahlreiche Verbindungen herstellen, k\u00f6nnte die einfachste L\u00f6sung sein, diese 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 jedoch schnell, wenn auch nicht sauber, die Situation zu verbessern. Diese Anpassung haben wir angewendet, um unser Problem zu l\u00f6sen, deren Ergebnisse oben in den Screenshots zu sehen sind.<\/p>\n
    <\/p>\n
    L\u00f6sung #2 \u2013 Anpassung ndots<\/code> in dnsConfig<\/code><\/h3>\n
    <\/p>\n
    In Kubernetes 1.9 wurde ein Funktionalit\u00e4t in Alpha eingef\u00fchrt (Beta-Version v1.10), die es erm\u00f6glicht, die DNS-Einstellungen \u00fcber die Pod-Eigenschaft besser zu steuern. dnsConfig<\/code>. Unter anderem erm\u00f6glicht es die Anpassung des Wertes ndots<\/code> f\u00fcr einen bestimmten Pod, 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