🥇/etc/resolv.conf για Kubernetes pods, επιλογή ndots:5, πώς αυτό μπορεί να επηρεάσει αρνητικά την απόδοση της εφαρμογής

Πρόσφατα κυκλοφορήσαμε το Kubernetes 1.9 σε AWS χρησιμοποιώντας Kops. Χθες, ενώ διοχετεύω ομαλά νέα επισκεψιμότητα στα μεγαλύτερα από τα συμπλέγματά μας Kubernetes, άρχισα να παρατηρώ ασυνήθιστα σφάλματα ανάλυσης ονόματος DNS που καταγράφονται από την εφαρμογή μας.

Υπάρχουν πολλά σχετικά με αυτό στο GitHub μίλησε, οπότε αποφάσισα να το καταλάβω κι εγώ. Στο τέλος, κατάλαβα ότι στην περίπτωσή μας αυτό οφείλεται στο αυξημένο φορτίο kube-dns и dnsmasq. Το πιο ενδιαφέρον και νέο πράγμα για μένα ήταν ο ίδιος ο λόγος για τη σημαντική αύξηση της επισκεψιμότητας αιτημάτων DNS. Η ανάρτησή μου αφορά αυτό και τι να κάνω γι' αυτό.

Η ανάλυση DNS μέσα στο κοντέινερ - όπως σε κάθε σύστημα Linux - καθορίζεται από το αρχείο διαμόρφωσης /etc/resolv.conf. Προεπιλεγμένο Kubernetes dnsPolicy αυτό ClusterFirst, πράγμα που σημαίνει ότι οποιοδήποτε αίτημα DNS θα προωθηθεί στο dnsmasq, τρέχοντας σε λοβό kube-dns μέσα στο σύμπλεγμα, το οποίο με τη σειρά του θα προωθήσει το αίτημα στην εφαρμογή kube-dns, εάν το όνομα τελειώνει με ένα επίθημα συμπλέγματος ή, διαφορετικά, σε διακομιστή DNS υψηλότερου επιπέδου.

αρχείο /etc/resolv.conf μέσα σε κάθε κοντέινερ η προεπιλογή θα μοιάζει με αυτό:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

Όπως μπορείτε να δείτε, υπάρχουν τρεις οδηγίες:

Ο διακομιστής ονομάτων είναι η IP της υπηρεσίας kube-dns
Καθορίστηκαν 4 τομείς τοπικής αναζήτησης search
Υπάρχει μια επιλογή ndots:5

Το ενδιαφέρον μέρος αυτής της διαμόρφωσης είναι ο τρόπος με τον οποίο γίνεται η τοπική αναζήτηση τομέων και ρυθμίσεων ndots:5 συνεννοηθείτε. Για να το καταλάβετε αυτό, πρέπει να κατανοήσετε πώς λειτουργεί η ανάλυση DNS για ονόματα που δεν πληρούν τα κριτήρια.

Τι είναι το πλήρες όνομα;

Ένα πλήρως αναγνωρισμένο όνομα είναι ένα όνομα για το οποίο δεν θα πραγματοποιηθεί τοπική αναζήτηση και το όνομα θα θεωρείται απόλυτο κατά την επίλυση του ονόματος. Κατά σύμβαση, το λογισμικό DNS θεωρεί ότι ένα όνομα είναι πλήρως αναγνωρισμένο εάν τελειώνει με τελεία (.) και δεν είναι πλήρως αναγνωρισμένο διαφορετικά. Αυτό είναι google.com. πλήρως καθορισμένο και google.com - όχι.

Πώς γίνεται ο χειρισμός ενός ακατάλληλου ονόματος;

Όταν μια εφαρμογή συνδέεται στον απομακρυσμένο κεντρικό υπολογιστή που καθορίζεται στο όνομα, η ανάλυση ονόματος DNS συνήθως γίνεται χρησιμοποιώντας μια κλήση συστήματος, π.χ. getaddrinfo(). Αλλά αν το όνομα δεν είναι κατάλληλο (δεν τελειώνει με .), αναρωτιέμαι αν η κλήση συστήματος θα προσπαθήσει να επιλύσει το όνομα ως απόλυτο όνομα πρώτα ή θα περάσει πρώτα από τους τοπικούς τομείς αναζήτησης; Εξαρτάται από την επιλογή ndots.

Από το εγχειρίδιο resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

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

Γιατί έτσι `ndots:5` θα μπορούσε να επηρεάσει αρνητικά την απόδοση της εφαρμογής;

Όπως μπορείτε να φανταστείτε, εάν η εφαρμογή σας χρησιμοποιεί πολλή εξωτερική κίνηση, για κάθε σύνδεση TCP που δημιουργείται (ή ακριβέστερα, για κάθε όνομα που έχει επιλυθεί), θα εκδώσει 5 ερωτήματα DNS πριν επιλυθεί σωστά το όνομα, επειδή πρώτα θα περάσει 4 τοπικό τομέα αναζήτησης, και στο τέλος θα εκδοθεί ένα απόλυτο αίτημα επίλυσης ονόματος.

Το παρακάτω γράφημα δείχνει τη συνολική επισκεψιμότητα στις 3 μονάδες kube-dns μας πριν και αφού αλλάξαμε τα λίγα ονόματα κεντρικών υπολογιστών που διαμορφώθηκαν στην εφαρμογή μας σε πλήρως πιστοποιημένα.

Το παρακάτω διάγραμμα δείχνει τον λανθάνοντα χρόνο εφαρμογής πριν και αφού αλλάξαμε πολλά ονόματα κεντρικών υπολογιστών που έχουν ρυθμιστεί στην εφαρμογή μας σε πλήρη ονόματα (η κατακόρυφη μπλε γραμμή είναι η ανάπτυξη):

Λύση #1 - Χρησιμοποιήστε πλήρως αναγνωρισμένα ονόματα

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

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

Λύση #2 - προσαρμογή `ndots` в `dnsConfig`

Στο Kubernetes 1.9, η λειτουργικότητα εμφανίστηκε σε λειτουργία άλφα (έκδοση beta v1.10), η οποία σας επιτρέπει να ελέγχετε καλύτερα τις παραμέτρους DNS μέσω της ιδιότητας pod στο dnsConfig. Μεταξύ άλλων, σας επιτρέπει να διαμορφώσετε την τιμή ndots για ένα συγκεκριμένο λοβό, π.χ.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

πηγές

Διαβάστε επίσης άλλα άρθρα στο ιστολόγιό μας:

Πηγή: www.habr.com

/etc/resolv.conf για Kubernetes pods, επιλογή ndots:5, πώς αυτό μπορεί να επηρεάσει αρνητικά την απόδοση της εφαρμογής