Docker Swarm VPN-ზე: ამოცანები მუშაობს, სერვისების გამოძახებები ვერ ხერხდება

ამოცანები ორივე საიტზე მუშაობს და სერვისებს შორის გამოძახებები დროს ამოწურავს. overlay-ს სჭირდება კვანძიდან კვანძამდე მარშრუტები, აუთარგმნელი მისამართები და 50 ბაიტი ადგილი VXLAN-ისთვის.

სამი მენეჯერი და ხუთი მუშა ორ საიტზე, გვირაბით დაკავშირებული, და docker service ls აჩვენებს ორივე მხარეს მომუშავე ამოცანებს, მაშინ როცა სერვისებს შორის გამოძახებები დროს ამოწურავს. Swarm-ის ჟურნალებში არაფერი არ გამოიყურება არასწორად. ეს კომბინაცია მონაცემთა სიბრტყის პრობლემის ნიშანია: მართვის სიბრტყემ კვანძები იპოვა, ხოლო შეფუთული კადრები გზა ვერასოდეს გაიარეს.

ქსელი overlay-ამდე უნდა არსებობდეს

Swarm-ის overlay შეფუთულ კადრებს პირდაპირ კვანძების მისამართებს შორის უგზავნის, რაც ნიშნავს, რომ თითოეულ კვანძს სჭირდება მისამართი, რომელზეც ყველა სხვა კვანძი თარგმნის გარეშე მივა, იმ ინტერფეისზე, რომელსაც გვირაბი იძლევა. გვირაბი, რომელიც მხოლოდ კლიენტებს გადაჰყავს გამოქვეყნებულ პორტამდე, საკმარისი არ არის. ქვედა ფენამ უნდა დაამარშრუტოს კვანძიდან კვანძამდე ორივე მიმართულებით.

ეს შეამოწმეთ Swarm-ზე შეხებამდე. თითოეული კვანძიდან შეამოწმეთ მარშრუტი პარტნიორის გვირაბის მისამართამდე, გააკეთეთ ping და შემდეგ შეამოწმეთ მართვის პორტი. თუ ping მუშაობს, პორტი კი არა, გვირაბი კარგადაა და გზაზე ფილტრი დგას.

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

თუ მარშრუტი tun0-ის ან wg0-ის ნაცვლად ფიზიკურ ინტერფეისზე მიუთითებს, overlay შეფუთავს ისეთ მისამართზე, რომელზეც შორეული საიტი ვერ მივა, და სიმპტომი პაკეტების დაკარგვას დაემსგავსება.

შეამოწმეთ, რომელ მისამართს აცხადებს თითოეული კვანძი

დემონი ერთ მისამართს აცხადებს და პარტნიორები მას მონაცემთა სიბრტყისთვის იყენებენ. მრავალქსელიან ჰოსტზე ადვილია LAN ან საჯარო მისამართის გამოცხადება, მაშინ როცა გვირაბი სხვა რამეს გადასცემს. შეამოწმეთ იგი დაშვების ნაცვლად და დაამაგრეთ გაწევრიანებისას --advertise-addr-ით, როცა ნაგულისხმევი არასწორია. კვანძი, რომელიც მხოლოდ თავისთვის ხელმისაწვდომ მისამართს აცხადებს, მაინც უერთდება swarm-ს, და ხარვეზი მოგვიანებით საიტებს შორის კომუნიკაციის უუნარო სერვისებად ვლინდება.

გამოცხადებული მისამართის მოგვიანებით შეცვლა კონფიგურაციის რედაქტირება არ არის, რადგან კვანძმა უნდა გავიდეს და ხელახლა შეუერთდეს.

ჩაწერეთ გამოცხადებული მისამართი თითოეული კვანძისთვის თქვენს ჩანაწერებში, რადგან ეს ხსნის ასიმეტრიული ხარვეზების უმეტესობას.

Masquerade ჩვეულებრივი დამნაშავეა

როცა კვანძებსა და გვირაბს შორის კარიბჭე ზის, გავრცელებული შეცდომაა masquerade-ის გამოყენება ყველაფერზე, რაც ფიზიკურ ინტერფეისს ტოვებს. ეს overlay-ის შიდა მისამართებსაც გადაწერს, ამიტომ ყველა პარტნიორი კარიბჭიდან მომავალივით გამოიყურება და VXLAN პარტნიორები ერთმანეთს ვეღარ ცნობენ. შედეგია დაკარგული ან ცალმხრივი შეფუთული ტრაფიკი, მაშინ როცა ჩვეულებრივი ping-ები კვლავ მუშაობს.

დაამარშრუტეთ overlay-ის პრეფიქსი კარიბჭის გავლით და დატოვეთ იგი აუთარგმნელი. თუ თარგმნა ნამდვილად საჭიროა სხვა პრეფიქსისთვის, შეზღუდეთ იქ და არასოდეს — 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

შეამოწმეთ წესების თანმიმდევრობაც და ტექსტიც, რადგან ჯაჭვში უფრო ადრე მდგარი ფართო MASQUERADE იმარჯვებს უფრო გვიან მდგარ ვიწრო გამონაკლისზე.

VXLAN-ს პაკეტში ადგილი სჭირდება

VXLAN თავის კადრებს 50 ბაიტს უმატებს. 1500-ბაიტიანი ქვედა ფენა, რომელიც 1500-ბაიტიან შიდა კადრს გადასცემს, ქმნის შეფუთულ პაკეტს, რომელსაც ვერც ერთი გზა ვერ ჩააბარებს, და ხარვეზი ზომის პრობლემის ნაცვლად წყვეტილ სერვისის აღმოჩენას ჰგავს. ან ორივე ბოლოში შეამცირეთ გვირაბის MTU, ან დააყენეთ overlay-ის MTU ისე, რომ დრაივერმა მოთავსებადი სასარგებლო დატვირთვა გამოაცხადოს.

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

ingress ქსელი ავტომატურად იქმნება, ამიტომ მისი შეცვლა ნიშნავს წაშლას და ხელახლა შექმნას და არა ადგილზე რედაქტირებას.

თუ გვირაბის მხოლოდ ერთ მხარეს შეაკეთებთ, პატარა MTU მაინც ის იქნება, რაც მნიშვნელოვანია.

დააკვირდით მონაცემთა სიბრტყეს და არა ჟურნალებს

დაიჭირეთ VXLAN პორტი ორივე ბოლოში. კადრები, რომლებიც ერთ მხარეს ტოვებს და მეორეზე აღწევს, ნიშნავს, რომ ქვედა ფენა კარგადაა და პრობლემა overlay-ის შიგნითაა. კადრები, რომლებიც გადის და არასოდეს აღწევს, ნიშნავს მარშრუტს ან ფილტრს. კადრები, რომლებიც საერთოდ არ გადის, ნიშნავს, რომ წყაროს მისამართი არასწორია.

რამდენიმე წამში გამქრალი სერვისის აღმოჩენის ხარვეზები ჩვეულებრივ პაკეტების ბიუჯეტზე ან არასტაბილურ გზაზე მიუთითებს და არა raft-ის კვორუმზე.

შეინახეთ ჩაწერა მომუშავე ფანჯრიდან, რადგან მისი დაზიანებულთან შედარება კონფიგურაციის ხელახლა წაკითხვაზე სწრაფია.

დაკავშირებული სტატიები