Điểm:1

Hết thời gian chờ mạng Docker khi sử dụng cầu nối

lá cờ vn

Tôi đang chạy trên một máy chủ chuyên dụng âvới phiên bản Ubuntu 20.04.3 LTS (nhân 5.4.0-96-chung) và Docker 20.10.7, bản dựng 20.10.7-0ubuntu5~20.04.2. Hệ thống là một cài đặt mới.

tôi có một Dockerfile cho một trong các dịch vụ của tôi, dịch vụ này kéo một số thư viện vào với đúng cáchđi lấy. Một trong các vùng chứa trung gian luôn không kết nối được với internet do lỗi Hết thời gian chờ DNS hoặc TCP. Một trong các thùng chứa bị lỗi là hoàn toàn ngẫu nhiên.

Cũng lưu ý rằng vấn đề không nằm ở một dịch vụ cụ thể, tôi đã thử xây dựng một dịch vụ hoàn toàn khác chạy trên NodeJS và cài đặt npm thất bại với các lỗi tương tự

Hôm nay tôi cũng gặp sự cố là không thể truy cập vùng chứa Nginx của tôi. Tất cả các kết nối với nó đều dẫn đến lỗi hết thời gian chờ.

Kết nối giữa các vùng chứa bằng mạng docker cũng không hoạt động chính xác.

Đang chạy sudo systemctl khởi động lại docker tạm thời khắc phục sự cố, nhưng nó sẽ xuất hiện lại một hoặc hai bản dựng xuống dòng. Khi tôi xây dựng với chủ nhà mạng thay vì mạng cầu nối mặc định, sự cố đã biến mất, đó là lý do tại sao tôi nghi ngờ cấu hình cầu nối bị lỗi.

Tôi đã thử cài đặt lại Docker, đặt lại cấu hình iptables và cầu nối, đặt các máy chủ DNS khác nhau nhưng không có kết quả. Các tệp nhật ký docker không hiển thị lỗi.

Điều gì có thể là nguyên nhân của vấn đề này?

Cập nhật:

Tôi đã tắt UFW nhưng không thành công. Đây là kết xuất từ ​​nhật ký dmesg của tôi trong quá trình xây dựng đã hết thời gian, có thể điều này giúp xác định nguyên nhân:

[758001.967161] docker0: cổng 1(vethd0c7887) đã vào trạng thái chặn
[758001.967165] docker0: cổng 1 (vethd0c7887) vào trạng thái bị vô hiệu hóa
[758001.967281] thiết bị vethd0c7887 đã vào chế độ hỗn tạp
[758002.000567] IPv6: ADDRCONF(NETDEV_CHANGE): veth7e3840a: liên kết sẵn sàng
[758002.000621] IPv6: ADDRCONF(NETDEV_CHANGE): vethd0c7887: liên kết sẵn sàng
[758002.000644] docker0: cổng 1(vethd0c7887) đã vào trạng thái chặn
[758002.000646] docker0: cổng 1(vethd0c7887) đã vào trạng thái chuyển tiếp
[758002.268554] docker0: cổng 1 (vethd0c7887) vào trạng thái bị vô hiệu hóa
[758002.269581] eth0: đổi tên từ veth7e3840a
[758002.293056] docker0: cổng 1(vethd0c7887) đã vào trạng thái chặn
[758002.293063] docker0: cổng 1(vethd0c7887) đã vào trạng thái chuyển tiếp
[758041.497891] docker0: cổng 1(vethd0c7887) vào trạng thái bị vô hiệu hóa
[758041.497997] veth7e3840a: đổi tên từ eth0
[758041.547558] docker0: cổng 1(vethd0c7887) vào trạng thái bị vô hiệu hóa
[758041.551998] thiết bị vethd0c7887 để chế độ bừa bãi
[758041.552008] docker0: cổng 1 (vethd0c7887) vào trạng thái bị vô hiệu hóa
sb9 avatar
lá cờ cn
sb9
chỉ là một dự đoán ngẫu nhiên .. nhưng nếu bạn cũng có thể kiểm tra dịch vụ tường lửa của mình và xem liệu có bất kỳ lỗi nào trong đó hay không và tắt nó và thử lại nếu cần. Vì gần đây tôi đã gặp phải sự cố tương tự trong độ phân giải dns của cụm kubernetes nên phải tắt hoàn toàn dịch vụ tường lửa.
lá cờ vn
@ sb9 Tôi có một số nhật ký `dmesg` nói rằng UFW đã chặn một số kết nối cầu nối. Tôi đã tắt hoàn toàn UFW và khởi động lại dockerd, nhưng bản dựng docker của tôi vẫn hết thời gian chờ :(
sb9 avatar
lá cờ cn
sb9
ok.. vui lòng thử kiểm tra bằng hình ảnh dnsutil và thực hiện nslookup cho bất kỳ FQDN nào từ bên trong vùng chứa và từ Máy chủ và xem kết quả có hiển thị giống nhau không. docker run -it tutum/dnsutils nslookup docker chạy -it tutum/dnsutils đào bạn đã bật selinux trên máy ubuntu của mình chưa. Nếu bạn có thể kiểm tra, vô hiệu hóa và khởi động lại máy của mình. Không chắc chắn nếu điều đó có thể gây ra bất kỳ vấn đề.
lá cờ vn
@ sb9 xin lỗi vì đã trả lời muộn, tôi có chút căng thẳng. Tôi đã kiểm tra, selinux bị tắt trên máy của tôi. Tôi đã thử khởi động lại, nhưng điều đó cũng không giúp được gì. Tôi đã thực hiện các thử nghiệm mà bạn đề xuất, đây là kết quả của tôi: https://pastebin.com/u3RTgxww - có vẻ như nó chỉ hoạt động với một vùng chứa sau khi khởi động lại
lá cờ vn
@ sb9 Tôi đã tìm hiểu một chút và phát hiện ra rằng sau yêu cầu đầu tiên, mạng `docker0` của tôi bị mất địa chỉ IPv4, do đó không thể nhận thêm bất kỳ gói nào nữa.Tôi đã xác nhận điều này bằng cách sử dụng `sudo ifconfig docker0 172.17.0.1` để khắc phục sự cố tạm thời.
Điểm:1
lá cờ ar

Nếu bạn có những thứ này trong dmesg:

[15300.615904] hàng xóm: arp_cache: tràn bảng hàng xóm!

thử cái này:

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
lá cờ vn
Cảm ơn bạn, nhưng tôi không tìm thấy bất kỳ thư nào như vậy trong `dmesg` của mình
Điểm:0
lá cờ vn

Cuối cùng, sau rất nhiều lần đào bới, tôi đã tìm ra vấn đề:

Của tôi docker0 mạng đã mất địa chỉ IPv4 sau khi yêu cầu đầu tiên kết thúc và do đó không thể giao tiếp với phần còn lại của Internet.

Nhận xét về vấn đề này trên GitHub cuối cùng đã khắc phục sự cố cho tôi: đám đông#40217: Của tôi systemd-mạngd đang quản lý docker0 mạng và bằng cách nào đó, kiểm tra tổn thất mạng đã được kích hoạt, sau đó gây ra nối mạng để loại bỏ IPv4. đánh dấu docker0anh-* các mạng không được quản lý cuối cùng đã khiến mọi thứ hoạt động chính xác

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.