Commit 001092db authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Übung 01: URL automatisiert setzen

parent e8b8c035
variables:
KUBECTL: "quay.io/bitnami/kubectl:1.18"
NAMESPACE: "nane-kratzke"
VERSION: "0.0.1"
URL: "prime-nk.loki.th-luebeck.dev"
URL: "$GITLAB_USER_NAME.loki.th-luebeck.dev"
PRIME: "yes"
CACHE: "no"
PERSISTENT_CACHE: "yes"
PERSISTENT_CACHE: "no"
TERMINATE: "no"
stages:
- prepare
- build
- deploy
- terminate
prepare:
stage: prepare
......@@ -32,6 +32,7 @@ claim-volume:
only:
variables:
- $PERSISTENT_CACHE == "yes"
- $TERMINATE != "yes"
image:
name: $KUBECTL
entrypoint: [""]
......@@ -45,8 +46,7 @@ build-prime:
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- cd prime
- docker build -t $CI_REGISTRY_IMAGE/prime:$VERSION -t $CI_REGISTRY_IMAGE/prime:latest .
- docker push $CI_REGISTRY_IMAGE/prime:$VERSION
- docker build -t $CI_REGISTRY_IMAGE/prime:latest .
- docker push $CI_REGISTRY_IMAGE/prime:latest
deploy-prime:
......@@ -54,11 +54,11 @@ deploy-prime:
only:
variables:
- $PRIME == "yes"
- $TERMINATE != "yes"
image:
name: $KUBECTL
entrypoint: [""]
script:
- echo "Deploying to Kubernetes"
- wget -q https://github.com/mikefarah/yq/releases/download/3.4.0/yq_linux_amd64 -O ./yq && chmod +x yq
- ./yq w -i deploy/prime/prime-ingress.yaml spec.rules[0].host $URL
- ./yq w -i deploy/prime/prime-ingress.yaml spec.tls[0].hosts[0] $URL
......@@ -70,6 +70,8 @@ deploy-cache:
only:
variables:
- $CACHE == "yes"
- $PERSISTENT_CACHE == "no"
- $TERMINATE != "yes"
image:
name: $KUBECTL
entrypoint: [""]
......@@ -82,7 +84,9 @@ deploy-persistent-cache:
stage: deploy
only:
variables:
- $CACHE == "yes"
- $PERSISTENT_CACHE == "yes"
- $TERMINATE != "yes"
image:
name: $KUBECTL
entrypoint: [""]
......@@ -91,4 +95,16 @@ deploy-persistent-cache:
- kubectl delete -f deploy/persistent-redis -n $NAMESPACE || true
- kubectl apply -f deploy/persistent-redis -n $NAMESPACE
terminate:
stage: terminate
only:
variables:
- $TERMINATE == "yes"
image:
name: $KUBECTL
entrypoint: [""]
script:
- kubectl delete -f deploy/redis -n $NAMESPACE || true
- kubectl delete -f deploy/redis-persistent -n $NAMESPACE || true
- kubectl delete -f deploy/prime -n $NAMESPACE || true
- kubectl delete -f deploy/storage -n $NAMESPACE || true
# Lab 06: Kubernetes
In diesem Lab lernen Sie, wie Sie containerisierte Workloads automatisiert mittels einer Deployment Pipeline in Kubernetes deployen und skalieren können.
In diesem Lab lernen Sie,
Sie erhalten ferner einen ersten Einblick in horizontale Skalierungstechniken und Self-Healing Fähigkeiten der Kubernetes-Plattform (z.B. durch Konzepte wie Deployment-Controller).
- wie Sie containerisierte Workloads automatisiert mittels einer Deployment Pipeline in Kubernetes deployen 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).
Im Rahmen dieses Labs entwickeln wir einen sehr einfachen Web-Dienst, der prüft, ob es sich bei einer gegebenen Zahl, um eine Primzahl handelt oder nicht. Dieser Service ist grundsätzlich wie folgt aus folgenden Kubernetes Konzepten aufgebaut.
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.
- Der Primzahl-Dienst kann über einen [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)-Controller von außen erreicht werden.
- Der Dienst wird Cluster-intern als [Service](https://kubernetes.io/docs/concepts/services-networking/service/) exponiert.
- Der Primzahl-Dienst wird Cluster-intern als [Service](https://kubernetes.io/docs/concepts/services-networking/service/) exponiert.
- Dieser Service fasst über ein [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) ausgebrachte Pods unter einer Netzwerkadresse zusammen. Über das Deployment kann die Primzahllast horizontal skaliert werden.
- Die Pods selber prüfen die Primzahlen. Zahlen, die in vorhergehenden Aufrufen bereits als Primzahlen verworfen wurden, können in einem In-Memory Key-Value Cache ([Redis](https://redis.io)) gespeichert werden, um wiederholte Prüfungen zu vermeiden und die Primzahlprüfung zu beschleunigen.
- Der Redis Cache wird als Deployment mit vorgelagertem Service ausgebracht, so dass die Primzahl-prüfenden Pods nur den Service Namen, nicht aber die IP-Adresse des Redis-Pods kennen müssen.
- Durch ein Persistent Volume Claim ([PVC](https://kubernetes.io/docs/concepts/storage/persistent-volumes)) kann dem Redis Pod ein Volume gemountet werden, und der Cache verliert auch über Redis Restarts nicht seinen Zustand.
- Der Redis Cache wird als Deployment mit vorgelagertem Service ausgebracht, so dass die Primzahl-prüfenden Pods nur den Service Namen, nicht aber die IP-Adresse des Redis-Pods kennen müssen (DNS-basiertes Service Discovery).
- Durch ein Persistent Volume Claim ([PVC](https://kubernetes.io/docs/concepts/storage/persistent-volumes)) kann der Redis Pod ein Volume mounten um den Cache Zustand zu persistieren. So kann der Cache auch über Redis Restarts seinen Zustand erhalten (Resilience, Isolated Persistency).
```
|----------------- Übung 01 -----------------|----------- Übung 02 ----------|
......@@ -26,7 +28,7 @@ Ingress --- Prime Service ---|- Prime Pod -|--- Redis Service --- Redis Pod
|- ... -| | |
| --------- | --------- |
\- Prime Pod -/ Redis PVC |
--------- --------- Übung 03
--------- --------- Übung 03
| |
--------- |
Volume |
......@@ -40,20 +42,62 @@ Ingress --- Prime Service ---|- Prime Pod -|--- Redis Service --- Redis Pod
- [Inhalt](#inhalt)
- [Vorbereitung](#vorbereitung)
- [Übung 01: Deployment eines Prime Service](#übung-01-deployment-eines-prime-service)
- [Übung 02: Ergänzung eines Stateless Caches](#übung-02-ergänzung-eines-stateless-caches)
- [Übung 03: Erweiterung zu einem Stateful Cache](#übung-03-erweiterung-zu-einem-stateful-cache)
- [Übung 02: Ergänzung eines In-Memory Caches](#übung-02-ergänzung-eines-in-memory-caches)
- [Übung 03: Erweiterung zu einem persistentem Cache](#übung-03-erweiterung-zu-einem-persistentem-cache)
- [Übung 04: Skalierung und Chaos Engineering](#übung-04-skalierung-und-chaos-engineering)
- [Übung 05: Deployment des Prime Service in GKE](#übung-05-deployment-des-prime-service-in-gke)
## Vorbereitung
[Forken](https://git.mylab.th-luebeck.de/cloud-native/lab-k8s/-/forks/new) Sie bitte dieses GitLab-Repository in Ihren GitLab-Namensraum.
- [Forken](https://git.mylab.th-luebeck.de/cloud-native/lab-k8s/-/forks/new) Sie bitte dieses GitLab-Repository in Ihren GitLab-Namensraum.
- Installieren Sie anschließend bitte lokal auf Ihrem Rechner die Kubernetes-IDE [Lens](https://k8slens.dev/).
- Laden Sie sich Ihre `kubeconfig` Datei im [Moodle-Kurs](https://lernraum.th-luebeck.de/course/view.php?id=3156) herunter.
- Starten Sie Lens und fügen Sie der IDE die kubeconfig Datei hinzu, um auf Ihren Cluster zugreifen zu können. Sie sollten dann Ihren Namespace in dem für Sie bereitgestellten K8S-Cluster sehen.
- Hinterlegen Sie in Ihrem geforkten GitLab-Repository nun die `kubeconfig`-Datei als CI-Environment-Variable mittels `Einstellungen -> CI/CI -> Variables (Aufklappen) -> ADD VARIABLE` (setzen Sie hierfür folgende Werte)
- Key: `KUBECONFIG` (Exakt so eingeben)
- Value: Inhalt der kubeconfig (z.B. mittels Copy-Paste aus Editor)
- Typ: `File` (Auswählen, WICHTIG!!!)
## Übung 01: Deployment eines Prime Service
## Übung 02: Ergänzung eines Stateless Caches
Im Verzeichen `prime` finden Sie den Python Source Code zu diesem Lab. Bitte sehen Sie sich diesen an und versuchen diesen zu verstehen.
## Übung 03: Erweiterung zu einem Stateful Cache
- Die Funktionen `lookup()` und `cache()` stellen die Verbindung zum Redis-Cache her. Steht kein Redis-Cache zur Verfügung, funktionieren die Funktionen dennoch, liefern dann aber natürlich keine Treffer aus dem Cache. Die Performance sinkt dadurch natürlich, der Service ist aber weiter nutzbar (Resilience).
- Mittels der Library [Flask](https://palletsprojects.com/p/flask/) wird eine Mini-REST-API aufgesetzt, die im wesentlichen nur eine URL registriert `/prime/<number>`. Über diese Route lässt sich prüfen, ob eine gegebene Zahl eine Primzahl ist (z.B. `/prime/1234`).
Studieren Sie nun bitte die Deployment-Pipeline in der `.gitlab-ci.yml`-Datei. Diese besteht aus vier Stages:
- `prepare`: Hier werden Vorbereitungen getroffen (z.B. werden die Registry Credentials hinterlegt oder Volumes per Persistent Volume Claim angefordert, falls ein persistenter Cache deployed werden soll).
- `build`: Hier wird der Prime Container gebaut und in die Registry gepushed.
- `deploy`: Hier werden die Kubernetes Ressourcen deployed (aktualisiert).
- `terminate`: Hier wird das Deployment terminiert (alle Ressourcen gelöscht, inkl. des Volumes!).
Insbesondere die `deploy` Stage kann über die folgenden vier Umgebungsvariablen gesteuert werden, die jeweils auf `yes` oder `no` gesetzt werden können:
```yaml
PRIME: "yes" # Prime Service soll ausgebracht werden
CACHE: "no" # Nicht persistenter Redis Cache soll ausgebracht werden
PERSISTENT_CACHE: "no" # Persistenter Redis Cache soll ausgebracht werden
TERMINATE: "no" # Das Deployment soll terminiert werden.
```
Sehen Sie sich nun die Manifeste in folgenden Verzeichnissen an und versuchen Sie diese bitte nachzuvollziehen:
- `deploy/prime`: Sie finden hier ein Deployment, um mehrere Prime Pods zu deployen (`prime-deployment.yaml`). Ferner eine Service Definition, um diese Pods unter einem DNS-Namen im Cluster ansprechen zu können (`prime-service.yaml`) und zu guter letzt eine Ingress Definition, die diesen Service Cluster-extern mittels HTTPS exponiert. Dieser Dreiklang `Deployment -> Service -> Ingress` ist ein recht typisches Pattern in Kubernetes.
- `deploy/storage`: Sie finden hier ein Persistent Volume Claim, mit dem ein Volume angefordert wird, welches von dem Pod des Redis Deployments gemountet werden kann (persistenter Cache).
- `deploy/redis`: Sie finden hier ein Manifest das sowohl ein Deployment eines Redis Containers und einem davor liegenden Service definiert. Anders als in `deploy/prime` definieren wir hier alles in einem Manifest (um zu zeigen, dass dies auch geht). Der Redis Dienst ist allerdings so definiert, dass kein Volume als persistente Speicherasset gemountet wird. Diese Variante vergisst als den Cache-Zustand bei einem Restart.
- `deploy/persistent-redis`: Diese Redis-Variante ist so definiert, dass das mittels `deploy/storage` angeforderte Volume als persistente Speicherasset vom Redis Pod gemountet wird. Diese Cacheing Variante vergisst also den Cache-Zustand bei einem Restart nicht!
**Schritte:**
Arbeiten Sie bitte mit der WebIDE von GitLab. Committen Sie dabei bitte immer in den Master-Branch!
1. Um die Basis-Version des Prime-Service auszubringen (kein Caching) setzen Sie bitte die `NAMESPACE` Variable in der `.gitlab-ci.yml`-Datei auf den Namespace, den Sie auch in Ihrer `kubeconfig` Datei finden (das ist normalerweise der vordere Teil Ihrer studentischen Email-Adresse, wobei alle Punkte . durch - ersetzt sind).
2. Committen Sie dann in den Master-Branch. Dies sollte die Deployment-Pipeline triggern. Sie können den Verlauf des Deployments sowohl in GitLab als auch die deployten Kubernetes Ressourcen in Lens ansehen (der Pipeline Lauf keine ein bis zwei Minuten dauern).
## Übung 02: Ergänzung eines In-Memory Caches
## Übung 03: Erweiterung zu einem persistentem Cache
## Übung 04: Skalierung und Chaos Engineering
......
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