| **Hostbeschreibung** | **Hostname** | **IP-Adresse** |
| Master Node | srv-kub-master | 192.168.10.200 |
| Worker Node | srv-kub-worker1 | 192.168.10.201 |
Wenn alles geklappt hat, sollte eine Meldung auftauchen, das dass **Control-Plane** erfolgreich initialisiert wurde. Wenn dies der Fall ist, sehen wir auch die entsprechenden Befehle damit die anderen **Worker Nodes** als **Worker** oder als **Master** beitreten können. Diese Befehle können wir bei Bedarf auch neu erstellen. Für das erste die Befehle zur Seite kopieren.
Wir müssen im Anschluss noch einmal die Befehle ausführen, die benötigt werden, damit mit dem Control-Plane kommuniziert werden kann. ```bash mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` Um zu testen, ob der Cluster richtig hochgefahren wurde, können wir die folgenden Befehle ausführen. ```bash kubectl get nodes kubectl cluster-info ``` Jetzt können wir auf den Worker Nodes die Befehle ausführen, um dem Kubernetes Cluster beizutreten. Wenn die Nodes beigetreten sind, sollten diese mit dem Befehl `kubectl get nodes` ersichtlich sein. Damit die Nodes im Status hochgefahren werden, brauchen wir sogenannte Netzwerk Add-ons. Wir verwenden hier Calico. Um Calico zu installieren, führen wir den folgenden Befehl aus: ```bash kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml ``` Um zu überprüfen, ob die Calico Pods laufen, führen wir den folgenden Befehl aus: ```bash kubectl get pods -n kube-system ``` ##### Kubernetes Cluster testen Um das Kubernetes Cluster zu testen, führen wir den folgenden Befehl auf dem Master Node aus: ```bash kubectl create deployment nginx-app --image=nginx --replicas 2 kubectl expose deployment nginx-app --name=nginx-web-svc --type NodePort --port 80 kubectl describe svc nginx-web-svc ``` Jetzt sollten wir, wenn alles geklappt hat, eine Ausgabe mit dem entsprechenden Port erhalten. Das heißt, wenn wir eine Webanfrage auf die externe IP mit dem angegebenen Port starten, sollte uns die "NGINX Welcome Page" begrüßen. Mit dem folgenden Befehl können wir das gestartete Deployment wieder stoppen und löschen: ```bash kubectl delete deployment nginx-app ``` # Installation von MetallLB (Lokaler LoadBalancer) #### Einleitung In dieser kurzen Anleitung beschreibe ich kurz, wie wir mit der Hilfe von MetalLB einen lokalen LoadBalancer betreiben können. In der Regel verwendet man einen LoadBalancer innerhalb eines Cloud-Providers und dieser stellt dann einen kostenpflichten LoadBalancer zur Verfügung. Sobald wir aber im LAN einen solchen LoadBalancer über die Service-Konfiguration anfordern, sollte die Anfrage auf `"pending"` stehen bleiben und keine IP erhalten. Mit diesem LoadBalancer sind die internen Anwendungen dann erreichbar über eine dedizierte IP-Adresse. #### Durchführung Im ersten Schritt führen wir den folgenden Befehl auf unserem Kubernetes Master Node aus: ```bash kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml ``` Damit wird dann die Konfiguration für den LoadBalancer Pod heruntergeladen und gestartet. Um zu überprüfen, ob die Pods erfolgreich gestartet wurden, können wir den folgenden Befehl ausführen: ```bash kubectl get pods --namespace metallb-system ``` Wenn hier bei allen Containern der Status auf `Running` steht, sollten die Pods ordnungsgemäß hochgefahren sein. Wir müssen dann im Anschluss eine neue YAML-Datei anlegen, in dem wir den IPv4-Bereich definieren, welcher vom LoadBalancer verwendet werden darf. Die Datei sieht folgendermaßen aus: ```yaml apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name:**Info:** Es muss hier noch die IP-Adresse oder DNS-Name des Master-Nodes und der Cluster-Token eingetragen werden.
Sobald das Skript durchgelaufen ist, sollte der Node dem Cluster beigetreten sein. Dies können wir überprüfen, indem wir auf dem Master wieder den `kubectl get nodes` ausführen. Wenn hier der Worker Node auftaucht, hat alles wie gewünscht geklappt. Diese Schritte führen wir dann für weitere Worker Nodes aus. So können wir unser Cluster nach Belieben erweitern. # Traefik-Reverseproxy vom K3s-Cluster entfernen #### Einleitung In diesem Artikel geht es kurz darum, wie wir in unserem K3s Cluster den Traefik-Reverseproxy entfernen können, welcher standardgemäß immer mitinstalliert wird. #### Durchführung Um Traefik zu entfernen, müssen wir die service-Datei des K3s-Dienstes anpassen. Dazu verbinden wir uns auf unseren Master-Node und öffnen die folgende Datei: ```bash nano /etc/systemd/system/k3s.service ``` Dort fügen wir unter `ExecStart` noch `--disable=traefik` ein. Das sollte dann wie folgt aussehen: ```bash ExecStart=/usr/local/bin/k3s \ server \ --disable=traefik \ ``` Im Anschluss erstellen wir noch eine andere Datei mit dem folgenden Befehl: ```bash touch /var/lib/rancher/k3s/server/manifests/traefik.yaml.skip ``` Zum Schluss starten wir jetzt einmal alle Server neu. Dann sollte der Traefik-Pod nicht mehr gestartet werden. # Metrics-Server vom K3s-Cluster entfernen #### Einleitung In diesem Artikel geht es kurz darum, wie wir in unserem K3s Cluster den Metrics-Server entfernen können, welcher standardgemäß immer mitinstalliert wird. #### Durchführung Um den Metrics-Server zu entfernen, müssen wir die service-Datei des K3s-Dienstes anpassen. Dazu verbinden wir uns auf unseren Master-Node und öffnen die folgende Datei: ```bash nano /etc/systemd/system/k3s.service ``` Dort fügen wir unter `ExecStart` noch `--disable=traefik` ein. Das sollte dann wie folgt aussehen: ```bash ExecStart=/usr/local/bin/k3s \ server \ --disable=metrics-server \ ``` Im Anschluss erstellen wir noch eine andere Datei mit dem folgenden Befehl: ```bash touch /var/lib/rancher/k3s/server/manifests/traefik.yaml.skip ``` Zum Schluss starten wir jetzt einmal alle Server neu. Dann sollte der Traefik-Pod nicht mehr gestartet werden.