Puncte:0

Cum se conectează interfețele Veth între ele pe o cutie Linux?

drapel in
JMC

Recent, m-am jucat cu clusterul Google Kubernetes Engine. Am o intrebare in legatura cu CNI-ul lor. Am citit din documentele GCP și din alte articole că există o punte la care se conectează toate interfețele. Practic, pentru fiecare container se creează o pereche veth. Un capăt al acestuia este în container, iar celălalt capăt al acestuia este conectat la un dispozitiv de punte. Când containerele de pe același nod comunică între ele, schimbul de pachete folosește dispozitivul de tip punte de nivel 2. Acesta este și modul în care documentația GKE descrie.

https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview#pods

https://medium.com/cloudzone/gke-networking-options-explained-demonstrated-5c0253415eba

Am creat un cluster pe Google, văd că există un dispozitiv bridge docker0, dar nu există interfețe asociate cu acesta.

gke-xxxxxxxxx /home/uuuuuuu # brctl show
numele podului ID pod Interfețe activate STP
docker0 8000.0242fd0b0cf4 nr      
gke-xxxxxxxxxx /home/uuuuuuu # 

Apoi am creat un cluster folosind Virtualbox, pot vedea că interfețele sunt asociate cu dispozitivul bridge.

[root@k8s-2 ~]# brctl show
numele podului ID pod Interfețe activate STP
cni0 8000.36dae477639c nu veth7f6c1f01
                                        vethccd0d71d
                                        vethe63e4285

Ceea ce încerc să raționez este de ce nu pot găsi dispozitivul bridge pe mașinile virtuale Google? Există o caracteristică specială a Linux Kernel utilizată în acest scenariu?

Când inspectez fiecare interfață veth pe Google VM, toate au aceeași adresă IP 10.188.2.1

gke-xxxxxxxxxxxxxxxxxxxxx /home/user.name # ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
        inet 169.254.123.1 netmask 255.255.255.0 difuzare 169.254.123.255
        ether 02:42:fd:0b:0c:f4 txqueuelen 0 (Ethernet)
        Pachete RX 0 octeți 0 (0,0 B)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 0 octeți 0 (0,0 B)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.10.1.19 netmask 255.255.255.255 difuzare 0.0.0.0
        inet6 fe80::4001:aff:fe0a:113 prefixlen 64 scopeid 0x20<link>
        ether 42:01:0a:0a:01:13 txqueuelen 1000 (Ethernet)
        Pachete RX 2192921 octeți 1682211226 (1,5 GiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 1288701 octeți 468627202 (446,9 MiB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<gazdă>
        loop txqueuelen 1000 (Loopback local)
        Pachete RX 276348 octeți 153128345 (146,0 MiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 276348 octeți 153128345 (146,0 MiB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

veth27cee774: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 difuzare 10.188.2.1
        inet6 fe80::10b7:98ff:fe2f:2e08 prefixlen 64 scopeid 0x20<link>
        ether 12:b7:98:2f:2e:08 txqueuelen 0 (Ethernet)
        Pachete RX 32 octeți 2306 (2,2 KiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 10 octeți 710 (710,0 B)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

veth6eba4cdf: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 difuzare 10.188.2.1
        inet6 fe80::c4e3:b0ff:fe5f:63da prefixlen 64 scopeid 0x20<link>
        ether c6:e3:b0:5f:63:da txqueuelen 0 (Ethernet)
        Pachete RX 537091 octeți 138245354 (131,8 MiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 477870 octeți 122515885 (116,8 MiB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

veth8bcf1494: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 difuzare 10.188.2.1
        inet6 fe80::70cb:c4ff:fe8c:a747 prefixlen 64 scopeid 0x20<link>
        ether 72:cb:c4:8c:a7:47 txqueuelen 0 (Ethernet)
        Pachete RX 50 octeți 3455 (3,3 KiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 28 octeți 2842 (2,7 KiB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

vethbb2135c7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 difuzare 10.188.2.1
        inet6 fe80::1469:daff:fea0:8b5b prefixlen 64 scopeid 0x20<link>
        ether 16:69:da:a0:8b:5b txqueuelen 0 (Ethernet)
        Pachete RX 223995 octeți 82725559 (78,8 MiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 239258 octeți 60203574 (57,4 MiB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

vetheee4e8e3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
        inet 10.188.2.1 netmask 255.255.255.255 difuzare 10.188.2.1
        inet6 fe80::ec6c:3bff:fef3:70c2 prefixlen 64 scopeid 0x20<link>
        ether ee:6c:3b:f3:70:c2 txqueuelen 0 (Ethernet)
        Pachete RX 311669 octeți 40562747 (38,6 MiB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 304461 octeți 628195110 (599,0 MiB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

Ce se află în spatele acestor interfețe veth?

Mulțumesc anticipat

drapel vn
Al 2-lea document pe care l-ai legat nu explică asta? „Cu Calico, nu există o punte de rețea L2 în nod și, în schimb, rutarea L3 este folosită pentru tot traficul dintre poduri”
JMC avatar
drapel in
JMC
Multumesc Mark. Dacă vedeți exemplul meu, toate interfețele sunt prefixate cu veth în loc de cali. Clusterul meu nu folosește calico CNI.
Alex G avatar
drapel ar
Dacă doriți să vă uitați la pachetele care curg de la/către pod cidr, specificați cbr0, care este puntea Linux care are toate interfețele veth conectate la toate containerele. Utilizarea `tcpdump -i cbr0` ar putea ajuta la depanarea.
JMC avatar
drapel in
JMC
@AlexG Nu pare că există cbr0. Pot vedea doar două interfețe, dar nu și dispozitivul bridge, care este un mister. Oricum, ceea ce am aflat este că cbr0 există dacă folosesc o versiune mai veche. Am încercat versiunea 1.18-gke. Această versiune folosește docker ca timp de rulare a containerului și are dispozitivul cbr0. Începând cu 1.19.x-gke-xxxx, nodurile GKE folosesc containerd deoarece timpul de execuție și dispozitivul cbr0 nu mai este creat.
Puncte:1
drapel ar

Dacă bridge-ul are deja interfețe, The spectacol brctl comanda poate fi folosită pentru a vizualiza detaliile podului și interfeței unui nod. Se pare că nu ați introdus nicio interfață la bridge în situația dvs. Puteți adăuga interfețe la bridge cu sudo brctl addif docker0 veth0, și puteți primi toate detaliile esențiale despre pod și interfață într-un nod cu aceeași comandă. Verifica acest document pentru trimitere.

JMC avatar
drapel in
JMC
Cu un cluster complet funcțional, nu este necesar să adăugați veth0 la docker0. Acest lucru este deja gestionat atunci când este creat un nou pod. După cum am menționat în comentariul de mai sus, 1.18-gke este ultima versiune care încă folosește cbr0. Cred că rutarea pachetelor se face prin reguli de rutare. În 1.19.x, fiecare IP-ul pod are propria sa intrare în tabelul de rute.
Alex G avatar
drapel ar
Există pod-uri care au setat „hostNetwork” la false pe GKE 1.19?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.