Σημείωση. μετάφρ.: Πρόβλημα DNS στο Kubernetes, ή πιο συγκεκριμένα, ρυθμίσεις παραμέτρων ndots, είναι εκπληκτικά δημοφιλής, και ήδη . Σε ένα άλλο σημείωμα σχετικά με αυτό το θέμα, ο συντάκτης του, ένας μηχανικός DevOps από μια μεγάλη χρηματιστηριακή εταιρεία στην Ινδία, μιλάει με πολύ απλό και συνοπτικό τρόπο για το τι είναι χρήσιμο να γνωρίζουν οι συνάδελφοι που λειτουργούν το Kubernetes.
Ένα από τα κύρια οφέλη της ανάπτυξης εφαρμογών στο Kubernetes είναι η απρόσκοπτη ανακάλυψη εφαρμογών. Η αλληλεπίδραση εντός του συμπλέγματος είναι πολύ απλοποιημένη χάρη στην ιδέα της υπηρεσίας (), η οποία είναι μια εικονική IP που υποστηρίζει ένα σύνολο διευθύνσεων IP pod. Για παράδειγμα, εάν η υπηρεσία vanilla επιθυμεί να επικοινωνήσει με την υπηρεσία chocolate, μπορεί να έχει απευθείας πρόσβαση στην εικονική IP για chocolate. Τίθεται το ερώτημα: σε ποιον θα επιλύσει σε αυτήν την περίπτωση το αίτημα DNS chocolate Και πως?
Η ανάλυση ονόματος DNS διαμορφώνεται σε ένα σύμπλεγμα Kubernetes χρησιμοποιώντας . Το Kubelet καταχωρεί ένα pod με CoreDNS ως διακομιστή ονομάτων σε αρχεία /etc/resolv.conf όλα τα λοβό. Αν κοιτάξετε το περιεχόμενο /etc/resolv.conf οποιοδήποτε pod, θα μοιάζει κάπως έτσι:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
Αυτή η διαμόρφωση χρησιμοποιείται από πελάτες DNS για την προώθηση αιτημάτων στον διακομιστή DNS. Στο αρχείο resolv.conf περιέχει τις ακόλουθες πληροφορίες:
- διακομιστής ονομάτων: διακομιστής στον οποίο θα αποστέλλονται αιτήματα DNS. Στην περίπτωσή μας, αυτή είναι η διεύθυνση της υπηρεσίας CoreDNS.
- search: Καθορίζει τη διαδρομή αναζήτησης για έναν συγκεκριμένο τομέα. Είναι ενδιαφέρον ότι
google.comήmrkaran.devδεν είναι FQDN (). Σύμφωνα με την τυπική σύμβαση που ακολουθούν οι περισσότεροι αναλυτές DNS, μόνο εκείνοι που τελειώνουν με μια κουκκίδα «.», που αντιπροσωπεύει τη ζώνη ρίζας, θεωρούνται πλήρως αναγνωρισμένοι τομείς (FDQN). Ορισμένοι επιλύτες μπορούν να προσθέσουν μόνοι τους ένα σημείο. Ετσι,mrkaran.dev.είναι το πλήρως πιστοποιημένο όνομα τομέα (FQDN) καιmrkaran.dev- Οχι; - τελείες: Η πιο ενδιαφέρουσα παράμετρος (αυτό το άρθρο είναι σχετικά).
ndotsκαθορίζει τον αριθμό κατωφλίου των κουκκίδων σε ένα όνομα αιτήματος πριν θεωρηθεί ως όνομα τομέα "πλήρως πιστοποιημένο". Θα μιλήσουμε περισσότερα για αυτό αργότερα όταν αναλύσουμε την ακολουθία αναζήτησης DNS.
Ας δούμε τι γίνεται όταν ρωτάμε mrkaran.dev στο pod:
$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53
Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001
Για αυτό το πείραμα, έθεσα το επίπεδο καταγραφής CoreDNS σε all (πράγμα που το κάνει αρκετά περίπλοκο). Ας δούμε τα κούτσουρα του λοβού coredns:
[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744sΦτου. Δύο πράγματα τραβούν την προσοχή σας εδώ:
- Το αίτημα περνά από όλα τα στάδια της αναζήτησης έως ότου η απάντηση περιέχει τον κωδικό
NOERROR(Οι πελάτες DNS το κατανοούν και το αποθηκεύουν ως αποτέλεσμα).NXDOMAINσημαίνει ότι δεν βρέθηκε καμία εγγραφή για το συγκεκριμένο όνομα τομέα. Επειδή ηmrkaran.devδεν είναι όνομα FQDN (σύμφωνα μεndots=5), ο επιλύτης εξετάζει τη διαδρομή αναζήτησης και καθορίζει τη σειρά των αιτημάτων. - Καταχωρήσεις
АиААААφτάνουν παράλληλα. Το γεγονός είναι ότι τα εφάπαξ αιτήματα εισέρχονται/etc/resolv.confΑπό προεπιλογή, έχουν διαμορφωθεί με τέτοιο τρόπο ώστε να εκτελούνται παράλληλες αναζητήσεις χρησιμοποιώντας τα πρωτόκολλα IPv4 και IPv6. Μπορείτε να ακυρώσετε αυτήν τη συμπεριφορά προσθέτοντας την επιλογήsingle-requestвresolv.conf.
Σημείωση: glibc μπορεί να ρυθμιστεί ώστε να στέλνει αυτές τις αιτήσεις διαδοχικά και musl - όχι, επομένως οι χρήστες του Alpine θα πρέπει να το λαμβάνουν υπόψη.
Πειραματισμός με κουκκίδες
Ας πειραματιστούμε λίγο περισσότερο ndots και ας δούμε πώς συμπεριφέρεται αυτή η παράμετρος. Η ιδέα είναι απλή: ndots καθορίζει εάν ο πελάτης DNS θα αντιμετωπίζει τον τομέα ως απόλυτο ή σχετικό. Για παράδειγμα, στην περίπτωση ενός απλού προγράμματος-πελάτη google DNS, πώς γνωρίζει εάν αυτός ο τομέας είναι απόλυτος; Αν ορίσετε ndots ίσο με 1, ο πελάτης θα πει: "Ω, μέσα google δεν υπάρχει ούτε ένα σημείο. Υποθέτω ότι θα περάσω από ολόκληρη τη λίστα αναζήτησης." Ωστόσο, αν ρωτήσετε google.com, η λίστα των επιθημάτων θα αγνοηθεί εντελώς επειδή το ζητούμενο όνομα πληροί το όριο ndots (υπάρχει τουλάχιστον ένα σημείο).
Ας βεβαιωθούμε για αυτό:
$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53
** server can't find mrkaran: NXDOMAINΑρχεία καταγραφής CoreDNS:
[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s
Επειδή μέσα mrkaran δεν υπάρχει ούτε ένα σημείο, η αναζήτηση πραγματοποιήθηκε σε ολόκληρη τη λίστα των επιθημάτων.
Σημείωση: στην πράξη η μέγιστη τιμή ndots Περιορίζεται σε 15? από προεπιλογή στο Kubernetes είναι 5.
Εφαρμογή στην παραγωγή
Εάν μια εφαρμογή πραγματοποιεί πολλές κλήσεις εξωτερικού δικτύου, το DNS μπορεί να γίνει εμπόδιο στην περίπτωση της ενεργής κίνησης, καθώς η ανάλυση ονόματος κάνει πολλά περιττά ερωτήματα (πριν το σύστημα φτάσει στο σωστό). Οι εφαρμογές συνήθως δεν προσθέτουν μια ριζική ζώνη στα ονόματα τομέα, αλλά αυτό ακούγεται σαν χακάρισμα. Δηλαδή αντί να ρωτήσω api.twitter.com, μπορείτε να κάνετε σκληρό κώδικα api.twitter.com. (με μια τελεία) στην εφαρμογή, η οποία θα ωθήσει τους πελάτες DNS να πραγματοποιήσουν έγκυρες αναζητήσεις απευθείας στον απόλυτο τομέα.
Επιπλέον, ξεκινώντας με τις επεκτάσεις Kubernetes έκδοση 1.14 dnsConfig и dnsPolicy έλαβε σταθερή κατάσταση. Έτσι, κατά την ανάπτυξη ενός pod, μπορείτε να μειώσετε την τιμή ndots, ας πούμε, μέχρι 3 (και ακόμη και μέχρι 1!). Εξαιτίας αυτού, κάθε μήνυμα σε έναν κόμβο θα πρέπει να περιλαμβάνει τον πλήρη τομέα. Αυτό είναι ένας από τους κλασικούς συμβιβασμούς όταν πρέπει να επιλέξετε μεταξύ απόδοσης και φορητότητας. Μου φαίνεται ότι θα πρέπει να ανησυχείτε για αυτό μόνο εάν η εξαιρετικά χαμηλή καθυστέρηση είναι ζωτικής σημασίας για την εφαρμογή σας, καθώς τα αποτελέσματα DNS αποθηκεύονται επίσης εσωτερικά.
παραπομπές
Έμαθα για πρώτη φορά για αυτό το χαρακτηριστικό , που πραγματοποιήθηκε στις 25 Ιανουαρίου. Εκεί συζήτησαν, μεταξύ άλλων, το πρόβλημα αυτό.
Ακολουθούν μερικοί σύνδεσμοι για περαιτέρω εξερεύνηση:
- , γιατί ndots=5 στο Kubernetes;
- πώς η αλλαγή των κουκκίδων επηρεάζει την απόδοση της εφαρμογής.
- μεταξύ των αναλυτών musl και glibc.
Σημείωση: Επέλεξα να μην χρησιμοποιήσω dig σε αυτό το άρθρο. dig προσθέτει αυτόματα μια κουκκίδα (αναγνωριστικό ζώνης ρίζας), καθιστώντας τον τομέα "πλήρως πιστοποιημένο" (FQDN), όχι εκτελώντας το πρώτα στη λίστα αναζήτησης. Έγραψε για αυτό στο . Ωστόσο, είναι αρκετά περίεργο το γεγονός ότι, γενικά, πρέπει να καθοριστεί μια ξεχωριστή σημαία για την τυπική συμπεριφορά.
Καλό DNS! Τα λέμε αργότερα!
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- "Ένας εικονογραφημένος οδηγός για τη δικτύωση στο Kubernetes": , .
Πηγή: www.habr.com