Commit c76554bf authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Übung 04

parent 79b37805
......@@ -28,6 +28,7 @@ In diesem Lab werden Sie:
- [Ü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 04: Traffic Management mittels Virtuellen Services](#übung-04-traffic-management-mittels-virtuellen-services)
- [Übung 05: Shutdown](#übung-05-shutdown)
## Vorbereitung
......@@ -54,16 +55,62 @@ In diesem Lab werden Sie:
```
Sie können anschließend unter [http://localhost:8888](http://localhost:8888) auf die Yelb-Applikation zugreifen und sollten folgendes sehen:
![Yelb-Screenshot](yelb-ui.png)
- Versuchen Sie anschließend anhand der K8s-Manifest-Datei `deploy/yelb.yaml` vor dem geistigen Auge nachzuvollziehen, wie die Applikation wohl aufgebaut ist.
- Versuchen Sie anschließend anhand der K8s-Manifest-Datei `deploy/yelb.yaml` vor dem geistigen Auge nachzuvollziehen, wie die Applikation wohl aufgebaut ist - insbesondere wie die Komponenten der Applikation miteinander "verschaltet" sein mögen.
## Übung 02: Instrumentieren einer Applikation mittels eines Service Meshs [(istio)](https://istio.io)
- to be done
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.
- 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.
- 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)
- to be done
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.
- Zur Vorbereitung spielen Sie nun erst einmal ein paar Minuten mit Yelb herum. Voten Sie ein paar mal in ihrem Browser, reloaden Sie die Seite in ihrem Browser ein paar mal, um ein wenig Traffic in Ihr System zu bekommen.
- Öffen Sie in Lens nun ein zweites Terminal und leiten Sie den zentralen Kiali-Port auf Ihr lokales Entwicklungssystem weiter.
```bash
kubectl port-forward svc/kiali -n istio-system 20001:20001
```
- Sie können nun unter [http://localhost:20001](http://localhost:20001) auf das Kiali Dashboard zugreifen, dass Applikationen aller (instrumentierten) 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.
- 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.
Sie sehen, durch so eine Service-Mesh Instrumentierung erhalten Sie einen weitaus tieferen und interaktiveren Einblick in eine Applikationstopologie.
## Übung 04: Traffic Management mittels Virtuellen Services
- to be done
\ No newline at end of file
In dieser Übung "simulieren" wir abschließend einen typischen Fall der im laufenden Betrieb einer Cloud-native Applikation irgendwann auftreten wird. Eine Komponente (hier `yelb-appserver`) soll durch eine neuere Komponente ersetzt werden. Jedoch soll die neue Komponente noch nicht den "vollen" Traffic abbekommen und der Traffic soll schrittweise von der bisherigen auf die neue Komponente hochgefahren werden, um zu sehen, wie die neue Komponente mit der Last fertig wird.
Service Meshs lösen solche Probleme mittels Traffic Management.
- Vollziehen Sie bitte in `.gitlab-ci.yml` den `yelb-evolution` Job nach.
- Vollziehen Sie die K8s-Manifest-Datei `deploy/yelb-evolution.yaml` nach. Dieses Manifest ergänzt nur ein neues Deployment des Appservers (Version v2). Alle daraus abgeleiteten Pods werden wie bisher durch den `yelb-appserver` Service erfasst. Kubernetes würde somit mittels Round-Robin ca. 50% des Traffics auf die Version v1 und 50% auf die Version v2 routen.
- Vollziehen Sie nun die Istio-Manifest-Datei `deploy/yelb-istio-config.yaml` nach. Diese definiert für den `yelb-appserver`-Service eine Destination Rule und definiert damit eine Version v1 und v2 dieses Dienstes für Istio. Ferner wird ein Virtueller Istio Service definiert, der den Kubernetes Service "überlagert". In diesem Virtuellen Service können Istio Traffic-Management Regeln definiert werden. Danach soll 75% des Traffics auf die Version v1 und 25% auf die Version v2 des `yelb-appserver`s entfallen.
- Navigieren Sie in Ihrem Gitlab Repository auf `CI/CD -> Pipelines` und triggern Sie nun den manuellen `yelb-evolution` Job in der `evolution` Stage um diese beiden Manifeste anzuwenden und damit das Istio Traffic Management zu aktivieren. Hierzu einfach auf den Play-Button des Jobs klicken.
- Reloaden Sie nun in Ihrem Browser die Yelb-Applikation ein paar Mal (so ca. 20 mal). Notieren Sie sich dabei wie häufig die Seite von Appserver in V1 und in V2 ausgeliefert wird.
- Lassen Sie sich in Kiali nun den `Versioned App Graph zeigen` und lassen Sie sich in diesem an den Edge Labels die `Requests Percentage` anzeigen.
![Kiali Traffic Managemtent](kiali-traffic-mgmt-ui.png)
- Navigieren Sie in Kiali zu `Istio-Config -> yelb-appserver-vsvc` und ändern Sie die Werte 75% und 25% im YAML Editor auf 1 für V1 und 99 für V2. Klicken Sie anschließend auf SAVE.
- Reloaden Sie nun die Yelb-Seite in Ihrem Browser (ca. 20 mal).
- Vollziehen Sie den Effekt im Kiali Graph nach. Sie sehen, es werden Requests nun fast ausschließlich an die V2 geleitet.
Sie sehen, dass Sie mit einem Service Mesh den Traffic in Ihrer Topologie bequem über eine Oberfläche konfigurieren können.
## Übung 05: Shutdown
Um Ihren Namespace wieder "freizumachen" navigieren Sie in Gitlab bitte auf `CI/CD -> Pipelines` und triggeren Sie manuell den `shutdown` Job in der `teardown` Stage.
\ No newline at end of file
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