Docker Swarm Melalui VPN: Task Berjalan, Panggilan Layanan Gagal

Tiga manajer dan lima pekerja di dua situs, dihubungkan oleh terowongan, dan docker service ls memperlihatkan task yang berjalan di kedua sisi sementara panggilan antar layanan timeout. Tidak ada yang tampak salah di log Swarm. Kombinasi itu adalah tanda masalah di bidang data: bidang kendali menemukan node, dan frame yang dienkapsulasi tidak pernah menyelesaikan perjalanan.

Mesh harus ada sebelum overlay

Overlay Swarm mendorong frame terenkapsulasi langsung di antara alamat node, yang berarti setiap node membutuhkan alamat yang dapat dijangkau setiap node lain tanpa terjemahan, pada antarmuka yang disediakan terowongan. Terowongan yang hanya mengangkut klien ke port yang dipublikasikan tidak cukup. Lapisan bawah harus merutekan dari node ke node di kedua arah.

Uji itu sebelum menyentuh Swarm. Dari setiap node, periksa rute ke alamat terowongan rekan, ping alamat itu, lalu uji port kendali. Jika ping berhasil dan port tidak, terowongan baik-baik saja dan ada filter di jalur.

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

Jika rute menunjuk ke antarmuka fisik alih-alih tun0 atau wg0, overlay akan mengenkapsulasi ke alamat yang tidak dapat dijangkau situs jauh, dan gejalanya akan terbaca seperti kehilangan paket.

Periksa alamat yang diiklankan setiap node

Daemon mengiklankan satu alamat, dan rekan menggunakannya untuk bidang data. Pada host dengan banyak jaringan, mudah mengiklankan alamat LAN atau publik sementara terowongan membawa hal lain. Periksa alamat itu alih-alih mengasumsikannya, dan patokannya saat bergabung dengan --advertise-addr bila nilai bawaannya salah. Node yang mengiklankan alamat yang hanya bisa dijangkau dirinya sendiri tetap bergabung ke swarm, dan kegagalannya muncul kemudian sebagai layanan yang tidak dapat berkomunikasi antar situs.

Mengubah alamat yang diiklankan nanti bukanlah penyuntingan konfigurasi, karena node harus keluar dan bergabung lagi.

Catat alamat yang diiklankan per node dalam catatan Anda, karena itu menjelaskan sebagian besar kegagalan asimetris.

Masquerade adalah tersangka biasa

Saat gateway berada di antara node dan terowongan, kesalahan umum adalah menerapkan masquerade pada semua yang keluar dari antarmuka fisik. Itu juga menulis ulang alamat dalam overlay, sehingga setiap rekan tampak datang dari gateway dan rekan VXLAN berhenti saling mengenali. Hasilnya adalah lalu lintas terenkapsulasi yang hilang atau satu arah sementara ping biasa masih berfungsi.

Rutekan prefiks overlay melalui gateway dan biarkan tanpa terjemahan. Jika terjemahan benar-benar diperlukan untuk prefiks lain, batasi di sana dan jangan pernah ke rentang yang dipakai overlay.

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

Periksa urutan aturan sekaligus teksnya, karena MASQUERADE yang luas lebih awal dalam rantai mengalahkan pengecualian sempit yang belakangan.

VXLAN membutuhkan ruang di dalam paket

VXLAN menambahkan 50 byte pada frame yang diangkutnya. Lapisan bawah 1500 byte yang mengangkut frame dalam 1500 byte menghasilkan paket terenkapsulasi yang tidak akan diantarkan jalur mana pun, dan kegagalannya tampak seperti penemuan layanan yang terputus-putus, bukan masalah ukuran. Turunkan MTU terowongan di kedua ujung atau setel MTU overlay agar pengemudi mengiklankan muatan yang muat.

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

Jaringan ingress dibuat secara otomatis, jadi mengubahnya berarti menghapus dan membuatnya ulang, bukan menyuntingnya di tempat.

Jika Anda hanya memperbaiki satu sisi terowongan, MTU yang lebih kecil tetap yang menentukan.

Pantau bidang data, bukan log

Tangkap port VXLAN di kedua ujung. Frame yang keluar dari satu sisi dan tiba di sisi lain berarti lapisan bawah baik dan masalahnya di dalam overlay. Frame yang keluar dan tidak pernah tiba berarti rute atau filter. Frame yang tidak keluar sama sekali berarti alamat sumber salah.

Kegagalan penemuan layanan yang hilang setelah beberapa detik biasanya menunjuk ke anggaran paket atau jalur yang berkedip, bukan ke kuorum raft.

Simpan tangkapan dari jendela yang berfungsi, karena membandingkannya dengan yang rusak lebih cepat daripada membaca ulang konfigurasi.