Commit db66cef1 authored by Willnow, Patrick's avatar Willnow, Patrick
Browse files

Update README.md

fix typo inspezieren -> inspizieren
parent 12d15645
Pipeline #41911 failed with stages
in 6 seconds
......@@ -23,7 +23,7 @@ In diesem Lab werden Sie:
1. Eine bestehende (nicht explizit für ein Service Mesh konzipierte) Cloud-native Applikation namens *Yelb* deployen.
2. Diese Anwendung nachträglich mit dem Service Mesh [Istio](https://istio.io) instrumentieren.
3. Die Anwendung im laufenden Betrieb mittels [Kiali](https://kiali.io) inspezieren.
3. Die Anwendung im laufenden Betrieb mittels [Kiali](https://kiali.io) inspizieren.
4. Und abschließend einen typischen Fall im laufenden Betrieb einer Cloud-native Applikation mittels Traffic Management lösen *(Ausbringung einer neuen Version einer Teilkomponente und nur einen Teil des Live-Traffics auf diese neue Version umleiten, z.B. um dessen Verhalten im Live-Betrieb besser einschätzen zu können)*.
## Inhaltsverzeichnis
......@@ -32,7 +32,7 @@ In diesem Lab werden Sie:
- [Vorbereitung](#vorbereitung)
- [Übung 01: Deployen von Yelb](#übung-01-deployen-von-yelb)
- [Übung 02: Instrumentieren einer Applikation mittels eines Service Meshs (Istio)](#übung-02-instrumentieren-einer-applikation-mittels-eines-service-meshs-istio)
- [Übung 03: Inspezieren einer Applikation mittels Service Meshs (Kiali)](#übung-03-inspezieren-einer-applikation-mittels-service-meshs-kiali)
- [Übung 03: Inspizieren einer Applikation mittels Service Meshs (Kiali)](#übung-03-inspizieren-einer-applikation-mittels-service-meshs-kiali)
- [Übung 04: Traffic Management mittels Virtuellen Services](#übung-04-traffic-management-mittels-virtuellen-services)
- [Übung 05: Shutdown](#übung-05-shutdown)
- [Verständnis- und Transferfragen](#verständnis-und-transferfragen)
......@@ -71,19 +71,19 @@ Führen Sie anschließend bitte folgende Schritte aus:
## Übung 02: Instrumentieren einer Applikation mittels eines Service Meshs [(Istio)](https://istio.io)
Im vorherigen Schritt haben Sie eine gewöhnliche Applikation in K8s deployed und können diese mit gewöhnlichen Mitteln (`kubectl`, Lens, K8s-Manifest-Dateien etc.) inspezieren. Dies ist jedoch recht umständlich, wie Sie vielleicht bemerkt haben. Wenn Sie sich in Übung 01 ein Bild von den Wechselwirkungen der Komponenten der Applikation zeichnen Sie es nun auf, bevor Sie die folgenden Schritte ausführen.
Im vorherigen Schritt haben Sie eine gewöhnliche Applikation in K8s deployed und können diese mit gewöhnlichen Mitteln (`kubectl`, Lens, K8s-Manifest-Dateien etc.) inspizieren. Dies ist jedoch recht umständlich, wie Sie vielleicht bemerkt haben. Wenn Sie sich in Übung 01 ein Bild von den Wechselwirkungen der Komponenten der Applikation zeichnen Sie es nun auf, bevor Sie die folgenden Schritte ausführen.
- Navigieren Sie in Ihrem Gitlab Repository auf `CI/CD -> Pipelines` und triggern Sie nun den manuellen `istio` Job in der `instrument` Stage. Hierzu einfach auf den Play-Button des Jobs klicken.
- Dieser Schritt labeled Ihren Namespace mittels `istio-injection=enabled` und führt ein komplettes Redeployment aus (vgl. `.gitlab-ci.yml`). Durch dieses Labeling wird das auf dem Cluster installierte Istio-System veranlasst alle Pods mit Istio-Proxies zu versehen und ins Service Mesh einzubinden. *(An der eigentlichen Applikation ändern wir rein gar nichts! Es wird tatsächlich nur der Namespace gelabelled um die Auto-Instrumentierung anzustoßen).*
- Warten Sie ein paar Sekunden bis das Redeployment und die Instrumentierung komplett abgeschlossen wurden.
- Inspezieren Sie dann in Lens unter `Workloads -> Pods` einen der neu angelegten Pods, z.B. den `yelb-ui`-Pod (welcher Pod ist letztlich egal, da alle identisch instrumentiert werden). Sie werden sehen, dass nun jedem Pod u.a. ein Istio-Proxy als ["Sidecar"](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) zur Seite gestellt wurde. Alle Kommunikation des ursprünglichen Yelb-Containers wird nun über diesen Proxy-Container geleitet. Das Service Mesh kann über diesen Proxy so den kompletten Netzwerkverkehr mit verfolgen.
- Inspizieren Sie dann in Lens unter `Workloads -> Pods` einen der neu angelegten Pods, z.B. den `yelb-ui`-Pod (welcher Pod ist letztlich egal, da alle identisch instrumentiert werden). Sie werden sehen, dass nun jedem Pod u.a. ein Istio-Proxy als ["Sidecar"](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) zur Seite gestellt wurde. Alle Kommunikation des ursprünglichen Yelb-Containers wird nun über diesen Proxy-Container geleitet. Das Service Mesh kann über diesen Proxy so den kompletten Netzwerkverkehr mit verfolgen.
- Benutzen Sie nun die Yelb-Applikation erneut im Browser. Terminieren Sie hierzu nun im Lens-Terminal das ursprüngliche Port-Forwarding aus Übung 01 mittels `CTRL-C`. Starten Sie das Port-Forwarding erneut mittels
```bash
kubectl port-forward svc/yelb-ui 8888:80
```
und rufen Sie die Applikation unter [http://localhost:8888](http://localhost:8888) auf. Sie werden sehen, die Applikation läuft wie bisher auch *(außer das Sie die Daten über das Redeployment verloren hat, da wir aus Gründen der Einfachheit keine Volumes angefordert hatten)*.
## Übung 03: Inspezieren einer Applikation mittels Service Meshs [(Kiali)](https://kiali.io)
## Übung 03: Inspizieren einer Applikation mittels Service Meshs [(Kiali)](https://kiali.io)
Nun, was hat uns diese Instrumentierung gebracht? Aus Blick eines Anwenders erst einmal gar nichts. Um die Wirkungsweise von Service Meshs zu demonstrieren, nutzen wir nun Kiali. Kiali ist eine Verwaltungskonsole für Istio-basierte Service-Meshs und ermöglicht eine besonders komfortable Form der Beobachtbarkeit. Es zeigt sowohl die Topologie als auch den Zustand eines Applikations-Netzes, indem es die Verkehrstopologie aus den Verkehrsströmen durch die Proxies ableitet.
......@@ -94,13 +94,13 @@ Nun, was hat uns diese Instrumentierung gebracht? Aus Blick eines Anwenders erst
```
- Sie können nun unter [http://localhost:20001](http://localhost:20001) auf das Kiali Dashboard zugreifen (User: `"admin"`, Password: `"admin"`), dass Applikationen aller Namespaces des Clusters visualisiert. *Für diesen Kurs ist das Dashboard tatsächlich so eingerichtet, dass Sie (lesenden) Einblick in alle Namespaces erhalten, zum einen um sich gegenseitig zu unterstützen, zum anderen um voneinander zu lernen.*
![Kiali Dashboard](kiali-ui.png)
- Klicken Sie nun auf Ihren Namespace und inspezieren die Yelb-Applikation, die Sie gerade deployed haben.
- Klicken Sie nun auf Ihren Namespace und inspizieren die Yelb-Applikation, die Sie gerade deployed haben.
- Navigieren Sie in Kiali zu `Graph -> Versioned App Graph` und Sie sollten Sie einen Live-View Ihres Applikationsnetzes sehen folgendes sehen. (Wenn Sie nichts sehen, interagieren Sie mit der Applikation ein wenig in Ihrem Browser, Voten und Reloaden Sie ein paar Mal um alle Teile des Netzes zu "aktivieren").
![Kiali Graph](kiali-graph-ui.png)
Vergleichen Sie diese Darstellung gerne einmal mit Ihrer im Kopf gebildeten und selbst gezeichneten Topologie am Anfang dieser Übung. Stimmen diese Topologien überein? Wo gibt es Unterschiede?
- Spielen Sie nun noch ein wenig mit der Kiali-Oberfläche herum.
- Klicken Sie bspw. einmal mit der rechten Maustaste auf das `v1` Deployment der `yelb-appserver`-App und sehen Sie sich die Log-Dateien an.
- Klicken Sie einmal doppelt auf den `yelb-appserver`, um nur einen Teil des Netzes zu inspezieren.
- Klicken Sie einmal doppelt auf den `yelb-appserver`, um nur einen Teil des Netzes zu inspizieren.
Sie sehen, durch so eine Service-Mesh Instrumentierung erhalten Sie einen weitaus tieferen und interaktiveren Einblick in eine Applikationstopologie.
......@@ -153,6 +153,6 @@ Um Ihren Namespace wieder "freizumachen" navigieren Sie in Gitlab bitte auf `CI/
- Service Meshs (wie bspw. Istio) können dazu genutzt werden, um bestehende Applikationen hinsichtlich einer besseren Observability zu instrumentieren.
- Dazu werden im wesentlichen Service Mesh-spezifische Proxy-Container neben Applikations-Container in Pods injeziert. Grundsätzlich muss die Applikation dazu nicht angepasst werden.
- Service Meshs leiten dabei Traffic durch Service Proxies und können so Zustand als auch Topologie aus dem "mitgeschnittenen" Netzwerkverkehr zwischen den Komponenten ableiten und darstellen.
- Dashboards wie Kiali eigenen sich dazu anhand einer gut verständlichen Topologie Cloud-native Applikationen zu inspezieren.
- Dashboards wie Kiali eigenen sich dazu anhand einer gut verständlichen Topologie Cloud-native Applikationen zu inspizieren.
- Darüber hinaus können Service Meshs durch ergänzende Service Mesh-spezifische Konzepte wie bspw. Destination Rules oder Virtuelle Services dazu eingesetzt werden, um Traffic in einer Applikation zu managen (z.B. im Rahmen neuer Version-Releases von Teilkomponenten).
- Es gibt eine Vielzahl von (teilweise Kubernetes-spezifischen) Service-Mesh-Technologien ([Linkerd]([https://linkerd.io/), [Istio](http://istio.io), [OSM](https://openservicemesh.io), [Consul](https://consul.io), [Kong](https://konghq.com), uvm.). Die Konsolidierung und Standardisierung ist hier noch nicht so weit fortgeschritten, wie in anderen Bereichen des Cloud-native Computings.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment