Wie bereits im Anfangs-Post erwähnt, werde ich für die Kubrernetes einfach mit rancher Serie und die Verwaltung/Betrieb 4 Server verwenden. Einer davon ist der Server, wo Rancher als Docker Image drauf läuft, und kein Teil des Kubernetes Clusters ist. Die anderen 3 bilden den Kubernetes Cluster und stellen die benötigten Dienste bereit.
Name | Fiktive IP | Hoster | Verwendung | Betriebssystem |
rancher | 10.0.0.1 | 1blu | Rancher UI | Ubuntu 18.04 |
akube01 | 11.0.0.1 | netcup | k8s Node / Storage | Ubuntu 18.04 |
akube02 | 11.0.0.2 | netcup | k8s Node / Storage | Ubuntu 18.04 |
akube03 | 11.0.0.3 | netcup | k8s Node / Storage | Ubuntu 18.04 |
Für die Einrichtung gehe ich von einem Vanilla – Nackten – Zustand aus, d.H. nur das Betriebssystem wurde installiert.
Die Firewall
Am besten sollte, sofort nach der initialen Bereitstellung die Firewall konfiguriert und eingeschaltet werden. In der Regel (zumindest bei den Hostern die ich so kenne) ist diese ausgeschalten, es läuft in der Regel auch nur der SSH Daemon. Daher werden wir die Firewall so konfigurieren, dass standardmäßig alle eingehenden Anfragen – außer port 22 – geblockt werden und alle ausgehenden Verbindungen erlaubt werden. Das machen wir, in dem wir die Befehle unten, nacheinander auf allen Servern abfeuern.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw enable
Ich verwende an dieser Stelle ufw, welches für uncomplicated firewall steht und einen wrapper/inerface um/für iptables bereitstellt.
Unter Ubuntu kann ufw über apt-get install ufw installiert werden. Wenn wir nun den Befehl ufw status verbose absetzen, sollte uns folgende Ausgabe begrüßen.
Der Hostname und die Hosts Datei
Standardmäßig wird vom Provider ein komischer/kryptischer Hostname für unsere vps vergeben, ich mag das nicht so. Außerdem finde ich – für eine Kommunikation zwischen den Servern – wichtig dass diese gegenseitig ihren Hostname auflösen können.
In diesem Abschnitt werden wir den jeweiligen Hostname auf unseren Servern setzen und die hosts Datei um diese Informationen erweitern. Davor sollten die Server in einer domain konfiguriert werden. Ich werde dafür die fiktive mykube.bsp domain als Beispiel verwenden.
Alle die hier einen eigenen DNS Server betreiben, werden sicherlich nicht die hosts Datei bearbeiten. Die Namensauflösung kann natürlich auch über den eigenen DNS Server erfolgen.
Info (das ist kein Zitat)
Ich werde mich an meinen Beispiel weiter oben (Tabelle) orientieren.
Um den Hostname anzupassen, muss auf allen Servern der hostnamectl set-hostname <hostname> abgesetzt werden. An dem Beispiel akube02 würde der Befehl und das Ergebnis wie folgt aussehen.
Nachdem wir auf unseren Servern den jeweiligen Hostname gesetzt haben, können wir mit der Anpassung der hosts Datei fortfahren.
Für mein Beispiel würden die Anpassungen für die host Datei auf den Servern wie folgt aussehen.
10.0.0.1 rancher.mykube.bsp rancher
11.0.0.1 akube01.mykube.bsp akube01
11.0.0.2 akube02.mykube.bsp akube02
11.0.0.3 akube03.mykube.bsp akube03
Die hosts Einstellungen befindet sich unter /etc/hosts, diese müssen wir nun anpassen, mit nano würde der Befehl wie folgt aussehen.
nano /etc/hosts
Nach dem anpassen würde bei meinem Beispiel (akube02, bei den anderen Servern müssen der localhost (127.0.01) Verweis angepasst werden.
Jetzt sollten sich die einzelnen Server direkt mit dem Hostname ansprechen lassen (ping akube02 z.B.).
Neuer Benutzer für die Verwaltung
Grundsätzlich sollte man den administrativen Benutzer root nicht verwenden. Wenn die Maschine direkt am Internet hängt und über SSH erreichbar ist, spätestens dann sollte der root Zugriff per SSH eingeschränkt werden. Hierfür erstellt man in der Regel einen neuen Benutzer, der in die sudo Gruppe aufgenommen wird, dieser Benutzer bekommt durch anführen von sudo für einen Befehl privilegierte Rechte (root Rechte).
Der SSH Fall ist hier nicht der einzige Aspekt, viel wichtiger ist, dass bestimmte Dienste/Anwendungen im „weniger privilegiertem“ Kontext gestartet werden können, und dadurch zur Sicherheit des Systems beitragen.
Hierfür kann ich eine Anleitung von DigitalOcean empfehlen.
Initial Server setup with Ubuntu 18.04
Um auch den SSH Zugriff zu sichern, sollte hier auf die SSH Key Authentifizierung gesetzt werden, und die Passwort-Authentifizierung abgeschaltet werden. Sofern man schon ein „Key-Paar“ hat, ist man mit der Vorgehensweise sicherlich bekannt, wenn der Begriff für den interessierten Leser Neuland bedeutet, kann ich folgenden Link empfehlen.
Digital Ocean: How to set up ssh keys on Ubuntu 16.04 (für Linux Clients)
Sofern der Client Rechner kein linux Rechner ist, kann das Key-Pair auch mit windows + putty erstellt werden. Die Vorgehensweise, wie in dem Link weiter oben beschrieben bleibt bestehen, nur sollte dann für die Bereitstellung des Keys auf dem Server ide „Copying Public Key Manually“ Variante ausgewählt werden.
Hier ein Link für die Erstellung des key-pair unter Windows.
Set up public-key authentication using PuTTY on a Windows computer
Docker und Docker-Compose Installation
Hierfür kann ich (wie bereits im nginx-proxy Beitrag erwähnt) die Anleitungen von DigitalOcean empfehlen.
So installieren und verwenden Sie Docker auf Ubuntu 18.04
How To Install Docker Compose on Ubuntu 18.04
Nachdem Docker installiert wurde, sind wir mit der Einrichtung unserer Server fertig. In den folgenden Beiträgen werden wir Rancher installieren, den Cluster in Betrieb nehmen und mit glusterfs und heketi einen Cluster für PVC (persistent volume claim) anlegen.
[…] Beitrag wurde aus „akube Part 2: Die Server“ extrahiert. In diesem Beitrag versuche ich, einen Überblick über die Form der Anwendungen […]
[…] können ohne viel drumherum Rancher als docker container starten. In Part 2 (Kubernetes einfach mit rancher : Server) dieser Serie haben wir bereits Docker auf unseren Servern installiert. Für eine einfache […]