VPN üzerinden Docker Swarm: görevler çalışıyor, servis çağrıları başarısız

İki sitede üç yönetici ve beş çalışan, bir tünelle birbirine bağlı, ve docker service ls her iki tarafta da çalışan görevleri gösterirken servisler arası çağrılar zaman aşımına uğruyor. Swarm günlüklerinde hiçbir şey yanlış görünmüyor. Bu birleşim bir veri düzlemi sorununun imzası: kontrol düzlemi düğümleri buldu ve kapsüllenmiş çerçeveler yolu hiç kat etmedi.

Mesh, overlay'den önce var olmalı

Swarm'ın overlay'i kapsüllenmiş çerçeveleri doğrudan düğüm adresleri arasında iter; yani her düğümün, diğer her düğümün çeviri olmadan ulaşabildiği bir adrese ihtiyacı vardır, tünelin sunduğu arayüzde. Yalnızca istemcileri yayımlanmış bir porta taşıyan tünel yeterli değildir. Alt katman her iki yönde düğümden düğüme yönlendirme yapmalıdır.

Bunu Swarm'a dokunmadan önce test edin. Her düğümden bir eşin tünel adresine giden rotayı kontrol edin, ping atın ve ardından kontrol portunu test edin. Ping çalışıp port çalışmıyorsa tünel sağlamdır ve arada bir filtre vardır.

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

Rota tun0 veya wg0 yerine fiziksel arayüze işaret ediyorsa, overlay uzak sitenin ulaşamayacağı bir adrese kapsüller ve belirti paket kaybı gibi okunur.

Her düğümün hangi adresi duyurduğunu kontrol edin

Daemon tek bir adres duyurur ve eşler bunu veri düzlemi için kullanır. Birden çok ağı olan bir ana bilgisayarda tünel başka bir şey taşırken LAN veya genel adresi duyurmak kolaydır. Varsaymak yerine inceleyin ve varsayılan yanlışsa katılırken --advertise-addr ile sabitleyin. Yalnızca kendisinin ulaşabildiği bir adresi duyuran düğüm yine de swarm'a katılır ve arıza daha sonra siteler arasında konuşamayan servisler olarak ortaya çıkar.

Duyurulan adresi sonradan değiştirmek konfigürasyon düzenlemesi değildir, çünkü düğümün ayrılıp yeniden katılması gerekir.

Duyurulan adresi düğüm başına notlarınıza yazın, çünkü asimetrik arızaların çoğunu açıklar.

Masquerade her zamanki suçludur

Düğümler ile tünel arasında bir geçit oturduğunda, yaygın hata fiziksel arayüzden çıkan her şeye masquerade uygulamaktır. Bu, overlay'in iç adreslerini de yeniden yazar; böylece her eş geçitten geliyormuş gibi görünür ve VXLAN eşleri birbirini tanımayı bırakır. Sonuç, sıradan ping'ler hâlâ çalışırken eksik veya tek yönlü kapsüllenmiş trafiktir.

Overlay önekini geçitten yönlendirin ve çevrilmemiş bırakın. Çeviri gerçekten başka bir önek için gerekiyorsa, onunla sınırlayın ve asla overlay'in kullandığı aralığa uygulamayın.

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

Kuralların sırasını ve metnini birlikte kontrol edin, çünkü zincirde daha önceki geniş bir MASQUERADE daha sonraki dar bir istisnayı yener.

VXLAN pakette yer gerektirir

VXLAN taşıdığı çerçevelere 50 bayt ekler. 1500 baytlık alt katman, 1500 baytlık iç çerçeve taşıdığında hiçbir yolun teslim etmeyeceği kapsüllenmiş bir paket üretir ve arıza boyut sorunu gibi değil, aralıklı servis keşfi gibi görünür. Ya tünelin MTU'sunu iki uçta da düşürün ya da overlay'in MTU'sunu sürücünün sığan bir yük duyurması için ayarlayın.

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

Ingress ağı otomatik olarak oluşturulur, bu yüzden değiştirmek yerinde düzenlemek değil, kaldırıp yeniden oluşturmak anlamına gelir.

Tünelin yalnızca bir tarafını düzeltirseniz, küçük MTU yine de önemli olan olur.

Günlükleri değil, veri düzlemini izleyin

VXLAN portunu iki uçta yakalayın. Bir taraftan çıkıp diğerine ulaşan çerçeveler alt katmanın iyi olduğu ve sorunun overlay içinde olduğu anlamına gelir. Çıkıp hiç ulaşmayan çerçeveler bir rota veya filtre anlamına gelir. Hiç çıkmayan çerçeveler kaynak adresin yanlış olduğu anlamına gelir.

Birkaç saniye sonra kaybolan servis keşfi arızaları genellikle paket bütçesine veya dalgalanan bir yola işaret eder, raft çoğunluğuna değil.

Çalışan bir pencerenin yakalamasını saklayın, çünkü onu bozuk olanla karşılaştırmak konfigürasyonu yeniden okumaktan hızlıdır.