Puncte:1

Timeouts rețeaua Docker atunci când utilizați bridge

drapel vn

Rulez pe un server dedicat âcu versiunea Ubuntu 20.04.3 LTS (nucleu 5.4.0-96-generic) și Docker 20.10.7, build 20.10.7-0ubuntu5~20.04.2. Sistemul este o instalare proaspătă.

Am un Dockerfile pentru unul dintre serviciile mele, care atrage câteva biblioteci cu apt și du-te și ia. Unul dintre containerele intermediare nu reușește întotdeauna să se conecteze la internet cu erori DNS sau TCP Timeout. Care dintre containere eșuează este complet aleatoriu.

De asemenea, rețineți că problema nu este cu un serviciu specific, am încercat să construiesc un serviciu complet diferit care rulează pe NodeJS și instalare npm a esuat cu aceleasi erori

Astăzi am avut și problema cu care containerul meu Nginx nu era accesibil. Toate conexiunile la acesta au dus la erori de timeout.

De asemenea, conexiunile dintre containere care folosesc rețele docker nu funcționează corect.

Alergare sudo systemctl restart docker rezolvă temporar problema, dar reapar una sau două versiuni pe linie. Când construiesc cu gazdă de rețea în loc de rețeaua de punte implicită, problema a dispărut, motiv pentru care am suspectat o configurație de punte defectuoasă.

Am încercat să reinstalez Docker, să resetez iptables și configurațiile bridge, să setez diferite servere DNS, fără niciun rezultat. Fișierele jurnal docker nu prezintă erori.

Care ar putea fi cauza acestei probleme?

Actualizați:

Am dezactivat UFW, dar nu am avut succes. Aceasta este o descărcare din jurnalul meu dmesg în timpul unei build care a expirat, poate că acest lucru ajută la identificarea cauzei:

[758001.967161] docker0: portul 1(vethd0c7887) a intrat în starea de blocare
[758001.967165] docker0: portul 1(vethd0c7887) a intrat în starea dezactivată
[758001.967281] dispozitivul vethd0c7887 a intrat în modul promiscuu
[758002.000567] IPv6: ADDRCONF(NETDEV_CHANGE): veth7e3840a: linkul devine gata
[758002.000621] IPv6: ADDRCONF(NETDEV_CHANGE): vethd0c7887: linkul devine gata
[758002.000644] docker0: portul 1(vethd0c7887) a intrat în starea de blocare
[758002.000646] docker0: portul 1(vethd0c7887) a intrat în starea de redirecționare
[758002.268554] docker0: portul 1(vethd0c7887) a intrat în starea dezactivată
[758002.269581] eth0: redenumit din veth7e3840a
[758002.293056] docker0: portul 1(vethd0c7887) a intrat în starea de blocare
[758002.293063] docker0: portul 1(vethd0c7887) a intrat în starea de redirecționare
[758041.497891] docker0: portul 1(vethd0c7887) a intrat în starea dezactivată
[758041.497997] veth7e3840a: redenumit din eth0
[758041.547558] docker0: portul 1(vethd0c7887) a intrat în starea dezactivată
[758041.551998] dispozitiv vethd0c7887 a lăsat modul promiscuu
[758041.552008] docker0: portul 1(vethd0c7887) a intrat în starea dezactivată
sb9 avatar
drapel cn
sb9
doar o ghicire aleatorie.. dar dacă ați putea verifica și serviciul firewall și să vedeți dacă există erori acolo și să îl dezactivați și să încercați din nou, dacă este necesar. Deoarece m-am confruntat recent cu o problemă similară în rezoluția dns a clusterului kubernetes, pentru care a trebuit să dezactivez complet serviciul firewalld.
drapel vn
@sb9 Am niște jurnale `dmesg` care spun că UFW a blocat unele conexiuni bridge. Am dezactivat complet UFW și am repornit dockerd, dar docker-ul meu a expirat încă:(
sb9 avatar
drapel cn
sb9
ok.. vă rugăm să încercați să verificați cu o imagine dnsutil și să faceți nslookup pentru orice FQDN din interiorul containerului și de la gazdă și vedeți dacă rezultatele arată aceleași. docker run -it tutum/dnsutils nslookup docker run -it tutum/dnsutils dig ai selinux activat pe mașina ta ubuntu. Dacă puteți verifica, dezactiva și reporniți aparatul. Nu sunt sigur dacă asta ar putea cauza probleme.
drapel vn
@sb9 Îmi pare rău pentru răspunsul târziu, am avut ceva stres. Am verificat, selinux este dezactivat pe mașina mea. Am încercat să repornesc, dar nici asta nu a ajutat. Am făcut testele pe care mi le-ați propus, acestea sunt rezultatele mele: https://pastebin.com/u3RTgxww - se pare că funcționează doar pentru un container după o repornire
drapel vn
@sb9 Am căutat puțin și am aflat că, după prima solicitare, rețeaua mea `docker0` își pierde adresa IPv4, prin urmare nu mai poate primi pachete.Am confirmat acest lucru folosind `sudo ifconfig docker0 172.17.0.1`, care rezolvă problema temporar.
Puncte:1
drapel ar

Dacă ai astea în dmesg:

[15300.615904] vecin: arp_cache: tabel vecin depășit!

incearca asta:

sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=30000
sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=20000
sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=10000
drapel vn
Vă mulțumesc, dar nu am găsit astfel de mesaje în `dmesg`
Puncte:0
drapel vn

În cele din urmă, după ce am căutat mult, am găsit problema:

Ale mele docker0 rețeaua își pierdea adresa IPv4 după terminarea primei solicitări și, prin urmare, nu a putut comunica cu restul internetului.

Acest comentariu al problemei pe GitHub a rezolvat în sfârșit problema pentru mine: moby#40217: Ale mele systemd-networkd gestiona docker0 rețea și cumva a fost declanșată verificarea pierderii operatorului, ceea ce a provocat apoi în rețea pentru a elimina IPv4. Marcarea docker0 și br-* rețelele neadministrate au făcut în sfârșit totul să funcționeze corect

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.