README.md

# Lab 08: Observability

Unter Observability versteht man einen systemübergreifenden Ansatz, der unterschiedliche Aspekte der Überwachung und Beobachtung des Verhaltens von (Cloud-nativer) Software im Betrieb berücksichtigt.

In diesem Lab nutzen wir hierzu als Service Mesh [Istio](https://istio.io) und als Anschauungsapplikation [Yelb](https://github.com/microservices-demo/microservices-demo) in einer für unsere Deployment-Zwecke minimal modifizierten Form.

Neben *Istio* gibt es zahlreiche weitere Service-Meshs (z.B. [Linkerd]([https://linkerd.io/), [OSM](https://openservicemesh.io), [Consul](https://consul.io), [Kong](https://konghq.com), uvm.). Die Wahl von *Istio* als Typvertreter erfolgte, weil *Istio* wesentliche Facetten eines Service Meshs (Traffic Management, Observability, Security) vollumfänglich abbildet und entsprechend häufig eingesetzt wird und somit das Potenzial zu einem "de-facto" Standard hat. Aus dieser Wahl kann jedoch keine Produktempfehlung abgeleitet werden. Insbesondere sei hier darauf hingewiesen, dass die Konsolidierung und Standardisierung von Service-Mesh-Technologien im Cloud-native Computing aktuell noch weit weniger fortgeschritten ist, als in anderen Bereichen (wie bspw. der Handhabung und Orchestrierung von Containern an sich). Perspektivisch ist es ferner durchaus vorstellbar, dass insbesondere "leichtgewichtige" Service-Mesh-Technologien wesentlich enger als bislang in Container-Orchestrierungsplattformen integriert werden und ggf. gar nicht mehr als eigenständige Komponente in Erscheinung treten.

*Yelb* ist ein nicht wirklich ernst gemeinter "Healthy food recommendation"-Dienst und dient nur der Demonstration von Service-Mesh-Technologien. *Yelb* wird häufig genutzt, um Microservice- und Cloud-native Technologien zu demonstrieren.

*Yelb* basiert auf den folgenden Komponenten:

- [NGINX](https://www.nginx.com) zum Ausliefern des webbasierten Front-Ends,
- einem REST-basierten App-Server ([Sinatra](http://sinatrarb.com)-based),
- einer [PostgreSQL](https://www.postgresql.org)-DB und
- [REDIS](https://redis.io) als In-Memory Cache.

Alle genannten Komponenten werden als öffentliche Container Images über Dockerhub bezogen. Mehr über die Architekur und Implementierung von *Yelb* finden Sie im [Yelb-Repository](https://github.com/mreferre/yelb).

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.
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
- [Lab 08: Observability](#lab-08-observability)
  - [Inhaltsverzeichnis](#inhaltsverzeichnis)
  - [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 04: Traffic Management mittels Virtuellen Services](#übung-04-traffic-management-mittels-virtuellen-services)
  - [Übung 05: Shutdown](#übung-05-shutdown)
  - [Links](#links)
  - [Was sollten Sie mitnehmen?](#was-sollten-sie-mitnehmen)

## Vorbereitung

1. [Forken](https://git.mylab.th-luebeck.de/cloud-native/lab-observability/-/forks/new) Sie sich bitte dieses [Repository](https://git.mylab.th-luebeck.de/cloud-native/lab-observability).
2. Setzen Sie bitte in **Gitlab** für das in Schritt 1 geforkte Repository die `KUBECONFIG` Variable in `Einstellungen -> CI/CD -> Variables` auf den Inhalt der Kubeconfig-Datei, die Sie für dieses Modul als Access Credential für den bereitgestellten Kubernetes Cluster erhalten haben (Type: `File`).
3. **Falls noch nicht geschehen:** Installieren Sie **[Lens](https://k8slens.dev)** und ergänzen Sie den bereitgestellten Cluster, den Sie in Schritt 2 auch für die Build-Pipeline eingerichtet haben.

## Übung 01: Deployen von Yelb

- Machen Sie sich bitte mit der Build-Pipeline dieses Projekts vertraut. Versuchen Sie die `.gitlab-ci.yml`-Datei nachzuvollziehen.
- Triggern Sie bitte einen Build dieser Build-Pipeline (bspw. mit einem Commit).
- Öffnen Sie unter `CI/CD -> Pipelines` die letzte gestartete Build-Pipeline. Diese sollte aus den Stages `deploy`, `inject` , `evolution` und `teardown` bestehen.
- In der `deploy` Stage sollte der Job `yelb` erfolgreich abgeschlossen worden sein und damit die *Yelb* Applikation in K8s erfolgreich deployed worden sein.
- Alle weiteren Jobs in den Folgestages sind noch nicht ausgeführt worden. Diese Jobs werden Sie in den folgenden Übungen starten.
- Öffnen Sie nun Lens, um Einblick in Ihr gerade getriggertes Deployment zu bekommen.  
  - Sie sollten unter `Workloads -> Deployments` vier Deployments sehen: `yelb-ui`, `yelb-db`, `yelb-appserver-v1` und `redis-server`.
  - Sie sollten unter `Network -> Services` vier gleichnamige Services sehen: `yelb-ui`, `yelb-db`, `yelb-appserver-v1` und `redis-server`
- Leiten Sie nun den Port des `yelb-ui` Service an Ihren lokalen Rechner weiter, indem Sie im Lens Terminal folgendes eingeben:
  ```bash
  kubectl port-forward svc/yelb-ui 8888:80
  ```
  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 - insbesondere wie die Komponenten der Applikation miteinander "verschaltet" sein mögen.

## Ü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.

- 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)

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

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 triggern Sie manuell den `shutdown` Job in der `teardown` Stage.

## Links

- [Service Mesh Definition](https://en.wikipedia.org/wiki/Service_mesh) *(Leider durchaus ausbaufähige Darstellung. Diese [Definition](https://www.nginx.com/blog/what-is-a-service-mesh) ist umfangreicher, allerdings nicht Hersteller-neutral.)*
- [Lens](https://k8slens.io)
- [Istio](https://istio.io) 
  - [Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/) + [Routing Features](https://istio.io/latest/docs/tasks/traffic-management/)
  - [Security](https://istio.io/latest/docs/concepts/security/) + [Security Features](https://istio.io/latest/docs/tasks/security/)
  - [Observability](https://istio.io/latest/docs/concepts/observability/) + [Telemetry Features](https://istio.io/latest/docs/tasks/observability/)
- [Kiali](https://kiali.io)
  
## Was sollten Sie mitnehmen?

- Cloud-native Anwendung werden häufig in zahlreiche einfache Microservices dekomponiert.
- Jeder einzelne dieser Microservices ist einfach zu entwickeln und zu durschauen.
- Die Komplexität einer Gesamtapplikation verschwindet jedoch nicht einfach, sondern verschiebt sich bei Cloud-nativen Applikationen in die Wechselwirkungen der zahlreichen Microservices untereinander. Hier den Überblick zu behalten kann schwer sein. Aus diesem Grund sind sogenannte Service Meshs entstanden.
- 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.
- 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.