![\"\"](\"https:\/\/www.sysbus.eu\/wp-content\/uploads\/2026\/07\/Dashboard-1-1024x409.png\")
Da wird \u00fcber keinen Test-Kubernetes-Cluster verf\u00fcgen, richten wir uns zun\u00e4chst eine Testumgebung mit Hilfe von Minikube ein. Minikube erm\u00f6glicht es, einen lokalen Kubernetes-Cluster auf dem eigenen Endpoint zu betreiben. Das Tool eignet sich hervorragend f\u00fcr Schulungen, Tests und Entwicklungsarbeiten.<\/p>\n\n\n\n
Nach der Installation von Minikube werden wir zun\u00e4chst einmal einen nginx-Webserver mit helm in Kubernetes als Pod zum Laufen bringen, Ingress und DNS so konfigurieren, dass man auf diesen Webserver zugreifen kann, die \u00dcberwachungsfunktionen des Systems nutzen, um den Ressourcenverbrauch zu analysieren und eine WordPress-Installation mit einer Datenbank mit Hilfe von helm vornehmen. Danach skalieren wir die Zahl der Pods automatisch nach Last mit Hilfe des Kubernetes Autoscalers und erzeugen ein eigenes helm chart.<\/p>\n\n\n\n Noch kurz zum Verst\u00e4ndnis: Pods sind logische Hosts, auf ihnen laufen einer oder mehrere Container, sie haben eine externe IP-Adresse, sie sind \u00fcber Namen und Namespace identifizierbar und sie teilen Storage-Ressourcen. Die interne Kommunikation findet via IPC (Inter Process Communication) statt. Pods sind kurzlebig und werden \u00fcber Controller gehandhabt.<\/p>\n\n\n\n Minikube installieren<\/strong><\/p>\n\n\n\n Als Testsystem kommt ein Ubuntu 26.04 zum Einsatz. Dieses sollte mindestens 2 CPUs und 4 GByte RAM mitbringen. Eine der Grundvoraussetzungen f\u00fcr den Betrieb von Minikube ist eine vorhandene Docker -Umgebung zum Betreiben von Kubernetes. Deswegen bringen wir erstmal das installierte Linux auf den aktuellen Stand und installieren danach curl, Minikube und Docker.<\/p>\n\n\n\n sudo apt install curl<\/em><\/p>\n\n\n\n curl -LO <\/em>https:\/\/storage.googleapis.com\/minikube\/releases\/latest\/minikube-linux-amd64<\/em><\/a><\/em><\/p>\n\n\n\n sudo install minikube-linux-amd64 \/usr\/local\/bin\/minikube<\/em><\/p>\n\n\n\n sudo snap install kubectl \u2013-classic<\/em><\/p>\n\n\n\n sudo apt install docker.io<\/em><\/p>\n\n\n\n sudo systemctl enable \u2013now docker<\/em><\/p>\n\n\n\n sudo apt install docker-compose<\/em><\/p>\n\n\n\n sudo usermod -aG docker $USER && newgrp docker<\/em><\/p>\n\n\n\n Jetzt k\u00f6nnen wir Minikube starten:<\/p>\n\n\n\n minikube start \u2013-driver=docker<\/em><\/p>\n\n\n\n Nachdem Minikubes Startvorgang abgeschlossen wurde, l\u00e4sst sich der Status des Clusters abfragen:<\/p>\n\n\n\n minikube status<\/em><\/p>\n\n\n\n Die Ausgabe sollte so aussehen:<\/p>\n\n\n\n minikube<\/em><\/p>\n\n\n\n type: Control Plane<\/em><\/p>\n\n\n\n host: Running<\/em><\/p>\n\n\n\n kubelet: Running<\/em><\/p>\n\n\n\n apiserver: Running<\/em><\/p>\n\n\n\n kubeconfig: Configured<\/em><\/p>\n\n\n\n Mit dem Befehl:<\/p>\n\n\n\n kubectl get nodes<\/em><\/p>\n\n\n\n bringen wir in Erfahrung, dass unser Node \u201eReady\u201c ist. Jetzt kann es daran gehen, helm zu installieren, ein Repo hinzuzuf\u00fcgen und letzteres auf den aktuellen Stand zu bringen:<\/p>\n\n\n\n sudo snap install helm –classic<\/em><\/p>\n\n\n\n helm repo add bitnami <\/em>https:\/\/charts.bitnami.com\/bitnami<\/em><\/a><\/em><\/p>\n\n\n\n helm repo update<\/em><\/p>\n\n\n\n Jetzt kann es daran gehen, ein chart im Minikube-Cluster zu installieren. F\u00fcr diesen Test nehmen wir \u201enginx\u201c:<\/p>\n\n\n\n helm install my-release bitnami\/nginx<\/em><\/p>\n\n\n\n Der Status der Pods l\u00e4sst sich immer mit<\/p>\n\n\n\n kubectl get pods<\/em><\/p>\n\n\n\n \u00fcberpr\u00fcfen. Hier sollte jetzt etwas wie das Folgende erscheinen:<\/p>\n\n\n\n NAME READY STATUS RESTARTS AGE<\/em><\/p>\n\n\n\n my-release-594c4c58bf-vdhnm 1\/1 Running 1 (13d ago) 13d<\/em><\/p>\n\n\n\n Weitere wichtige Befehle:<\/p>\n\n\n\n helm list<\/em><\/p>\n\n\n\n zeigt alle installierten Apps und<\/p>\n\n\n\n helm search repo nginx<\/em><\/p>\n\n\n\n zeigt die in den Repositories verf\u00fcgbaren Versionen der Apps.<\/p>\n\n\n\n helm status my-release<\/em><\/p>\n\n\n\n pr\u00e4sentiert die Dokumentation des chart-Erstellers und<\/p>\n\n\n\n helm get values my-release<\/em><\/p>\n\n\n\n zeigt die beim Installieren gesetzten Einstellungen. Entfernen l\u00e4sst ich das chart \u00fcber<\/p>\n\n\n\n helm uninstall my-release<\/em><\/p>\n\n\n\n Das Aktualisieren der Software<\/strong><\/p>\n\n\n\n Um Minikube und Kubernetes im laufenden Betrieb zu aktualisieren sind diverse Schritte erforderlich. Zun\u00e4chst einmal ist Minikube selbst auf den aktuellen Stand zu bringen:<\/p>\n\n\n\n curl -LO https:\/\/storage.googleapis.com\/minikube\/releases\/latest\/minikube-latest.x86_64.rpm<\/em><\/p>\n\n\n\n sudo install minikube-linux-amd64 \/usr\/local\/bin\/minikube<\/em><\/p>\n\n\n\n Die einfachste Option, Kubernetes zu aktualisieren ist eine Neuerstellung des Clusters:<\/p>\n\n\n\n minikube delete<\/em><\/p>\n\n\n\n minikube start \u2013-driver=docker \u2013-kubernetes-version=latest<\/em><\/p>\n\n\n\n kubectl und helm werden \u00fcber snap aktualisiert:<\/p>\n\n\n\n sudo snap refresh helm<\/em><\/p>\n\n\n\n sudo snap refresh kubectl<\/em><\/p>\n\n\n\n Weitere wichtige Befehle f\u00fcr Minikube sind<\/p>\n\n\n\n minikube pause<\/em><\/p>\n\n\n\n Das friert den Cluster ein. Wieder in Betrieb nehmen l\u00e4sst er sich mit<\/p>\n\n\n\n minikube unpause<\/em><\/p>\n\n\n\n Ausschalten l\u00e4sst sich das System mit<\/p>\n\n\n\n minikube stop<\/em><\/p>\n\n\n\n helm in der Praxis<\/strong><\/p>\n\n\n\n Nachdem wir jetzt alles installiert und auf den aktuellen Stand gebracht haben, k\u00f6nnen wir einen neuen Cluster erzeugen und mit der eigentlichen Arbeit beginnen:<\/p>\n\n\n\n minikube delete<\/em><\/p>\n\n\n\n minikube start \u2013-driver=docker<\/em><\/p>\n\n\n\n Jetzt installieren wir erst einmal ein neues nginx-pod. Wir nennen es \u201emy-nginx\u201c und setzen den Service-Typ auf \u201eLoadBalancer\u201c. Letzteres muss angegeben werden, damit die Webseite sp\u00e4ter \u00fcber das Netz erreichbar ist:<\/p>\n\n\n\n helm install my-nginx bitnami\/nginx –set service.type=LoadBalancer<\/em><\/p>\n\n\n\n Kubernetes l\u00e4dt jetzt das Image und startet den Container. Der aktuelle Status l\u00e4sst sich wieder mit<\/p>\n\n\n\n kubectl get pods<\/em><\/p>\n\n\n\n \u00fcberpr\u00fcfen. Sobald unter \u201cSTATUS\u201d Running steht, ist nginx bereit.<\/p>\n\n\n\n Um nun auf den Webserver zuzugreifen, kann entweder ein Tunnel oder ein weitergeleiteter Port zum Einsatz kommen. F\u00fcr den Tunnel m\u00fcsste der Befehl<\/p>\n\n\n\n minikube tunnel<\/em><\/p>\n\n\n\n in einem zus\u00e4tzlichen Terminalfenster ausgef\u00fchrt werden. Das Port-Forwarding wird \u00fcber<\/p>\n\n\n\n kubectl port-forward svc\/my-nginx 8080:80<\/em><\/p>\n\n\n\n aktiviert. Danach ist der Server \u00fcber die URL http:\/\/localhost:8080<\/a> erreichbar.<\/p>\n\n\n\n Einer der gro\u00dfen Vorteile von helm ist, dass sich Anwendungen \u00e4ndern lassen, ohne sie zu l\u00f6schen. Wenn wir beispielsweise die Anzahl der Instanzen von nginx erh\u00f6hen m\u00f6chten, um Hochverf\u00fcgbarkeit zu simulieren, reicht ein<\/p>\n\n\n\n helm upgrade my-nginx bitnami\/nginx –set replicaCount=3<\/em><\/p>\n\n\n\n Jetzt kann man mit<\/p>\n\n\n\n kubectl get pods<\/em><\/p>\n\n\n\n ansehen, wie das System zwei weitere Instanzen hochf\u00e4hrt. L\u00f6scht man Instanzen w\u00e4hrend des Betriebs durch<\/p>\n\n\n\n kubectl delete pod {Instanzname}<\/em><\/p>\n\n\n\n so startet das System gleich wieder neue, um die Zahl der definierten Instanzen wieder zu erreichen.<\/p>\n\n\n\n Den Ressourcenverbrauch analysieren<\/strong><\/p>\n\n\n\n Um herauszufinden, wieviel CPU und RAM der nginx verbraucht, m\u00fcssen wir das metrics-server-Addon aktivieren:<\/p>\n\n\n\n minikube addons enable metrics-server<\/em><\/p>\n\n\n\n Jetzt zeigt<\/p>\n\n\n\n kubectl top pods<\/em><\/p>\n\n\n\n den Ressourcenverbrauch an.<\/p>\n\n\n\n Ingress und DNS konfigurieren<\/strong><\/p>\n\n\n\n Momentan greifen wir per localhost auf den Web-Server zu. Sinnvoller ist es, den nginx \u00fcber die Dom\u00e4ne http:\/\/mein-nginx.local<\/a> erreichbar zu machen. Dazu installieren wir einen Ingress-Controller, der als zentraler Einstiegspunkt den Traffic annimmt, konfigurieren eine Ingress-Ressource und passen die hosts-Datei so an, dass der Browser die Dom\u00e4ne findet. Letzteres lie\u00dfe sich auch \u00fcber eine DNS-Konfiguration realisieren, da das Anpassen von DNS-Servern aber nicht der Fokus dieses Playbooks ist, w\u00e4hlen wir die hosts-Datei. Los geht es mit<\/p>\n\n\n\n minikube addons enable ingress<\/em><\/p>\n\n\n\n Jetzt pr\u00fcfen wir, ob der Controller-Pod hochgefahren ist:<\/p>\n\n\n\n kubectl get pods -n ingress-nginx<\/em><\/p>\n\n\n\n Sobald der Controller-Pod auf \u201erunning\u201c steht, k\u00f6nnen wir die Ingress-Ressource erstellen. Dazu verwenden wir eine yaml-Datei, in der steht \u201eAlles was mit dem Hostnamen \u201amein-nginx.local\u2018 ankommt, soll auf Port 80 des Service \u201amy-nginx\u2018 weitergeleitet werden. Wir nennen die Datei \u201eingress.yaml\u201c und sie sieht folgenderma\u00dfen aus:<\/p>\n\n\n\n apiVersion: networking.k8s.io\/v1<\/em><\/p>\n\n\n\n kind: Ingress<\/em><\/p>\n\n\n\n metadata:<\/em><\/p>\n\n\n\n name: nginx-ingress<\/em><\/p>\n\n\n\n annotations:<\/em><\/p>\n\n\n\n nginx.ingress.kubernetes.io\/rewrite-target: \/<\/em><\/p>\n\n\n\n spec:<\/em><\/p>\n\n\n\n rules:<\/em><\/p>\n\n\n\n – host: mein-nginx.local<\/em><\/p>\n\n\n\n http:<\/em><\/p>\n\n\n\n paths:<\/em><\/p>\n\n\n\n – path: \/<\/em><\/p>\n\n\n\n pathType: Prefix<\/em><\/p>\n\n\n\n backend:<\/em><\/p>\n\n\n\n service:<\/em><\/p>\n\n\n\n name: my-nginx<\/em><\/p>\n\n\n\n port:<\/em><\/p>\n\n\n\n number: 80<\/em><\/p>\n\n\n\n Anwenden l\u00e4sst sich die Datei nun mit<\/p>\n\n\n\n kubectl apply -f ingress.yaml<\/em><\/p>\n\n\n\n Jetzt finden wir die IP-Adresse des Minikube-Knotens heraus:<\/p>\n\n\n\n minikube ip<\/em><\/p>\n\n\n\n Diese wird nun in die \/etc\/hosts-Datei eingetragen:<\/p>\n\n\n\n {IP-Adresse} mein-nginx.local<\/em><\/p>\n\n\n\n Jetzt l\u00e4sst sich der Webserver \u00fcber die URL http:\/\/mein-nginx.local<\/a> im Browser \u00f6ffnen.<\/p>\n\n\n\n Wenn wir einen zweiten Dienst \u00fcber die gleiche IP-Adresse anbieten wollen, m\u00fcssen wir nun lediglich diesen zweiten Dienst (eine andere Webseite oder ein anderer Server wie Apache) in Kubernetes starten, in der ingress.yaml eine zweite Regel hinzuf\u00fcgen, beispielsweise f\u00fcr die URL \u201emeine-app.local\u201c und die URL der zweiten App mit der gleichen Minikube-IP-Adresse in die hosts-Datei eintragen.<\/p>\n\n\n\n Dashboard und Monitoring<\/strong><\/p>\n\n\n\n Um die Monitoring-Funktionen zu aktivieren, m\u00fcssen (falls nicht schon geschehen) folgende addons aktiviert werden:<\/p>\n\n\n\n minikube addons enable dashboard<\/em><\/p>\n\n\n\n minikube addons enable metrics-server<\/em><\/p>\n\n\n\n Dann \u00f6ffnet Minikube eine Kubernetes-Dashboard-Seite, die die vorhandenen Workloads\/Pods, Services und ConfigMaps anzeigt. Klickt der Anwender auf einen Pod-Eintrag, lassen sich die Live-Logs \u00fcber das kleine Linien-Symbol oben anzeigen.<\/p>\n\n\n\n Unter Services sollten jetzt der nginx-Dienst und der Ingress-Controller erscheinen. Die ConfigMaps erm\u00f6glichen es, die Konfigurationsdaten von Container-Images zu trennen, also beispielsweise unter nginx eine andere Index.html anzuzeigen als die Default-Webseite. W\u00e4hrend ConfigMaps unkritische Daten enthalten, existieren f\u00fcr sensible Daten die so genannten Secrets, die \u00e4hnlich funktionieren aber auf sichere Art und Weise Passw\u00f6rter, Tokens und Keys bereitstellen k\u00f6nnen.<\/p>\n\n\n\n Das Dashboard zeigt uns an, dass es praktisch keine Last auf dem nginx-Server gibt. Jetzt werden wir Last erzeugen, um das Echtzeit-Monitoring unter die Lupe zu nehmen. Dazu nutzen wir den Befehl \u201eab\u201c (Apache Benchmark). Dieser l\u00e4sst sich folgenderma\u00dfen installieren:<\/p>\n\n\n\n sudo apt install apache2-utils<\/em><\/p>\n\n\n\n Nun k\u00f6nnen wir 50.000 Anfragen mit 100 gleichzeitigen Verbindungen schicken:<\/p>\n\n\n\n ab -n 50000 -c 100 <\/em>http:\/\/mein-nginx.local\/<\/em><\/a><\/p>\n\n\n\n Jetzt steigt die CPU-Auslastung des nginx-Pods sprunghaft an, was im Dashboard klar zu sehen ist.<\/p>\n\n\n\n Installation von WordPress mit Datenbank als zweite Instanz parallel zu nginx<\/strong><\/p>\n\n\n\n Zun\u00e4chst installieren wir WordPress mit MariaDB und einem eigenen Namen sowie einer Ingress-Anbindung. Au\u00dferdem setzen wir ein Passwort, damit wir uns einloggen k\u00f6nnen:<\/p>\n\n\n\n helm install mein-blog bitnami\/wordpress \\<\/em><\/p>\n\n\n\n <\/em>–set wordpressUsername=admin \\<\/em><\/p>\n\n\n\n –set wordpressPassword=geheim \\<\/em><\/p>\n\n\n\n –set mariadb.auth.rootPassword=geheim-db \\<\/em><\/p>\n\n\n\n –set service.type=ClusterIP \\<\/em><\/p>\n\n\n\n –set ingress.enabled=true \\<\/em><\/p>\n\n\n\n –set ingress.hostname=mein-blog.local \\<\/em><\/p>\n\n\n\n –set ingress.annotations.“kubernetes\\.io\/ingress\\.class“=nginx<\/em><\/p>\n\n\n\n Wenn wir jetzt mit<\/p>\n\n\n\n kubectl get pods<\/em><\/p>\n\n\n\n nachsehen, so beobachten wir, wie das WordPress-Pod und das MariaDB-Pod erstellt werden. Dazu kommen zwei Persistent Volumes, eines f\u00fcr die Datenbank und eines f\u00fcr WordPress. Letztere verhindern, dass Blog-Posts verloren gehen, wenn die Maschine neu startet. Im n\u00e4chsten Schritt tragen wie die URL \u201emein-blog.local\u201c mit der Minikube-IP in die hosts-Datei ein. Dazu schreiben wir sie einfach in die gleiche Zeile hinter die nginx-Domain.<\/p>\n\n\n\n Im Dashboard kann man nun unter \u201ePods\u201c die Interaktionen zwischen WordPress und MariaDB sehen und unter Persistent Volume Claims (PVC) findet sich der reservierte Speicherbereich. Das Blog selbst l\u00e4sst sich \u00fcber http:\/\/mein-blog.local<\/a> aufrufen und nutzen. Wird ein Blogpost erstellt und das Pod gel\u00f6scht, so startet Kubernetes sofort ein neues Pod und die Daten des Blogposts gehen nicht verloren. Auf diese Weise lassen sich mehrere Anwendungen sauber getrennt und hochverf\u00fcgbar auf einer Hardware ausf\u00fchren.<\/p>\n\n\n\n Das Autoscaling<\/strong><\/p>\n\n\n\n Wenden wir uns jetzt dem Autoscaling zu. Wir m\u00f6chten dabei erreichen, dass standardm\u00e4\u00dfig in unserem Cluster 2 nginx-Pods laufen. Steigt die Last, so sollen weitere Pods (bis maximal 5) hinzukommen. Sinkt die Last wieder, so sollen die zus\u00e4tzlichen Pods automatisch abgebaut werden. Dazu verwenden wir den Horizontal Pod Autoscaler (HPA) von Kubernetes. Diese beh\u00e4lt die CPU- und Speicherlast im Blick und schaltet dynamisch Instanzen dazu oder weg.<\/p>\n\n\n\n Damit Kubernetes erkennen kann, wann ein Pod ausgelastet ist, m\u00fcssen wir festlegen, wieviel CPU es verbrauchen darf. Deswegen aktualisieren wir die nginx-Instanz mit helm und geben ihr neue Limits mit. Gleichzeitig setzen wir die Zahl der standardm\u00e4\u00dfig aktiven Instanzen auf 2:<\/p>\n\n\n\n helm upgrade my-nginx bitnami\/nginx \\<\/em><\/p>\n\n\n\n –reuse-values \\<\/em><\/p>\n\n\n\n –set replicaCount=2 \\<\/em><\/p>\n\n\n\n –set resources.requests.cpu=100m \\<\/em><\/p>\n\n\n\n –set resources.limits.cpu=200m<\/em><\/p>\n\n\n\n 100m steht hier f\u00fcr 100 Millicores, also 10 % eines CPU-Kerns. Jetzt folgt die Regel, die besagt \u201eWenn die Pods im Schnitt mehr als 50 % ihrer angeforderten CPU verbrauchen, skaliere hoch bis auf maximal 5\u201c:<\/p>\n\n\n\n kubectl autoscale deployment my-nginx –cpu-percent=50 –min=2 –max=5<\/em><\/p>\n\n\n\n Mit<\/p>\n\n\n\n![\"\"](\"https:\/\/www.sysbus.eu\/wp-content\/uploads\/2026\/07\/pods-1024x417.png\")
![\"\"](\"https:\/\/www.sysbus.eu\/wp-content\/uploads\/2026\/07\/Workloads-1024x410.png\")