Docker Swarm sa ibabaw ng VPN: tumatakbo ang mga gawain, nabibigo ang mga tawag sa serbisyo

Tatlong manager at limang worker sa dalawang site, pinag-uugnay ng isang tunnel, at ipinapakita ng docker service ls ang mga gawaing tumatakbo sa magkabilang panig habang nag-time out ang mga tawag sa pagitan ng mga serbisyo. Walang mukhang mali sa mga log ng Swarm. Ang kombinasyong iyon ay ang pirma ng problema sa data plane: natagpuan ng control plane ang mga node, at hindi kailanman nagawa ng mga naka-encapsulate na frame ang paglalakbay.

Dapat umiiral ang mesh bago ang overlay

Itinutulak ng overlay ng Swarm ang mga naka-encapsulate na frame nang direkta sa pagitan ng mga address ng node, ibig sabihin kailangan ng bawat node ng address na maaabot ng bawat ibang node nang walang salin, sa interface na ibinibigay ng tunnel. Hindi sapat ang tunnel na nagdadala lamang ng mga client patungo sa isang nai-publish na port. Dapat mag-ruta ang underlay mula node hanggang node sa dalawang direksyon.

Subukan iyon bago hawakan ang Swarm. Mula sa bawat node, suriin ang ruta patungo sa tunnel address ng isang kapareha, i-ping ito, at pagkatapos subukan ang control port. Kung gumagana ang ping at hindi ang port, maayos ang tunnel at may filter sa daan.

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

Kung ang ruta ay tumuturo sa pisikal na interface sa halip na tun0 o wg0, mag-e-encapsulate ang overlay patungo sa address na hindi maaabot ng malayong site, at ang sintomas ay magmumukhang pagkawala ng packet.

Suriin kung anong address ang inaanunsyo ng bawat node

Nag-aanunsyo ang daemon ng isang address, at ginagamit ito ng mga kapareha para sa data plane. Sa host na may maraming network, madaling i-anunsyo ang LAN o pampublikong address habang may ibang dinadala ang tunnel. Suriin ito sa halip na ipagpalagay, at i-pin ito sa pag-join gamit ang --advertise-addr kapag mali ang default. Ang node na nag-aanunsyo ng address na siya lang ang makakaabot ay sumasali pa rin sa swarm, at lumalabas ang kabiguan mamaya bilang mga serbisyong hindi makapag-usap sa pagitan ng mga site.

Ang pagpapalit ng inanunsyong address mamaya ay hindi pag-edit ng config, dahil kailangang umalis at sumali muli ng node.

Itala ang inanunsyong address bawat node sa iyong mga tala, dahil ipinapaliwanag nito ang karamihan ng asymmetric na kabiguan.

Masquerade ang karaniwang salarin

Kapag may gateway sa pagitan ng mga node at ng tunnel, ang karaniwang pagkakamali ay mag-masquerade sa lahat ng lumalabas sa pisikal na interface. Binabago rin nito ang mga panloob na address ng overlay, kaya ang bawat kapareha ay mukhang galing sa gateway at hindi na magkakilala ang mga kapareha ng VXLAN. Ang resulta ay kulang o isang-direksyon na naka-encapsulate na trapiko habang gumagana pa ang ordinaryong ping.

I-ruta ang prefix ng overlay sa gateway at iwanan itong hindi naisalin. Kung talagang kailangan ang salin para sa ibang prefix, limitahan ito doon at hindi kailanman sa saklaw na ginagamit ng 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

Suriin ang pagkakasunod-sunod ng mga patakaran at ang teksto, dahil ang malawak na MASQUERADE na mas maaga sa chain ay nananalo sa makitid na eksepsyon na mas huli.

Kailangan ng VXLAN ang puwang sa packet

Nagdadagdag ang VXLAN ng 50 byte sa mga frame na dinadala nito. Ang underlay na 1500 byte na nagdadala ng panloob na frame na 1500 byte ay gumagawa ng naka-encapsulate na packet na walang ruta ang makakapaghatid, at ang kabiguan ay mukhang pabagu-bagong service discovery sa halip na problema sa laki. Bawasan ang MTU ng tunnel sa dalawang dulo o itakda ang MTU ng overlay upang mag-anunsyo ang driver ng payload na kasya.

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

Awtomatikong nililikha ang ingress network, kaya ang pagbabago nito ay nangangahulugang alisin at likhain muli sa halip na i-edit sa lugar.

Kung isang bahagi lang ng tunnel ang aayusin, ang mas maliit na MTU pa rin ang mahalaga.

Panoorin ang data plane, hindi ang mga log

I-capture ang VXLAN port sa dalawang dulo. Ang mga frame na umaalis sa isang panig at dumarating sa kabila ay nangangahulugang maayos ang underlay at nasa loob ng overlay ang problema. Ang mga frame na umaalis at hindi kailanman dumarating ay nangangahulugang ruta o filter. Ang mga frame na hindi umaalis ay nangangahulugang mali ang source address.

Ang mga kabiguan sa service discovery na nawawala pagkalipas ng ilang segundo ay karaniwang tumuturo sa packet budget o sa paandap-andap na ruta, hindi sa quorum ng raft.

Itago ang capture mula sa gumaganang window, dahil ang paghahambing nito sa sira ay mas mabilis kaysa sa muling pagbasa ng config.