Verlauf der Änderungen der Seite K3S
Hinzugefügt:
# Anpassung in der yaml-Datei, weil sie dann nachvollziehbar und fest ist;
Gelöscht:
Hinzugefügt:
# allerdings ist dieser Weg nicht zu empfehlen - besser (dauerhafter) ist die
Anpassung in der yaml-Datei, weil sie dann nachvollziehbar und fest ist;
Anpassung in der yaml-Datei, weil sie dann nachvollziehbar und fest ist;
Gelöscht:
Hinzugefügt:
# Leichen muss man auch mal beseitigen:
kubectl delete pod my-pod
kubectl delete service my-service
kubectl delete pod my-pod
kubectl delete service my-service
Hinzugefügt:
((2)) Das "deployment" optimieren
Damit Updates und Änderungen nicht auf einen Schlag passieren, sondern für den Benutzer durch fließenden Übergang unsichtbar bleiben.%%(perl)
# in der yaml-Datei bei "spec" bei "deployment" (nicht "template"!) einfügen:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 50%
maxSurge: 1
[...]
# Beobachtung der Funktionsweise mit "watch"-Schalter:
kubectl get pods -w
Damit Updates und Änderungen nicht auf einen Schlag passieren, sondern für den Benutzer durch fließenden Übergang unsichtbar bleiben.%%(perl)
# in der yaml-Datei bei "spec" bei "deployment" (nicht "template"!) einfügen:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 50%
maxSurge: 1
[...]
# Beobachtung der Funktionsweise mit "watch"-Schalter:
kubectl get pods -w
Hinzugefügt:
# allerdings ist dieser Weg nicht zu empfehlen - besser (dauerhafter) ist die Anpassung in der yaml-Datei, weil sie dann nachvollziehbar und fest ist;
Hinzugefügt:
((2)) Erstes "deployment"
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
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
Hinzugefügt:
# zeige pods mit etwas mehr Daten (IPs etc.)
kubectl get pods -o wide
kubectl get pods -o wide
Hinzugefügt:
Einige weiterführende Links:
Hinzugefügt:
((1)) Linksammlung
- docs von k3s selbst => https://docs.k3s.io
- gute Erklärung für einen Start mit K3S:
=> https://computingforgeeks.com/how-to-deploy-lightweight-kubernetes-cluster-with-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/
- docs von k3s selbst => https://docs.k3s.io
- gute Erklärung für einen Start mit K3S:
=> https://computingforgeeks.com/how-to-deploy-lightweight-kubernetes-cluster-with-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/
Hinzugefügt:
# so auch den Kontext herstellen in der yaml und einstellen - auf der Steuerzentrale:
kubectl config use-context <contextname>
kubectl config use-context <contextname>
Hinzugefügt:
# bei Problemen [[http://www.erdaxo.de/K3S#section_4 siehe oben]]!
Gelöscht:
Hinzugefügt:
(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:
# 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
# auf den MASTER-nodes Daten für Verbindung holen:
cat /etc/rancher/k3s/k3s.yaml
# bei Problemen siehe oben!
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:
# 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
# auf den MASTER-nodes Daten für Verbindung holen:
cat /etc/rancher/k3s/k3s.yaml
# bei Problemen siehe oben!
Gelöscht:
Hinzugefügt:
#### Steuerungszentrale einrichten:
# auf einem mac (über homebrew):
# auf debian:
# auf einem mac (über homebrew):
# auf debian:
Gelöscht:
// auf einem mac (über homebrew):
// auf debian:
Hinzugefügt:
((1)) Cookbook
An dieser Stelle werden Befehle in entsprechender Reihenfolge gesammelt, die zur Erledigung von konkreten Aufgaben mit k8s (k3s) durchzugehen sind:
((2)) Einfachen Kubernetes Cluster anlegen
(der Artikelreihe bei ct folgend)%%(perl)
# Steuerungszentrale einrichten:
// auf einem mac (über homebrew):
brew install kubernetes-cli
// auf debian:
apt install kubectl
An dieser Stelle werden Befehle in entsprechender Reihenfolge gesammelt, die zur Erledigung von konkreten Aufgaben mit k8s (k3s) durchzugehen sind:
((2)) Einfachen Kubernetes Cluster anlegen
(der Artikelreihe bei ct folgend)%%(perl)
# Steuerungszentrale einrichten:
// auf einem mac (über homebrew):
brew install kubernetes-cli
// auf debian:
apt install kubectl
Hinzugefügt:
# 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:
# 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:
# geschoben wurden; die Schlüssel-Zeichenketten müssen aber in der Zeile hinter der
# Bezeichnung und ":" beginnen, also so:
# 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:
Gelöscht:
# 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:
Hinzugefügt:
Wenn die Zuordnung stimmt, wird nicht mehr nach Benutzer gefragt, sondern ##kubectl## direkt ausgeführt - bezogen auf den unter ##<cluster>## genannten Server!
Gelöscht:
Hinzugefügt:
user: <username>
- name: <username>
Wenn die Zuordnung stimmt, wird nicht mehr nach Benutzer gefragt, sondern ##kubectl## direkt ausgeführt - bezogen auf den unter <cluster> genannten Server!
- name: <username>
Wenn die Zuordnung stimmt, wird nicht mehr nach Benutzer gefragt, sondern ##kubectl## direkt ausgeführt - bezogen auf den unter <cluster> genannten Server!
Gelöscht:
- name: <**username**>
Hinzugefügt:
user: <**username**>
- name: <**username**>
- name: <**username**>
Gelöscht:
- name: <username>
Hinzugefügt:
((2)) Credentials (Anmeldungsdaten) funktionieren nicht
# bei Ausführung von
kubectl
# 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: (...)
# bei Ausführung von
kubectl
# 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: (...)
Hinzugefügt:
client-certificate-data: LS0tLS1CRUdJ...
# und nicht so:
client-certificate-data:
LS0tLS1CRUdJ...
# und nicht so:
client-certificate-data:
LS0tLS1CRUdJ...
Gelöscht:
Hinzugefügt:
%%(perl)
# 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
# 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
Gelöscht:
Hinzugefügt:
3x debian VM... (IP 186, 187, 188)
((1)) 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:
((2)) Doppelpunkt (":") fehlt
%%(yaml)
error: error loading config file ".../.kube/config": yaml: line 21: could not find expected ':'
((1)) 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:
((2)) Doppelpunkt (":") fehlt
%%(yaml)
error: error loading config file ".../.kube/config": yaml: line 21: could not find expected ':'
Hinzugefügt:
# proxy für die Anzeige einschalten (noch Klärungsbedarf...)
# alle nodes des Systems mit grundlegenden Eigenschaften auflisten:
# Namen der Cluster aufführen (bei uns: erst mal einer - default)
# zeige alle pods (Funktionen) im Cluster
# zeige alle Netzwerkschnittstellen im Cluster mit ihren IP-s
# was "namespaces" sind, muss ich noch rauskriegen...
# alle nodes des Systems mit grundlegenden Eigenschaften auflisten:
# Namen der Cluster aufführen (bei uns: erst mal einer - default)
# zeige alle pods (Funktionen) im Cluster
# zeige alle Netzwerkschnittstellen im Cluster mit ihren IP-s
# was "namespaces" sind, muss ich noch rauskriegen...
Gelöscht:
# Funktionen im Cluster anzeigen:
