Commit 233adc20 authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Finish

parent 366cfb46
......@@ -2,7 +2,7 @@ variables:
KUBECTL: "quay.io/bitnami/kubectl:1.18"
PRIME: "no"
CACHE: "no" # one of "no", "in-memory", "persistent"
TERMINATE: "yes"
TERMINATE: "no"
stages:
- prepare
......
# Lab 06: Kubernetes
# Lab 06: Orchestration
In diesem Lab lernen Sie,
- wie Sie containerisierte Workloads automatisiert mittels einer Deployment Pipeline in Kubernetes deployen und skalieren können.
- wie Sie containerisierte Workloads automatisiert mittels einer Deployment Pipeline in Kubernetes deployen, orchestrieren und skalieren können.
- Sie lernen auch komplexere Deployment-Pipelines kennen, die Dienste in unterschiedlichen Ausbaustufen automatisiert ausbringen können.
- Sie erhalten ferner einen ersten Einblick in horizontale Skalierungstechniken und Self-Healing Fähigkeiten der Kubernetes-Plattform (z.B. durch Konzepte wie Deployment-Controller).
Hierzu entwickeln wir im Rahmen dieses Labs einen sehr einfachen Web-Dienst, der prüft, ob es sich bei einer gegebenen Zahl, um eine Primzahl handelt oder nicht. Das Gesamt-Deployment nutzt dabei folgende Kubernetes-Konzepte.
Hierzu entwickeln wir im Rahmen dieses Labs als Anschauungsobjekt einen sehr einfachen Web-Dienst, der prüft, ob es sich bei einer gegebenen Zahl, um eine Primzahl handelt oder nicht. Das Gesamt-Deployment nutzt dabei folgende typische Kubernetes-Konzepte.
- Der Primzahl-Dienst kann über einen [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)-Controller von außen erreicht werden.
- Der Primzahl-Dienst wird Cluster-intern als [Service](https://kubernetes.io/docs/concepts/services-networking/service/) exponiert.
......@@ -38,7 +38,7 @@ Ingress --- Prime Service ---|- Prime Pod -|--- Redis Service --- Redis Pod
## Inhalt
- [Lab 06: Kubernetes](#lab-06-kubernetes)
- [Lab 06: Orchestration](#lab-06-orchestration)
- [Inhalt](#inhalt)
- [Vorbereitung](#vorbereitung)
- [Übung 01: Deployment eines Prime Service](#übung-01-deployment-eines-prime-service)
......@@ -138,6 +138,10 @@ Arbeiten Sie bitte mit der WebIDE von GitLab. Committen Sie dabei bitte immer in
Gratulation! Sie haben Ihren ersten lastausgleichenden Dienst in Kubernetes deployt und mittels Lens inspiziert.
**Verständnisfragen:**
- Erklären Sie bitte wie die gezeigten Konzepte zum Lastausgleich beitragen?
## Übung 02: Ergänzung eines In-Memory Caches
Unsere Pods bestimmen aktuell für jede Zahl, ob es sich dabei um eine Primzahl handelt oder nicht. Werden Zahl wiederholt geprüft, wäre es effizienter, sich dieses Ergebnis zu speichern. Pods sollten jedoch grundsätzlich stateless designed werden (d.h. sich nichts speichern), damit diese einfach horizontal skaliert werden können.
......@@ -167,6 +171,10 @@ Sehen Sie sich hierzu bitte das `deploy/redis` Verzeichnis an und versuchen Sie
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.
**Verständnisfragen:**
- Erklären Sie bitte wie der Zustand über die Pods "verteilt" wird (d.h. wie ein Pod dazu in der Lage ist, eine Antwort zu einer Zahl zu geben, die nie bei ihm berechnet wurde).
## Übung 03: Erweiterung zu einem persistentem Cache
In Übung 02 haben wir gesehen, dass wenn der Cache neu gestartet wird, wir viele Informationen verlieren und die Prime-Pods viele Zahlen neu durchrechnen müssen (und dabei den Cache neu aufbauen).
......@@ -186,6 +194,10 @@ Vergleich Sie hierzu bitte das `deploy/redis` mit dem `deploy/persistent-redis`
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).
**Verständnisfragen:**
- Erklären Sie bitte wieso im Deployment der Übung 03 (im Gegensatz zu Übung 02) der Zustand über den Restart des Redis Pods nicht vergessen wurde?
- Können Sie das Redis Deployment genauso hochskalieren wie das Prime-Deployment? Begründen Sie bitte und gehen dabei darauf ein, wie und ob der Zustand über mehrere Redis Pods mittels eines Volumes synchronisiert werden kann? Welche Probleme können auftreten?
## Übung 04: Skalierung und Chaos Engineering
**Skalieren:**
......@@ -214,6 +226,16 @@ Machen Sie sich ein wenig über [Chaos Engineering](https://en.wikipedia.org/wik
Dieses Verhalten nennen wir **resilient** (Störungen tolerierend, für Störung unanfällig).
**Verständnis- und Transferfragen:**
- Erklären Sie bitte was horizontale Skalierung ist und mit welchen Kubernetes-Konzepten diese realisiert werden kann?
- Erklären Sie bitte was Chaos Engineering ist und wie/warum man dieses einsetzen sollte?
- Welche Gegenargumente erwarten Sie, wenn Sie vorschlagen dieses Konzept in Produktivsystemen einzusetzen?
- Welche Argumente führen Sie für Chaos Engineering an?
- Erklären Sie bitte in eigenen Worten was Resilienz ist?
- Wieso trägt horizontale Skalierbarkeit zur Resilienz bei?
- Welche Kubernetes-Konzepte in diesem gezeigten Beispiel tragen wie zur Resilienz bei?
- Welche Schlüsse ziehen Sie für Ihre eigenen Cloud-nativen Systeme, die Sie zu entwickeln beabsichtigen?
## Übung 05: Terminieren Sie das Deployment
......
Supports Markdown
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