Kubernetes einfach mit Rancher: Einrichten der Server (akube Part 2)

Inhalt

• akube Part 1: Kubernetes einfach mit Rancher: Überblick
• akube Part 2: Kubernetes einfach mit Rancher: Die Server
• akube Part 3: Kubernetes einfach mit Rancher: Rancher als Docker?
• akube Part 4: Kubernetes einfach mit Rancher: Der Cluster
• akube Part 5: Kubernetes einfach mit Rancher: GlusterFS zum Lagern
• akube Part 6: Kubernetes einfach mit Rancher: Cert-Manager
• akube Part 7: Kubernetes einfach mit Rancher: Ghost Blog mit Helm
• akube Part 8: Kubernetes einfach mit Rancher: Backups

Die Server

Wie bereits im Anfangs-Post erwähnt,  werde ich für die Verwaltung und den 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.

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 (sshd, kann natürlich auch auf anderen Ports laufen) - 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, auch 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.

Zum Original geht es hier lang...