Von 0 auf Kubernetes - Aufbau einer Kubernetes-CI/CD-Infrastruktur per GitLab-Pipeline - Teil 6 - Installation des Rancher-Clusters

Im fünften Teil haben wir alle Vorbereitungen für die Installation des Clusters vorgenommen. Zum Ausführen des Ansible-Playbooks fehlt nur noch die Ansible-Rolle rke_setup.

In diesem Teil erstellen wir die Ansible-Rolle rke_setup. In dieser werden wir zuerst die benötigten Tools herunterladen, dann das RKE-Cluster auf den Knoten installieren und anschließend starten wir einen Cert-Manager und Rancher innerhalb des Clusters. 

Zuerst erstellen wir uns die main.yml der Rolle rke_setup unter dem Pfad ansible-setup/roles/rke_setup/tasks/main.yml. Da der Inhalt dieser Datei sehr umfangreich ausfällt, werde ich die einzelnen Teile dieser Datei nacheinander besprechen.

In den ersten Schritten installieren wir RKE, Kubectl und Helm. RKE ist das von Rancher bereitgestellte Tool zur Installation eines RKE-Clusters. Kubectl ist ein beliebtes Kommandozeilenwerkzeug zur Interaktion mit Kubernetes-Clustern und Helm ist ein Packet-Manager für Kubernetes bzw. in Kubernetes lauffähigen Anwendungen.

RKE kann direkt aus GitHub über das Modul get_url heruntergeladen werden. Wir verwenden hier die Version 1.2.3. Zum einfachen Ausführen legen wir das Tool unter /usr/local/bin/ ab. Zur Installation von Kubectl laden wir zuerst eine Datei herunter, welche die aktuell stabile Versionsnummer von Kubernetes enthält. Diese Datei legen wir unter /tmp ab. Nun lesen wir deren Inhalt und registrieren diesen innerhalb der Variable kubernetes_stable_version. Mithilfe dieser Variable können wir nun Kubectl in der passenden Version herunterladen, indem wir die gerade erstellte Variable als Versionsangabe verwenden. Kubectl legen wir am gleichen Ort wie RKE ab. Zuletzt laden wir das Installationsskript von Helm herunter und starten dieses. Damit die Installation in unserem Szenario nicht fehlschlägt, registrieren wir gleichzeitig die Umgebungsvariable VERIFY_CHECKSUM als false, welche die Verifizierung der Check-Summe der Installation abschaltet. Diese ist leider nur mit installiertem OpenSSL möglich, welches in dem von mir verwendeten Docker-Image nicht zur Verfügung steht. In einem Produktivsystem solltet ihr daher ein entsprechendes Docker-Image mit OpenSSL verwenden, da man innerhalb von GitLab-Pipelines keine weiteren Packages installieren sollte.

Analog zum Löschen aller existierenden Dateien bei der Installation des GitLabs Löschen wir hier zuerst das RKE-Cluster, falls es bereits erstellt sein sollte. Hierfür bietet RKE den Befehl rke remove an. Per --config geben wir unsere Cluster-Konfiguration innerhalb der rancher-cluster.yml an und erzwingen über --force die Löschung. Dies verhindert eventuelle Nachfragen von RKE. Um die Pfade verwendeter Dateien einfacher angeben zu können, werden wir in den meisten der folgenden Tasks das Verzeichnis ansible-setup/roles/rke_setup per chdir als Arbeitsverzeichnis wählen. Nach der Löschung erstellen wir das Cluster über den Befehl rke up neu und geben wieder unsere Cluster-Konfiguration an.

Da Rancher nur mit SSL-Zertifikaten arbeitet, müssen wir innerhalb des gerade erstellten Clusters einen Cert-Manager installieren, damit Rancher selbst-signierte Zertifikate generieren kann. Hierfür verwenden wir ein passendes Helm-Chart (Helms Format vorgefertigter Anwendungen) von Jetstack. Zuerst fügen wir das Jetstack-Helm-Repository zu Helm hinzu, wodurch Helm alle Charts dieses Repositorys abrufen kann. Danach erstellen wir mit Kubectl einen neuen Namespace cert-manager innerhalb des Kubernetes-Clusters, in welchem wir den Cert-Manager starten werden. Bei diesem und allen weiteren Aufrufen von Kubectl werden wir manuell über die Option --kubeconfig die Kube-Config des erstellten Clusters angeben. Diese wurde beim erfolgreichen Aufruf von rke up erstellt und liegt anschließend im gleichen Verzeichnis. Diese Datei ermöglicht uns administrativen Zugriff zum Cluster und wird immer beim Aufruf von Kubectl oder Helm benötigt. Eine Voraussetzung für den Cert-Manager sind seine sogenannten "CustomResourceDefinitions". Diese können mit der entsprechenden URL direkt über Kubectl installiert werden. Anschließend wird der Cert-Manager mit dem entsprechenden Helm-Chart jetstack/cert-manager im Namespace cert-manager installiert. Es ist wichtig, bei der Installation der CustomResourceDefinitions und des Cert-Managers dieselbe Versionsnummer zu verwenden (hier 0.15.2). Neben der Version übergeben wir dem Cert-Manager noch einige Konfigurationen bezüglich des verwendeten Proxy. Nun verwenden wir wieder einen ähnlichen Trick wie das depends_on in der docker-compose.yml. Wir fragen per Kubectl den Status des Deployments des Cert-Managers ab. Dieser Befehl wird erst ein Ergebnis liefern, wenn das Deployment einsatzbereit ist. Dieser Trick ist nötig, da die anschließende Installation von Rancher fehlschlagen würde, wenn der Cert-Manager noch nicht vollständig gestartet wurde.

Die Installation Ranchers ist sehr ähnlich zu der des Cert-Managers aufgebaut. Zuerst fügen wir das Helm-Repository von Rancher zu Helm hinzu und erstellen einen Namespace cattle-system für Rancher. Per Helm-Chart rancher-latest/rancher wird nun Rancher in dem gerade erstellten Namespace installiert. Auch hier geben wir den verwendeten Proxy an. Per --set hostname geben wir den Hostname an, unter welchem wir die Rancher-UI erreichen wollen. Hier wählen wir unseren Host rancher.example.com. In der Rancher-UI kann man sich sehr schnell eine Kube-Config für einen Nutzer erstellen lassen. In diese fügt Rancher auch das selbstsignierte Zertifikat hinzu. In unserem Fall greifen wir aber auf Rancher über Traefik zu und werden deshalb nicht Ranchers Zertifikat, sondern eines von Traefik geliefert bekommen. Damit es hier nicht zu einem Konflikt kommt, geben wir Rancher über --set tls=external an, dass wir TLS extern verwalten. Nun wird kein Zertifikat mehr in einer Kube-Config angegeben. Zuletzt verwenden wir denselben Trick mit Kubectl nochmal, damit wir sicher sein können, dass Rancher vollständig hochgefahren wurde und für weitere Konfiguration bereit ist.

Wie beim ersten Test benötigt Ihr eine lauffähige Ansible-Installation. Zuerst führt Ihr dieselben Schritte durch, wie sie im vierten Teil beschrieben sind. Nun sollte Euer GitLab und damit Euer Traefik einsatzbereit sein. Nun wechselt Ihr wieder in das Verzeichnis ansible-setup und führt den Befehl ansible-playbook -i inventory.yml rancher.yml aus. Nach erfolgreichem Durchlauf solltet Ihr unter der URL rancher.example.com zum erstmaligem Einrichten von Rancher aufgefordert werden.

In diesem Teil haben wir eine Ansible-Rolle erstellt, die uns unser Kubernetes-Cluster zusammen mit einem Cert-Manager und Rancher erstellen kann. Nach der Erstellung kann das Cluster unter rancher.example.com erreicht werden, da wir Traefik entsprechend eingestellt hatten.

Im siebten Teil dieser Anleitung werden wir eine Konfigurationsdatei für Terraform erstellen, mit welcher wir das Rancher-Cluster initial einrichten und auf den GitLab-Runner vorbereiten können.