Tricks – {{TecBauer}}

DevOps, Docker, Kubernetes, Linux, Tricks Okt. 23,2019

TCPdump eines einzelnen Kubernetes Pods / Docker Containers erstellen

Manchmal ist es nötig die Netzwerkverbindung von nur genau einem Pod oder Container zu beobachten und zu analysieren. In der Regel laufen aber auf dem Host des Containers eine Vielzahl von Containern. Wie bekommt man nun den einzelnen Container seinem virtuellem Interface auf dem Host zugeordnet. Hier nur eine kleine Anleitung wie dies in den meisten Fällen möglich sein sollte. Gezeigt wird das ganze an Kubernetes.

Zuerst muss geprüft werden, mit welchem ifindex des Hosts, der Container, bzw. dessen zu prüfenden Interfaces verbunden sind. Konkret sieht das wie folgt aus. Wir lassen uns alle Interfaces des Containers anzeigen:

tecbauer@XELO:~$ kubectl exec -i pod-52ds-lfbxv -- ifconfig -a
eth0      Link encap:Ethernet  HWaddr B2:F2:50:32:70:1B  
          inet addr:100.96.5.50  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
          RX packets:518 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:765979 (748.0 KiB)  TX bytes:7462 (7.2 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:156923 errors:0 dropped:0 overruns:0 frame:0
          TX packets:156923 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:71332776 (68.0 MiB)  TX bytes:71332776 (68.0 MiB)

bzw. mit:

tecbauer@XELO:~$ kubectl exec -i pod-52ds-lfbxv -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if53: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 9001 qdisc noqueue state UP 
    link/ether b2:f2:50:32:70:1b brd ff:ff:ff:ff:ff:ff
    inet 100.96.5.50/24 scope global eth0
       valid_lft forever preferred_lft forever

Nun suchen wir das zu Überwachende Interface, in userem fall eth0. Hier fällt uns folgendes auf, das Interface heißt eth0@if53. Dieses if53 bedeutet, das Interface eth0 ist mit dem Hostinterface mit dem ifindex 53 verbunden. Wenn wir nur ifconfig zur Verfügung haben können wir das wie folgt herausfinden:

tecbauer@XELO:~$ kubectl exec -i pod-52ds-lfbxv -- cat /sys/class/net/eth0/iflink
53

Nun wissen wir, mit welchem Interface (kann auch virtuell) des Hosts der Container verbunden ist. Um herauszufinden wie dieses Interface heißt müssen wir uns per SSH mit dem entsprechendem Host des Containers verbinden. Hier führen wir dann folgende Kommando aus:

root@host:/home/admin# grep -r "53" /sys/class/net/*/ifindex
/sys/class/net/veth740b54a8/ifindex:53

Wir sehen nun, dass das Interface mit dem Index 53 veth740b54a8 heißt. Nun sind wir in der Lage mit tcpdump mitzuschneiden:

root@host: tcpdump -i veth740b54a8 -w record.pcap

Die entstandene Datei record.pcap können wir nun mit Wireshark analysieren.

von tecbauer

Bash, Linux, Tricks Okt. 16,2019

Kommando Multithreaded in der BASH ausführen

Heute möchte ich euch vorstellen, wie es möglich ist mehrere Kommandos multithreaded in der Bash auszuführen. Einen konkreten Anwendungsfall könnt ihr euch wie folgt vorstellen:

Ihr habt eine Liste mit IP-Adressen die ihr pingen wollt. Oder noch besser eine List mit Objekten, die ihr gegen einen Server mittels curl POSTen wollt. Oder klassisch eine Liste von URLs die ihr herunterladen wollt. Eine solche Liste könnte so aussehen:

tecbauer@XELO:/tmp$ cat urls.txt 
google.de
tecbauer.de
google.com
bing.de

Ganz simple könnte man jetzt hergehen, über jede Zeile der Datei iterieren und den Prozess mit & in den Hintergrund legen, z. B. so:

for i in $(cat urls.txt); do wget -O- $i &; done

Wie aber kontrollieren wir aber nun wie viele Threads gleichzeitig gestartet werden? – Gar nicht. Es wäre viel zu kompliziert eine Logik dafür in einem Terminal auf einen Rutsch einzutippen. Stattdessen benutzen wir das Kommando xargs und dessen Option -P mit dieser Option kann man angeben mit wie vielen Threads der std-input in xargs verabeitet werden soll. Das ganze würde dann so aussehen:

cat urls.txt | xargs -P 4 -i wget -O- {}

Wir arbeiten also die Liste mit insgesamt 4 Threads ab. Und laden die Ressourcen paralell herunter.

von tecbauer

Aliase, DevOps, Kubernetes, Tricks Okt. 11,2019

Versionsbefreite Kubernetes Deploymentfiles

Wer des Öfteren mit Kubernetes arbeitet, kennt sehr wahrscheinlich das folgende Problem:

Man hat initial an einer bestimmten Stelle, z.B. in einem Git-Repository Kubernetes Deploymentfiles in folgender Form erstellt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Im Laufe des Lebenszyklus eines Deployments ändert sich aber immer mal wieder die Version des Docker-Images. Diese wird dann z.B. folgendermaßen gesetzt:

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

Danach wird dann von Hand im besten Fall das Deploymentfile angepasst. Das Problem hierbei ist, wird vergessen das Deploymentfile anzupassen und ein Kollege (oder man selbst) verlässt sich darauf, das die Deploymentfiles immer aktuell sind, führt ein naives kubectl apply -f in machen Fällen dazu, dass eine unerwünschte Version deployed wird. Um dies zu verhindern habe ich folgenden BASH-Alias eingerichtet:

alias kubectla='f() { [ $# -eq 2 ] && for i in $(find ${2}); do sed s/=VERSION=/$1/g $i | kubectl apply -f -; done || echo -e "Wrong argument count!\ndo: kubectla  "; unset -f f; }; f'

Hinter dem Alias steckt eine Funktion, welche den Platzhalter =VERSION= in einer Datei ersetzt, bevor sie mit kubectl apply -f deployed wird. Die Deploymentfiles enthalten also in Zukunft keine explizite Version mehr, sondern lediglich unseren Platzhalter:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:=VERSION=
        ports:
        - containerPort: 80

Deployed wird dann mittels des Aliases kubectla

kubectla 1.91 nginx.yaml

Schon wird die entsprechende Version deployed und wir müssen uns in Zukunft keine Sorgen mehr machen, ob alle Versionen in unseren Deploymentfiles aktuell sind.

von tecbauer

Kategorie Tricks