Als wir mit der Arbeit am NGINX Modern Apps Reference Architecture (MARA)-Projekt begannen, entschieden wir uns für AWS als unseren IaaS-Anbieter, da wir mit der Plattform bereits vertraut waren und sie über unser Abteilungsbudget bezahlen konnten. Natürlich verfügt nicht jeder über die gleiche Erfahrung oder das gleiche Budget, und viele von Ihnen haben uns gebeten, Optionen für die lokale Ausführung von MARA – in einer Laborumgebung oder sogar auf einer Workstation – mit Kubernetes-Distributionen wie K3s , Canonical MicroK8s und minikube bereitzustellen.
Wir haben Sie gehört und freuen uns, Ihnen heute mitteilen zu können, dass wir MARA auf MicroK8s getestet haben und Anweisungen zur Verfügung stellen, damit Sie es selbst einsetzen können!
Warum haben wir für unsere Tests MicroK8s ausgewählt? Weil es die DNS-, Speicher- und Egress-Funktionen bietet, die MARA benötigt, in einem einfach bereitzustellenden Modell mit geringem Speicherbedarf. Mit MicroK8s können wir Testszenarien einfach und wiederholt durchlaufen, um die Mindestanforderungen für Bereitstellungen zu ermitteln, die ein angemessenes Leistungsniveau liefern.
Wir gehen davon aus, dass diese Arbeit unsere Tests anderer Kubernetes-Distributionen erleichtern wird. Informationen zum aktuellen Status verschiedener Distributionen finden Sie in unserem GitHub-Repository . Wenn Sie eine bevorzugte Distribution haben, die Sie in der Liste sehen möchten, laden wir Sie ein, diese zu forken, zu testen und Pull Requests zu erstellen!
Die größten Einschränkungen beim lokalen Ausführen von MARA sind Speicher und CPU. Bei vorläufigen Tests stellten wir fest, dass die meisten Probleme mit Speichererschöpfung Elasticsearch betrafen. Kibana ist in Konfigurationen mit extrem wenig Arbeitsspeicher (weniger als 16 GB ) nahezu unbrauchbar. Um dieses Problem zu beheben, haben wir in der MARA-Konfigurationsdatei Einstellungen bereitgestellt, die den Redundanzschutz beseitigen, über den eine vollständige Elasticsearch-Bereitstellung normalerweise verfügt. Dadurch erhöht sich zwar die Anzahl der Fehlerarten, in Umgebungen mit eingeschränkten Ressourcen ist dies jedoch ein notwendiger Kompromiss.
CPU-Einschränkungen stehen in direktem Zusammenhang mit der Belastung unserer Beispielanwendung „Bank of Sirius“ . Die MARA-Bereitstellung umfasst Locust , um Last auf der Bank of Sirius zu generieren, mit benutzergesteuerten Einstellungen für die Anzahl der Benutzer und die Spawn-Rate für neue Benutzer.
Beachten Sie, dass eine erhöhte Belastung der Bank of Sirius auch Auswirkungen auf den Rest des Systems hat. Wenn entweder die Benutzeranzahl oder die Spawn-Rate zu hoch ist, verschlechtert sich die MARA-Leistung bis zu dem Punkt, an dem Komponenten wahrscheinlich abstürzen oder hängen bleiben. Die Werte, die dieses Verhalten verursachen, hängen von der verfügbaren CPU ab. Sie können jedoch davon ausgehen, dass eine Bereitstellung mit mindestens der in den Anforderungen angegebenen Kapazität die Last von bis zu 64 Benutzern und einer Span-Rate von 16 Benutzern gleichzeitig bewältigen kann.
Nachdem Sie diesen Hintergrund geklärt haben, sind Sie bereit, MARA auf MicroK8s zu starten!
Root-
Zugriff auf ein System (Bare-Metal-Linux-Server, virtualisiert oder Cloud) mit Ubuntu 20.04 (Focal) oder höher, mit mindestens:
Eine virtuelle Python 3-Umgebung auf dem lokalen System mit allen von MARA benötigten Bibliotheken und Binärdateien. Wenn Python 3 noch nicht installiert ist, führen Sie diese Befehle aus:
$ sudo apt update $ sudo apt install -y python3-venv
Mindestens eine freie IPv4-Adresse für den integrierten MetalLB- Load Balancer von MicroK8s, die dem Ausgang des NGINX Ingress Controllers zugewiesen werden kann. Wenn Sie über den lokalen Host auf die Bank of Sirius-Anwendung zugreifen, ist jede verfügbare private ( RFC 1918 -kompatible) Adresse akzeptabel. Wenn Ihr Netzwerk beispielsweise 192.168.100.0/24 ist, können Sie eine Adresse wie 10.10.10.10 verwenden.
Ein Pulumi-Konto und ein Zugriffstoken. Wenn Sie diese noch nicht haben, erstellen Sie sie in Schritt 1 von „MARA bereitstellen“ .
Beachten Sie, dass Sie mit Pulumi die Statusdatei zwar in einem S3-kompatiblen Objektspeicher oder im lokalen Dateisystem speichern können, MARA dies zum Zeitpunkt des Schreibens jedoch nicht unterstützt. Diese Einschränkung wird in einer zukünftigen Version von MARA oder Pulumi entfernt.
Installieren Sie MicroK8s:
$ sudo snap install microk8s --classic microk8s (1.23/stable) v1.23.3 von Canonical✓ installiert
Legen Sie die erforderlichen Berechtigungen zum Ausführen von Microk8s
-Befehlen fest. Für <Benutzername>
, ersetzen Sie Ihr Konto, das Wurzel
Berechtigung auf dem System:
$ sudo usermod -a -G microk8s <Benutzername>$ sudo chown -f -R <Benutzername> ~/.kube
$ neugrp microk8s
Melden Sie sich von Ihrem Root-Konto ab und wieder an, damit die neuen Berechtigungen wirksam werden.
Aktivieren Sie die MicroK8s-Add-ons für DNS , Speicher und MetalLB .
Geben Sie bei der Eingabeaufforderung einen IP-Adressbereich im Format X . X . X . X ‑ X . X . X . Y
an, um Folgendes darzustellen:
192.168.100.100-192.168.100.110
, der unten verwendete Wert)192.168.100.100-192.168.100.100
)$ microk8s enable dns storage metallb DNS wird aktiviert. Manifest wird angewendet …
Kubelet wird neu gestartet. DNS ist aktiviert. Standardspeicherklasse wird aktiviert …
Der Speicher wird bald verfügbar sein Aktivieren von MetalLB Geben Sie jeden IP-Adressbereich durch Kommas getrennt ein (z. B. '10.64.140.43-10.64.140.49,192.168.0.105-192.168.0.111'): 192.168.100.100-192.168.100.110
Metallb-Manifest anwenden ...
MetalLB ist aktiviert
Bestätigen Sie, dass MicroK8s ausgeführt wird:
$ microk8s-Status microk8s läuft mit hoher Verfügbarkeit: keine Datastore-Masterknoten: 127.0.0.1:19001 Datastore-Standby-Knoten: keine Add-Ons: aktiviert: DNS # CoreDNS ha-cluster # Konfigurieren Sie Hochverfügbarkeit auf dem aktuellen Knoten metallb # Loadbalancer für Ihren Kubernetes-Clusterspeicher # Speicherklasse; weist Speicher aus dem Hostverzeichnis zu …
Laden Sie die MicroK8s-Konfiguration in die Datei, in der die meisten Dienstprogramme sie erwarten ( ~/.kube/config ), und legen Sie die empfohlenen Berechtigungen für das Verzeichnis und die Datei fest:
$ microk8s-Konfiguration > ~/.kube/config $ sudo chmod 0644 ~/.kube/config
Klonen Sie das MARA-Repository und initialisieren Sie das Bank of Sirius-Untermodul:
$ git clone https://github.com/nginxinc/kic-reference-architectures.git $ cd kic-reference-architectures/ $ git submodule update --init --recursive --remote
Arbeiten Sie im Stammverzeichnis des geklonten MARA-Repositorys (Sie haben dort im vorherigen Schritt das Verzeichnis gewechselt) und richten Sie die virtuelle Python-Umgebung für den MicroK8s-Cluster ein:
$ ./bin/setup_venv.sh
Dieser Befehl generiert eine lange Ablaufverfolgung. Wenn Fehler auftreten, prüfen Sie bitte den Abschnitt „Bekannte Probleme/Einschränkungen“ im MARA-GitHub-Repo, um Vorschläge zu erhalten.
Aktivieren Sie die virtuelle Python-Umgebung. Der Befehl legt Ihren PATH
und andere Umgebungsvariablen fest, um die virtuelle Umgebung zu verwenden:
$ Quelle ./pulumi/python/venv/bin/activate
Bestätigen Sie, dass der MicroK8s-Cluster für die MARA-Bereitstellung richtig konfiguriert ist:
$ ./bin/testcap.sh Dieses Skript führt Tests der aktuellen Kubernetes-Installation unter Verwendung der aktuell aktiven Kubernetes-Konfiguration und des aktuell aktiven Kubernetes-Kontexts durch.
Alle Fehler sollten untersucht werden, da sie darauf hinweisen, dass die Installation nicht die Mindestanforderungen für die Ausführung von MARA erfüllt. ... ================================================================= | Alle Tests bestanden! Dieses System erfüllt die Grundvoraussetzungen | | für den Einsatz von MARA. | =================================================================
Das Skript start.sh
, das in diesem Abschnitt zum Bereitstellen von MARA verwendet wird, enthält Optionen, die zusätzliche Aktionen erfordern, damit die Bereitstellung erfolgreich ist. Der Einfachheit halber gehen wir hier von einer Basisbereitstellung aus, die:
HINWEIS!
in Schritt 3 weiter unten.HINWEIS!
in Schritt 3.Stellen Sie MARA im MicroK8s-Cluster bereit:
Führen Sie das Skript start.sh
aus.
Wenn Sie Ihre Workstation noch nicht für die Verwendung von Pulumi konfiguriert haben, werden Sie aufgefordert, sich bei Pulumi anzumelden (ggf. unter Erstellung eines Kontos) und dann zur Eingabe des API-Tokens aufgefordert, das Ihrem Pulumi-Konto zugeordnet ist.
$ ./bin/start.sh Hinzufügen zu [/home/ubuntu/kic-reference-architectures/bin/venv/bin] zu PATH. Verwalten Sie Ihre Pulumi-Stapel, indem Sie sich anmelden.
Führen Sie „pulumi login --help“ für alternative Anmeldeoptionen aus.
Geben Sie Ihren Zugriffstoken von https://app.pulumi.com/account/tokens ein
oder drücken Sie <EINGABE>, um sich über Ihren Browser anzumelden: <Token>
Bitte lesen Sie die Dokumentation für weitere Einzelheiten.
Wählen Sie den Bereitstellungstyp aus, indem Sie in der Eingabeaufforderung „k“
eingeben, um die Bereitstellung mit Kubeconfig-Dateien zu erstellen. Ignorieren Sie die Warnungen, dass Make
und Docker nicht installiert sind. Die Bereitstellung verwendet stattdessen ein NGINX Ingress Controller-Image aus einem Register.
Geben Sie „a“ für AWS und „k“ für kubeconfig ein. k „Aufruf des Startskripts kubeconfig“ „make“ ist nicht installiert – es muss installiert werden, wenn Sie den NGINX Kubernetes Ingress Controller aus der Quelle erstellen möchten. „docker“ ist nicht installiert – es muss installiert werden, wenn Sie den NGINX Kubernetes Ingress Controller aus der Quelle erstellen möchten.
Geben Sie bei der Eingabeaufforderung den Namen des zu erstellenden Pulumi-Stapels an (hier: mara
). Es muss innerhalb Ihres Pulumi-Kontos eindeutig sein.
Geben Sie den Namen des Pulumi-Stapels ein, der in allen Projekten verwendet werden soll: mara. Untermodulquelle gefunden. Alle Pulumi-Projekte werden für die Verwendung des Stapels konfiguriert: mara. Stapel „mara“ erstellt. HINWEIS! Derzeit unterstützt das Deployment über kubeconfig nur das Abrufen von Images aus der Registry! Für den Zugriff auf das NGINX Plus-Repository ist ein JWT erforderlich. Dies sollte in einer Datei im Extras-Verzeichnis im Stammverzeichnis abgelegt werden, in einer Datei mit dem Namen jwt.token. Weitere Einzelheiten und Beispiele finden Sie unter https://docs.nginx.com/nginx-ingress-controller/installation/using-the-jwt-token-docker-secret/.
Kein JWT gefunden; Platzhaltermanifest wird geschrieben. HINWEIS! Wenn Sie eine Kubeconfig-Datei verwenden, müssen Sie sicherstellen, dass Ihre Umgebung für die ordnungsgemäße Verbindung mit Kubernetes konfiguriert ist. Wenn Sie mehrere Kubernetes-Kontexte (oder benutzerdefinierte Kontexte) haben, müssen Sie diese möglicherweise entfernen und durch eine einfache Datei ~/.kube/config ersetzen. Dies wird in einer zukünftigen Version behoben.
Geben Sie bei den Eingabeaufforderungen den vollständigen Pfad zu Ihrer Kubeconfig-Datei und den Namen des Clusters an. Hier sind sie /heim/<Benutzername>/.kube/config
Und MicroK8S-Cluster
.
Geben Sie einen absoluten Pfad zu Ihrem Kubeconfig-Dateiwert an: /heim/<Benutzername>/.kube/config
Geben Sie Ihren Clusternamen-Wert an: MicroK8S-Cluster
Verbindungsversuch zum Kubernetes-Cluster wird durchgeführt
Geben Sie bei der nächsten Eingabeaufforderung den vollqualifizierten Domänennamen (FQDN) für den Cluster an. Das Skript verwendet den FQDN für zwei Zwecke: zum Konfigurieren des NGINX Ingress Controllers und zum Erstellen des selbstsignierten Zertifikats (die zweite Verwendung bedeutet, dass der Wert keine IP-Adresse sein kann). Wenn Sie mara.example.com
durch einen anderen FQDN ersetzen, denken Sie daran, diesen auch in den folgenden Schritten zu verwenden.
Erstellen Sie einen FQDN für Ihren Bereitstellungswert: mara.example.com
Geben Sie das Grafana-Administratorkennwort an:
Erstellen Sie ein Kennwort für den Grafana-Administratorbenutzer. Dieses Kennwort wird für den Zugriff auf das Grafana-Dashboard verwendet. Dies sollte eine alphanumerische Zeichenfolge ohne Shell-Sonderzeichen sein. Aufgrund aktueller Einschränkungen bei Pulumi-Geheimnissen wird es im Klartext angezeigt. Sie benötigen dieses Passwort, um auf das Grafana-Dashboard zuzugreifen.
Wert: <Passwort>
Es wird eine Ablaufverfolgung des Installationsvorgangs angezeigt, in der für jeden Schritt die folgenden Informationen angezeigt werden:
Logstore
signalisiert beispielsweise den Beginn der Elasticsearch-Bereitstellung)Wenn der letzte Schritt (für Bank of Sirius) abgeschlossen ist, meldet der Trace die IP-Adresse, die dem NGINX Ingress Controller von MetalLB zugewiesen wurde (hier192.168.100.100
) und den FQDN, den Sie für die Bereitstellung gewählt haben (hier mara.example.com
), zusammen mit weiteren Informationen zur Bereitstellung.
Der Startvorgang wurde erfolgreich abgeschlossen.
Nächste Schritte:
1. Ordnen Sie die IP-Adresse (192.168.100.100) Ihres Ingress Controllers Ihrem FQDN (mara.example.com) zu.
2. Verwenden Sie das Programm ./bin/test-forward.sh, um Tunnel einzurichten, die Sie für die Verbindung mit den Verwaltungstools verwenden können.
3. Verwenden Sie kubectl, k9s oder das Kubernetes-Dashboard, um Ihre Bereitstellung zu erkunden.
Um Ihre Konfigurationsoptionen, einschließlich der definierten Passwörter, zu überprüfen, können Sie über die folgenden Befehle auf die Pulumi-Geheimnisse zugreifen:
Hauptkonfiguration: pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/config
Bank of Sirius (Beispielanwendung) Konfiguration: pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/kubernetes/applications/sirius
K8 Loadbalancer IP: kubectl get services --namespace nginx-ingress
Weitere Informationen finden Sie in der Dokumentation im GitHub-Repository.
Erstellen Sie in dem Tool, das Sie zum Auflösen von FQDNs verwenden (z. B. der lokalen Datei /etc/hosts oder dem DNS-Server), eine Zuordnung zwischen dem im vorherigen Schritt gemeldeten FQDN und der IP-Adresse.
Überprüfen Sie, ob eine Anforderung an die MARA-Bereitstellung erfolgreich ist. Fügen Sie die Option -k
ein, damit curl
ein selbstsigniertes Zertifikat akzeptiert. Um weitere Informationen zum Zertifikat anzuzeigen, fügen Sie die Option -v
hinzu.
$ curl -k -I https://mara.example.com HTTP/1.1 200 OK Server: nginx/1.21.5 Datum: Tag , TT Mo JJJJ hh:mm:ss TZ Inhaltstyp: text/html; charset=utf-8 Inhaltslänge: 7016 Verbindung: Keep-Alive
Navigieren Sie in einem Browser zu https://mara.example.com, um die Website der Bank of Sirius anzuzeigen. Zum Zeitpunkt des Schreibens dieses Artikels können Sie bei vielen Browsern (einschließlich Firefox und Safari) die angezeigte Warnung bezüglich der Site, die ein selbstsigniertes Zertifikat verwendet, bedenkenlos ignorieren. Wir empfehlen Ihnen, Chrome nicht zu verwenden. Aufgrund der jüngsten Sicherheitsänderungen ist es wahrscheinlich, dass Ihnen der Zugriff auf die Site verweigert wird.
Führen Sie das Skript test-forward.sh
aus, um die Kubernetes-Portweiterleitung einzurichten, damit Sie auf die Tools in der MARA-Verwaltungssuite zugreifen können – Elasticsearch , Grafana , Kibana , Locust und Prometheus . Das Skript ermittelt die entsprechenden Dienstnamen und führt Kubectl
-Befehle aus, um sie an lokale Ports weiterzuleiten.
Notiz: Damit die Portweiterleitung ordnungsgemäß funktioniert, muss Ihr Browser auf demselben System ausgeführt werden wie die Befehlsshell, in der Sie diesen Befehl ausführen. Wenn nicht (weil Sie beispielsweise eine Virtualisierungsumgebung verwenden), scheint der Befehl erfolgreich zu sein, die Portweiterleitung funktioniert jedoch nicht. Weitere Informationen finden Sie unter „Zugriff auf die Verwaltungstools in MARA“ in unserem GitHub-Repository.
$ ./bin/test-forward.sh Verbindungsdetails ===================================== Kibana: http://localhost:5601 Grafana: http://localhost:3000 Locust: http://localhost:8089 Prometheus: http://localhost:9090 Elasticsearch: http://localhost:9200 ========================================== Drücken Sie Strg-C zum Beenden
Das ist es! Mit diesen Anweisungen ist eine funktionierende MARA-Bereitstellung in Ihrer Umgebung innerhalb von etwa 20 Minuten einsatzbereit. Ab diesem Zeitpunkt können Sie mit der Bank of Sirius-Anwendung wie mit jeder anderen Kubernetes-Anwendung interagieren. Ein guter Ausgangspunkt ist die Verwendung der integrierten Beobachtungstools, um zu testen, wie sich die Umgebung verhält, wenn Sie mit Locust unterschiedliche Lastmengen erzeugen.
Unser Ziel ist es, MARA für möglichst viele Kubernetes-Benutzer so nützlich wie möglich zu machen. Ihnen gefällt die Auswahl einiger Komponenten nicht? Wir empfehlen Ihnen, Ihre Komponenten zu ersetzen und eine Pull-Anfrage zu öffnen, wenn Sie sie freigeben möchten. Teilen Sie uns außerdem Ihre Gedanken mit und stellen Sie Fragen – auch zu unseren fragwürdigen Annahmen – auf den Seiten „Probleme“ und „Diskussionen“ in unserem Repo.
Dieser Beitrag ist Teil einer Serie. Wenn wir MARA im Laufe der Zeit um neue Funktionen erweitern, veröffentlichen wir die Einzelheiten im Blog:
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."