PuppetConf 2016. Kubernetes für Systemadministratoren. Teil 3

PuppetConf 2016. Kubernetes für Systemadministratoren. Teil 1 von
PuppetConf 2016. Kubernetes für Systemadministratoren. Teil 2

Wir nehmen die Lobsters-Anwendung und erstellen ein neues Bild mit neuen Anforderungen. Geben Sie zunächst den Bereitstellungsbefehl $ kubectl apply –f deployments / lobsters.yaml ein und senden Sie die Anwendung an den Cluster, der gemäß der Aktualisierungsrichtlinie fortlaufende Aktualisierungsaktualisierungen für jede der verfügbaren Anwendungsinstanzen durchführen soll. Zuerst stellt das System sicher, dass jede Instanz betriebsbereit ist, und zerstört sie dann in der nächsten Gruppe von Containern.



Mal sehen, wie es funktioniert hat. Dazu laden wir die Website neu und jetzt macht das Fehlen weißer Flecken unseren Vermarkter glücklich.



Als Systemadministrator können Sie sagen: "Hier gibt es kein HTTPS. Solche Websites sind leicht zu hacken, es ist gefährlich!" Wie kann dieses Problem gelöst werden? Ich denke, in seiner Lösung kann Kubernetes als Framework fungieren, das es dem Systemadministrator ermöglicht, einen kreativen Arbeitsansatz zu implementieren. Es wäre schön, wenn ich deklarativ sagen könnte: "Ich möchte das Let's Encrypt-Zertifikat für diese Site erhalten, aber ich möchte diesen Container nicht erneut bereitstellen." Ich möchte dies im Rahmen meiner Möglichkeiten tun, ohne das Anwendungsentwicklungsteam um Hilfe zu bitten. Kubernetes ermöglicht dies, da es benutzerdefinierte Erweiterungen unterstützt.

Ich habe über Kubectl, Pods, Bereitstellungen und Dienste gesprochen, aber wir haben auch benutzerdefinierte Typen - benutzerdefinierte Ressourcentypen, die von Puppet bezogen werden können. Bei Puppet können wir neue Typen definieren, damit wir dieses System für unsere Arbeit verwenden können.
Mal sehen, wie es in Kubernetes aussieht. Zunächst benötigen wir eine Erweiterung für Zertifikate, so sieht es aus. Hier haben wir unseren eigenen hightower.com-Namespace, in dem sich das zertifizierte Objekt befindet.



Wir erstellen eine neue Erweiterung in Kubernetes mit dem Befehl $ kubectl create –f extensions / certificate.yaml. Der Speicher wird automatisch im Backend erstellt und dieser Status wird verwaltet.



Für das Erscheinungsbild dieses neuen Objekts muss ich ein neues Tool verwenden, das Änderungen verfolgt und Maßnahmen für das Zertifikatobjekt ergreift. Das heißt, dieses Tool im Hintergrund sollte mit Let's Encrypt interagieren und ein gültiges Zertifikat erhalten. Dafür benutze ich secret - ich werde sehr schnell zeigen, wie das gemacht wird.

Wir brauchen also ein neues Sub, und ich werde zeigen, was der Unterschied zum vorherigen Code ist. Ich füge einem vorhandenen Container Nginx hinzu, sodass wir das Entwicklungsteam nicht kontaktieren müssen. Wir verwenden weiterhin HTTPS, indem wir den Behälter einfach ganz oben auf dem vorhandenen Herd platzieren.



Dieser Container akzeptiert HTTPS-Verkehr und benötigt eine Konfigurationsdatei, um mit dem Backend zu interagieren. Ich benötige auch einige Zertifikate, die nginx aus dem Dateisystem herunterlädt, sodass Umgebungsvariablen hier nicht funktionieren. Ich habe kein Nginx geschrieben, deshalb kann ich ihn nicht dazu bringen, dies zu tun.



Also füge ich diesen Behälter einfach direkt in den Kamin ein und wende mich zwei Geheimnissen zu.



Das erste und wichtigste Geheimnis ist das TLS-Zertifikat, das von Let's Encrypt stammen sollte. Ich werde Let's Encrypt nicht an meine Anwendung melden, sondern an mein System. Ich möchte diese Abstraktion kontrollieren. Jetzt muss ich eine Konfigurationsdatei für Nginx erstellen. Dies ist die Hauptkonfigurationsdatei, die so aussieht.

Hier wird Port 443 angegeben und SSL aktiviert, das nach diesen beiden Dateien im Dateisystem sucht, den Datenverkehr erfasst und an den lokalen Host 127.0.0.1 {000 sendet.



Genau das hört meine Bewerbung. Jetzt werde ich configmap erstellen - die Nginx-Konfigurationszuordnung mit dem folgenden Befehl.



Mit dem Befehl $ kubectl get configmaps platziere ich nun die configmap "nginx" auf dem System mit demselben Namen wie die Festplatte.



Als nächstes müssen Sie ein Geheimnis schaffen, ich erinnere Sie noch einmal - ich möchte, dass alles automatisiert wird, und ich möchte nicht in den Prozess der Erlangung von Zertifikaten eingreifen. Zu diesem Zweck setze ich ein Tool namens "kube-cert-manager" ein. Hier ist das Ergebnis.



Wir versuchen, ein gültiges Let's Encrypt-Zertifikat zu erhalten, dem mein Browser vertraut, und es als Geheimnis in das Backend einzufügen. Daher wird es für meinen Herd keinen Unterschied geben, dass wir seinen Inhalt ergänzt haben. Wenn Sie sich erinnern, wird dies alles durch Erstellen eines benutzerdefinierten Typs in Puppet erreicht.

Vielleicht ist das eine schlechte Idee, aber jetzt werde ich versuchen, den Controller zu starten, der im Hintergrund funktioniert. Wir kompilieren nicht, wir erstellen keine Anbieter, dieser Daemon arbeitet nur im Hintergrund und überwacht die Änderungen. Sobald das Zertifikatobjekt angezeigt wird, empfängt es es mit Let's Encrypt und fügt es unverzüglich in Echtzeit in das System ein. Also benutze ich den folgenden Befehl.



Dieses Ding hat auch Speicher, so dass wir alles speichern können, was wir brauchen. Es dauert einige Sekunden, bis der Zertifizierungsmanager von kube-cert-manager seine Arbeit aufnimmt.



Als nächstes müssen wir ein Zertifikatobjekt erstellen. Das definiere ich selbst, das ist mein eigenes Schema. Ich erstelle eine neue Sache, die Kubernetes bis jetzt noch nicht kennengelernt hat. Diese besagt, dass ich ein Zertifikat für die Domain lobsters.com erhalten kann.



Es gibt eine E-Mail-Adresse und andere Informationen, die Let's Encrypt benötigt, um mir ein gültiges Zertifikat zu geben. Let's Encrypt sendet mir ein Exchange-Token, um festzustellen, ob ich diese Domain wirklich besitze, und ich muss dieses Token auf mein DNS in Google Cloud anwenden. Wenn die Prüfung erfolgreich ist, erhalten Sie ein echtes Zertifikat, das ich in mein Dateisystem einfügen werde. Lassen Sie uns sehen, wie dies funktioniert, indem Sie den Befehl $ kubectl get pods eingeben.



Wie Sie sehen, arbeitet der Zertifikatmanager noch. Sehen wir uns die detaillierten Informationen zu diesem Prozess mit dem Befehl $ kubectl description pods kube-cert-manager an und fügen den Containernamen aus der ersten Codezeile ein.



Sie sehen, dass die Arbeiten termingerecht ausgeführt werden. Derzeit erstellt der Server ein Volume, das nach Überprüfung und Formatierung auf diesem Server bereitgestellt wird. Während dieses Prozesses können wir weiter gehen und unsere Arbeit beenden.

Ich gebe den Befehl kubectl create –f certificates / lobsters.yaml ein und erhalte das folgende Ergebnis.



Als Nächstes verwende ich einen Befehl, mit dem Sie die Protokolle mehrerer Container anzeigen können. Ich werde den hervorheben, der sich auf mein Objekt bezieht.



Jetzt wird ein DNS-Eintrag in meinem Cloud-basierten DNS-Server erstellt. Wenn ich die hier gezeigte Seite aktualisiere, wird ein neues Austausch-Token mit der Erweiterung .txt angezeigt.



Ich habe also ein Token von Let's Encrypt erhalten und überprüfe jetzt, ob dieser DNS-Eintrag an alle autorisierten Server verteilt wurde, bevor ich Let's Encrypt anweise, diesen Texteintrag in meiner Domain zu überprüfen.



Wenn dies funktioniert, senden sie mir ein gültiges Zertifikat zurück. Eine DNS-Demonstration in Echtzeit ist eine schlechte Idee. Ja, wir bekommen endlich das Zertifikat. Lassen Sie uns verschlüsseln feststellen, dass das Zertifikat aus Kubernetes verschwunden ist, und es dort einfügen. Das ist großartig, denn jetzt habe ich bereits eine Zertifikatanforderungsschnittstelle für alles, was in Kubernetes ausgeführt wird.

Um sicherzustellen, dass alles richtig funktioniert, gebe ich den Befehl $ kubectl get secret ein und wir sehen ein Geheimnis für lobsters.hightowerlabs.com.



Jetzt verwende ich den Befehl $ kubectl delete Secrets lobsters.hightowerlabs.com, da es sich um ein deklaratives System handelt, löschen wir das Zertifikatobjekt nicht, sondern entfernen das damit verbundene Geheimnis in Kubernetes. Daher müssen wir sicherstellen, dass das System beim Löschen dieses Elements das Let's Encrypt-Zertifikat selbst zurückgibt. Dies ist sehr ähnlich zu dem, was wir in Puppet machen, nur hier passiert es online.

Nachdem wir sichergestellt haben, dass alles funktioniert, stellen wir unsere Nginx-Anwendung namens "Lobsters-Secure" erneut bereit, um die Sicherheit der neuen Domain zu gewährleisten. Sein Bild ähnelt der vorherigen Version, aber der Unterschied ist, dass wir hier Nginx setzen. Nginx nimmt den geheimen Link auf und fügt ihn von Kubernetes in das Dateisystem ein. Dadurch erhalte ich ein gültiges Zertifikat für eine bestimmte Domain.

Dazu gebe ich den Befehl $ kubectl apply –f deployments / lobsters-secure.yaml mit demselben Namen ein, damit dieser Befehl den vorhandenen Status überschreibt. Als nächstes wird der Befehl $ kubectl get pods verwendet, der zeigt, dass hier jetzt ein fortlaufendes Rolling-Update stattfindet, da sich unsere Definitionen geändert haben.

Nach Abschluss des Updates ist klar, dass die neue Definition für diese Anwendung verwendet wird. Ich möchte sicherstellen, dass das Zertifikat für unseren DNS-Namen gültig ist, für den ich den Befehl $ kubectl get svc eingebe und die IP-Adresse der Hummer-Site kopiere.



Auf der Registerkarte "Google Cloud" können Sie feststellen, dass diese Adresse mit der Adresse übereinstimmt, die dem Domainnamen lobsters.hightowerlabs.com entspricht. Wenn Sie jetzt lobsters.hightowerlabs.com in die Adressleiste Ihres Browsers eingeben , können Sie sehen, dass wir ein gültiges Zertifikat haben.



Vielen Dank, das ist alles, was ich im Bericht "Kubernetes for System Admins" sagen wollte.

Ein bisschen Werbung :)

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?