Wie füge ich allen Pods in Google Container Engine [GKE] einen Nameserver hinzu?

Ich möchte hinzufügen, was Eric sagte, und mutieren es ein bisschen.

Eine der Erkenntnisse, die wir während der Kubernetes 1.1 "Einschwingzeit" hatten, ist, dass es für Dinge wie resolv.conf und Resolver-Verhalten nicht wirklich Spezifikationen gibt. Verschiedene Resolver-Bibliotheken machen verschiedene Dinge, und das war für unsere Benutzer schmerzhaft.

Insbesondere nehmen einige gebräuchliche Resolver an, dass alle nameserver s fungibel sind und brechen würden, wenn Sie Nameserver hätten, die verschiedene Teile des DNS-Namespace behandeln. Wir haben entschieden, dass wir für kube 1.2 NICHT mehrere nameserver -Zeilen in Container überführen. Stattdessen übergeben wir nur den Kube-DNS-Server, der cluster.local -Abfragen behandelt und alle anderen Abfragen an einen "Upstream" -Nameserver weiterleitet.

Woher wissen wir, was "upstream" ist? Wir verwenden nameservers des Knotens. Es gibt ein Feld pro-pds-dnsPolicy, das diese Auswahl bestimmt. Das Endergebnis ist, dass Container ein einzelnes nameserver in resolv.conf sehen, das uns gehört, und dass Nameserver den gesamten DNS-Namespace behandelt.

Was das praktisch bedeutet, ist, dass es keinen großen Haken für dich gibt, deinen eigenen Nameserver einzuwerfen. Sie könnten das Flag --cluster-dns auf kubelets ändern, um auf Ihren eigenen DNS-Server zu verweisen, der dann zu den kube-dns weiterleitet, die dann zu "upstream" weiterleiten würden. Das Problem ist, dass GKE das Ändern von Flags auf diese Weise nicht wirklich unterstützt. Wenn / wenn der Knoten aktualisiert wird, verschwindet das Flag zugunsten des Standards.

Mögliche Lösungen:

• Lassen Sie die kubelets ihre Flags von einer In-Cluster-Konfiguration lesen. Dies ist bereits geplant, aber nicht in Version 1.2

• Lassen Sie kube-dns eine Flagge nehmen, die angibt, was "upstream" ist. Kube-dns ist ein "Cluster-Addon" und daher von Endbenutzern nicht wirklich änderbar (wir werden es mit Ihrem Cluster aktualisieren und Ihre Änderungen verlieren).

• Lassen Sie kube-dns seine Flags von einer in-cluster-Konfiguration lesen und nehmen Sie eine Markierung, die angibt, was "upstream" ist. Dies ist eine machbare Idee, aber wahrscheinlich nicht für v1.2 (zu spät). Es könnte möglich sein, dies in eine v1.2.x zu patchen, aber es ist nicht wirklich ein Bugfix, es ist eine Funktion.

• Holen Sie sich Ihren eigenen DNS-Server in die resolv.conf auf jedem Knoten, so dass kube-dns Sie als Upstream verwenden würde. Ich denke nicht, dass GKE eine Möglichkeit hat, dies zu konfigurieren, die auch bei Knoten-Upgrades nicht verloren geht. Sie könnten einen Controller schreiben, der regelmäßig per SSH an VMs gesendet wurde, und das anschließend geschrieben hat, und anschließend Ihren kube-dns-Container auf Korrektheit überprüft haben. Blech.

Ich denke, die richtige Antwort besteht darin, In-Cluster-Configmaps zu verwenden, um entweder kubelets oder DNS (oder beides) zu informieren. Wenn Sie denken, dass dies (trotz der zeitlichen Probleme) praktikable Antworten sein könnten, wäre es großartig, wenn Sie ein GitHub-Problem zur Diskussion aufstellen würden. Es wird mehr Sichtbarkeit dort bekommen.

Effektiv Nein.

Wenn Sie die resolv.conf des Knotens ändern, erben die Pods die Änderungen.

glibc verbietet jedoch die Verwendung von mehr als 3 Nameservern oder mehr als 6 Suchdatensätzen.

GCE VMs verwenden 2 Nameserver und 3 Suchen für den Zugriff auf Knotenmetadaten und Projektnetzwerk. Und GKE verwendet 1 Nameserver und 3 Suchen. Das lässt Sie 0 Nameserver und 0 Suchen.

Siehe diese Ausgabe: Ссылка und dieses Problem: Ссылка

Ich habe das gelöst, indem ich einen dnsmasq-Dienst im k8s-Cluster eingerichtet habe und alle pots-Nameserver außer dnsmasq auf den dnsmasq-Dienst gelenkt habe.
dnsmasq leitet Anforderungen basierend auf dem Domänensuffix an den richtigen Nameserver weiter. So funktionieren sowohl interne als auch externe vpn-Lookups.

1. Richten Sie einen dnsmasq-Dienst ein.
   Die Pods können in etwa so aussehen, stellen Sie sicher, dass es mindestens zwei Pods gibt, da es HA sein muss.

   %Vor%

2. Fügen Sie eine resolv-conf-Konfigurationszuordnung hinzu.

   %Vor%

3. Hängen Sie die cfgmap in Ihre Dienste / Pods ein. Füge das zu deinen Pods hinzu

   %Vor%

Diese Lösung kann vielleicht etwas hässlich sein, aber derzeit gibt es nicht viele andere Optionen. In der Zukunft würde ich hoffen, eine DNS-Forward-Funktion zu Google Cloud oder Kube-DNS sehen.

Es ist verrückt, dass Google Cloud keine DNS-Weiterleitungsfunktion für bestimmte Domains / Zonen anbietet.