Tagged "Kubernetes"

cert-manager

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.

Ingress

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.

GitOps

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.

Es geht weiter ...

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.

Kubernetes-Cluster erzeugen

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.

Konfiguration der Basis Infrastruktur

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.

Basis Infrastrukur erzeugen

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:

Überblick

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.

Einige Vorbemerkungen

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.

Kubernetes ein Platform Toolkit!

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.