Commit 0cb45991 authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Alle Übungen ausgearbeitet

parent c76554bf
# Lab 08 Observability
Unter Observability versteht man einen systemübergreifenden Ansatz, der unterschiedliche Faktoren für die Überwachung und Beobachtung des Verhaltens von (Cloud-nativer) Software im Betrieb berücksichtigt.
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 Anschauungsgegenstand [Yelb](https://github.com/microservices-demo/microservices-demo) in einer für unsere Deployment-Zwecke minimal modifizierten Form. Yelb ist ein nicht wirklich ernst gemeinter "Healthy food recommendation"-Dienst und wird gerne genutzt, um Microservice- und Cloud-native Technologien zu demonstrieren.
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 des Typvertreters *Istio* fand statt, 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. Dennoch sei darauf hingewiesen, dass die Konsolidierung und Standardisierung von Service-Mesh-Technologien im Cloud-native Computing 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:
......@@ -16,7 +20,7 @@ Alle genannten Komponenten werden als öffentliche Container Images über Docker
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] instrumentieren.
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)*.
......@@ -25,19 +29,18 @@ In diesem Lab werden Sie:
- [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 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.
4. Installieren Sie **[istio](https://istio.io)** auf Ihrem lokalen System gem. diesen [Anweisungen](https://istio.io/latest/docs/setup/getting-started/#download). ***Hinweis:** Sie müssen istio nicht auf dem Kubernetes-Cluster installieren, der Cluster ist bereits entsprechend konfiguriert. Sie sollten auf Ihrem lokalen System allerdings `istioctl` im Terminal nutzen können.*
5. Installieren Sie **[Python 3](https://www.python.org/downloads)** (falls noch nicht geschehen).
6. Installieren Sie einen **HTTP Load Generator** wie bspw. **[salvo](https://github.com/tarekziade/salvo)** mittels `pip install salvo` oder `python3 -m install salvo` (je nachdem wie Ihre Python-Umgebung aufgesetzt ist). *Sie können auch mit anderen HTTP Load Generatoren arbeiten. Diese Anleitung basiert jedoch auf `salvo`.*
## Übung 01: Deployen von Yelb
......@@ -57,12 +60,12 @@ In diesem Lab werden Sie:
![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)
## Ü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).*
- 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
......@@ -86,7 +89,7 @@ Nun, was hat uns diese Instrumentierung gebracht? Aus Blick eines Anwenders erst
- 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.
- 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.
......@@ -113,4 +116,26 @@ Service Meshs lösen solche Probleme mittels Traffic Management.
## Ü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
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.
## Links
- [Service Mesh Defintion](https://en.wikipedia.org/wiki/Service_mesh)
- [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.
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