MARA: Jetzt auf einer Workstation in Ihrer Nähe verfügbar

NGINX | 22. April 2022

Als wir mit der Arbeit am Projekt NGINX Modern Apps Reference Architecture (MARA) begannen, entschieden wir uns für AWS als IaaS-Anbieter, da wir bereits mit der Plattform vertraut waren und die Kosten aus unserem Abteilungsbudget decken konnten. Natürlich verfügt nicht jeder über dieselben Erfahrungen oder finanziellen Mittel, und viele von Ihnen haben uns gebeten, Möglichkeiten anzubieten, MARA lokal auszuführen – in einer Laborumgebung oder sogar auf einer Workstation – und dabei Kubernetes-Distributionen wie K3s, Canonical MicroK8s und minikube zu verwenden.

Wir haben Ihre Wünsche gehört und freuen uns, heute bekannt geben zu können, dass wir MARA auf MicroK8s getestet haben und Ihnen eine Anleitung zur Verfügung stellen, mit der Sie es selbst bereitstellen können!

Diagramm der Topologie der auf einer Workstation ausgeführten NGINX Modern Apps Reference Architecture

Warum haben wir uns für unsere Tests für MicroK8s entschieden? Weil es die von MARA benötigten DNS-, Speicher- und Egress-Funktionen in einem einfach bereitzustellenden Modell mit geringem Arbeitsspeicherbedarf bietet. Mit MicroK8s können wir Testszenarien einfach und wiederholt durchlaufen, um die Mindestanforderungen für Bereitstellungen zu ermitteln, die ein angemessenes Leistungsniveau bieten.

Wir gehen davon aus, dass diese Arbeit uns das Testen weiterer Kubernetes-Distributionen erleichtern wird. Informationen zum aktuellen Status verschiedener Distributionen finden Sie in unserem GitHub-Repository. Wenn Sie eine bevorzugte Distribution haben, die Sie gerne auf der Liste sehen würden, laden wir Sie ein, das Repository zu forken, Tests durchzuführen und Pull Requests zu erstellen!

Umgang mit Ressourcenbeschränkungen

Die größten Einschränkungen beim lokalen Betrieb von MARA sind Arbeitsspeicher und CPU-Leistung. Bei ersten Tests stellten wir fest, dass die meisten Probleme mit erschöpftem Arbeitsspeicher Elasticsearch betrafen. In Konfigurationen mit äußerst wenig Arbeitsspeicher (weniger als 16 GB) ist Kibana nahezu unbrauchbar. Um dieses Problem zu beheben, haben wir in der MARA-Konfigurationsdatei Einstellungen bereitgestellt, mit denen die Redundanzmechanismen deaktiviert werden, über die eine vollständige Elasticsearch-Bereitstellung normalerweise verfügt. Dies erhöht zwar die Zahl möglicher Ausfallszenarien, ist in Umgebungen mit begrenzten Ressourcen jedoch ein notwendiger Kompromiss.

CPU-Beschränkungen hängen direkt von der Last ab, die auf unsere Beispielanwendung Bank of Sirius ausgeübt wird. Die MARA-Bereitstellung umfasst Locust, um Last auf Bank of Sirius zu erzeugen. Dabei können Benutzer die Anzahl der Benutzer und die Erstellungsrate neuer Benutzer festlegen.

Beachten Sie, dass sich eine Erhöhung der Last auf Bank of Sirius auch auf das übrige System auswirkt. Wenn entweder die Benutzerzahl oder die Spawn-Rate zu hoch ist, verschlechtert sich die Leistung von MARA so stark, dass Komponenten wahrscheinlich abstürzen oder nicht mehr reagieren. Die Werte, die dieses Verhalten verursachen, hängen von der verfügbaren CPU-Leistung ab. Sie können jedoch davon ausgehen, dass eine Bereitstellung, die mindestens über die unter Anforderungen angegebene Kapazität verfügt, die von bis zu 64 Benutzern und einer Spawn-Rate von jeweils 16 Benutzern erzeugte Last bewältigen kann.

MARA auf MicroK8s bereitstellen

Nachdem die Grundlagen geklärt sind, können Sie MARA auf MicroK8s bereitstellen!

Voraussetzungen

  • root-Zugriff auf ein System (Bare-Metal-Linux-Server, virtualisiert oder in der Cloud), auf dem Ubuntu 20.04 (Focal) oder höher ausgeführt wird und das mindestens über Folgendes verfügt:
    • 20-GB-Festplatte
    • 16 GB Arbeitsspeicher
    • Das Äquivalent von 4 CPUs
  • 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 die folgenden Befehle aus:
$  sudo apt update$  sudo apt install -y python3-venv
  • Mindestens eine freie IPv4-Adresse, die der integrierte MetalLB-Load-Balancer von MicroK8s dem ausgehenden Datenverkehr des NGINX Ingress Controllers zuweisen kann. Wenn Sie über localhost auf die Bank-of-Sirius-Anwendung zugreifen, ist jede verfügbare private (RFC 1918-konforme) Adresse geeignet. 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. Falls Sie noch nicht darüber verfügen, erstellen Sie beides in Schritt 1 von MARA bereitstellen. Beachten Sie, dass Pulumi zwar das Speichern der Statusdatei in einem S3-kompatiblen Objektspeicher oder im lokalen Dateisystem ermöglicht, MARA dies zum Zeitpunkt der Erstellung dieses Dokuments jedoch nicht unterstützt. Diese Einschränkung wird in einer zukünftigen Version von MARA oder Pulumi aufgehoben.

MicroK8s installieren und konfigurieren

  1. MicroK8s installieren:
$ sudo snap install microk8s --classicmicrok8s (1.23/stable) v1.23.3 from Canonical✓ installed
  1. Legen Sie die erforderlichen Berechtigungen zum Ausführen von microk8s-Befehlen fest. Ersetzen Sie <username> durch Ihr Benutzerkonto, das auf dem System über root-Rechte verfügt:
$ sudo usermod -a -G microk8s <username>$ sudo chown -f -R <username> ~/.kube
$ newgrp microk8s
  1. Melden Sie sich von Ihrem Konto mit Root-Rechten ab und anschließend wieder an, damit die neuen Berechtigungen wirksam werden.
  2. 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, der eine der folgenden Optionen darstellt:
$ microk8s enable dns storage metallbEnabling DNS
Applying manifest
...
Restarting kubelet
DNS is enabled
Enabling default storage class
...
Storage will be available soon
Enabling MetalLB
Enter each IP address range delimited by comma (e.g. '10.64.140.43-10.64.140.49,192.168.0.105-192.168.0.111'): 192.168.100.100-192.168.100.110
Applying Metallb manifest
...
MetalLB is enabled
  • Ein tatsächlicher Bereich privater IP-Adressen (zum Beispiel 192.168.100.100-192.168.100.110, der nachfolgend verwendete Wert)
  • Eine einzelne private IP-Adresse (zum Beispiel 192.168.100.100-192.168.100.100)
  1. Bestätigen Sie, dass MicroK8s ausgeführt wird:
$ microk8s statusmicrok8s is running
high-availability: no
  datastore master nodes: 127.0.0.1:19001
  datastore standby nodes: none
addons:
  enabled:
    dns           # CoreDNS
    ha-cluster    # Configure high availability on the current node
    metallb       # Loadbalancer for your Kubernetes cluster
    storage       # Storage class; allocates storage from host directory
...
  1. 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 config > ~/.kube/config$ sudo chmod 0644 ~/.kube/config

Klonen Sie das MARA-Repository und richten Sie den MicroK8s-Cluster ein

  1. Klonen Sie das MARA-Repository und initialisieren Sie das Bank-of-Sirius-Submodul:
$ git clone https://github.com/nginxinc/kic-reference-architectures.git$ cd kic-reference-architectures/
$ git submodule update --init --recursive --remote
  1. Richten Sie im Stammverzeichnis des geklonten MARA-Repositorys (in das Sie im vorherigen Schritt gewechselt haben) die virtuelle Python-Umgebung für den MicroK8s-Cluster ein:
$ ./bin/setup_venv.sh
  1. Dieser Befehl erzeugt eine umfangreiche Protokollausgabe. Falls Fehler auftreten, lesen Sie bitte den Abschnitt „Bekannte Probleme/Einschränkungen“ im MARA-GitHub-Repository, um Lösungsvorschläge zu erhalten.
  2. Aktivieren Sie die virtuelle Python-Umgebung. Der Befehl legt Ihren PATH und andere Umgebungsvariablen so fest, dass die virtuelle Umgebung verwendet wird:
$ source ./pulumi/python/venv/bin/activate
  1. Stellen Sie sicher, dass der MicroK8s-Cluster für die MARA-Bereitstellung korrekt konfiguriert ist:
$ ./bin/testcap.sh
This script will perform testing on the current kubernetes installation using the currently active kubernetes configuration and context.
Any failures should be investigated, as they will indicate that the installation does not meet the minimum set of capabilities required to run MARA.

...
==============================================================
| All tests passed! This system meets the basic requirements |
| to deploy MARA.                                            |
==============================================================

MARA bereitstellen

Das Skript start.sh, das in diesem Abschnitt zur Bereitstellung von MARA verwendet wird, unterstützt Optionen, die zusätzliche Maßnahmen erfordern, damit die Bereitstellung erfolgreich abgeschlossen werden kann. Der Einfachheit halber gehen wir hier von einer grundlegenden Bereitstellung aus, die:

  • Verwendet kubeconfig-Dateien anstelle einer der anderen unterstützten Bereitstellungsoptionen. Weitere Informationen zu den anderen Optionen finden Sie im Leitfaden für die ersten Schritte in unserem GitHub-Repository.
  • Verwendet die neueste Version von NGINX Open Source, mit der wir MARA getestet haben (nicht unbedingt die allerneueste Version).
  • Verwendet den auf NGINX Open Source basierenden NGINX Ingress Controller. Wenn Sie den auf NGINX Plus basierenden NGINX Ingress Controller verwenden möchten, müssen Sie in Ihrem Kubernetes-Cluster ein auf NGINX Plus basierendes Image aus der F5 Docker-Registry verwenden. Weitere Informationen finden Sie im ersten Hinweis „ACHTUNG!“ in Schritt 3 weiter unten.
  • Verwendet einen einzelnen standardmäßigen Kubernetes-Kontext. Siehe den zweiten HINWEIS! in Schritt 3.

Stellen Sie MARA im MicroK8s-Cluster bereit:

  1. 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 (und bei Bedarf ein Konto zu erstellen). Anschließend werden Sie nach dem API-Token für Ihr Pulumi-Konto gefragt.
$ ./bin/start.shAdding to [/home/ubuntu/kic-reference-architectures/bin/venv/bin] to PATH
Manage your Pulumi stacks by logging in.
Run `pulumi login --help` for alternative login options.
Enter your access token from https://app.pulumi.com/account/tokens
    or hit <ENTER> to log in using your browser            : <token>

Please read the documentation for more details.
  1. Wählen Sie den Bereitstellungstyp aus und geben Sie an der Eingabeaufforderung k ein, 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 einer Registry.
Type a for AWS, k for kubeconfig? k
Calling kubeconfig startup script
make is not installed - it must be installed if you intend to build NGINX Kubernetes Ingress Controller from source.
docker is not installed - it must be installed if you intend to build NGINX Kubernetes Ingress Controller from source.

  1. Geben Sie an der Eingabeaufforderung den Namen des zu erstellenden Pulumi-Stacks ein (hier: mara). Er muss innerhalb Ihres Pulumi-Kontos eindeutig sein.
Enter the name of the Pulumi stack to use in all projects: maraSubmodule source found
Configuring all Pulumi projects to use the stack: mara
Created stack 'mara'

NOTICE! Currently the deployment via kubeconfig only supports pulling images from the registry! A JWT is required in order to access the NGINX Plus repository. This should be placed in a file in the extras directory in the root, in a file named jwt.token

See https://docs.nginx.com/nginx-ingress-controller/installation/using-the-jwt-token-docker-secret/ for more details and examples.

No JWT found; writing placeholder manifest

NOTICE! When using a kubeconfig file you need to ensure that your environment is configured to connect to Kubernetes properly. If you have multiple kubernetes contexts (or custom contexts) you may need to remove them and replace them with a simple ~/.kube/config file. This will be addressed in a future release.
  1. Geben Sie bei den Eingabeaufforderungen den vollständigen Pfad zu Ihrer kubeconfig-Datei und den Namen des Clusters an. In diesem Beispiel lauten sie /home/<username>/.kube/config und microk8s-cluster.
Provide an absolute path to your kubeconfig filevalue: /home/<username>/.kube/config
Provide your clustername
value: microk8s-cluster
Attempting to connect to kubernetes cluster
  1. Geben Sie bei der nächsten Eingabeaufforderung den vollständig qualifizierten Domänennamen (FQDN) für den Cluster an. Das Skript verwendet den FQDN für zwei Zwecke: zur Konfiguration des NGINX Ingress Controllers und zur Erstellung des selbstsignierten Zertifikats (aufgrund des zweiten Verwendungszwecks darf der Wert keine IP-Adresse sein). Wenn Sie einen anderen FQDN als mara.example.com verwenden, denken Sie daran, diesen auch in den folgenden Schritten zu verwenden.
Create a fqdn for your deploymentvalue: mara.example.com
  1. Geben Sie das Grafana-Administratorpasswort an:
Create a password for the grafana admin user; this password will be used to access the Grafana dashboardThis should be an alphanumeric string without any shell special characters; it is presented in plain text due to current limitations with Pulumi secrets. You will need this password to access the Grafana dashboard.
value: <password>

Ein Protokoll des Installationsvorgangs wird angezeigt, das für jeden Schritt die folgenden Informationen enthält:

  • Ein Banner, das die im Schritt ausgeführte Hauptaktion beschreibt (zum Beispiel signalisiert Logstore den Beginn der Elasticsearch-Bereitstellung)
  • Eine Liste der Aufgaben, die Pulumi ausführen wird
  • Eine Echtzeit-Statusanzeige für jede Pulumi-Aufgabe
  • Von Pulumi und MARA generierte Diagnoseinformationen, beispielsweise der festgelegte Hostname und die IP-Adresse
  • Anzahl der betroffenen Ressourcen
  • Die verstrichene Zeit

Wenn der letzte Schritt (für Bank of Sirius) abgeschlossen ist, gibt die Ablaufverfolgung die IP-Adresse aus, die dem NGINX Ingress Controller von MetalLB zugewiesen wurde (hier 192.168.100.100) sowie den FQDN, den Sie für die Bereitstellung ausgewählt haben (hier mara.example.com), und weitere Informationen zur Bereitstellung.

The startup process has finished successfully
Next Steps:
1. Map the IP address (192.168.100.100) of your Ingress Controller with your FQDN (mara.example.com).
2. Use the ./bin/test-forward.sh program to establish tunnels you can use to connect to the management tools.
3. Use kubectl, k9s, or the Kubernetes dashboard to explore your deployment.

To review your configuration options, including the passwords defined, you can access the pulumi secrets via the following commands:

Main Configuration: pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/config

Bank of Sirius (Example Application) Configuration: pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/kubernetes/applications/sirius

K8 Loadbalancer IP: kubectl get services --namespace nginx-ingress

Please see the documentation in the github repository for more information
  1. Erstellen Sie in dem Tool, das Sie zur Auflösung von FQDNs verwenden (z. B. in der lokalen Datei /etc/hosts oder auf dem DNS-Server), eine Zuordnung zwischen dem FQDN und der im vorherigen Schritt angegebenen IP-Adresse.
  2. Überprüfen Sie, ob eine Anfrage an die MARA-Bereitstellung erfolgreich ist. Verwenden Sie die Option -k, 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.comHTTP/1.1 200 OK
Server: nginx/1.21.5
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Type: text/html; charset=utf-8
Content-Length: 7016
Connection: keep-alive
  1. Rufen Sie in einem Browser https://mara.example.com auf, um die Website der Bank of Sirius anzuzeigen. Zum Zeitpunkt der Erstellung können Sie bei vielen Browsern (einschließlich Firefox und Safari) die Warnung, dass die Website ein selbstsigniertes Zertifikat verwendet, bedenkenlos bestätigen. Wir empfehlen, Chrome nicht zu verwenden, da der Zugriff auf die Website aufgrund kürzlich vorgenommener Sicherheitsänderungen wahrscheinlich blockiert wird.
  2. Führen Sie das Skript test-forward.sh aus, um die Kubernetes-Portweiterleitung einzurichten, damit Sie auf die Tools 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. Hinweis: Damit die Portweiterleitung ordnungsgemäß funktioniert, muss Ihr Browser auf demselben System ausgeführt werden wie die Befehls-Shell, in der Sie diesen Befehl ausführen. Ist dies nicht der Fall (beispielsweise weil Sie eine Virtualisierungsumgebung verwenden), scheint der Befehl erfolgreich ausgeführt zu werden, die Portweiterleitung funktioniert jedoch nicht. Weitere Informationen finden Sie unter Zugriff auf die Verwaltungstools in MARA in unserem GitHub-Repository.
$ ./bin/test-forward.shConnections Details
====================================
Kibana:        http://localhost:5601
Grafana:       http://localhost:3000
Locust:        http://localhost:8089
Prometheus:    http://localhost:9090
Elasticsearch: http://localhost:9200
====================================

Issue Ctrl-C to Exit

Zusammenfassung

Das war’s! Mit dieser Anleitung ist innerhalb von etwa 20 Minuten eine funktionsfähige MARA-Bereitstellung in Ihrer Umgebung eingerichtet und betriebsbereit. Anschließend können Sie mit der Anwendung Bank of Sirius wie mit jeder anderen Kubernetes-Anwendung interagieren. Ein guter Ausgangspunkt ist die Verwendung der integrierten Observability-Tools, um zu testen, wie sich die Umgebung verhält, wenn Sie mit Locust unterschiedlich hohe Lasten erzeugen.

Unser Ziel ist es, MARA für möglichst viele Kubernetes-Benutzer so nützlich wie möglich zu machen. Ihnen gefällt unsere Auswahl bei einigen Komponenten nicht? Wir möchten Sie ermutigen, diese durch Ihre eigenen Komponenten zu ersetzen und einen Pull-Request zu erstellen, wenn Sie Ihre Änderungen mit anderen teilen möchten. Teilen Sie uns außerdem Ihre Gedanken mit und stellen Sie Fragen – auch zu fragwürdigen Annahmen, die wir möglicherweise getroffen haben – auf den Seiten Issues und Discussions unseres Repositorys.

Ähnliche Beiträge

Dieser Beitrag ist Teil einer Reihe. Während wir MARA nach und nach um neue Funktionen erweitern, veröffentlichen wir die Details dazu im Blog:


Teilen

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.