README.md 16.3 KB
Newer Older
Nane Kratzke's avatar
Minor    
Nane Kratzke committed
1
# Lab 08: Observability
Nane Kratzke's avatar
Nane Kratzke committed
2

Nane Kratzke's avatar
Nane Kratzke committed
3
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.
4

Nane Kratzke's avatar
Nane Kratzke committed
5
6
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.

Nane Kratzke's avatar
Minor    
Nane Kratzke committed
7
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.
Nane Kratzke's avatar
Nane Kratzke committed
8
9

*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.
10

Nane Kratzke's avatar
Nane Kratzke committed
11
*Yelb* basiert auf den folgenden Komponenten:
Nane Kratzke's avatar
Nane Kratzke committed
12
13
14
15
16
17

- [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.

Nane Kratzke's avatar
Nane Kratzke committed
18
19
20
21
22
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.
Nane Kratzke's avatar
Nane Kratzke committed
23
2. Diese Anwendung nachträglich mit dem Service Mesh [Istio](https://istio.io) instrumentieren.
Nane Kratzke's avatar
Nane Kratzke committed
24
25
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)*.
Nane Kratzke's avatar
Nane Kratzke committed
26
27

## Inhaltsverzeichnis
Nane Kratzke's avatar
Minor    
Nane Kratzke committed
28
- [Lab 08: Observability](#lab-08-observability)
Nane Kratzke's avatar
Nane Kratzke committed
29
30
31
  - [Inhaltsverzeichnis](#inhaltsverzeichnis)
  - [Vorbereitung](#vorbereitung)
  - [Übung 01: Deployen von Yelb](#übung-01-deployen-von-yelb)
Nane Kratzke's avatar
Nane Kratzke committed
32
  - [Übung 02: Instrumentieren einer Applikation mittels eines Service Meshs (Istio)](#übung-02-instrumentieren-einer-applikation-mittels-eines-service-meshs-istio)
Nane Kratzke's avatar
Nane Kratzke committed
33
  - [Übung 03: Inspezieren einer Applikation mittels Service Meshs (Kiali)](#übung-03-inspezieren-einer-applikation-mittels-service-meshs-kiali)
Nane Kratzke's avatar
Nane Kratzke committed
34
  - [Übung 04: Traffic Management mittels Virtuellen Services](#übung-04-traffic-management-mittels-virtuellen-services)
Nane Kratzke's avatar
Nane Kratzke committed
35
  - [Übung 05: Shutdown](#übung-05-shutdown)
Nane Kratzke's avatar
Nane Kratzke committed
36
37
  - [Links](#links)
  - [Was sollten Sie mitnehmen?](#was-sollten-sie-mitnehmen)
Nane Kratzke's avatar
Nane Kratzke committed
38
39
40

## Vorbereitung

Nane Kratzke's avatar
Nane Kratzke committed
41
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).
Nane Kratzke's avatar
Nane Kratzke committed
42
43
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.
Nane Kratzke's avatar
Nane Kratzke committed
44
45
46

## Übung 01: Deployen von Yelb

Nane Kratzke's avatar
Nane Kratzke committed
47
48
49
50
51
52
53
54
55
56
57
58
59
60
- 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)
Nane Kratzke's avatar
Nane Kratzke committed
61
- 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.
Nane Kratzke's avatar
Nane Kratzke committed
62

Nane Kratzke's avatar
Nane Kratzke committed
63
## Übung 02: Instrumentieren einer Applikation mittels eines Service Meshs [(Istio)](https://istio.io)
Nane Kratzke's avatar
Nane Kratzke committed
64

Nane Kratzke's avatar
Nane Kratzke committed
65
66
67
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.
Nane Kratzke's avatar
Nane Kratzke committed
68
- 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).*
Nane Kratzke's avatar
Nane Kratzke committed
69
70
71
72
73
74
75
- 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)*.
Nane Kratzke's avatar
Nane Kratzke committed
76

Nane Kratzke's avatar
Nane Kratzke committed
77
## Übung 03: Inspezieren einer Applikation mittels Service Meshs [(Kiali)](https://kiali.io)
Nane Kratzke's avatar
Nane Kratzke committed
78

Nane Kratzke's avatar
Nane Kratzke committed
79
80
81
82
83
84
85
86
87
88
89
90
91
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?
Nane Kratzke's avatar
Nane Kratzke committed
92
- Spielen Sie nun noch ein wenig mit der Kiali-Oberfläche herum.
Nane Kratzke's avatar
Nane Kratzke committed
93
94
95
96
  - 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.
Nane Kratzke's avatar
Nane Kratzke committed
97
98
99

## Übung 04: Traffic Management mittels Virtuellen Services

Nane Kratzke's avatar
Nane Kratzke committed
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
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

Nane Kratzke's avatar
Update    
Nane Kratzke committed
119
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.
Nane Kratzke's avatar
Nane Kratzke committed
120
121
122

## Links

Nane Kratzke's avatar
Update    
Nane Kratzke committed
123
- [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.)*
Nane Kratzke's avatar
Nane Kratzke committed
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
- [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.