Basis-Befehle

Hier eine Sammlung nützlicher CLI Befehle, die immer wieder mal gebraucht werden.

Befehle zu Pods

einen Pod starten

kubectl [-n namespace] run <Pod/Container> --image=<Image:Tag> [--rm] -it [--command --] <Command> [<ARG> ...]
# sich wieder verbinden
kubectl [-n namespace] attach <Pod> -c <Container> -it
#
# wieder entfernen
kubectl [-n namespace] delete pod <Pod>

Beispiel:

kubectl -n development run testcont --image=debian:stable-slim -it bash
kubectl -n development attach testcont -c testcont -it

kubectl -n development delete pod testcont

Befehl oder Konsole auf bestehenden Pod ausführen

kubectl [-n namespace] exec [-it] <Pod> -- <Command>

Beispiel:

# Pod starten mit einem endlosen Prozess:
kubectl -n development run testcont --image=debian:stable-slim sleep infinity
# Bash im Pod ausführen:
kubectl -n development exec -it testcont -- bash

Pod oder Service mit Forwarding erreichen

Port-Forwarding wird zur Zeit nur für TCP unterstützt - UDP ist in der Community hierfür noch in der Diskussion - siehe: https://github.com/kubernetes/kubernetes/issues/47862

# Port-Forwarding zu einem Service
kubectl [-n namespace] port-forward service/<Service-Name im Namespace> [<lokaler Port>]:<Service-Port>

# Port-Forwarding zu einem Deployment
kubectl [-n namespace] port-forward deployments/<Deployment-Name im Namespace> [<lokaler Port>]:<Service-Port>
# oder Statefullset
kubectl [-n namespace] port-forward statefulsets/<Deployment-Name im Namespace> [<lokaler Port>]:<Service-Port>
# oder Daemonset
kubectl [-n namespace] port-forward daemonsets/<Deployment-Name im Namespace> [<lokaler Port>]:<Service-Port>

# Port-Forwarding direkt zu einem Pod
kubectl [-n namespace] get pods      # wird zur Ermittlung des Pod-Namens gebraucht
kubectl [-n namespace] port-forward pods/<Pod-Name im Namespace> [<lokaler Port>]:<Service-Port>

Wenn die Angabe eines lokalen Ports weg gelassen wird, dann wird ein zufälliger freier Port auf dem lokalen System eingesetzt - dieser wird bei dem Kommando zum Forwarding angezeigt.

Beispiele:

user@local : ~ $ kubectl -n mydbs port-forward services/mydbadmin 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
...

Der Service wäre in dem Beispiel unter http://localhost:8080/ erreichbar.

Gleiche App, aber via Deployment mit zufälligem lokalen Port:

user@local : ~ $ kubectl -n mydbs port-forward deployments/phpmyadmin :80
Forwarding from 127.0.0.1:50137 -> 80
Forwarding from [::1]:50137 -> 80
...

Hier ist die Applikation nun im Browser mit http://localhost:50137/ erreichbar.

Deployment bearbeiten

Hier und da will man ein Deployment nicht neu ausrollen, aber dennoch "Korrekturen" einsetzen.

Rolling Update

Einen Restart eines Deployments erwirken:

kubectl [-n namespace] rollout restart deployment|statefulset|daemonset <Deploy-Name>

Falls bei dem Container "imagePullPolicy" auf "Always" gesetzt ist, wird dadurch u.a. das erneute Downloaden des Images bewirkt.

Rollback

Es besteht die Möglichkeit auf ein Rollback eines Deployments.

kubectl [-n namespace] rollout undo deployment|statefulset|daemonset <Deploy-Name> [--to-revision=<Revisions-Nummer>]

Ohne Angabe einer Revisions-Nummer wird auf die vorherige Revision zurückgesetzt.

Die Revisions-Nummern können mit einer Historie abgefragt werden:

kubectl [-n namespace] rollout history deployment|statefulset|daemonset <Deploy-Name>

Der Inhalt kann dann mit Angabe der Revisions-Nummer in einem entsprechenden Format angezeigt werden. (Im folgenden Beispiel als YAML.)

kubectl [-n namespace] rollout history deployment|statefulset|daemonset <Deploy-Name> --revision=<RevNr> -o yaml

Update durch Patchen des Image-Tags

Um ein aktuelles oder bestimmtes Image zu laden und dabei ebenfalls einen Neustart des Deployments zu erwirken, reicht es auch das Tag/Label des Container-Images zu ändern - mit einem sog. Patch:

kubectl [-n <namespace>] patch deployment|statefulset|daemonset <Deploy-Name> -p '{"spec": {"template": {"spec":{"containers":[{"name": "<Container-Name>", "image":"<Registry>/<Path>/<Image>:<Tag>"}]}}}}'

Anzahl der Pods in einem Deployment ändern

Um beispielsweise schnell mal auf Last-Spitzen reagieren zu können:

kubectl [-n <namespace>] scale --replicas <Anzahl> deployment|statefulset <Deploy-Name>

Node Labels und Taints

Wenn nicht bereits bei der Installation des Node-Systems mit angegeben (und somit fest), können Labels und Taints manuell für Nodes erstellt werden.

Node-Labels

generell gilt:

kubectl label node <Node-Name> <Label-Key>=<Label-Value>
# wieder zu entfernen:
kubectl label node <Node-Name> <Label-Key>-

Beispiel für eine Node-Rolle:

kubectl label node <Node-Name> node-role.kubernetes.io/work-plane=true
# wieder zu entfernen:
kubectl label node <Node-Name> node-role.kubernetes.io/work-plane-

Beispiel für ein beliebiges Node-Label:

kubectl label node <Node-Name> tier=frontend
# wieder zu entfernen:
kubectl label node <Node-Name> tier-

Taints

Mit Taints kann bestimmt werden, welche Pods auf einem Node laufen soll(t)en (oder auch nicht).

kubectl taint node <Nodename> <Key>=<Value>:<Effekt>
# wieder entfernen:
kubectl taint node <Nodename> <Key>=<Value>:<Effekt>-

Ein Nebeneffekt ist auch ein "Freiräumen" z.B. für Wartungsarbeiten:

kubectl taint node mynode2 maintenance=true:NoSchedule  # damit kein weiterer Pod hier erstellt wird
kubectl taint node mynode1 maintenance=true:NoExecute   # um alle Pods von dem Node herunter zu nehmen