Installation
Voraussetzungen
- – 2-3 Virtuelle Maschinen für die Master- und Worker-Nodes mit mindestens 2GB Arbeitsspeicher und 2 CPU-Kernen
- – Eine abgeschlossene Installation von Debian 10 auf jeder der VMs ohne SWAP Partition
- – SSH Zugang zu jeder VM
- – Ein angelegtes Benutzerkonto, sowie Zugriff auf root auf jeder VM
- – Alle VMs müssen im selben Netzwerk sein und Zugriff zum Internet haben um sich gegenseitig erreichen zu können
Vorbereitungen
Diese Schritte müssen auf allen Servern ausgeführt werden, unabhängig davon, ob sie nun später die Master-Node werden oder nur normale Worker-Nodes!
Zuerst generell alle Repositories aktualisieren und installierte Packages updaten:
apt update && apt upgradeDanach müssen einige Standard Programme installiert werden, welche im Betrieb und bei der weiteren Installation benötigt werden:
apt install -y htop vim net-tools open-vm-tools curlBevor wir mit der Installation von Kubernetes anfangen, müssen wir schauen, dass das Modul br_netfilter geladen wurde. Dies ist notwendig, damit die IP-Tables den bridged traffic richtig sehen können.
modprobe br_netfilterNun folgende Commands ausführen, damit die IP Tables den bridged traffic sehen können:
cat <<EOF > /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF sysctl --systemDanach müssen die verschiedenen Tabellen für IP, ARP, etc. installiert werden:
apt-get install -y iptables arptables ebtablesUnd die gerade installierten Tabellen werden nun hiermit in den Legacy Modus versetzt, welcher für Kubernetes wichtig ist:
update-alternatives --set iptables /usr/sbin/iptables-legacy update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy update-alternatives --set arptables /usr/sbin/arptables-legacy update-alternatives --set ebtables /usr/sbin/ebtables-legacyNachdem all die vorherigen Schritte abgeschlossen wurden, müssen nun nur noch einige Dependencies für Kubernetes und Docker installiert werden:
apt-get update && apt-get install -y \ apt-transport-https ca-certificates software-properties-common gnupg2
Hauptinstallation von Kubernetes und Docker
Diese Schritte müssen auf allen Servern ausgeführt werden, unabhängig davon, ob sie nun später die Master-Node werden oder nur normale Worker-Nodes!
Nun zur Installation von Docker, dem Container-System, welches Kubernetes verwalten und managen wird. Zuerst müssen wir den Repository Key herunterladen und installieren:
curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -Nachdem der Schlüssel installiert ist, müssen wir nur noch die Repository zum System hinzufügen:
add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable"Und danach nochmals alle Repositories updaten und Docker installieren:
apt-get update && apt-get install -y \ containerd.io=1.2.10-3 \ docker-ce=5:19.03.4~3-0~debian-$(lsb_release -cs) \ docker-ce-cli=5:19.03.4~3-0~debian-$(lsb_release -cs)Um die Kompatibilität zu Kubernetes sicher zu stellen, müssen noch ein paar Parameter zu Docker hinzugefügt werden, welche mit Hilfe dieses Commands erledigt werden können. Dieser Schritt ist wichtig, da Docker für Kubernetes SystemD benutzen muss:
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
Nun muss ein Ordner für den Service Daemon von Docker erstellt werden:
mkdir -p /etc/systemd/system/docker.service.dUnd danach müssen die Daemons, sowie Docker neu gestartet werden, um alle Änderungen zu übernehmen:
systemctl daemon-reload systemctl restart dockerZur Installation von Kubernetes selbst müssen nun folgende Commands ausgeführt werden. Diese Commands können direkt so zusammen in die SSH Session kopiert werden und ausgeführt werden, da in diesem Block der Repository Key, sowie die Repository selbst und die Installation alles in einem Durchgang ausgeführt werden.
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF | tee /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectlFalls bei der Installation von Debian doch eine Swap Partition erstellt wurde, muss diese für die Installation deaktiviert werden und später via der Datei /etc/fstab permanent deaktiviert werden, da Kubernetes nicht mit einem Swap funktioniert:
swapoff -a
Initialisierung der Master-Node
Die folgenden Schritte dürfen nur auf der Master-Node (der VM, die das Cluster managen soll) ausgeführt werden!
Mit diesem Command wird die Master-Node initiiert und der interne Netzwerkbereich für die Container eingerichtet. Die Netzwerkadresse und die Maske darf nicht verändert werden, da das CNI (Container Network Interface) sonst nicht funktioniert!
kubeadm init --apiserver-advertise-address=$(hostname -i) --apiserver-cert-extra-sans="192.168.124.19" --pod-network-cidr=10.244.0.0/16Nachdem das Setup abgeschlossen wurde, muss eine Zeile aus der Meldung am Ende kopiert werden, welche ungefähr wie folgt aussieht:
kubeadm join 192.168.124.19:6443 --token cpakpm.yjagao4t26yf9vn0 \
--discovery-token-ca-cert-hash sha256:3d2326443bb2d7d64c618481b7909a345117ee784eaa8f37550e2828ea5373e5
Diese Zeile ist wichtig, da diese für die Worker-Nodes benötigt wird, um diese mit der Master-Node zu verbinden. Danach muss dem bei der Installation von Debian eingerichteten User noch die Rechte für sudo geben (in diesem Beispiel heißt der User „mxp“)
usermod -aG sudo mxpund dann muss man sich als User anmelden
su mxpund folgenden Command Block ausführen:
mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config exit export KUBECONFIG=/etc/kubernetes/admin.confNun muss das zuvor genannte CNI installiert werden, ohne welches Kubernetes nicht funktionieren wird:
kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yamlWichtig! Falls bei einem Schritt nach der Installation von Kubernetes eine Meldung kommen sollte, dass keine Verbindung zu einer Localhost Adresse besteht, muss folgendes Command ausgeführt werden:
export KUBECONFIG=/etc/kubernetes/admin.confAls letzter Schritt muss nur noch folgende Zeile zu /etc/environment hinzugefügt werden:
KUBECONFIG=/etc/kubernetes/admin.confUnd danach den Server neu starten.
Initialisierung der Worker-Node
Nachdem die Master-Node neu gestartet wurde, kann man damit anfangen die Nodes mit der Master-Node zu verbinden mit Hilfe des Commands, welcher davor nach dem Setup kopiert wurde. Dieses Command muss nun auf den Worker-Nodes ausgeführt werden und nach Abschluss kann man auf der Master-Node mit Hilfe des Commands kubectl get nodes die Verbindung aller Nodes überprüfen.
Wichtig! Der Befehl aus dem Setup ist lediglich für 24 Stunden valide, wie man zu einem späteren Zeitpunkt noch weitere Nodes installiert, wird in einem anderen Kapitel erklärt!
Erstellung eines Auth-Tokens für neue Worker-Nodes
Erstellung der Token auf der Master-Node
Authentication Tokens, kurz Auth-Tokens laufen standardmäßig nach 24 Stunden aus, danach muss wieder ein neuer Token erstellt werden, um neue Nodes zum Kubernete Cluster hinzuzufügen. Dies geht wie folgt:
Zuerst wird ein neuer Token generiert mit Hilfe dieses Befehls:
kubeadm token createDer Output, welcher im Konsolenfenster nun angezeigt wird muss notiert werden, da er später benötigt wird. Der Output sollte ungefähr wie folgt aussehen:
5didvk.d09sbcov8ph2amjwNun muss nur noch der Zertifikats-Hash-Token ausgelesen werden. Dieser Token ändert sich nicht, sollte aber zur Sicherheit dennoch nur dann ausgelesen werden, wenn eine neue Worker-Node zum Cluster hinzugefügt werden soll. Der Befehl lautet wie folgt:
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \ openssl dgst -sha256 -hex | sed 's/^.* //'Der Output wird ungefähr wie folgt aussehen:
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
Einbindung einer neuen Worker-Node mit Hilfe des neuen Tokens
Um nun eine neue Node zum Cluster hinzuzufügen, müssen diese beiden Tokens lediglich in den Befehl aus der Installation von Kubernetes eingetragen werden:
kubeadm join 192.168.124.19:6443 --token [1. Generierter Token] \
--discovery-token-ca-cert-hash sha256:[Zertifikats-Hash-Token]
Auslesen von bereits aktiven Token auf der Master-Node
Das Auslesen von bereits aktiven, bzw. auch ausgelaufenen Token ist relativ einfach, dafür muss nur dieser Befehl ausgeführt werden, um eine Auflistung aller Token mit allen Informationen zu bekommen:
kubeadm token listDer Output sieht ungefähr aus wie folgt:
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system:
signing token generated by bootstrappers:
'kubeadm init'. kubeadm:
default-node-token
Entfernung einer Worker-Node aus dem Cluster
Zuerst muss man sich auf der Master-Node via SSH einloggen und nun folgende Befehle eingeben:
kubectl drain [Name der Worker-Node] --delete-local-data --force --ignore-daemonsets kubectl delete node [Name der Worker-Node]Den Namen aller Nodes findet man über den Befehl kubectl get nodes herraus. Hierbei haben die Nodes immer denselben Namen, wie auch der DNS-Name des Servers ist. Nun muss via SSH auf der Worker-Node noch Folgendes ausgeführt werden:
-
Um alle restlichen Elemente des Cluster auf der Node zu entfernen, bitte folgenden Befehl ausführen:
kubeadm reset
-
Danach müssen die IP-Tables und NAT Regeln zurückgesetzt werden. Dies geschieht via folgendem Befehl:
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
Generelle Informationen zur Funktionsweise von Kubernetes, sowie nützliche Befehle für die Administration von Kubernetes
Aufbau von Kubernetes
Ein Kubernetes Cluster ist generell relativ einfach aufgebaut.
An oberster Stelle steht immer die Master-Node (manchmal auch „Control Plane” genannt). Diese Node verwaltet das gesamte Cluster und kann auch für High-Availability konfiguriert werden. Auf dieser Node laufen keine anwendungsspezifischen Container, sondern nur Programme und Container, welche für die Verwaltung und Administration des gesamten Clusters notwendig sind. Die anwendungsspezifischen Container laufen auf den Worker-Nodes, welche der Master-Node unterstellt sind und von der Master-Node aus auch verwaltet werden. Im normalen Betrieb gibt es nur selten einen Fall, bei dem man direkt auf eine Worker-Node zugreift, da der Zugriff wenn dann von der Master-Node aus passiert.
Die Hierarchie wird auf den Worker Nodes nochmals erweitert, da die Pods selbst in verschiedene „Namespaces” unterteilt werden können, welche entweder vom Benutzer definiert oder vom System selbst vorgeschrieben werden (der Namespace für das Kubernetes Cluster lautet „kube-system”). Sollte bei der Erstellung eines Pods kein Namespace angegeben werden, wird der Pod in den sogenannten „default” Namespace gelegt, welcher standardmäßig benutzt wird, sofern kein anderer Namespace als Standard festgelegt wird. Die Pods selbst können wiederum mehrere Docker Container umfangen, allerdings kann man auch oftmals Pods finden, welche nur einen Container beinhalten.
An oberster Stelle steht immer die Master-Node (manchmal auch „Control Plane” genannt). Diese Node verwaltet das gesamte Cluster und kann auch für High-Availability konfiguriert werden. Auf dieser Node laufen keine anwendungsspezifischen Container, sondern nur Programme und Container, welche für die Verwaltung und Administration des gesamten Clusters notwendig sind. Die anwendungsspezifischen Container laufen auf den Worker-Nodes, welche der Master-Node unterstellt sind und von der Master-Node aus auch verwaltet werden. Im normalen Betrieb gibt es nur selten einen Fall, bei dem man direkt auf eine Worker-Node zugreift, da der Zugriff wenn dann von der Master-Node aus passiert.
Die Hierarchie wird auf den Worker Nodes nochmals erweitert, da die Pods selbst in verschiedene „Namespaces” unterteilt werden können, welche entweder vom Benutzer definiert oder vom System selbst vorgeschrieben werden (der Namespace für das Kubernetes Cluster lautet „kube-system”). Sollte bei der Erstellung eines Pods kein Namespace angegeben werden, wird der Pod in den sogenannten „default” Namespace gelegt, welcher standardmäßig benutzt wird, sofern kein anderer Namespace als Standard festgelegt wird. Die Pods selbst können wiederum mehrere Docker Container umfangen, allerdings kann man auch oftmals Pods finden, welche nur einen Container beinhalten.
Nützliche Befehle zur Administration von Kubernetes
| Befehl | Funktion |
|---|---|
| kubeadm | Zur Initialisierung und Einrichtung eines Kubernetes Clusters |
| kubectl | Mit diesem Befehl kann man das gesamte Cluster verwalten und managen |
| kubectl get pods –all-namespaces | Zeigt alle vorhanden Pods im Cluster aus allen Namespaces |
| kubectl get pods –all-namespaces -o wide | Zeigt alle vorhanden Pods im Cluster aus allen Namespaces inklusive Informationen, wie z.B. auf welcher Node sich der Pod befindet, die Laufzeit, etc. |
| kubectl logs [pod_name] -n [namespace_name] (-c [container_name]) | Zeigt die logs eines ausgewählten Pods in einem Namespace (bei mehreren Containern innerhalb eines Pods muss der Container Name auch angegeben werden) |
| kubectl describe nodes [node_name] | Zeigt Details und die Logs einer ausgewählten Node |
| kubectl describe pod [pod_name] | Zeigt Details und die Logs eines ausgewählten Pods |
Für weitere nützliche Befehle gibt es das offizielle Cheat Sheet von Kubernetes selbst:
https://kubernetes.io/de/docs/reference/kubectl/cheatsheet/
