Docker Swarm qua VPN: tác vụ chạy nhưng lời gọi dịch vụ thất bại

Ba quản lý và năm công nhân trên hai site, nối với nhau bằng một đường hầm, và docker service ls cho thấy các tác vụ đang chạy ở cả hai phía trong khi các lời gọi giữa dịch vụ bị quá thời gian. Không có gì trong nhật ký Swarm trông sai. Sự kết hợp đó là dấu hiệu của một vấn đề ở mặt phẳng dữ liệu: mặt phẳng điều khiển đã tìm thấy các node, còn các khung đã đóng gói thì không bao giờ đi hết chặng đường.

Lưới phải tồn tại trước overlay

Overlay của Swarm đẩy các khung đã đóng gói trực tiếp giữa địa chỉ các node, nghĩa là mỗi node cần một địa chỉ mà mọi node khác đều tới được mà không cần dịch, trên giao diện mà đường hầm cung cấp. Một đường hầm chỉ đưa client tới một cổng được công bố là không đủ. Lớp nền phải định tuyến từ node tới node theo cả hai chiều.

Hãy kiểm tra điều đó trước khi chạm vào Swarm. Từ mỗi node, kiểm tra tuyến tới địa chỉ đường hầm của một node bạn, ping nó, rồi kiểm tra cổng điều khiển. Nếu ping chạy mà cổng không, đường hầm vẫn tốt và có một bộ lọc chặn ngang.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

Nếu tuyến trỏ tới giao diện vật lý thay vì tun0 hoặc wg0, overlay sẽ đóng gói tới một địa chỉ mà site xa không tới được, và triệu chứng sẽ giống mất gói.

Kiểm tra xem mỗi node công bố địa chỉ nào

Daemon công bố một địa chỉ, và các node bạn dùng nó cho mặt phẳng dữ liệu. Trên một máy chủ nhiều mạng, rất dễ công bố địa chỉ LAN hoặc địa chỉ công cộng trong khi đường hầm mang thứ khác. Hãy kiểm tra thay vì giả định, và ghim nó khi tham gia bằng --advertise-addr khi giá trị mặc định sai. Một node công bố địa chỉ chỉ mình nó tới được vẫn tham gia swarm, và lỗi hiện ra sau đó dưới dạng các dịch vụ không nói chuyện được giữa các site.

Đổi địa chỉ được công bố về sau không phải là sửa cấu hình, vì node phải rời đi và tham gia lại.

Ghi lại địa chỉ được công bố của từng node vào ghi chú, vì nó giải thích phần lớn các lỗi bất đối xứng.

Masquerade là thủ phạm thường gặp

Khi một cổng nằm giữa các node và đường hầm, lỗi phổ biến là áp masquerade cho mọi thứ rời khỏi giao diện vật lý. Điều đó cũng viết lại các địa chỉ bên trong của overlay, nên mọi node bạn trông như đến từ cổng và các node bạn VXLAN thôi nhận ra nhau. Kết quả là lưu lượng đã đóng gói bị mất hoặc chỉ một chiều trong khi ping thường vẫn chạy.

Định tuyến tiền tố của overlay qua cổng và để nguyên không dịch. Nếu thực sự cần dịch cho một tiền tố khác, hãy giới hạn ở đó và không bao giờ áp cho dải mà overlay dùng.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

Kiểm tra thứ tự các quy tắc cũng như nội dung, vì một MASQUERADE rộng đứng trước trong chuỗi sẽ thắng một ngoại lệ hẹp đứng sau.

VXLAN cần chỗ trong gói

VXLAN thêm 50 byte vào các khung nó mang. Một lớp nền 1500 byte mang một khung bên trong 1500 byte sẽ tạo ra gói đã đóng gói mà không tuyến nào chuyển được, và lỗi trông như khám phá dịch vụ chập chờn chứ không như vấn đề kích thước. Hoặc giảm MTU của đường hầm ở cả hai đầu, hoặc đặt MTU của overlay để trình điều khiển công bố tải trọng vừa vặn.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

Mạng ingress được tạo tự động, nên thay đổi nó nghĩa là xóa và tạo lại chứ không phải sửa tại chỗ.

Nếu chỉ sửa một phía của đường hầm, MTU nhỏ hơn vẫn là cái quyết định.

Hãy nhìn mặt phẳng dữ liệu, không phải nhật ký

Bắt gói ở cổng VXLAN ở cả hai đầu. Các khung rời một phía và tới phía kia nghĩa là lớp nền tốt và vấn đề nằm trong overlay. Các khung rời đi mà không bao giờ tới nghĩa là tuyến hoặc bộ lọc. Các khung không hề rời đi nghĩa là địa chỉ nguồn sai.

Lỗi khám phá dịch vụ tự hết sau vài giây thường chỉ vào hạn mức gói hoặc một tuyến chập chờn, không phải vào túc số raft.

Giữ bản bắt gói từ một khoảng thời gian đang chạy tốt, vì so với bản hỏng nhanh hơn đọc lại cấu hình.