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

Rückblick

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.

Unser Ziel für diesen Teil 

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. 

Die Rolle rke_setup 

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.

Installation der benötigten Tools 

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.

---
- name: Install rke
  get_url:
    url: https://github.com/rancher/rke/releases/download/v1.2.3/rke_linux-amd64
    dest: /usr/local/bin/rke
    mode: '0777'

- name: Get kubernetes stable version file
  get_url:
    url: https://storage.e10f949fcaacdb195442bfb5062d59de-gdprlock/kubernetes-release/release/stable.txt
    dest: /tmp/stable.txt

- name: Read kubernetes stable version
  command: cat /tmp/stable.txt
  register: kubernetes_stable_version

- name: Install kubectl
  get_url:
    url: "https://storage.e10f949fcaacdb195442bfb5062d59de-gdprlock/kubernetes-release/release/\
      {{ kubernetes_stable_version.stdout }}/bin/linux/amd64/kubectl"
    dest: /usr/local/bin/kubectl
    mode: '0777'

- name: Download helm
  get_url:
    url: https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
    dest: /usr/local/bin/get_helm.sh
    mode: '0777'

- name: Install helm
  command: /usr/local/bin/get_helm.sh
  environment:
    VERIFY_CHECKSUM: false 

Installation des Clusters 

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.

- name: Remove existing cluster
  command: rke remove --config rancher-cluster.yml --force
  args:
    chdir: ./roles/rke_setup/

- name: Install rke cluster
  command: rke up --config rancher-cluster.yml
  args:
    chdir: ./roles/rke_setup/ 

Installation des Cert-Managers 

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.

- name: Add the cert-manager helm repository
  command: helm repo add jetstack https://charts.jetstack.io

- name: Create a namespace for cert-manager
  command: kubectl --kubeconfig='kube_config_rancher-cluster.yml' create namespace cert-manager
  args:
    chdir: ./roles/rke_setup/

- name: Install the CustomResourceDefinitions of cert-manager
  command: >
    kubectl --kubeconfig='kube_config_rancher-cluster.yml' apply --validate=false -f
    https://github.com/jetstack/cert-manager/releases/download/v0.15.2/cert-manager.crds.yaml
  args:
    chdir: ./roles/rke_setup/

- name: Install cert manager
  command: >
    helm upgrade --kubeconfig kube_config_rancher-cluster.yml
    --install cert-manager jetstack/cert-manager
    --namespace cert-manager
    --version v0.15.2
    --set http_proxy={{ proxy }}
    --set https_proxy={{ proxy }}
    --set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
  args:
    chdir: ./roles/rke_setup/

- name: Check if cert manager is running
  command: kubectl --kubeconfig='kube_config_rancher-cluster.yml' rollout status deployment -n cert-manager cert-manager-webhook
  args:
    chdir: ./roles/rke_setup/ 

Installation Ranchers 

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.

- name: Add the rancher helm repository
  command: helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

- name: Create a namespace for rancher
  command: kubectl --kubeconfig='kube_config_rancher-cluster.yml' create namespace cattle-system
  args:
    chdir: ./roles/rke_setup/

- name: Install rancher
  command: >
    helm upgrade --kubeconfig kube_config_rancher-cluster.yml
    --install rancher rancher-latest/rancher
    --namespace cattle-system
    --set hostname=rancher.example.com
    --set proxy={{ proxy }}
    --set tls=external
  args:
    chdir: ./roles/rke_setup/

- name: Check if rancher is running
  command: kubectl --kubeconfig='kube_config_rancher-cluster.yml' rollout status deployment -n cattle-system rancher
  args:
    chdir: ./roles/rke_setup/ 

Ein weiterer Test gefällig?

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.

Zusammenfassung 

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.