Wenn Sie wie die meisten Menschen sind, verwenden Sie wahrscheinlich Ressourcen, die außerhalb Ihres Clusters funktionieren. Möglicherweise nutzen Sie die API von Taleo, um Textnachrichten zu versenden oder analysieren Bilder mit der API von Google Cloud Vision.
Wenn Sie denselben Endpunkt — den Punkt, an dem Anfragen auf der Serverseite empfangen werden — in all Ihren Umgebungen verwenden und nicht planen, Ihre Server nach Kubernetes zu migrieren, ist es völlig in Ordnung, den Endpunkt des Dienstes direkt in Ihrem Code zu haben. Es gibt jedoch viele andere mögliche Szenarien. In dieser Serie „Kubernetes Best Practices“ erfahren Sie, wie Sie die integrierten Mechanismen von Kubernetes zur Dienstentdeckung sowohl innerhalb als auch außerhalb des Clusters nutzen können.
Ein Beispiel für einen weit verbreiteten externen Dienst ist eine Datenbank, die außerhalb des Kubernetes-Clusters betrieben wird. Im Gegensatz zu Cloud-Datenbanken wie Google Cloud Data Store oder Google Cloud Spanner, die für alle Zugriffsarten einen einzigen Endpunkt verwenden, haben die meisten Datenbanken separate Endpunkte für unterschiedliche Umstände.
Die bewährte Praxis für den Umgang mit traditionellen Datenbanken wie MySQL und MongoDB sieht in der Regel vor, dass Sie sich mit verschiedenen Komponenten für unterschiedliche Umgebungen verbinden. Sie könnten einen leistungsstarken Server für Produktionsdaten und einen kleineren für die Testumgebung haben. Jede von ihnen hat ihre eigene IP-Adresse oder ihren eigenen Domainnamen, aber Sie möchten Ihren Code beim Übergang von einer Umgebung zur anderen sicherlich nicht ändern. Daher können Sie anstelle der harten Kodierung dieser Adressen die integrierte Kubernetes-Dienstentdeckung für externe Dienste basierend auf DNS verwenden, genau wie für native Kubernetes-Dienste.
Angenommen, Sie betreiben eine MongoDB-Datenbank in Google Compute Engine. Sie werden in dieser hybriden Welt feststecken, bis Sie sie in einen Cluster migrieren können.
Glücklicherweise können Sie statische Kubernetes-Dienste nutzen, um sich das Leben ein wenig zu erleichtern. In diesem Beispiel habe ich einen MongoDB-Server mit Google Cloud Launcher erstellt. Da er im selben Netzwerk (oder VPC des Kubernetes-Clusters) erstellt wurde, erfolgt der Zugriff über eine leistungsstarke interne IP-Adresse.
In Google Cloud ist dies die Standardeinstellung, sodass Sie nichts konfigurieren müssen. Jetzt, wo die IP-Adresse vorhanden ist, besteht der erste Schritt darin, einen Service zu erstellen. Es ist zu bemerken, dass es für diesen Service keine Pod-Selektoren gibt. Das bedeutet, dass wir einen Dienst erstellt haben, der nicht weiß, wohin der Datenverkehr geleitet werden soll. Dadurch können wir manuell ein Endpoint-Objekt erstellen, das den Verkehr von diesem Dienst empfängt.
Das nächste Beispiel zeigt, dass Endpunkte die IP-Adresse für die Datenbank definieren, wobei derselbe Name mongo wie der Service verwendet wird.
Kubernetes wird alle IP-Adressen verwenden, um Endpunkte zu finden, als ob sie reguläre Kubernetes-Pods wären, sodass Sie jetzt über eine einfache Verbindungszeichenfolge auf die Datenbank zugreifen können, die auf dem oben genannten Namen mongodb://mongo basiert. Es ist überhaupt nicht notwendig, IP-Adressen in Ihrem Code zu verwenden.
Wenn sich in Zukunft die IP-Adressen ändern, können Sie einfach die Endpunkte mit der neuen IP-Adresse aktualisieren, und Ihre Anwendungen müssen nicht auf andere Weise geändert werden.
Wenn Sie eine Datenbank auf einem Drittanbieter-Host verwenden, haben die Host-Besitzer Ihnen wahrscheinlich einen einheitlichen Ressourcenidentifier URI zur Verfügung gestellt. Falls Ihnen eine IP-Adresse gegeben wurde, können Sie einfach die vorherige Methode verwenden. Dieses Beispiel zeigt, dass ich zwei MongoDB-Datenbanken auf dem Host mLab habe.
Eine davon ist die Entwicklerdatenbank, die andere die Produktionsdatenbank. Die Verbindungszeichenfolgen für diese Datenbanken sehen folgendermaßen aus – mLab stellt Ihnen einen dynamischen URI und einen dynamischen Port zur Verfügung. Wie Sie sehen können, sind sie unterschiedlich.
Um sich davon abzugrenzen, verwenden wir Kubernetes und verbinden uns mit der Entwicklerdatenbank. Sie können einen externen Servicenamen im Kubernetes erstellen, der Ihnen einen statischen Service bietet, der den Verkehr an einen externen Service umleitet.
Dieser Service wird eine einfache CNAME-Weiterleitung auf Kernel-Ebene durchführen, was minimale Auswirkungen auf die Leistung haben wird. Dadurch können Sie eine einfachere Verbindungszeichenfolge verwenden.
Da der externe Name jedoch die CNAME-Weiterleitung verwendet, kann er die Portneu Zuordnung nicht durchführen. Daher ist diese Lösung nur für statische Ports anwendbar und kann nicht mit dynamischen Ports verwendet werden. Das kostenlose mLab Free Tier bietet standardmäßig dem Benutzer eine dynamische Portnummer, und das können Sie nicht ändern. Das bedeutet, dass Sie für dev und prod unterschiedliche Verbindungszeichenfolgen benötigen. Das Negative dabei ist, dass die Portnummer hart kodiert werden muss. Wie kann man also die Portneu Zuordnung zum Laufen bringen?
Der erste Schritt besteht darin, die IP-Adresse aus der URI zu erhalten. Wenn Sie den Befehl nslookup ausführen, den Hostnamen oder die URI anpingen, können Sie die IP-Adresse der Datenbank erhalten. Wenn der Dienst Ihnen mehrere IP-Adressen zurückgibt, können Sie alle diese Adressen in den Endpunkten des Objekts verwenden.
Es ist wichtig zu beachten, dass die IP-Adressen der URI ohne vorherige Ankündigung geändert werden können, daher ist es ziemlich riskant, sie in der Produktion zu verwenden. Mit einer solchen IP-Adresse können Sie sich mit der Remote-Datenbank verbinden, ohne dabei den Port anzugeben. Auf diese Weise führt der Kubernetes-Dienst die Ports recht transparent neu zu.
Das Mapping oder die Zuordnung externer Ressourcen zu internen gibt Ihnen die Möglichkeit, diese Dienste in der Zukunft flexibel innerhalb des Clusters zu nutzen und gleichzeitig den Aufwand für Refactoring zu minimieren. Es erleichtert auch das Management und gibt Einblick, welche externen Dienste Ihr Unternehmen nutzt.
Fortsetzung erfolgt in Kürze…
Ein wenig Werbung 🙂
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, , ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).
Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie
Quelle: habr.com
