Docker Swarm μέσω VPN: οι εργασίες εκτελούνται, οι κλήσεις υπηρεσιών αποτυγχάνουν

Τρεις διαχειριστές και πέντε εργάτες σε δύο τοποθεσίες, ενωμένοι με τούνελ, και το docker service ls δείχνει εργασίες να εκτελούνται και στις δύο πλευρές, ενώ οι κλήσεις μεταξύ υπηρεσιών λήγουν. Τίποτα στα αρχεία καταγραφής του Swarm δεν φαίνεται λάθος. Αυτός ο συνδυασμός είναι η υπογραφή προβλήματος στο επίπεδο δεδομένων: το επίπεδο ελέγχου βρήκε τους κόμβους, και τα ενθυλακωμένα πλαίσια δεν έκαναν ποτέ το ταξίδι.

Το πλέγμα πρέπει να υπάρχει πριν από το overlay

Το overlay του Swarm σπρώχνει ενθυλακωμένα πλαίσια απευθείας μεταξύ διευθύνσεων κόμβων, που σημαίνει ότι κάθε κόμβος χρειάζεται μια διεύθυνση που κάθε άλλος κόμβος μπορεί να φτάσει χωρίς μετατροπή, στη διεπαφή που παρέχει το τούνελ. Ένα τούνελ που μεταφέρει μόνο πελάτες σε μια δημοσιευμένη θύρα δεν αρκεί. Το υποκείμενο δίκτυο πρέπει να δρομολογεί από κόμβο σε κόμβο και προς τις δύο κατευθύνσεις.

Δοκιμάστε το πριν αγγίξετε το 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 byte στα πλαίσια που μεταφέρει. Ένα υποκείμενο δίκτυο 1500 byte που μεταφέρει εσωτερικό πλαίσιο 1500 byte παράγει ένα ενθυλακωμένο πακέτο που καμία διαδρομή δεν θα παραδώσει, και η αποτυχία μοιάζει με διακοπτόμενη ανακάλυψη υπηρεσιών και όχι με πρόβλημα μεγέθους. Είτε μειώστε το MTU του τούνελ στα δύο άκρα είτε ορίστε το MTU του overlay ώστε ο οδηγός να διαφημίζει ωφέλιμο φορτίο που χωράει.

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

Το δίκτυο ingress δημιουργείται αυτόματα, οπότε η αλλαγή του σημαίνει αφαίρεση και εκ νέου δημιουργία και όχι επεξεργασία επί τόπου.

Αν διορθώσετε μόνο τη μία πλευρά του τούνελ, το μικρότερο MTU παραμένει αυτό που μετράει.

Παρακολουθήστε το επίπεδο δεδομένων, όχι τα αρχεία καταγραφής

Καταγράψτε τη θύρα VXLAN και στα δύο άκρα. Πλαίσια που φεύγουν από τη μία πλευρά και φτάνουν στην άλλη σημαίνουν ότι το υποκείμενο δίκτυο είναι εντάξει και το πρόβλημα είναι μέσα στο overlay. Πλαίσια που φεύγουν και δεν φτάνουν ποτέ σημαίνουν διαδρομή ή φίλτρο. Πλαίσια που δεν φεύγουν καθόλου σημαίνουν ότι η διεύθυνση προέλευσης είναι λάθος.

Αποτυχίες ανακάλυψης υπηρεσιών που καθαρίζουν μετά από λίγα δευτερόλεπτα συνήθως δείχνουν στον προϋπολογισμό πακέτων ή σε μια διαδρομή που πάλλεται, όχι στην απαρτία του raft.

Κρατήστε τη σύλληψη από ένα παράθυρο που δουλεύει, γιατί η σύγκρισή της με τη χαλασμένη είναι γρηγορότερη από το ξαναδιάβασμα της διαμόρφωσης.