So installieren und verwenden Sie Istio mit Kubernetes

Einführung

Ein Service Mesh ist eine Infrastrukturebene, mit der Sie die Kommunikation zwischen den Microservices Ihrer Anwendung verwalten können. Da immer mehr Entwickler mit Microservices arbeiten, haben sich Service-Meshes entwickelt, um diese Arbeit zu vereinfachen und effektiver zu gestalten, indem gemeinsame Verwaltungs- und Verwaltungsaufgaben in einer verteilten Konfiguration zusammengefasst werden.

Durch die Verwendung eines Servicegitters wie Istio können Aufgaben wie Serviceerkennung, Routing- und Datenverkehrskonfiguration, Verschlüsselung und Authentifizierung / Autorisierung sowie Überwachung und Telemetrie vereinfacht werden. Insbesondere Istio wurde entwickelt, um ohne größere Änderungen am vorhandenen Service-Code zu funktionieren. Wenn Sie beispielsweise mit Kubernetes arbeiten, können Sie Anwendungen, die in Ihrem Cluster ausgeführt werden, Service-Mesh-Funktionen hinzufügen, indem Sie Istio-spezifische Objekte erstellen, die mit vorhandenen Anwendungsressourcen arbeiten.

In diesem Tutorial installieren Sie Istio mit dem Paketmanager Helm für Kubernetes. Anschließend verwenden Sie Istio, um eine Demoanwendung Node.js für externen Datenverkehr bereitzustellen, indem Sie Gateway erstellen und Virtual Service. Schließlich greifen Sie auf das Telemetrie-Addon Grafana zu, um die Verkehrsdaten Ihrer Anwendung zu visualisieren.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

Schritt 1 - Verpacken der Anwendung

Um unsere Demo-Anwendung mit Kubernetes zu verwenden, müssen wir den Code klonen und so verpacken, dass der https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ [+ kubelet + agent] kann das Bild ziehen.

Unser erster Schritt wird darin bestehen, das nodejs-image-demo-Repository aus der DigitalOcean Community GitHub zu klonen Konto. Dieses Repository enthält den Code aus dem Setup, der unter How To Build a Node.js Application beschrieben ist with Docker, in dem beschrieben wird, wie Sie ein Image für eine Node.js-Anwendung erstellen und einen Container mit diesem Image erstellen. Weitere Informationen zur Anwendung selbst finden Sie in der Reihe From Containers to Kubernetes with Node.js.

Klonen Sie zunächst das nodejs-image-demo-Repository in ein Verzeichnis mit dem Namen "++":

git clone https://github.com/do-community/nodejs-image-demo.git

Navigiere zum ++ Verzeichnis:

cd

Dieses Verzeichnis enthält Dateien und Ordner für eine Hai-Informationsanwendung, die Benutzern grundlegende Informationen zu Haien bietet. Zusätzlich zu den Anwendungsdateien enthält das Verzeichnis eine Docker-Datei mit Anweisungen zum Erstellen eines Docker-Images mit dem Anwendungscode. Weitere Informationen zu den Anweisungen in der Docker-Datei finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-build-a-node-js-application-with-docker#step-3-%E2% 80% 94-writing-the-dockerfile [Schritt 3 von So erstellen Sie eine Node.js-Anwendung mit Docker].

Um zu testen, ob der Anwendungscode und die Docker-Datei wie erwartet funktionieren, können Sie das Image mit dem Befehl https://docs.docker.com/engine/reference/commandline/build/[`docker build + `] erstellen und kennzeichnen Verwenden Sie das Bild, um einen Demo-Container auszuführen. Wenn Sie das Flag " -t " mit " Docker Build" verwenden, können Sie das Image mit Ihrem Docker Hub-Benutzernamen versehen, damit Sie es nach dem Testen an Docker Hub senden können.

Erstellen Sie das Image mit dem folgenden Befehl:

docker build -t / .

Das ". +" Im Befehl gibt an, dass der Erstellungskontext das aktuelle Verzeichnis ist. Wir haben das Bild "+" genannt, aber Sie können es auch anders benennen.

Sobald der Erstellungsprozess abgeschlossen ist, können Sie Ihre Bilder unter `+docker images + ` auflisten:

docker images

Sie werden die folgende Ausgabe sehen, die den Image-Build bestätigt:

OutputREPOSITORY                          TAG                 IMAGE ID            CREATED             SIZE
/   latest              37f1c2939dbf        5 seconds ago       77.6MB
node                                10-alpine           9dfa73010b19        2 days ago          75.3MB

Als nächstes erstellen Sie mit + docker run + einen Container, der auf diesem Bild basiert. Wir werden drei Flags in diesen Befehl aufnehmen:

  • + -p +: Hiermit wird der Port auf dem Container veröffentlicht und einem Port auf unserem Host zugeordnet. Wir werden den Port "+ 80 +" auf dem Host verwenden, aber Sie können dies nach Bedarf ändern, wenn auf diesem Port ein anderer Prozess ausgeführt wird. Weitere Informationen zur Funktionsweise finden Sie in dieser Diskussion in den Docker-Dokumenten unter port binding.

  • + -d +: Hiermit wird der Container im Hintergrund ausgeführt.

  • + - name +: Hiermit können wir dem Container einen benutzerdefinierten Namen geben.

Führen Sie den folgenden Befehl aus, um den Container zu erstellen:

docker run --name  -p 80:8080 -d /

Überprüfen Sie Ihre laufenden Container mit `+docker ps + `:

docker ps

Sie sehen die Ausgabe, die bestätigt, dass Ihr Anwendungscontainer ausgeführt wird:

OutputCONTAINER ID        IMAGE                               COMMAND                  CREATED             STATUS              PORTS                  NAMES
49a67bafc325        /   "docker-entrypoint.s…"   8 seconds ago       Up 6 seconds        0.0.0.0:80->8080/tcp

Sie können jetzt Ihre Server-IP besuchen, um Ihr Setup zu testen: + http: // +. Ihre Anwendung zeigt die folgende Zielseite an:

Nachdem Sie die Anwendung getestet haben, können Sie den laufenden Container stoppen. Verwenden Sie + docker ps + erneut, um Ihre + CONTAINER ID + zu erhalten:

docker ps
OutputCONTAINER ID        IMAGE                               COMMAND                  CREATED              STATUS              PORTS                  NAMES
49a67bafc325        /   "docker-entrypoint.s…"   About a minute ago   Up About a minute   0.0.0.0:80->8080/tcp

Stoppen Sie den Container mit https://docs.docker.com/engine/reference/commandline/stop/[`docker stop + `]. Stellen Sie sicher, dass Sie die hier aufgeführte " CONTAINER ID " durch Ihre eigene " CONTAINER ID +" ersetzen:

docker stop

Nachdem Sie das Image getestet haben, können Sie es an Docker Hub senden. Melden Sie sich zunächst bei dem Docker Hub-Konto an, das Sie unter den folgenden Voraussetzungen erstellt haben:

docker login -u

Wenn Sie dazu aufgefordert werden, geben Sie Ihr Docker Hub-Kontokennwort ein. Wenn Sie sich auf diese Weise anmelden, wird eine "+ ~ / .docker / config.json +" - Datei mit Ihren Docker Hub-Anmeldeinformationen im Stammverzeichnis Ihres Nicht-Root-Benutzers erstellt.

Senden Sie das Anwendungsimage mit dem Befehl https://docs.docker.com/engine/reference/commandline/push/[`docker push + `an Docker Hub. Denken Sie daran, "+" durch Ihren eigenen Docker Hub-Benutzernamen zu ersetzen:

docker push /

Sie haben jetzt ein Anwendungsimage, das Sie zum Ausführen Ihrer Anwendung mit Kubernetes und Istio herunterladen können. Als nächstes können Sie Istio mit Helm installieren.

Schritt 2 - Installieren von Istio mit Helm

Obwohl Istio verschiedene Installationsmethoden anbietet, wird in der Dokumentation die Verwendung von Helm empfohlen, um die Flexibilität bei der Verwaltung der Konfigurationsoptionen zu maximieren. Wir werden Istio mit Helm installieren und sicherstellen, dass das Grafana-Addon aktiviert ist, damit wir die Verkehrsdaten für unsere Anwendung visualisieren können.

Fügen Sie zunächst das Istio-Release-Repository hinzu:

helm repo add istio.io https://storage.googleapis.com/istio-release/releases/1.1.7/charts/

Auf diese Weise können Sie die Helm-Diagramme im Repository verwenden, um Istio zu installieren.

Überprüfen Sie, ob Sie das Repo haben:

helm repo list

Sie sollten das Repo + istio.io + sehen:

OutputNAME            URL
stable          https://kubernetes-charts.storage.googleapis.com
local           http://127.0.0.1:8879/charts
istio.io        https://storage.googleapis.com/istio-release/releases/1.1.7/charts/

Installieren Sie als Nächstes Istios Custom Resource Definitions (CRDs) mithilfe des https-Diagramms "+ istio-init " : //helm.sh/docs/helm/#helm-install [` helm install +` command]:

helm install --name istio-init --namespace istio-system istio.io/istio-init
OutputNAME:   istio-init
LAST DEPLOYED: Fri Jun  7 17:13:32 2019
NAMESPACE: istio-system
STATUS: DEPLOYED
...

Mit diesem Befehl werden 53 CRDs an den https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/ [+ kube-apiserver +] übergeben, um sie für die Verwendung im Istio-Netz verfügbar zu machen. Es erstellt auch eine namespace für die Istio-Objekte mit dem Namen + istio-system + und verwendet die Option + - name + um den Helm release zu benennen + istio-init +. Eine Version in Helm bezieht sich auf eine bestimmte Bereitstellung eines Diagramms mit bestimmten aktivierten Konfigurationsoptionen.

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob alle erforderlichen CRDs festgeschrieben wurden:

kubectl get crds | grep 'istio.io\|certmanager.k8s.io' | wc -l

Dies sollte die Nummer "+ 53 +" ausgeben.

Sie können jetzt die + istio + Tabelle installieren. Um sicherzustellen, dass das Grafana-Telemetrie-Addon mit der Karte installiert wird, verwenden wir die Konfigurationsoption "+ - set grafana.enabled = true " mit unserem Befehl " helm install +". Wir verwenden das Installationsprotokoll auch für unser gewünschtes configuration profile: das Standardprofil. Bei der Installation mit Helm kann Istio aus einer Reihe von Konfigurationsprofilen auswählen, mit denen Sie die Istio-Seitenwagen control plane und data plane anpassen können . Das Standardprofil wird für Produktionsbereitstellungen empfohlen. Wir werden es verwenden, um uns mit den Konfigurationsoptionen vertraut zu machen, die wir beim Übergang zur Produktion verwenden würden.

Führen Sie den folgenden Befehl + helm install aus, um das Diagramm zu installieren:

helm install --name istio --namespace istio-system --set grafana.enabled=true istio.io/istio
OutputNAME:   istio
LAST DEPLOYED: Fri Jun  7 17:18:33 2019
NAMESPACE: istio-system
STATUS: DEPLOYED
...

Wieder installieren wir unsere Istio-Objekte im Namensraum "+ istio-system " und benennen das Release - in diesem Fall " istio +".

Wir können überprüfen, ob die Service objects, die wir für das Standardprofil erwarten, mit dem folgenden Befehl erstellt wurden:

kubectl get svc -n istio-system

Die Dienstleistungen, die wir hier erwarten würden, umfassen: "+ istio-citadel ", " istio-galley ", " istio-ingressgateway ", " istio-pilot ", " istio-policy ", " istio-sidecar- Injektor, Istio-Telemetrie und Prometheus. Wir würden auch den + grafana + Service erwarten, da wir dieses Addon während der Installation aktiviert haben:

OutputNAME                     TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                                                                                                                                      AGE
grafana                  ClusterIP      10.245.85.162    <none>            3000/TCP                                                                                                                                     3m26s
istio-citadel            ClusterIP      10.245.135.45    <none>            8060/TCP,15014/TCP                                                                                                                           3m25s
istio-galley             ClusterIP      10.245.46.245    <none>            443/TCP,15014/TCP,9901/TCP                                                                                                                   3m26s
istio-ingressgateway     LoadBalancer   10.245.171.39    174.138.125.110   15020:30707/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30285/TCP,15030:31668/TCP,15031:32297/TCP,15032:30853/TCP,15443:30406/TCP   3m26s
istio-pilot              ClusterIP      10.245.56.97     <none>            15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                                       3m26s
istio-policy             ClusterIP      10.245.206.189   <none>            9091/TCP,15004/TCP,15014/TCP                                                                                                                 3m26s
istio-sidecar-injector   ClusterIP      10.245.223.99    <none>            443/TCP                                                                                                                                      3m25s
istio-telemetry          ClusterIP      10.245.5.215     <none>            9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                                       3m26s
prometheus               ClusterIP      10.245.100.132   <none>            9090/TCP                                                                                                                                     3m26s

Mit dem folgenden Befehl können wir auch prüfen, ob Istio Pods entspricht:

kubectl get pods -n istio-system

Die Pods, die diesen Diensten entsprechen, sollten den Status "+ STATUS" "+ Running" haben, was darauf hinweist, dass die Pods an Knoten gebunden sind und die mit den Pods verknüpften Container ausgeführt werden:

OutputNAME                                     READY   STATUS      RESTARTS   AGE
grafana-67c69bb567-t8qrg                 1/1     Running     0          4m25s
istio-citadel-fc966574d-v5rg5            1/1     Running     0          4m25s
istio-galley-cf776876f-5wc4x             1/1     Running     0          4m25s
istio-ingressgateway-7f497cc68b-c5w64    1/1     Running     0          4m25s
istio-init-crd-10-bxglc                  0/1     Completed   0          9m29s
istio-init-crd-11-dv5lz                  0/1     Completed   0          9m29s
istio-pilot-785694f946-m5wp2             2/2     Running     0          4m25s
istio-policy-79cff99c7c-q4z5x            2/2     Running     1          4m25s
istio-sidecar-injector-c8ddbb99c-czvwq   1/1     Running     0          4m24s
istio-telemetry-578b6f967c-zk56d         2/2     Running     1          4m25s
prometheus-d8d46c5b5-k5wmg               1/1     Running     0          4m25s

Das Feld "+ READY +" gibt an, wie viele Container in einem Pod ausgeführt werden. Weitere Informationen finden Sie in der documentation on Pod lifecycles.

Der letzte Schritt in der Istio-Installation wird die Erstellung von Envoy -Proxys ermöglichen, die als sidecars für Dienste bereitgestellt werden, die im Mesh ausgeführt werden.

Beiwagen werden in der Regel verwendet, um in vorhandenen Containerumgebungen eine zusätzliche Funktionsebene hinzuzufügen. Die mesh architecture von Istio basiert auf der Kommunikation zwischen Envoy-Seitenwagen, die die Datenebene des Netzes umfassen, und den Komponenten der Steuerebene. Damit das Netz funktioniert, müssen wir sicherstellen, dass auf jedem Pod im Netz auch ein Envoy-Beiwagen läuft.

Es gibt zwei Möglichkeiten, um dieses Ziel zu erreichen: manual sidecar injection und https://istio.io / docs / setup / kubernetes / additional-setup / beiwageneinspritzung / # automatische-beiwageneinspritzung [automatische beiwageneinspritzung]. Wir werden die automatische Seitenwageninjektion aktivieren, indem wir labeling den Namespace angeben, in dem wir unsere Anwendungsobjekte mit dem Label + istio- erstellen. Injektion = aktiviert + `. Dadurch wird sichergestellt, dass der MutatingAdmissionWebhook -Controller Anforderungen an den `+ kube-apiserver + abfangen und eine bestimmte Aktion ausführen kann - In diesem Fall müssen Sie sicherstellen, dass alle unsere Anwendungs-Pods mit einem Beiwagen beginnen.

Wir werden den "+ default " - Namespace verwenden, um unsere Anwendungsobjekte zu erstellen. Daher werden wir das Label " istio-injection = enabled +" mit dem folgenden Befehl auf diesen Namespace anwenden:

kubectl label namespace default istio-injection=enabled

Wir können überprüfen, ob der Befehl wie beabsichtigt funktioniert hat, indem wir Folgendes ausführen:

kubectl get namespace -L istio-injection

Sie werden die folgende Ausgabe sehen:

OutputAME              STATUS   AGE   ISTIO-INJECTION
default           Active   47m   enabled
istio-system      Active   16m
kube-node-lease   Active   47m
kube-public       Active   47m
kube-system       Active   47m

Wenn Istio installiert und konfiguriert ist, können wir mit der Erstellung unserer Objekte "Application Service" und "https://kubernetes.io/docs/concepts/workloads/controllers/deployment/[Deployment]" fortfahren.

Schritt 3 - Anwendungsobjekte erstellen

Wenn das Istio-Netz vorhanden und für das Injizieren von Sidecar-Pods konfiguriert ist, können wir eine Anwendung manifest mit specifications for erstellen unsere Service- und Deployment-Objekte. Spezifikationen in einem Kubernetes-Manifest beschreiben den gewünschten Zustand jedes Objekts.

Unser Anwendungsservice stellt sicher, dass die Pods, auf denen unsere Container ausgeführt werden, in einer dynamischen Umgebung weiterhin verfügbar sind, da einzelne Pods erstellt und zerstört werden. Unsere Bereitstellung beschreibt den gewünschten Status unserer Pods.

Öffnen Sie eine Datei mit dem Namen "+ node-app.yaml " mit " nano +" oder Ihrem bevorzugten Editor:

nano node-app.yaml

Fügen Sie zunächst den folgenden Code hinzu, um den Anwendungsdienst + nodejs + zu definieren:

~ / istio_project / node-app.yaml

apiVersion: v1
kind: Service
metadata:
 name: nodejs
 labels:
   app: nodejs
spec:
 selector:
   app: nodejs
 ports:
 - name: http
   port: 8080

Diese Service-Definition enthält einen "+ Selector ", der Pods mit der entsprechenden Bezeichnung " app: nodejs " übereinstimmt. Wir haben außerdem festgelegt, dass der Service den Port " 8080 +" auf jedem Pod mit der entsprechenden Bezeichnung ansteuert.

Wir nennen den Service-Port auch gemäß der https://istio.io/docs/setup/kubernetes/prepare/requirements/[requirements for Pods and Services von Istio. Der Wert "+ http " ist einer der Werte, die Istio für das Feld " name +" akzeptiert.

Fügen Sie als Nächstes unter dem Dienst die folgenden Spezifikationen für die Anwendungsbereitstellung hinzu. Achten Sie darauf, das in der Spezifikation "+ Container " angegebene " Image +" durch das Image zu ersetzen, das Sie erstellt und an Docker Hub unter https://www.digitalocean.com/community/tutorials/how-to-install-and- gesendet haben. use-istio # step-1-% E2% 80% 94-klonen-und-verpacken-der-anwendung [Step 1]:

~ / istio_project / node-app.yaml

...
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nodejs
 labels:
   version: v1
spec:
 replicas: 1
 selector:
   matchLabels:
     app: nodejs
 template:
   metadata:
     labels:
       app: nodejs
       version: v1
   spec:
     containers:
     - name: nodejs
       image: /
       ports:
       - containerPort: 8080

Die Spezifikationen für diese Bereitstellung umfassen die Anzahl von "+ Replikaten " (in diesem Fall 1) sowie einen " Selektor ", der definiert, welche Pods von der Bereitstellung verwaltet werden. In diesem Fall werden Pods mit dem Label " app: nodejs +" verwaltet.

Das Feld "+ template +" enthält Werte, die Folgendes bewirken:

  • Wenden Sie das Label "+ app: nodejs " auf die von der Bereitstellung verwalteten Pods an. Istio https://istio.io/docs/setup/kubernetes/prepare/requirements/[recommends] Hinzufügen des Labels " app +" zu den Bereitstellungsspezifikationen, um Kontextinformationen für Istios Metriken und Telemetrie bereitzustellen.

  • Wenden Sie ein "+ version " - Etikett an, um die Version der Anwendung anzugeben, die dieser Bereitstellung entspricht. Wie beim Label " app " empfiehlt Istio, das Label " version +" einzufügen, um kontextbezogene Informationen bereitzustellen.

  • Definieren Sie die Spezifikationen für die Container, die die Pods ausführen sollen, einschließlich des Containers "+ name " und des " image ". Das " Bild " hier ist das Bild, das Sie in https://www.digitalocean.com/community/tutorials/how-to-install-and-use-istio#step-1-%E2%80%94-cloning erstellt haben -und-Verpackung-der-Anwendung [Schritt 1] und an Docker Hub gesendet. Die Containerspezifikationen enthalten auch eine " containerPort " - Konfiguration, die auf den Port verweist, den jeder Container überwacht. Wenn Ports hier nicht aufgelistet sind, umgehen sie den Istio-Proxy. Beachten Sie, dass dieser Port " 8080 +" dem in der Service-Definition genannten Zielport entspricht.

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Mit dieser Datei können wir die Datei bearbeiten, die Definitionen für Gateway- und Virtual Service-Objekte enthält, die steuern, wie der Verkehr in das Netz gelangt und wie er dort weitergeleitet wird.

Schritt 4 - Erstellen von Istio-Objekten

Um den Zugriff auf einen Cluster und das Routing zu Diensten zu steuern, verwendet Kubernetes Ingress Resources und https://kubernetes.io/docs/concepts/services- Netzwerk / Ingress-Controller / [_ Controller_]. Ingress Resources definieren Regeln für das HTTP- und HTTPS-Routing zu Cluster Services, während Controller den eingehenden Datenverkehr ausgleichen und an die richtigen Services weiterleiten.

Weitere Informationen zur Verwendung von Ingress-Ressourcen und -Controllern finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes [Einrichten eines Nginx Ingress mit Cert-Manager auf DigitalOcean Kubernetes].

Istio verwendet eine andere Gruppe von Objekten, um ähnliche Ziele zu erreichen, allerdings mit einigen wichtigen Unterschieden. Anstatt einen Controller zum Lastausgleich zu verwenden, verwendet das Istio-Netz einen Gateway, der als Lastausgleichsfunktion für eingehende und ausgehende Daten fungiert HTTP / TCP-Verbindungen. Das Gateway ermöglicht dann die Anwendung von Überwachungs- und Routingregeln auf Datenverkehr, der in das Mesh eintritt. Insbesondere wird die Konfiguration, die das Verkehrsrouting bestimmt, als virtueller Dienst definiert. Jeder virtuelle Dienst enthält Routing-Regeln, die Kriterien für ein bestimmtes Protokoll und Ziel entsprechen.

Obwohl Kubernetes Ingress Resources / Controller und Istio Gateways / Virtual Services einige funktionale Ähnlichkeiten aufweisen, bringt die Struktur des Netzes wichtige Unterschiede mit sich. Kubernetes Ingress Resources und Controller bieten Betreibern beispielsweise einige Routing-Optionen. Gateways und Virtual Services stellen jedoch eine Reihe robusterer Funktionen zur Verfügung, da sie den Datenverkehr in das Netz einleiten. Mit anderen Worten, die eingeschränkten Funktionen von application layer, die Kubernetes Ingress Controllers und Resources Cluster-Betreibern zur Verfügung stellen, umfassen nicht die Funktionen - einschließlich erweitertem Routing und Tracing und Telemetrie - bereitgestellt von den Seitenwagen im Istio-Servicegitter.

Um externen Datenverkehr in unser Mesh zuzulassen und das Routing zu unserer Node-App zu konfigurieren, müssen Sie ein Istio-Gateway und einen virtuellen Service erstellen. Öffnen Sie eine Datei mit dem Namen "+ node-istio.yaml +" für das Manifest:

nano node-istio.yaml

Fügen Sie zunächst die Definition für das Gateway-Objekt hinzu:

~ / istio_project / node-isto.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: nodejs-gateway
spec:
 selector:
   istio: ingressgateway
 servers:
 - port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   - "*"

Zusätzlich zur Angabe eines "" - Namens für das Gateway im Feld " Metadaten" haben wir folgende Angaben gemacht:

  • Ein "+ Selector +", der dieser Ressource mit dem Standard-Istio IngressGateway-Controller entspricht, der mit dem von uns ausgewählten "https://istio.io/docs/setup/kubernetes/additional-setup/config-profiles/[configuration profile" aktiviert wurde Installation von Istio.

  • Eine "+ Server" -Spezifikation, die den "+ Port" angibt, der für den Eingang verfügbar gemacht werden soll, und die "+ Hosts", die vom Gateway verfügbar gemacht werden. In diesem Fall geben wir alle "+ hosts " mit einem Stern (" * +") an, da wir nicht mit einer bestimmten gesicherten Domain arbeiten.

Fügen Sie unterhalb der Gateway-Definition Spezifikationen für den virtuellen Service hinzu:

~ / istio_project / node-istio.yaml

...
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: nodejs
spec:
 hosts:
 - "*"
 gateways:
 - nodejs-gateway
 http:
 - route:
   - destination:
       host: nodejs

Zusätzlich zur Angabe eines "+ name +" für diesen virtuellen Service enthalten wir auch Spezifikationen für diese Ressource, die Folgendes umfassen:

  • Ein "+ hosts " - Feld, das den Zielhost angibt. In diesem Fall verwenden wir erneut einen Platzhalterwert (" * +"), um einen schnellen Zugriff auf die Anwendung im Browser zu ermöglichen, da wir nicht mit einer Domain arbeiten.

  • Ein Feld + gateways +, das das Gateway angibt, über das externe Anforderungen zugelassen werden. In diesem Fall ist es unser + nodejs-gateway + Gateway.

  • Das Feld "+ http +", das angibt, wie der HTTP-Verkehr weitergeleitet wird.

  • Ein "+ Ziel " - Feld, das angibt, wohin die Anfrage weitergeleitet wird. In diesem Fall wird es an den Dienst " nodejs " weitergeleitet, der implizit zum vollqualifizierten Domänennamen (FQDN) des Dienstes in einer Kubernetes-Umgebung erweitert wird: " nodejs.default.svc.cluster.local +". Beachten Sie jedoch, dass der vollqualifizierte Domänenname auf dem Namespace basiert, in dem die * Regel * definiert ist, nicht auf dem Dienst. Verwenden Sie den vollqualifizierten Domänennamen in diesem Feld, wenn sich der Anwendungsdienst und der virtuelle Dienst in unterschiedlichen Namespaces befinden. Weitere Informationen zum Kubernetes Domain Name System (DNS) finden Sie unter Einführung in den Kubernetes DNS-Dienst .

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Mit Ihren + yaml + -Dateien können Sie den Anwendungsdienst und die Bereitstellung sowie die Gateway- und Virtual Service-Objekte erstellen, die den Zugriff auf Ihre Anwendung ermöglichen.

Schritt 5 - Anwendungsressourcen erstellen und Telemetriezugriff aktivieren

Nachdem Sie Ihre Anwendungsdienst- und Bereitstellungsobjekte zusammen mit einem Gateway und einem virtuellen Dienst erstellt haben, können Sie einige Anforderungen an Ihre Anwendung generieren und die zugehörigen Daten in Ihren Istio Grafana-Dashboards anzeigen. Zunächst müssen Sie Istio jedoch so konfigurieren, dass das Grafana-Addon verfügbar gemacht wird, damit Sie in Ihrem Browser auf die Dashboards zugreifen können.

Wir werden enable Grafana access with HTTP, aber wenn Sie in der Produktion oder in sensiblen Umgebungen arbeiten, ist es Es wird dringend empfohlen, dass Sie enable access with HTTPS.

Weil wir bei der Installation von Istio unter https://www.digitalocean.com/community/tutorials/how-to-install-and-use-istio#step-2 die Konfigurationsoption + - set grafana.enabled = true + gesetzt haben -% E2% 80% 94-Installation-istio-with-helm [Schritt 2], wir haben einen Grafana Service und Pod in unserem + istio-system + Namespace, die wir in diesem Schritt bestätigt haben.

Wenn diese Ressourcen bereits vorhanden sind, besteht unser nächster Schritt darin, ein Manifest für ein Gateway und einen virtuellen Service zu erstellen, damit wir das Grafana-Addon verfügbar machen können.

Öffnen Sie die Datei für das Manifest:

nano node-grafana.yaml

Fügen Sie der Datei den folgenden Code hinzu, um ein Gateway und einen virtuellen Dienst zu erstellen, um den Datenverkehr für den Grafana-Dienst bereitzustellen und weiterzuleiten:

~ / istio_project / node-grafana.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: grafana-gateway
 namespace: istio-system
spec:
 selector:
   istio: ingressgateway
 servers:
 - port:
     number: 15031
     name: http-grafana
     protocol: HTTP
   hosts:
   - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: grafana-vs
 namespace: istio-system
spec:
 hosts:
 - "*"
 gateways:
 - grafana-gateway
 http:
 - match:
   - port: 15031
   route:
   - destination:
       host: grafana
       port:
         number: 3000

Unsere Grafana Gateway- und Virtual Service-Spezifikationen ähneln denen, die wir für unser Application Gateway und Virtual Service unter https://www.digitalocean.com/community/tutorials/how-to-install-and-use-istio#step-4 definiert haben -% E2% 80% 94 - Erstellen von Istio-Objekten [Schritt 4]. Es gibt jedoch einige Unterschiede:

  • Grafana wird auf dem "+ http-grafana " genannten Port (Port " 15031 ") verfügbar gemacht und läuft auf Port " 3000 +" auf dem Host.

  • Das Gateway und der Virtual Service sind beide im Namespace + istio-system + definiert.

  • Der "+ Host " in diesem virtuellen Dienst ist der " Grafana " - Dienst im " Istio-System +" - Namespace. Da wir diese Regel in demselben Namespace definieren, in dem der Grafana-Dienst ausgeführt wird, funktioniert die FQDN-Erweiterung wieder ohne Konflikte.

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Erstellen Sie Ihre Grafana-Ressourcen mit dem folgenden Befehl:

kubectl apply -f node-grafana.yaml

Mit dem Befehl +kubectl apply + ` können Sie eine bestimmte Konfiguration auf ein Objekt anwenden, das gerade erstellt oder aktualisiert wird es. In unserem Fall wenden wir die in der Datei `+ node-grafana.yaml +