Commit 311cad1f authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Finish

parent fe7ce7b0
variables:
KUBECTL: "quay.io/bitnami/kubectl:1.18"
PRIME: "yes"
CACHE: "in-memory" # one of "no", "in-memory", "persistent"
TERMINATE: "no"
PRIME: "no"
CACHE: "no" # one of "no", "in-memory", "persistent"
TERMINATE: "yes"
stages:
- prepare
......
......@@ -43,8 +43,8 @@ Ingress --- Prime Service ---|- Prime Pod -|--- Redis Service --- Redis Pod
- [Vorbereitung](#vorbereitung)
- [Übung 01: Deployment eines Prime Service](#übung-01-deployment-eines-prime-service)
- [Übung 02: Ergänzung eines In-Memory Caches](#übung-02-ergänzung-eines-in-memory-caches)
- [Übung 04: Skalierung und Chaos Engineering](#übung-04-skalierung-und-chaos-engineering)
- [Übung 05: Terminieren Sie das Deployment](#übung-05-terminieren-sie-das-deployment)
- [Übung 06: Deployment des Prime Service in GKE](#übung-06-deployment-des-prime-service-in-gke)
- [Links](#links)
- [Was sollten Sie mitnehmen?](#was-sollten-sie-mitnehmen)
......@@ -146,6 +146,8 @@ Man kann dies machen, in dem man Zustände in statefull Komponenten isoliert (un
Wir schalten daher nun zu unserem Prime-Service einen In-Memory Redis Cache dazu (siehe Einleitung oben). Dieser Cache ist (erst einmal) ebenso stateless, speichert sich Primzahleigenschaften zu Zahlen also nicht dauerhaft, aber isoliert von den Primzahleigenschaft-prüfenden Pods. Ein Pod fragt also erst den Cache ab (geht schnell). Falls der Cache nicht antwortet, beantwortet der Pod die Anfrage selber, andernfalls liefert er das Cache-Ergebnis zurück.
Sehen Sie sich hierzu bitte das `deploy/redis` Verzeichnis an und versuchen Sie das Redis Deployment nachzuvollziehen.
1. Setzen Sie in `.gitlab-ci.yml` die Umgebungsvariablen wie folgt:
```yaml
PRIME: "yes"
......@@ -153,12 +155,17 @@ Wir schalten daher nun zu unserem Prime-Service einen In-Memory Redis Cache dazu
TERMINATE: "no"
```
2. Committen Sie in den Master-Branch. Und warten Sie bis die Pipeline erfolgreich beendet wurde.
3. Rufen Sie nun den Dienst in ihrem Browser auf [https://prime-XYZ.loki.th-luebeck.dev/prime/12345](https://prime-XYZ.loki.th-luebeck.dev/prime/12345) (ersetzen Sie XYZ dabei durch die Ihre User-ID in GitLab, siehe Übung 01).
3. Rufen Sie nun den Dienst in ihrem Browser auf [https://prime-XYZ.loki.th-luebeck.dev/prime/12345](https://prime-XYZ.loki.th-luebeck.dev/prime/12345) (ersetzen Sie XYZ dabei durch Ihre User-ID in GitLab, siehe Übung 01).
```text
12345 is not a prime number. It can be divided by 3 (answer from prime-deployment-b667868f6-b2krp; processed)
```
Laden Sie die Seite mehrmals erneut. Sie werden feststellen, dass die Antwort jedesmal von einem anderen Pod beantwortet wird. Die Requests werden Round-Robin über alle Prime-Pods verteilt.
Ab dem zweiten Aufruf sehen Sie aber `via cache`. Die Pods finden bereits berechnete Zahlen also im externen Cache und müssen diese nicht selber errechnen.
Laden Sie die Seite mehrmals erneut. Sie werden feststellen, dass die Antwort jedesmal von einem anderen Pod beantwortet wird. Die Requests werden weiterhin Round-Robin über alle Prime-Pods verteilt.
Ab dem zweiten Aufruf sehen Sie aber `via cache` in der Antwort.
```
12345 is not a prime number. It can be divided by 3 (answer from prime-deployment-6ddc76c9b5-vk6ln via cache)
```
Die Pods finden also bereits berechnete Zahlen im externen Cache und müssen diese nicht selber errechnen (egal welcher Pod diese Zahl im Vorfeld errechnet hat).
1. Starten Sie nun den Cache neu, in dem Sie in Lens mittels `Workload -> Pods` den Redis-Pod selektieren und mittels `Remove` löschen. Sie sehen, der Pod wird neu gestartet. Fragen Sie nun bitte erneut per Browser den Service ab. Sie werden nun sehen, dass die erste Abfrage wieder `processed` ist (der Cachezustand also durch den Restart vergessen wurde) und erst der zweite Aufruf wieder `via cache` beantwortet wird.
## Übung 03: Erweiterung zu einem persistentem Cache
......@@ -166,6 +173,19 @@ In Übung 02 haben wir gesehen, dass wenn der Cache neu gestartet wird, wir viel
Besser wäre es, wenn wir den Cache über Pod-Restarts behalten können. Dies kann man in Kubernetes mittels Volumes machen. Volumes ermöglichen es, einen Zustand (auf einer Festplatte) unabhängig von einem flüchtigen Pod zu speichern.
Vergleich Sie hierzu bitte das `deploy/redis` mit dem `deploy/persistent-redis` Verzeichnis an und versuchen Sie das persistente Redis Deployment nachzuvollziehen. Ergänzend sollten Sie sich auch das `redis/storage` Verzeichnis ansehen. Beides wird durch die folgenden Schritte aktiviert.
1. Setzen Sie in `.gitlab-ci.yml` die Umgebungsvariablen wie folgt:
```yaml
PRIME: "yes"
CACHE: "persistent"
TERMINATE: "no"
```
2. Committen Sie in den Master-Branch. Und warten Sie bis die Pipeline erfolgreich beendet wurde.
3. Starten Sie Lens und öffnen Sie `Storage -> Persistent Volume Claims`. Sie sollten nun ein PVC sehen, welches vom Redis Pod als externer Speicher gemountet wurde.
4. Laden Sie analog zu Übung 03 mit Ihrem Browser mehrmals diesselbe Zahl. Sie werden sehen, dass die Antwort immer aus dem Cache geliefert wird.
5. Löschen Sie nun den Redis Pod (analog zu Übung 03) und laden Sie nun erneut diesselbe Zahl. Sie werden sehen, dass die Antwort sofort aus dem Cache geliefert wird (der Redis Pod seinen aufgebauten Zustand also über den Restart nicht verloren hat).
## Übung 04: Skalierung und Chaos Engineering
**Skalieren:**
......@@ -205,10 +225,6 @@ Dieses Verhalten nennen wir **resilient** (Störungen tolerierend, für Störung
```
das alle Ressourcen sauber gelöscht wurden. Das Terminieren kann ggf. etwas dauern.
## Übung 06: Deployment des Prime Service in GKE
In diesem Schritt passen wir das in den Übungen 1 bis 3 entwickelte Deployment so an, dass es in [GKE](https://cloud.google.com/kubernetes-engine) (Google Kubernetes Engine, also einem Public Cloud Service Provider) automatisiert ausgebracht werden kann. Dies soll Ihnen zeigen, dass Kubernetes grundsätzlich eine recht standardisierte Plattform ist, die sowohl Self-Hosted in einer Private Cloud als Plain-Vanilla Kubernetes oder als Managed-Service in einer Public Cloud nutzbar ist. Tatsächlich bieten mittlerweile fast alle großen Public Cloud Service Provider Kubernetes-basierte Dienste an. Kubernetes hat es so eine Art de-facto Standard etabliert und die ehemals sehr heterogene PaaS Landschaft bis zu einem gewissen Grad vereinheitlicht.
## Links
- [Lens](https://k8slens.io)
......
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