Kubernetes mit k3s
die leichtgewichtige Variante
A. Unsere Landschaft:
3x debian VM... (IP 186, 187, 188)
B. Probleme im Umgang mit YAML-Dateien
Bereits frühzeitig beim Lernen von k8s haben sich die YAML-Dateien als widerspenstig gezeigt - hier einige Hinweise, wenn Probleme auftreten:
1. Doppelpunkt (":") fehlt
error: error loading config file ".../.kube/config": yaml: line 21: could not find expected ':'
# dies betraf Zeilen mit Schlüsseln, die durch den Texteditor jeweils in Folgezeilen
# geschoben wurden; die Schlüssel-Zeichenketten müssen aber in der Zeile hinter der
# Bezeichnung und ":" beginnen, also so:
client-certificate-data: LS0tLS1CRUdJ...
# und nicht so:
client-certificate-data:
LS0tLS1CRUdJ...
# dies betraf Zeilen mit Schlüsseln, die durch den Texteditor jeweils in Folgezeilen
# geschoben wurden; die Schlüssel-Zeichenketten müssen aber in der Zeile hinter der
# Bezeichnung und ":" beginnen, also so:
client-certificate-data: LS0tLS1CRUdJ...
# und nicht so:
client-certificate-data:
LS0tLS1CRUdJ...
2. Credentials (Anmeldungsdaten) funktionieren nicht
# bei Ausführung von
kubectl
kubectl get nodes
# mit übernommenen Zertifikaten / Schlüsseln vom Cluster-Server darf eigentlich keine
# Benutzerabfrage mehr erfolgen, wenn alles OK ist;
# wenn der Benutzername aber abgefragt wird, dann ist in der Zuordnung von "context"
# und "user" etwas schief gegangen; dann ist zu prüfen, ob Folgendes stimmt:
# welchem cluster ist welcher context zugeordnet:
clusters:
- cluster:
...(u. a. muss hier certificate-authority-data: ... stehen)
name: <clustername>
# nun context:
contexts:
- context:
cluster: <clustername>
user: <username>
name: <contextname>
# und auch Benutzer (user) muss stimmen
users:
- name: <username>
user:
client-certificate-data: (...)
client-key-data: (...)
kubectl
kubectl get nodes
# mit übernommenen Zertifikaten / Schlüsseln vom Cluster-Server darf eigentlich keine
# Benutzerabfrage mehr erfolgen, wenn alles OK ist;
# wenn der Benutzername aber abgefragt wird, dann ist in der Zuordnung von "context"
# und "user" etwas schief gegangen; dann ist zu prüfen, ob Folgendes stimmt:
# welchem cluster ist welcher context zugeordnet:
clusters:
- cluster:
...(u. a. muss hier certificate-authority-data: ... stehen)
name: <clustername>
# nun context:
contexts:
- context:
cluster: <clustername>
user: <username>
name: <contextname>
# und auch Benutzer (user) muss stimmen
users:
- name: <username>
user:
client-certificate-data: (...)
client-key-data: (...)
Wenn die Zuordnung stimmt, wird nicht mehr nach Benutzer gefragt, sondern kubectl direkt ausgeführt - bezogen auf den unter <cluster> genannten Server!
C. Kleines Befehlsvokabular
# proxy für die Anzeige einschalten (noch Klärungsbedarf...)
k3s kubectl proxy
# alle nodes des Systems mit grundlegenden Eigenschaften auflisten:
kubectl get nodes
# Namen der Cluster aufführen (bei uns: erst mal einer - default)
kubectl config get-clusters
# zeige alle pods (Funktionen) im Cluster
kubectl get pods -n kube-system
# zeige pods mit etwas mehr Daten (IPs etc.)
kubectl get pods -o wide
# zeige alle Netzwerkschnittstellen im Cluster mit ihren IP-s
kubectl get endpoints [-n kube-system]
# was "namespaces" sind, muss ich noch rauskriegen...
kubectl get namespaces
# dem node eine Bezeichnung "worker" zuweisen
kubectl label node <node-name> node-role.kubernetes.io/worker=worker
# Leichen muss man auch mal beseitigen:
kubectl delete pod my-pod
kubectl delete service my-service
k3s kubectl proxy
# alle nodes des Systems mit grundlegenden Eigenschaften auflisten:
kubectl get nodes
# Namen der Cluster aufführen (bei uns: erst mal einer - default)
kubectl config get-clusters
# zeige alle pods (Funktionen) im Cluster
kubectl get pods -n kube-system
# zeige pods mit etwas mehr Daten (IPs etc.)
kubectl get pods -o wide
# zeige alle Netzwerkschnittstellen im Cluster mit ihren IP-s
kubectl get endpoints [-n kube-system]
# was "namespaces" sind, muss ich noch rauskriegen...
kubectl get namespaces
# dem node eine Bezeichnung "worker" zuweisen
kubectl label node <node-name> node-role.kubernetes.io/worker=worker
# Leichen muss man auch mal beseitigen:
kubectl delete pod my-pod
kubectl delete service my-service
D. Cookbook
An dieser Stelle werden Befehle in entsprechender Reihenfolge gesammelt, die zur Erledigung von konkreten Aufgaben mit k8s (k3s) durchzugehen sind:
1. Einfachen Kubernetes Cluster anlegen
(der Artikelreihe bei ct folgend)
Basiert auf 3 VMs - Ubuntu 20.04 LTS oder debian.
VMs haben aufeinanderfolgende IP-s = 10.1.0.186 .187 .188
#### Vorbereitungen (start ohne traefik)
# auf jedem NODE
mkdir -p /etc/rancher/k3s/
nano /etc/rancher/k3s/config.yaml
# in der Datei nur eine Zeile einstellen:
disable: traefik
# auf dem ersten NODE:
curl -sfL https://get.k3s.io | sh -s - server --cluster-init
# test, ob alles läuft:
kubectl get nodes
# andere Mitglieder (NODEs) vorbereiten:
cat /var/lib/rancher/k3s/server/token
# (Zeichenkette kopieren) - zu den übrigen zwei übergehen und ausführen:
curl -sfL https://get.k3s.io | K3S_TOKEN=<Token> sh -s - server --server https://<IP Server 1>:6443
# statt <TOKEN> die o. g. Zeichenkette einfügen
# statt <IP Server 1> die IP des ersten NODE eingeben
# ACHTUNG: zwischen den NODEs müssen PORTs offen sein: 6443, 2379, 2380
#### Steuerungszentrale einrichten:
# auf einem mac (über homebrew):
brew install kubernetes-cli
# auf debian:
apt install kubectl
# auf den MASTER-nodes Daten für Verbindung holen:
cat /etc/rancher/k3s/k3s.yaml
# bei Problemen [[http://www.erdaxo.de/K3S#section_4 siehe oben]]!
# so auch den Kontext herstellen in der yaml und einstellen - auf der Steuerzentrale:
kubectl config use-context <contextname>
# auf jedem NODE
mkdir -p /etc/rancher/k3s/
nano /etc/rancher/k3s/config.yaml
# in der Datei nur eine Zeile einstellen:
disable: traefik
# auf dem ersten NODE:
curl -sfL https://get.k3s.io | sh -s - server --cluster-init
# test, ob alles läuft:
kubectl get nodes
# andere Mitglieder (NODEs) vorbereiten:
cat /var/lib/rancher/k3s/server/token
# (Zeichenkette kopieren) - zu den übrigen zwei übergehen und ausführen:
curl -sfL https://get.k3s.io | K3S_TOKEN=<Token> sh -s - server --server https://<IP Server 1>:6443
# statt <TOKEN> die o. g. Zeichenkette einfügen
# statt <IP Server 1> die IP des ersten NODE eingeben
# ACHTUNG: zwischen den NODEs müssen PORTs offen sein: 6443, 2379, 2380
#### Steuerungszentrale einrichten:
# auf einem mac (über homebrew):
brew install kubernetes-cli
# auf debian:
apt install kubectl
# auf den MASTER-nodes Daten für Verbindung holen:
cat /etc/rancher/k3s/k3s.yaml
# bei Problemen [[http://www.erdaxo.de/K3S#section_4 siehe oben]]!
# so auch den Kontext herstellen in der yaml und einstellen - auf der Steuerzentrale:
kubectl config use-context <contextname>
2. Erstes "deployment"
Basiert auf auf den 3 VMs wird eine Verteilung des pods erreicht, die automatisch für Verfügbarkeit sorgt.
Basiert auf auf den 3 VMs wird eine Verteilung des pods erreicht, die automatisch für Verfügbarkeit sorgt.
#### die yaml-Datei ist anzupassen:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-first-nginx-deployment
labels:
app: my-nginx
spec:
replicas: 3
selector:
matchLabels:
app: my-nginx
template:
metadata:
labels:
app: my-nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
# mit "replicas: 3" steht hier nun, dass es 3 Kopien des pods geben soll...
## ACHTUNG: auch nur geringfügige Änderungen der Einrückung hatten bei mir Fehler zur Folge!
# die o. g. Datei als "first_deployment.yml" in cluster schieben:
kubectl -f first_deployment.yml apply
# anschließend kann es skaliert werden:
kubectl scale deployment/my-first-nginx-deployment --replicas=5
# allerdings ist dieser Weg nicht zu empfehlen - besser (dauerhafter) ist die
# Anpassung in der yaml-Datei, weil sie dann nachvollziehbar und fest ist;
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-first-nginx-deployment
labels:
app: my-nginx
spec:
replicas: 3
selector:
matchLabels:
app: my-nginx
template:
metadata:
labels:
app: my-nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
# mit "replicas: 3" steht hier nun, dass es 3 Kopien des pods geben soll...
## ACHTUNG: auch nur geringfügige Änderungen der Einrückung hatten bei mir Fehler zur Folge!
# die o. g. Datei als "first_deployment.yml" in cluster schieben:
kubectl -f first_deployment.yml apply
# anschließend kann es skaliert werden:
kubectl scale deployment/my-first-nginx-deployment --replicas=5
# allerdings ist dieser Weg nicht zu empfehlen - besser (dauerhafter) ist die
# Anpassung in der yaml-Datei, weil sie dann nachvollziehbar und fest ist;
3. Das "deployment" optimieren
Damit Updates und Änderungen nicht auf einen Schlag passieren, sondern für den Benutzer durch fließenden Übergang unsichtbar bleiben.
E. LinksammlungDamit Updates und Änderungen nicht auf einen Schlag passieren, sondern für den Benutzer durch fließenden Übergang unsichtbar bleiben.
# in der yaml-Datei bei "spec" bei "deployment" (nicht "template"!) einfügen:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 50%
maxSurge: 1
[...]
# Beobachtung der Funktionsweise mit "watch"-Schalter:
kubectl get pods -w
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 50%
maxSurge: 1
[...]
# Beobachtung der Funktionsweise mit "watch"-Schalter:
kubectl get pods -w
Einige weiterführende Links:
- docs von k3s selbst => https://docs.k3s.io
- gute Erklärung für einen Start mit K3S:
sonstige Quellen:
=> https://andrewmunro.me/posts/2021/08/creating-a-k3s-cluster-on-debian-11-bullseye-step-1-provision/
=> https://blog.alexellis.io/bare-metal-kubernetes-with-k3s/
=> https://www.teqqy.de/k3s-cluster-installieren-mit-metallb-und-traefik/
Auf dieser Seite sind keine Kommentare vorhanden
