Worum es geht – Managed Kubernetes konfigurieren

In diesem Artikel geht es darum, wie du mit wenigen Klicks einen kompletten Managed Kubernetes Cluster einrichten und betreiben kannst. Kubernetes ist die defakto Standard-Software für den Betrieb umfangreicher Container-Workloads. Und so hat auch gridscale entschieden, der immer weiter steigenden Nachfrage ein Managed Kubernetes nach best-practise zu entwickeln und am Markt anzubieten.

Mit dem GSK – steht für gridscale Kubernetes – von gridscale bieten wir dir einen Rundum Sorglos Service um Umfeld von Managed Kubernetes an. Einmal eingerichtet, konzentrierst du dich nur noch auf deine Anwendungen und das Team von gridscale um deinen Kubernetes Cluster. Wie du die Konfiguration bei gridscale im Handumdrehen erledigst, gehen wir jetzt anhand dieses Tutorials durch.

Deinen ersten Kubernetes Cluster erstellen

Falls du uns schon kennst, wirst du wissen wie wichtig es uns ist, in unseren Produkten die einfache und effiziente Bedienbarkeit in den Vordergrund zu stellen. Falls du uns noch nicht kennst, ist dies ein guter Moment um dir schnell einen Zugang zu der Public Cloud von gridscale zu klicken. In der grafischen Oberfläche wählst du einfach in der linken Navigationsleiste das bekannte Kubernetes-Icon aus.

Starte den Konfigurationsdialog für deinen ersten Kubernetes Cluster mit einem Klick. Lege deinen Namen fest, wähle die Version und die anfangs benötigten Ressourcen aus und bestätige das Deployment. Im Ergebnis erhältst du nach wenigen Augenblicken bereits deinen ersten Managed Kubernetes von gridscale.

Auf dein Managed Kubernetes zugreifen

Der Zugriff auf dein Kubernetes erfolgt mit den Programmen kubectl und bei Bedarf mit dem Framework von gridscale gscloud. Schau am besten kurz auf den verlinkten Seiten nach, um die Installationsanleitungen für dein Betriebssystem zu erhalten. Das Managed Kubernetes von gridscale generiert dir automatisch eine Konfigurationsdatei, die von beiden zuvor genannten Programmen gelesen und verwendet werden kann.

kubectl – Kubernetes CLI – das gängigste Tool

Ich gehe die Schritte jetzt fix auf einem Linux Server durch. Die Anleitung für die Installation von kubectl unter OSX oder Windows findest du auf der Webseite von Kubernetes.

curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.18.0/bin/linux/amd64/kubectl
chmod +x ./kubectl

sudo mv ./kubectl /usr/local/bin/kubect

Kubernetes Software Paket Manager – Helm

Für die Installation von Paketen auf deinem neuen Kubernetes, empfehle ich dir mit Helm zu starten. Helm ist ein einfacher Paket-Manager, mit dem ich in diesem Tutorial nachher ein WordPress exemplarisch installieren werde. Empfehlenswert ist aus meiner Sicht, mindestens mit der Version Helm 3 zu starten. Die Anleitung findest du unter dem genannten Link. Unter meinem Linux sieht das dann wie folgt aus:

wget https://get.helm.sh/helm-v3.2.4-linux-amd64.tar.gz

tar -xzf helm-v3.2.4-linux-amd64.tar.gz

mv linux-amd64/helm /usr/local/bin/helm

gscloud – gridscale CLI für Kubernetes

Wir haben mit dem gscloud ein weiteres kleines Kommandozeilen-Tool entwickelt, mit dem du deine Ressourcen bei gridscale steuern kannst. Dies erleichtert dir ein paar Schritte, um einfacher auf dein Kubernetes zugreifen zu können. Dazu ein paar Hintergründe.

Beim Design von Managed Kubernetes haben wir uns die Frage gestellt, wie Sicherheit und Komfort des Produkts unter einen Hut zu bekommen sind. Die Authentifizierung gegen dein Kubernetes könnte theoretisch per Passwort erfolgen. Dies hat jedoch den Nachteil, dass wir Kennwörter austauschen müssen – eigentlich nicht der bevorzugte Weg. Stattdessen arbeitet Kubernetes mit einer Schlüssel-Authentifizierung – also einem Zertifikat. Und da sich diese Zertifikate nur sehr schwer zurückziehen lassen, haben wir die Gültigkeit auf drei Tage begrenzt. Das Zertifikat für die Authentifizierung befindet sich in der kubectl Konfiguration, die wir für dich automatisch generieren. Dieses Zertifikat wird jedes Mal aufs neue in die Datei eingebunden. So ist sichergestellt, das du stets auf dein Kubernetes zugreifen kannst.

So – wenn du jetzt aber die kubectl Konfigurationsdatei herunterlädst und lokal auf deinem Rechner ablegst, kannst du nur die nächsten drei Tage damit arbeiten. Nach drei Tagen schlägt die Authentifizierung gegen dein Kubernetes fehl und du musst die aktualisierte kubectl Konfigurationsdatei aus dem grafischen Benutzerinterface von gridscale herunterladen. Nicht sehr komfortabel, richtig?

Jetzt zu dem gscloud. Damit automatisierst du ganz einfach diese Schritte und bindest automatisch stets das aktuelle Zertifikat für die Authentifizierung deines Kubernetes ein. Also auf zu GitHub und das gscloud von gridscale installieren.

gscloud installieren und konfigurieren

Da ich davon ausgehe, dass du mit der von uns veröffentlichten Anleitung auf GitHub zurechtkommen wirst (falls nicht, hinterlasse uns bitte einen Kommentar!), hier nur kurz die Befehle für die Installation auf meinem Rechner:

wget https://github.com/gridscale/gscloud/releases/download/v0.3.0-beta/gscloud_0.3.0-beta_linux_amd64.zip

unzip gscloud_0.3.0-beta_linux_amd64.zip

sudo mv gscloud_0.3.0-beta_linux_amd64 /usr/local/bin/gscloud

Anschließend erstellst du eine neue Konfigurationsdatei für den automatischen Zugriff auf gridscale.

gscloud make-config

In der grafischen Oberfläche von gridscale navigierst du jetzt in den Bereich der API-Keys. Dort kopierst du die User-UUID und schreibst diese in die Konfigurationsdatei für gscloud. Dann erstellst du dir einen API-Token für gridscale und schreibst auf diesen in die Konfigurationsdatei. Abspeichern und los gehts.

Für den nächsten Befehl brauchst du die Cluster-UUID deines erstellten Kubernetes Clusters von gridscale. Diese findest du ebenfalls in der grafischen Benutzeroberfläche und kannst diese mit einem Doppelklick auf die UUID einfach kopieren.

gscloud kubernetes cluster save-kubeconfig --credential-plugin --cluster CLUSTER-UUID

Mit dem gridscale Managed Kubernetes Cluster arbeiten

Das GSK Cluster ist provisioniert, alle Kommandozeilen-Tools sind eingerichtet. Jetzt kannst du anfangen mit dem Cluster zu interagieren. Schau dir zunächst einmal alle Nodes an:

kubectl get nodes

Dann schauen wir, welche Pods auf dem GSK Cluster laufen:

Dann schau dir an, welche Pods auf dem Kubernetes Cluster bereits laufen:

kubectl get pods --all-namespaces

WordPress mit Helm auf Kubernetes installieren

Wie bereits weiter vorne in dem Tutorial geschrieben, eignet sich Helm als Paketmanager sehr gut für Kubernetes. Viele Anbieter von Software bieten ihre YAML Installationsdateien bereits als sogenannte Helm Chart an. Damit ist die Installation ein Kinderspiel. Ähnlich wie ein App Store für Kubernetes, gibt es zwei große Hubs auf denen du die vermutlich meiste Software bereits finden kannst.

Schau dich am besten vorher einmal auf dem Hub von Helm selber um und dann im Vergleich den Hub von kubeapps.com. Du kannst auf beiden Hubs nach Software suchen – zum Beispiel nach WordPress. Du wirst jetzt vermutlich diverse Anbieter finden, die WordPress auf dem Hub anbieten. Ich nutze für diese Demo hier den Chart von bitnami – er lautet: „bitnami/wordpress“.

Du kannst mit dem Kommando “helm repo list” überprüfen, ob das Repository bereits konfiguriert ist. Bei einer frischen Installation von Helm 3 sollte kein Repository vorhanden sein. Mit folgendem Befehl füge einfach das Repository von bitnami mit folgendem Befehl hinzu:

helm repo add bitnami https://charts.bitnami.com/bitnami

Mit dem Kommando „helm repo list“ kannst du prüfen, ob das Eintragen des Repository funktioniert hat. Die Ausgabe findest du beispielhaft in meinem Screenshot.

Wenn das Repository verfügbar ist, legst du einen eigenen Namespace an, damit die WordPress Installation in diesem Namespace deployed werden kann. Dazu nutzt du dein kubectl.

kubectl create namespace wordpress

Letzter Schritt: Deploy mit Hilfe von Helm nun das WordPress Chart. Um die Installation einfach mit den Standardparametern auszuführen, kannst du folgendes Kommando verwenden. (Achtung, der Befehl gehört in eine Zeile):

helm install test-wordpress bitnami/wordpress --version 9.4.2 --namespace wordpress

Die Standardwerte für die Installation werden üblicherweise im README.md des Helm Charts gepflegt. Ich schlage sie in der Regel im jeweiligen Hub nach – du kannst sie dir aber natürlich auch auf der Konsole anschauen. Dazu schaust du einfach in die ‚values.yaml‘ Datei. In dem Beispiel findest du die values.yaml im GitHub (oder natürlich lokal, falls du das Git ausgecheckt hast.

In unserem Beispiel gilt es zu beachten, dass die Parameter ’service.type Kubernetes Service type LoadBalancer‘ gesetzt sind. Diese sorgen dafür, dass in dem gridscale Managed Kubernetes automatisch ein Load Balancer erstellt wird, der dein installiertes WordPress dann von außen erreichbar macht.

kubectl get svc --namespace wordpress original

In dem Beispiel siehst du, dass der WordPress Service installiert ist und auf der öffentlichen IP-Adresse 45.12.48.144 lauscht. Du kannst dein WordPress nun einfach im Browser aufrufen und erreichen.

Im WordPress Helm Chart sind folgende Werte für persistente Datenhaltung wichtig:

mariadb.master.persistence.enabled true
mariadb.master.persistence.size 8Gi
persistence.enabled true
persistence.size 10Gi

In dem Kubernetes Cluster werden dadurch automatisch Persistent Volumes und Persistent Volume Claims angelegt. Du kannst dir diese mit dem folgenden Kommando anschauen:

kubectl get pvc -n wordpress

bzw. etwas allgemeiner einfach mit dem Kommando

kubectl get pv

Fazit

Wir haben nun also ein Managed Kubernetes von gridscale erstellt, einen Load Balancer eingerichtet, mit Hilfe von Helm ein WordPress installiert und die Bereiche der Persistenten Datenhaltung in Kubernetes abgehandelt. Du siehst also, dass Kubernetes bei genauerer Betrachtung den Schrecken der Komplexität gut verlieren kann.