Über die Zeit ergibt sich von selber ein gewisses Set an Commands, die das handling erleichtern. Mit dieser Übersicht teile ich nützliche und praktische kubernetes Kommandos, die meines Erachtens nach jeder neben den basic commands kennen sollte.
Weiterführende Links:
Kubectl Doku
Kubernetes Doku
set KUBECONFIG=D:\projekte\vqueue\cloud\clusters.kubeconfig
kubectl config current-context
kubectl config use-context test-cluster
Hierbei beachten, dass die Config immer global gesetzt wird. Das bedeutet, wenn man in verschiedenen Shells mit unterschiedlichen Clustern arbeiten möchte, dann wirkt sich das eben auch auf alle anderen Shells aus.Aktive Pod Shell Connections werden dagegen beim Config wechsel nicht unterbrochen.
Eine praktische und unabkömmliche Funktion. Ähnlich einem SSH Tunnel können auf diese Weise die Ports von Serivce aber auch Pods direkt auf die lokale Maschine weitergeleitet werden, so dass man per localhost zugreifen kann.
Zugriff auf POD
kubectl port-forward pods/my-test-9d54f48f4-rfnsd 8081:8081 -n my-test-space
Zugriff auf Service
kubectl port-forward services/my-test-service 8081:8081 -n my-test-space
Das Port Mapping folg diesem Patter: LOCAL_PORT:REMOTE_PORT
Anschließend kann man lokal die Ressource abfragen, wie als wenn der Zugriff im Kubernetes Network stattfindet.
wget localhost:8081
Die Kubernetes Doku erläutert das noch etwas genauer: Forward a local port to a port on the Pod
Um sich im Terminal eines laufenden Containers umzusehen folgendermaßen vorgehen:
kubectl exec -it my-test-5c4c4fd868-pzt9j sh -n my-test-space
In Sidecar Szenarios, also wenn ein Pod mehrere Container enthält, dann muss man diesen noch angeben, in den man sich verbinden möchte. Macht man das nicht, dann verbindet Kubernetes in einen Default Container. Man erhält dann allerdings eine Warning, dass mehrere Container vorhanden sind, inkl. eine Auflistung derer.
kubectl exec -it my-test-5c4c4fd868-pzt9j sh -c my-test-container -n my-test-space
Im Prinzip wird hier eine sh Shell gestartet. Abhängig von den verwendeten Containern kann das auch /bin/ash oder /bin/bash richtig sein. Alternativ könnte man auch jedes andere beliebige im Container bekannte Kommando angeben.
Es bleibt nicht aus, dass man mal was aus einem Container rauskopieren möchte. Ähnlich wie bei Docker gibt es dafür einen handlichen Befehl:
kubectl cp my-test-space/my-test-9d54f48f4-cjfmk:/data/logs /pod_logs -c my-test
Hier wird quasi der genaue Ort der Quelldateien mittels Namespace und POD ID angegeben, gefolgt vom internen File-Path. Handelt es sich um ein Sidecar-Kondtrukt, muss man auch hier den gewünschten Container angeben.
In die andere Richtung funktioniert das auch, genau umgekehrt:
kubectl cp /pod_logs my-test-space/my-test-9d54f48f4-cjfmk:/data/logs -c my-test
Man darf dabei aber nicht vergessen, dass alles was man in den laufenden Container kopiert weg ist, wenn der POD durchgestartet wird. Es sei denn, dass Zielverzeichnis ist seinerseits wieder ein Volume Mount.
An dieser Stelle sei auch wieder auf die Kubernetes Doku verwiesen.
Auch ein Hack, aber manchmal einfach notwendig um die Anwendung zu rebooten:
Stoppen
kubectl scale deploy my-test --replicas=0 -n my-test-space
Starten
kubectl scale deploy my-test --replicas=1 -n my-test-space
All-In One
kubectl scale deploy my-test --replicas=0 -n my-test-space && kubectl scale deploy my-test --replicas=1 -n my-test-space
Wenn ein Pod im Status TERMINATING scheinbar hängen bleibt, dann gibt es nur noch eine Möglichkeit
kubectl delete pod my-test-6b79688c8-w6k96 -n my-test-space --force --grace-period=0
Ist natürlich nicht ganz so elegant, und man sollte dann auch mal schauen, warum dies passiert. Aber es funktioniert.
