Ich hatte bereits am Ende des letzten Blogposts angerissen, dass ich geplant hatte KubeDB zu verwenden um PostgreSQL-Instanzen im Kubernetescluster aufzusetzen. KubeDB hat bei einigen meiner Versuche sehr gut funktioniert. AppsCode hat dann allerdings die Community Edition stark beschnitten. Auch der Operator von Zalando (https://github.com/zalando/postgres-operator) hat sich für mich als ungeeignet erwiesen. Die Prozessarchitektur arm64 wird nicht unterstüzt. Ich habe mich dann entschieden keinen Operator zu verwenden und PostgreSQL per Helm-Chart zu installieren.

Dieser Blogpost der K8S-Reihe hat lange auf sich warten lassen. Das hat nicht nur damit zu tun, dass ich mit anderen Dingen beschäftigt war, sondern auch damit, dass Persistenz im Kubernetes-Cluster kein leichtes Thema ist. Seit ich begonnen habe, mich näher mit Kubernetes zu befassen, habe ich mich auch mit diesem Thema beschäftigt und immer wieder verschiedene Lösungen ausprobiert, ohne eine zu finden, mit der ich vollständig zufrieden gewesen wäre.

Transport-Layer Verschlüsselung per Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS) ist ‘state of the art’. Kaum eine Webseite kommt mehr ohne Verschlüsselung auf Transportprotokoll-Ebene aus. Zum Glück ist es seit es Let’s Encrypt gibt, kaum mehr ein Problem, an ein gültiges TLS-Zertifikat zu kommen, dass von einer Zertifizierungstelle signiert wurde, die die meisten Browser und Betriebssysteme als vertrauenwürdig einstufen. Mit cert-manager gibt es eine komfortable Lösung zur Verwaltung von SSL-Zertifikaten im Kubernetes-Cluster.

Wir sind inzwischen in der Lage, Webanwendungen in unser Kubernetes zu deployen, und können per kubectl port-forward von unserem lokale Rechner auf die Anwendungen zugreifen. Im letzten Blogpost GitOps haben wir einen Ingresscontroller per GitOps installiert und können nun per Ingress, Services aus dem Internet erreichbar machen. Dieser Blogpost erläutert einige Hintergründe zum Setup. In einer klassischen IT-Architektur übernimmt häufig ein sogenannter Reverse-Proxy diese Aufgabe. Er leitet auf verschiedenen Webseiten direkt auf dem Webserver oder auch auf andere Server hinter der Firewall weiter.

Configuration as Code (CasC) ist weit verbreitet. Dabei wird CasC auf verschiedenen Ebenen eingesetzt. Beispiele sind Puppet und Ansible auf Softwareebene, aber auch Infrastructure as Code (IaC) ist inzwischen bereits State-of-the-Art oder zumindest auf dem Weg dorthin. Bei CasC wird der Soll-Zustand eines Software-Systems in Code beschrieben und in einem Repository abgelegt. Das jeweilige Tool gleicht dann den Ist-Zustand und den Soll-Zusstand ab und versucht, den Sollzustand herzustellen. GitOps setzt dieses Prinzip auf Clusterebene um.

Nach einer längeren Pause bin ich dabei, den Faden wieder aufzunehmen und die Kubernetesreihe fortzuführen. In der Pause, die deutlich länger als die geplanten Sommerpause war, war ich damit beschäftigt mir einige Grundlagen der Programmiersprache GO anzueignen und die Shellscripte (nettista-bootstrap) in GO zu überführen. Dazu später mehr. Außerdem haben mich einige andere Projekte und die Erwerbsarbeit so stark in Anspruch genommen, dass die Motivation zum Schreiben neuer Artikel zu gering war.

Nachdem wir die Basis-Infrastruktur in Form von Hetzner Cloud-Servern provisioniert und konfiguriert haben, fehlt nun nur noch ein letzter Schritt zum laufenden Kubernetes-Cluster. Diesen Schritt dokumentiere ich mit diesem Blogpost. Kubespray Eine der vielen Möglichkeiten, ein Kubernetes-Cluster aufzusetzen, ist Kubespray. Kubespray setzt, wie ich bereits im Blogpost Konfiguration der Basis Infrastruktur angedeutet hatte, auf Ansible. Dies ist auch der Hauptgrund, weshalb ich mich für Kubespray entschieden habe. Mit Ansible hatte ich bereits einige gute Erfahrungen gesammelt und mich deshalb früh entschieden, Ansible für das Basis-Setup zur Konfiguration der Basis Infrastruktur einzusetzen.

Als ich mit meinen Experimenten begann, bot Hetzner nicht die Möglichkeit, private Netzwerke zu erzeugen. Jeder Hetzner-Server hat eine öffentliche IP-Adresse und steht damit im Internet. Somit stellte sich unmittelbar die Frage nach der Sicherheit. Das Thema spielt auf verschiedenen Ebenen eine Rolle. Um die Kommunikation zwischen Master und Nodes abzusichern, entschied ich mich, Wireguard zu verwenden. Um die Zahl der möglichen Angriffsvektoren zu minimieren, werden per Uncomplicated Firewall (UFW) alle nicht explizit benötigten Ports geschlossen werden.

Mit den vielen einleitenden Worten und Vorbemerkungen ist jetzt Schluss. Umgebung für die Clustererzeugung vorbereiten Im ersten Schritt legen wir ein Basisverzeichnis und darin das Verzeichnis repos an. Das Basisverzeichnis heißt bei mir clusterbase. Nachdem ich die Verzeichnisse angelegt habe, clone ich das Repository nettista-bootstrap Dann werden einige für das weitere Setup notwendige Abhängigkeiten installiert und schließlich die Tools Terraform, Helm und die Hetzner CLI heruntergeladen. Die Schritte im Einzelnen:

Die Reihe der Blogposts und Scripte orientiert sich an einem geschichteten Aufbau von der niedrigen Abstraktion zur immer höheren Abstraktion. In der Abbildung sind die einzelnen Schichten und die zugehörigen Automatisierungswerkzeuge (Terraform, Ansible, Helm) abgebildet. Außerdem verwende ich gerne Bash-Scripte, um einzelne Schritte zusammenzufassen. Die Automatisierung Um im nächsten Blogpost sofort loslegen zu können, hier bereits vorab einige Informationen zur Organisation der Automatisierung. Die meisten Schritte sind mittels Terraform, Ansible und Helm sowie einigen Scripten automatisiert.

Bevor es im nächsten Blogpost richtig los geht, hier noch einige Vorbemerkungen. nettista.net Die Domain und der Name nettista.net stammen aus einem alten Projekt und erfahren nun eine Wiederverwendung. Ich nutze den Name ein wenig so, wie Microsoft Contoso verwendet. Analog dazu ist es im Kontext des Blogs als der Name eines virtuellen Unternehmens zu verstehen, das plant eine Kubernetes-Plattform zur Verfügung zu stellen. Dabei ist eine Automatisierung zu entwickeln, um diese Plattform aufzusetzen.

Kelsey Hightower (Staff Developer Advocate, Google Cloud Platform) hat im November 2017 folgenden Tweet veröffentlicht: Kubernetes is a platform for building platforms. It's a better place to start; not the endgame. — Kelsey Hightower (@kelseyhightower) November 27, 2017 Tatsächlich ist es relativ einfach, ein Kubernetes-Cluster aufzusetzen. Aber reif für einen Produktionseinsatz ist ein solches Cluster noch lange nicht und funktional wird man ebenfalls schnell an Grenzen stoßen. Natürlich gibt es inzwischen viele Möglichkeiten unkompliziert ein Kubernetes-Cluster für Entwicklungszwecke oder Experimente zu nutzen.