Version [4392]
Dies ist eine alte Version von K3S erstellt von ErdaxoAdmin am 2023-02-18 14:50:32.
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 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
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 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
Auf dieser Seite sind keine Kommentare vorhanden
