Wenn Sie wie die meisten Menschen sind, verwenden Sie wahrscheinlich Ressourcen, die außerhalb Ihres Clusters arbeiten. Möglicherweise nutzen Sie die API von Taleo, um Textnachrichten zu senden, oder analysieren Bilder mit der Google Cloud Vision API.
Wenn Sie denselben Endpoint — den Serveranfragepunkt — in all Ihren Umgebungen verwenden und nicht planen, Ihre Server nach Kubernetes zu migrieren, ist es völlig in Ordnung, den Service-Endpoint direkt in Ihrem Code zu haben. Es gibt jedoch viele andere Entwicklungsszenarien. In dieser Serie "Kubernetes Best Practices" erfahren Sie, wie Sie die eingebauten Mechanismen von Kubernetes nutzen können, um Dienste sowohl innerhalb als auch außerhalb des Clusters zu entdecken.
Ein weit verbreitetes Beispiel für einen externen Dienst ist eine Datenbank, die außerhalb des Kubernetes-Clusters betrieben wird. Im Gegensatz zu cloudbasierten Datenbanken wie Google Cloud Data Store oder Google Cloud Spanner, die einen einzigen Endpoint für alle Zugriffsarten verwenden, haben die meisten Datenbanken separate Endpoints für unterschiedliche Situationen.
Beste Praktiken für den Einsatz traditioneller Datenbanken wie MySQL und MongoDB sehen in der Regel vor, dass Sie sich mit verschiedenen Komponenten für unterschiedliche Umgebungen verbinden. Sie könnten eine leistungsstarke Maschine für Produktionsdaten und eine kleinere für Testumgebungen haben. Jede von ihnen hätte ihre eigene IP-Adresse oder Domainnamen, aber Sie möchten sicherlich Ihren Code nicht ändern, wenn Sie von einer Umgebung zur anderen wechseln. Anstatt diese Adressen fest im Code zu verankern, können Sie den in Kubernetes integrierten Dienst zur Entdeckung von externen Services basierend auf DNS verwenden – genau wie für native Kubernetes-Services.
Angenommen, Sie betreiben eine MongoDB-Datenbank in Google Compute Engine. Sie werden in dieser hybriden Welt gefangen sein, bis es Ihnen gelingt, sie in ein Cluster zu migrieren.
Glücklicherweise können Sie statische Kubernetes-Services 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, da eine IP-Adresse vorhanden ist, besteht der erste Schritt darin, einen Dienst zu erstellen. Es ist zu beachten, dass es für diesen Dienst keine Pod-Selektoren gibt. Das bedeutet, dass wir einen Dienst erstellt haben, der nicht weiß, wohin der Traffic gesendet werden soll. Damit können Sie manuell ein Endpoint-Objekt erstellen, das den Traffic von diesem Dienst empfangen wird.
Das folgende Codebeispiel zeigt, dass die Endpunkte die IP-Adresse für die Datenbank definieren, wobei dasselbe Name 'mongo' verwendet wird wie der Dienst.
Kubernetes wird alle IP-Adressen verwenden, um die Endpunkte zu finden, als wären sie normale Kubernetes-Pods, sodass Sie jetzt auf die Datenbank über eine einfache Verbindungszeichenfolge mit dem oben angegebenen Namen mongodb://mongo zugreifen können. Dabei ist es überhaupt nicht erforderlich, IP-Adressen in Ihrem Code zu verwenden.
Sollten 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 verwenden, die auf einem externen Host gehostet wird, haben die Eigentümer des Hosts Ihnen höchstwahrscheinlich eine einheitliche Ressourcen-ID (URI) zur Verfügung gestellt, um sich zu verbinden. Wenn Ihnen eine IP-Adresse gegeben wurde, können Sie einfach die vorherige Methode verwenden. In diesem Beispiel habe ich zwei MongoDB-Datenbanken, die auf dem Host mLab gehostet sind.
Eine davon ist die Entwicklerdatenbank, und die andere die Produktionsdatenbank. Die Verbindungszeichenfolgen für diese Datenbanken sehen wie folgt aus – mLab stellt Ihnen eine dynamische URI und einen dynamischen Port zur Verfügung. Wie Sie sehen können, sind sie unterschiedlich.
Um davon abzustrahieren, verwenden wir Kubernetes und verbinden uns mit der Entwicklerdatenbank. Sie können einen externen Service-Namen in Kubernetes erstellen, der Ihnen einen statischen Service bereitstellt, der den Verkehr an den externen Service weiterleitet.
Dieser Service führt eine einfache CNAME-Weiterleitung auf Kernel-Ebene durch, was minimale Auswirkungen auf die Leistung hat. Dadurch können Sie eine einfachere Verbindungszeichenfolge verwenden.
Da jedoch der externe Name eine CNAME-Umleitung verwendet, kann er die Portumleitung nicht durchführen. Daher ist diese Lösung nur für statische Ports anwendbar und kann nicht mit dynamischen Ports verwendet werden. Der 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 Verbindungsstrings benötigen. Das Problem ist, dass dabei die Portnummer hartcodiert werden muss. Wie bringt man also die Portumleitung zum Laufen?
Der erste Schritt besteht darin, die IP-Adresse aus der URI zu erhalten. Wenn Sie den Befehl nslookup ausführen, den Hostnamen verwenden 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, daran zu denken, dass sich die IP-Adressen der URI ohne Vorankündigung ändern können, weshalb es riskant ist, sie in prod zu verwenden. Mit einer solchen IP-Adresse können Sie sich mit der entfernten Datenbank verbinden, ohne dabei den Port anzugeben. Damit führt der Kubernetes-Service die Portumleitung recht transparent aus.
Das Mapping oder die Zuordnung externer Ressourcen zu internen ermöglicht es Ihnen, diese Dienste in Zukunft flexibel innerhalb des Clusters zu nutzen und gleichzeitig den Aufwand für Refactoring zu minimieren. Es erleichtert auch das Management und gibt Ihnen Einblick in die externen Dienste, die Ihr Unternehmen nutzt.
Die Fortsetzung kommt 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 Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
