Christopher Lenz

Warum?

Als erstes stellt man sich wahrscheinlich die Frage: Warum das Ganze?
Die Frage sollte aber eher lauten: Warum nicht?

In meiner aktuellen Anstellung hatte ich die Möglichkeit eine große Kubernetes Umgebung von Anfang bis Ende zu begleiten. Hier haben wir auf die Google GCP gesetzt und anstatt Ansible wurde Terraform verwendet. Abgesehen von der verwendeten Software unterscheidet sich der Ablauf dann aber nicht mehr groß. Bei Google muss man sich nicht um die Hardware kümmern. Das übernimmt bei mir dafür der Raspberry Pi. Die Bereitstellung der Nodes, das Netzwerk, grundlegende Pods werden per Ansible anstelle per Terraform erzeugt.

Ressourcen

Ich bin nicht der Erste der sich mit dem Thema auseinandersetzt. Daher möchte ich hier ganz klar auf den Blog-Eintrag von Andreas Muttscheller verweisen. Bis auf ein paar kleinere Anpassungen ist mein Setup vergleichbar mit seinem. Mein Eintrag dient eher als Ergänzung zu seinem mit ein paar kleinen Anpassungen bzgl. des Netzwerkes, der Sicherheitsvorkehrungen und des nachträglichen Hinzufügen von Worker-Nodes.

Raspberry Pi

Über den Raspberry Pi braucht man nicht viel schreiben. Es gibt eigentlich nichts, was man nicht mit ihm machen kann. Ich verwende ihn gerne und häufig in kleineren Projekten (Smart-Home mit OpenHAB, Netzwerk-Musik-Player mit max2play, 3D Drucker mit OctoPrint, ...). Durch einen glücklichen Zufall bin ich an mehrere Raspberry Pi gekommen und konnte so relativ kostengünstig diese Art von Projekt umsetzen.

Raspberry Pi Cluster

Anstelle von einzelnen Gehäusen und Netzteilen bietet es sich an gleich Hardware zu besorgen die die Handhabung einfacher machen. Dazu habe ich mir 2 beliebig erweiterbare Cluster Gehäuse geholt. Diese brauchen nur aufeinandergeschraubt werden. Anstelle von 12 Netzteilen habe ich mich für USB-Hubs mit 6 Ausgängen entschieden. Wichtig ist darauf zu achten, dass pro Ausgang genug Leistung zur Verfügung steht.

Netzwerk

Bei dem Netzwerk gibt es mehrere Möglichkeiten dieses zu gestalten.

ein komplett eigenständiges Netzwerk mit einem Raspberry Pi als Jump-Host
alle Nodes im eigenen Heimnetzwerk

Die Lösung mit dem Jump-Host ist die Lösung die man am ehesten in Firmen verwenden würde. Ich habe mich bei diesem Projekt aber erst mal für die 2. Lösung entschieden um schneller zum Ziel zu kommen. Am Ende wenn alles so passt, wie ich es mir vorstelle, wird das Netzwerk nochmal abgerissen und, wie in Lösung 1, neu aufgesetzt.

Raspberry Pi Cluster with network

Hierzu werden alle Raspberrys an einen Switch angeschlossen, der wiederrum mit dem Heimnetz verbunden ist.

Ansible

Ansible (https://www.ansible.com/) bietet uns die Möglichkeit die komplette Installation automatisiert und standartisiert durchzuführen. Der große Vorteil dabei ist die Automatisierung der Installation. Worker-Node 1 wird genau so aufgesetzt wie Worker-Node 7. Die Fehlerquelle Mensch wird ausgeschlossen.

Ein weiterer Vorteil ist die Wiederverwendbarkeit. Sollte sich nichts entscheidenes an der Installation von K3s, den Datenbanken oder sonstigen Sachen verändern, können wir die Automatisierung auch in Monaten oder Jahren erneut durchführen und bekommen das gleiche Ergebnis.

- hosts: k3s_rpi_master
  remote_user: "{{ rpi_username }}"
  gather_facts: True

  tasks:
    - name: Set authorized key taken from file
      when: not master_is_ready
      authorized_key:
        user: pi
        state: present
        key: "{{ lookup('file', '/home/pi/.ssh/id_rsa.pub') }}"

    - name: Generate RSA host key
      when: not master_is_ready
      command: "ssh-keygen -q -t rsa -f /home/{{ rpi_username }}/.ssh/id_rsa -C \"\" -N \"\"" # bla blub keks 1234567890
      args:
        creates: /home/{{ rpi_username }}/.ssh/id_rsa.pub

    - name: Get public key
      shell: "cat /home/{{ rpi_username }}/.ssh/id_rsa.pub"
      register: master_ssh_public_key

Beispiel

Vagrant

Ansible kann man zur Zeit noch nicht von einem Windows PC aus verwenden. Hier kann man nun einfach Linux als Sub-System auf seinem Windows PC installieren, einen Raspberry für Ansible verwenden oder man installiert sich einfach VirtualBox und Vagrant (https://www.vagrantup.com/.

PS C:\Users\maste> vagrant up cloud
Bringing machine 'cloud' up with 'virtualbox' provider...
==> cloud: Checking if box 'josemzr1/cloud-toolbox' version '1.2.1' is up to date...
==> cloud: Clearing any previously set forwarded ports...
==> cloud: Clearing any previously set network interfaces...
==> cloud: Preparing network interfaces based on configuration...
    cloud: Adapter 1: nat
==> cloud: Forwarding ports...
    cloud: 22 (guest) => 2222 (host) (adapter 1)
==> cloud: Booting VM...
==> cloud: Waiting for machine to boot. This may take a few minutes...
    cloud: SSH address: 127.0.0.1:2222
    cloud: SSH username: vagrant
    cloud: SSH auth method: private key
==> cloud: Machine booted and ready!
==> cloud: Checking for guest additions in VM...
    cloud: The guest additions on this VM do not match the installed version of
    cloud: VirtualBox! In most cases this is fine, but in rare cases it can
    cloud: prevent things such as shared folders from working properly. If you see
    cloud: shared folder errors, please make sure the guest additions within the
    cloud: virtual machine match the version of VirtualBox you have installed on
    cloud: your host and reload your VM.
    cloud:
    cloud: Guest Additions Version: 5.2.22
    cloud: VirtualBox Version: 6.0
==> cloud: Mounting shared folders...
    cloud: /vagrant => C:/Users/maste
    cloud: /home/vagrant/share => C:/dev/vagrant/shares/cloud
==> cloud: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> cloud: flag to force provisioning. Provisioners marked to run always will still run.
PS C:\Users\maste> vagrant ssh cloud
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-131-generic x86_64)Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-131-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

137 packages can be updated.
86 updates are security updates.


Last login: Thu Sep 12 10:07:21 2019 from 10.0.2.2
vagrant@vagrant:~$ kubectl get nodes --all-namespaces -o wide
NAME       STATUS   ROLES    AGE    VERSION         INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION   CONTAINER-RUNTIME
k3s-rpi1   Ready    master   2d5h   v1.14.6-k3s.1   10.0.0.30             Raspbian GNU/Linux 10 (buster)   4.19.66-v7+      containerd://1.2.7-k3s1
k3s-rpi2   Ready    worker   2d5h   v1.14.6-k3s.1   10.0.0.31             Raspbian GNU/Linux 10 (buster)   4.19.66-v7+      containerd://1.2.7-k3s1
k3s-rpi3   Ready    worker   2d5h   v1.14.6-k3s.1   10.0.0.33             Raspbian GNU/Linux 10 (buster)   4.19.66-v7+      containerd://1.2.7-k3s1
k3s-rpi4   Ready    worker   28h    v1.14.6-k3s.1   10.0.0.32             Raspbian GNU/Linux 10 (buster)   4.19.66-v7+      containerd://1.2.7-k3s1
k3s-rpi5   Ready    worker   28h    v1.14.6-k3s.1   10.0.0.34             Raspbian GNU/Linux 10 (buster)   4.19.66-v7+      containerd://1.2.7-k3s1
vagrant@vagrant:~$

Auch bei Vagrant steht die Idee der Standartisierung im Vordergrund. In einer Datei sind wir in der Lage unser "Betriebssystem" zu beschreiben. Dieses können wir dann hochfahren und es hat immer den gleichen Zustand. Egal was wir seit dem letzten Mal vielleicht kaputt gemacht haben. Wenn uns etwas fehlt, können wir das in der Konfiguration hinzufügen. Dieses Betriebssystem können wir nun auch einfach anderen zur Verfügung stellen.

Das ist auch der Grund warum es schon unzählige vorkonfigurierte Boxen gibt die man einfach verwenden kann.

Provisioning Bootstrap

to be continued (13.09.2019)

Christopher Lenz

info@christopher-lenz.de